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.
This is the second post in my little project of self publishing my PhD Thesis. Last week I introduced an econometric analysis of the impact of Information Technology (IT) firm size. This time it is a more theoretical paper that presents a model for examining the impact of different types of IT on the structure of organizations. In particular, it compares having no IT, with centralized IT (think mainframes) and networked IT (think Internet and Intranet).
I was particularly happy with how this paper came out because it addresses a fundamental problem in economics: the organization of economic activity in firms versus markets. In re-reading the paper I found that I don’t actually bring this point out very well at all because I focused the paper too much on different organizational forms (inside of firms). So I will try to do a better job in this little recap / introduction.
Ever since Coase published his seminal essay on The Nature of the Firm, there has been a long running inquiry into a fundamental question of economics: why are some activities carried out in the market and others inside of firms? Coase and subsequent writers focused on the idea of differing transaction costs, but the precise mechanism by which transaction costs would be different in a market versus inside firms were hard to pin down. That changed with the work on principal agent problems and incentives. Tons of different economists contributed to this. I was fortunate to have one of them, Bengt Holmström, as one of my thesis advisors.
One of the key insights coming out of Bengt’s and others’ work is that firms exist to reduce incentives. Why would you want to reduce incentives? In order to get better coordination. If you pay people a flat wage then you can direct what problems you want them to work on and how you want them to work together on those problems. In fact, much of what companies do in HR and compensation, such as reviews, goals, options, bonuses, etc. is aimed at restoring some additional motivation in the face of much reduced incentives. Effectively you can think of this issue as a coordination - initiative tradeoff frontier. You can get more coordination inside of a firm than in the market by reducing individual initiative.
What my paper does is explore the shape of the coordination - initiative frontier based on different types of information technology. I distinguish between three different scenarios: no IT, centralized IT and networked IT. I examine how these three different scenarios would play themselves out in the absence of incentive problems, i.e. when everybody does the “right” thing to maximize joint production. That analysis provides a baseline for looking at the incentive case. In the incentive case people look to their own benefit first and thus exert less effort if their incentives are muted.
The key findings are summarize in the following diagram
The diagram shows the location and shape of the coordination - initiative frontier. The first key finding is that having information is a good thing as the frontier for both IT cases dominates the one without IT. The second key finding is that that networked IT dominates central IT case: it is possible to achieve full coordination at a much higher initiative level than with centralized IT.
In the paper I interpret this result along different organizational forms inside the firm. But it would be just as correct (and looking back at it more relevant) to classify this as the historical change that we have experienced from mostly individuals in the market (agriculture, crafts, trading), to having large hierarchical firms (industrial society), to replacing those hierarchies with networks (now). That of course is a very nice fit with what I and others have been arguing in the Peer Progressive agenda.
I started out in business selling development services. OK, so that’s hugely glorified. I was a teenager desperate to get my driver’s license in Germany where that is a costly process (lots of mandatory lessons). So I figured out how to make money programming custom applications for people, including a driving school. Ever since then I have had a love/hate relationship with sales.
The hate portion is easy to understand for any engineer. The things you have to do in selling run counter to a lot of things you care about as an engineer. For instance, you need to spend a lot of time explaining stuff to people that should be, well, obvious. And most importantly, time spent selling is not time spent creating. The same reasons for hating sales seem to apply to product and design folks.
But I also love sales and not just because it helped pay for my driver’s license. People paying for your product is what enables you to grow your business without giving up (more) equity. And selling is what provides critical feedback about what you should build, making your product better. If you have the right kind of product or service (one with network effects), then selling has the additional benefit of making the product/service better for everyone. Finally, selling is about educating users who otherwise wouldn’t know how or why to use the product or service.
Unfortunately, I see all too many product and/or engineering led organizations that are in thrall to their hate or disdain or at a minimum personal dislike for sales (and by extension sales people). That’s highly unfortunate because it dramatically reduces the overall chances of success for these organizations. And one of the grand ironies is that many of these organizations think that they are in some way emulating Google, which has somehow managed to create a myth that Google got big without sales (nothing could be further from the truth). A similar myth seems to be in the making about Facebook.
Incidentally, I don’t mean sales here just as in having sales people. I also mean selling as in convincing endusers explicitly of the value of a product (ok, so technically that’s marketing but it has many of the same aspects). I haven’t figured out yet how to help people to learn to love sales. But maybe a starting point will be to point at how important selling has been to the success of companies such as Google. And of course selling has been critical to the company currently so beloved by many engineers, designers and product folks alike: Apple.
I have had the privilege of observing a number of founders grow their companies from just a few people to over a hundred employees. Leaving all the other growth challenges aside, I have come to conclude that personal scaling is the most important issue. By personal scaling I mean figuring out how to go from mostly doing to mostly managing. There are many aspects to this transition but the central one would seem to be trust.
A map at 1:1 scale isn’t useful. And as I discovered yesterday during some research for my Skillshare class next week, Leibniz in 1686 expressed something similar about science, essentially saying that a theory has to be simpler than the data it explains. The same goes for delegation. Delegation is worthless if you redo every bit of work that comes back. So you can only delegate effectively if you trust the people you are delegating to. That’s one sense in which trust is key to personal scaling.
But trust is needed in the other direction as well. The people you delegate to have to trust you. They have to trust that they won’t be second guessed at every turn. That their work will be recognized and valued. Without that trust it is difficult if not impossible to sustain motivation. And without motivation delegation will not produce results.
Just to be clear, trust doesn’t substitute for processes such as goal setting and reporting. Trust is what makes those processes efficient and meaningful as opposed to going through the motions. And time and again it is clear that the pattern set at the top is replicated throughout an organization.
Many of the high growth companies in our portfolio have run into scaling issues. There is a lot of information out there on various technical approaches to scaling. What most of those leave out is the interaction between the choice of architecture and organizational scaling. Some architectures lend themselves much better to organizational scaling than others. A horizontal approach with a Data Access Layer, a Business Logic Layer, and a Presentation Layer suffers from a lot of organizational coordination overhead. To implement new functionality the various horizontal teams need to coordinate so that anything can get done.
I am therefore a big fan of a services based architecture, which takes more of a vertical approach to dividing up systems. For instance, most web sites and services have a concept of a user profile. In a services based architecture everything having to do with user profiles might be encapsulated in one service (create a profile, retrieve a profile, etc). Organizationally it now becomes possible to have a team that’s in charge of the profile service. That team can make changes to the service implementation as long as the changes don’t break the service API. In fact, the team can even enhance the functionality of the service by adding new methods to the API. This allows for much better organizational scaling as innovation no longer requires nearly as much coordination. In addition to innovation by each service team, it’s also possible to innovate by combining the existing services in novel ways to deliver end user functionality.