… to come to the aid of their country. Here is a supremely depressing chart from Businessweek showing the professional backgrounds of the members of Congress The largest groups in both the House and the Senate are lawyers (yellow) followed by business people (green). On the other extreme there is 1 lone engineer in the Senate and even worse only 2 engineers in the House. There are no scientists in the Senate and 2 in the House. This is a huge problem at a time when many of the issues we confr...

I already hinted at this topic in my last Tech Tuesday, when I wrote about having a healthy mix of young and more experienced engineers. More generally, diversity in engineering teams (and teams more generally) tends to be a healthy thing. Diversity helps prevent group think and provides for a better match with the wide variety of tasks that come up in the live of a startup engineering team. In the extreme if all you have are say realtime systems engineers your UI/UX is likely to be atrocious...

I have written before on Tech Tuesday on how to grow engineering teams but wanted to tackle this issue again from a slightly different perspective: what is the role of experience? Startup engineering teams often start out skewing very young as young founders tend to hire more young people. The overall bias tends to be to hire “bright young people who will figure it out” (whatever the relevant it may be). Many companies will go so far as having what they consider tests for brightness. The prob...

I have written about prioritization previously on Tech Tuesday, introducing a prioritization heuristic and emphasizing the importance of a healthy mix of different projects. Today I want to add some point on how to think about competition in the context of prioritization. This is particularly important when you are in a somewhat crowded field and need to differentiate yourself from the competition. What features should you prioritize when competing? Go back and take a look at the post on the ...

Several of the past Tech Tuesdays have been about topics that often get short shrift in startups, including security, backup and disaster recovery planning. Today I want to write about another topic in that annoying-but-needs-some-attention category: documentation. One of my very first experiences in commercial software development had me working as a 17-year old in a small software company in my hometown in Germany. The project they dumped into my lap was to port an accounting system from an...

Last Tech Tuesday I wrote about the importance of having backups and testing whether you can restore from them. While this sounds like something everyone should or would do it is all too easy with the many things a startup has to do to forget about them. Backup is part of the larger disaster recovery planning process. Again not something most startups spend much or any time thinking about. And in the spirit of staying lean I would suggest you don’t worry much about it until you are adding cus...

For startups, backup is a lot like security, something you need to have but not something that’s really visible to endusers or that endusers even care about unless of course things go terribly wrong! So in today’s Tech Tuesday I want to talk a bit about backup and will follow up with a broader disaster recovery post. It used to be not uncommon to encounter super early stage companies that quite literally have no backup strategy whatsoever. It simply didn’t make the cut with everything else th...

Last Tech Tuesday, I wrote about a heuristic for prioritization. If you took that approach to its extreme you would always work on only the lowest hanging fruit (at the time). That would of course be an over simplification for several reasons. First, for any but the most trivial projects there will be a list of known bugs of varying severity that have to be fixed. Second, as I mentioned in an earlier post on technical debt, you will have to allocate some time to getting rid of it. Third, cert...

Last Tech Tuesday I wrote that the companies which do well on hiring engineers are the ones that “prioritize both hiring *and* having a great work environment.” The post went on to talk about some of the best practices in hiring. Today’s follow-up is about creating a great work environment for engineers. There is obviously a lot that goes into creating a great work environment including overall company culture, office space, company mission etc. Instead of those more general points, here are ...

The last two posts on Tech Tuesday were both about growing your engineering organization. Someone wrote to me saying: it’s all well to talk about best practices for organizational design, but we can’t find enough qualified engineers in the first place! So today a post about hiring. I have been able to observe many companies over the years and even in the toughest markets some have a steady flow of high quality candidates and others always seem to struggle. The main distinction between the two...