There is a brilliant article here written by Yammer’s VP of Engineering Kris Gale. The article is covers a talk that he did at Hack+Startup on why the traditional engineering organisation structure is dead.
The truth is that in many ways he is absolutely right. The rise of Agile, Lean, DevOps and Continuous Delivery all show that the landscape has moved wildly within the last few years and the structure of engineering organisations needs to adapt to this.
Kris points to a new engineering organisation which follows the following rules:
- Small teams (2 to 10 people) doing small projects (2 to 10 projects)
- All projects have a definite end date
- Team members only assigned to one project at a time
- Prevent specialisation
- No code ownership
- Bug fixing is done by everyone
In his talk that went along with the article, he mentioned that he was deliberately contrarian and wanted to make people think and he’s succeeded and I agree with almost everything he says. Traditional engineering organisations need to follow this approach when it is right. The issue is that it is not always right.
This approach works brilliantly for small scope projects or for green field development with few integration points. The reality (and of course I am bound by my own experience here) is that that many projects can be done in this manner. Kris goes on to mention a fundamental point in how you want to operate your engineering org in Amdahl’s law – work can only be sped up to the inverse fraction that cannot be parallelised. In other words, in a project where a quarter must be done in a serial manner then no matter how many people you throw at it you will never be able to do better than 4x speed-up. The obviously corollary here is that as an organisation you want smaller projects to work on since it immediately allows you to be more efficient and get more bang for your buck. I mean, what CTO would not want this?
In fact the suggested approach should be considered as best practise for these types of project. But what happens when you have a larger project? A typical response would be to artificially break down the large project into a series of small ones. Sometimes this works but it is naive to state that this can be done for all projects. If large project can be broken down into smaller units like features or you are able to replace chucks of functionality that are naturally grouped like web pages then it is obviously tractable but there are many projects that cannot work like this. You want to merge two banking systems in this manner then good luck to you.
Now obviously not all projects are of this size or complexity but what about simpler projects but in a larger organization. Well I’ve seen exactly this where smaller teams were given autonomy within a larger organisation and the technology proliferation was incredible. There were multiple languages and multiple approaches with multiple datastores and caches with varying support needs and varying logging and operation monitoring requirements. The overhead for this was incredible. Training, support, operational monitoring, development time and licensing costs where all greater than they should have been since people were duplicating each other’s work or needing. Interestingly though, those areas where this did not happen were those where there was sufficient oversight from technologists that understood the entire business.
In a small organisation everyone can understand the entire business and you are able to have total autonomy but once you get passed a certain size the only way you can hold the entire mental model of the technology of the business in your head is to get people to step away from the code and to think about what can be safely reused or repeated. As someone with a background in software architecture I may be a little biased but empirically rationalising your efforts is the key. How much you need to do this controls the depth and shape of your engineering organisation. If you are a lean start up, then your engineering organising should be as flat as possible but if you have multiple products developed across multiple locations around the world you almost certainly need a CTO with Directors of Development underneath them and possibly Heads underneath them before you even get to the team leads – you know, the classic engineering organisation for a large enterprise.
What he is really talking about is empowering developers to make decisions that genuinely affect your product and having leaders that know how to do this. Many of your projects are amenable to this approach and it should be followed within the opinionated frameworks that matches the size of your company. This of course means that you should be hiring delivery teams that you trust to do this and that is probably the biggest take home message from Kris’s excellent talk.