New Date Announced for NY Tech Mixer Meetup

If you're interested in the NYC start-up scene - and these days who isn't? - then you have to come to the next Demos and Drinks on January 18. At Demos and Drinks a handful of start-ups get to demo and everyone drinks and socializes. The crowd is a mix of techies, designers, biz folks, and investors. It's organized by the NY Tech Mixer Meetup which has over 1500 members and regularly attracts 300+ people per event. Check the event page for more details. Sign-up now before it sells out. It's going to be a great event and it's going to be monthly from now on.

O'Reilly Strata Conference on Big Data

I'm really honored to have been chosen to be part of the O'Reilly Strata Conference, coming up in February in Santa Clara. It is a new conference that focuses on the business and practice of data.

All industries are experiencing an explosion of data volumes. But most companies are finding it hard to keep up and make use of all the data that they generate or have access to. This is creating great opportunities for those who understand how to effectively collect and use large quantities of data.

I will be part of the Real World Applications Panel: Enterprise and Industry. My focus will be the legal industry, where I work now, and there will be two other panelists from the music and meteorological industries.

It is going to be a great event. Drop me a line if you are going to be there.

About Us is the most important

I was looking at the web stats of a company website the other day. The company is relatively small and provides services to businesses. And the thing that struck me right away is that the most popular pages were the About Us pages.

This made me realize that when I look at other company websites, I instinctively go straight to the About Us pages instead of the products and services pages. If I'm on their website, it's more than likely that I already know what they do. And if I don't, then all I need is a quick scan of the homepage. I'm really much more interested in seeing the management team, the board of directors, the investors, and maybe some history in order to understand the company. Only after I get a sense of who's involved do I consider actually reading about their services or products. I have a feeling that this is becoming the norm.

HCIR 2010

I attended the HCIR 2010 workshop last Sunday on “Bridging Human-Computer Interaction and Information Retrieval”. Dan Russell from Google gave the keynote. This is a guy who is passionate about what he does, and it seems that his job is to study how people search, including how they think about searching, how they conduct searches, how they use search interfaces, etc. and to figure out how they could do it better.

One of the biggest problems that exists, he believes, is that there is no training or education for search. The overwhelming majority of people just do not know how to search well. For instance, he found that most people don't know that you can use control-F on almost every program in order to find a word or phrase. This is something that most techie people take for granted when they are looking for something. For certain searches, you look at the results in Google, you pop open one of the results that looks promising, and then you control-F to find your keyword on the page and see if it is what you're looking for. The step of using control-F obviously speeds things up greatly. According to Dan this is something that most people just don't know about. I was skeptical and so I mentioned it to someone I know who is a professional (college educated, works in an office, etc.) and he knew that you could do that in Excel but didn't realize that it worked in all programs. I was sort of astounded by this, which was something that Dan had mentioned happens to him all the time. So for search instead of making the results somehow better, there may be a lot more value in training the user and providing tips or heuristics to help the user while they are searching.

Hiring - finding out what you're really looking for

I've spoken to a few people recently about hiring. They were in an initial stage where they've said to me that they needed to find someone for a tech position. And in each case when I've asked for detail about the profile needed, it turned out that the person was not that clear on what they exactly needed. Everyone who has done hiring has been in this situation. You know you need someone and think you know what you need, but as soon as you start looking, you start to realize that you're really not sure.

Obviously it would be best to know before you start talking to candidates. For many hiring managers, though, it seems that they start by browsing ads posted by other companies to make a profile. And then the process of interviewing people is the way that they figure out what they are actually looking for.

One easy and obvious way to get a handle on this is to do the job yourself for a little while. Of course this depends on the job and company, but if you can, you'll clearly get the best sense of what's needed. This of course happens naturally in small, growing companies, but isn't always an option.

Another thing to do is focus on creating a good practical test for the job. For technical positions this is a necessity. And I believe that the best practical test simulates real work as opposed to theoretical problems or logic puzzles. So when you put together the test for what the candidate needs to know, you should be reviewing real work problems and tasks.

These are two things that have worked well for me. I also try to keep in mind that when you don't really know what you're looking for, not only can you make negative impressions on candidates, but - worst of all - you may not realize it when you find the right person.

Least amount of process principle

The least amount of process needed to do something is the right amount of process. For me this is a management principle that is akin to Occam's razor in science, where the simplest explanation is the correct one. As obvious or simple as this principle may be, it is violated all the time.

My main concern is with software development, but this principle is more universal for management, especially of creative work. The reason why this principle works is that all processes are carried out by a unique set of people who are all unique in their skills, personalities, and characters. As such, too much process will stifle the group and not allow the individuals to emerge and achieve.

This also means that you will encounter real difficulties when you take a defined process and try to implement it, because a defined process relies on roles that people have to play. You may get a group to enact a defined process, everyone playing their roles, but with time the process and roles will evolve based on the individuals. Of course this customization of the process is a good thing if you understand what's happening, and don't try to force things back to the defined process.

Kanban vs Scrum

I recently came across a great free book written by Henrik Kniberg and Mattias Skarin called, "Kanban and Scrum - making the most of both". It includes the most concise description of each development process that I've seen.

For Scrum, your overall concern is with timeboxing everything, making sure that there are short cycles and short meetings that are strictly adhered to. With Kanban, your main concern is with limiting the amount of work in progress. By limiting how many items are in each phase of development, your aim is to establish an on-going flow. It seems to me that Scrum is better geared for new product development and Kanban is better for existing products that need maintenance and new features. There is obviously much more to each and I recommend you read their book.

Business Value is Always the Goal

When you are creating software for a business, the creation of business value is always the goal. In general there are only two ways that business value is created. Either you are saving money because you make a process more efficient or you create new revenue with a new process, product, or feature.


As the goal of software development, it means that we are not even considering the qualities of systems that software developers are generally concerned with. So it makes absolutely no sense to create a system that is really easy to maintain if that increases the cost of the system so that it doesn't provide business value. These qualities have to be understood as constraints and they are understood in terms of trade-offs. If you are absolute about them, then you will have a hard time creating a successful system. This seems completely reasonable and obvious, but it happens all the time. Always remember: the cost of the system has to be less than the business value created.