Last Tech Tuesday I wrote about evolving your technology as you grow. As, if not more important, is how you grow your engineering organization. They after all are the ones who need to make the right choices about the technology! Here I have observed three common mistakes: staying flat too long, not investing early on in devops and missing the co-founder to manager transition (if such a transition turns out to be necessary).

Most startups begin with just a couple of engineers who tend to be enormously productive. Productivity continues to be great as you add early hires (assuming you are hiring well – more on that in a separate post). As you approach ten engineers the incremental productivity of new hires tends to degrade very rapidly. Why? Because a completely flat structure doesn’t scale. The instinct is almost always that people don’t want to create hierarchy so early on and that’s a good instinct. But you have to form teams. Teams that have team leaders and that work on clearly identified areas. Remember how productive you were when you got going? Forming teams of 3-4 engineers, one of whom is the lead will retain that. I will expand in a future post on why that is and how to make those teams work best.

For years now I have heard the same comment when asking about plans for Ops or Devops hires. It used to be “oh we are on managed hosting – they’ll take care of it” and then it became “we run on a cloud provider” or more recently “we are on platform as a service.” All of those have been great innovations for startups but they don’t eliminate the need for Ops. They take care of what people used to think of as system administrators quite nicely and you won’t need someone just to get your favorite OS to run on a particular machine but that is just some tiny aspect of actual operations. What are your build and test systems? Do you have a staging environment? Are you secure? Are you backing up and have you tested that? Are your systems properly instrumented for tracking bugs, performance, usage, etc? And the list goes on. Once you fall behind badly on any of these you will be fighting an uphill battle for a long time. So as soon as what you have built shows meaningful growth in usage you should invest in Devops. If you get to 10 engineers and don’t have someone who has this as their primary focus you are likely already behind.

Finally, technical co-founders sometimes hang on too long in running the engineering organization. I am a big believer in helping people grow on the job and just like our approach at USV is to help founders stay as CEOs of their companies we do the same on the engineering side. But here too, sometimes it works and sometimes it doesn’t. It’s hard to fathom when you get going just how different your job will be when you have twenty plus engineers from what it was when there were two or three of you. What you spend your time on and what you need to be good at will be radically different. Some technical co-founder turn out to be great at making that shift (either because they have done it before or because they pick it up quickly *and* enjoy it) – others don’t. When they don’t it often turns out to be a particularly rough and emotional transition. After all, it is often still a co-founder in the CEO spot who has to make that call.

So to phrase these in the positive, here are three critical things to growing your engineering organization at the early stage: Introduce a team structure early on, don’t forget about DevOps and make sure you either grow as a manager or transition to an experienced manager.

Last Tech Tuesday I wrote about evolving your technology as you grow. As, if not more important, is how you grow your engineering organization. They after all are the ones who need to make the right choices about the technology! Here I have observed three common mistakes: staying flat too long, not investing early on in devops and missing the co-founder to manager transition (if such a transition turns out to be necessary).

Most startups begin with just a couple of engineers who tend to be enormously productive. Productivity continues to be great as you add early hires (assuming you are hiring well – more on that in a separate post). As you approach ten engineers the incremental productivity of new hires tends to degrade very rapidly. Why? Because a completely flat structure doesn’t scale. The instinct is almost always that people don’t want to create hierarchy so early on and that’s a good instinct. But you have to form teams. Teams that have team leaders and that work on clearly identified areas. Remember how productive you were when you got going? Forming teams of 3-4 engineers, one of whom is the lead will retain that. I will expand in a future post on why that is and how to make those teams work best.

For years now I have heard the same comment when asking about plans for Ops or Devops hires. It used to be “oh we are on managed hosting – they’ll take care of it” and then it became “we run on a cloud provider” or more recently “we are on platform as a service.” All of those have been great innovations for startups but they don’t eliminate the need for Ops. They take care of what people used to think of as system administrators quite nicely and you won’t need someone just to get your favorite OS to run on a particular machine but that is just some tiny aspect of actual operations. What are your build and test systems? Do you have a staging environment? Are you secure? Are you backing up and have you tested that? Are your systems properly instrumented for tracking bugs, performance, usage, etc? And the list goes on. Once you fall behind badly on any of these you will be fighting an uphill battle for a long time. So as soon as what you have built shows meaningful growth in usage you should invest in Devops. If you get to 10 engineers and don’t have someone who has this as their primary focus you are likely already behind.

Finally, technical co-founders sometimes hang on too long in running the engineering organization. I am a big believer in helping people grow on the job and just like our approach at USV is to help founders stay as CEOs of their companies we do the same on the engineering side. But here too, sometimes it works and sometimes it doesn’t. It’s hard to fathom when you get going just how different your job will be when you have twenty plus engineers from what it was when there were two or three of you. What you spend your time on and what you need to be good at will be radically different. Some technical co-founder turn out to be great at making that shift (either because they have done it before or because they pick it up quickly *and* enjoy it) – others don’t. When they don’t it often turns out to be a particularly rough and emotional transition. After all, it is often still a co-founder in the CEO spot who has to make that call.

So to phrase these in the positive, here are three critical things to growing your engineering organization at the early stage: Introduce a team structure early on, don’t forget about DevOps and make sure you either grow as a manager or transition to an experienced manager.