Tim Leslie of Sumdog has some excellent advice for organising your development team to reduce friction and focus on delivering your project goals.
The importance of Global Goals
You’ve got an investment and you’ve recruited a bunch of talented new developers. What now? Organising your development team.
You need a team that is as responsive and adaptable as your business. You don’t want to introduce heavy bureaucracies and processes, but once your team gets to a certain size you can’t just put them in the same room and expect it to work without some thought.
We nearly doubled the size of our development team last year. We made a few mistakes along the way, but we’re now in a very good place with a highly motivated and productive team that is improving all the time. This is one of the lessons that we learned along the way.
Your organisation’s structure is important
People, structure and culture. Get these three right and you’re going to be flying. Of these, people are the most important. Get great people, trust them and, sooner or later, the right structure and culture will emerge. We got this right and ultimately it’s why we’re in the position we’re in. However, it is structure I want to talk about, partly because the company’s structure goes a long way to defining its culture. The wrong structure can really hold you back.
When we talk about company structure most people tend to think in terms of management hierarchy, however, choosing between a flat or deep hierarchy is not the most important consideration. The secrets of a successful structure are more subtle, thought provoking and sometimes counter-intuitive. The groundbreaking insight lies in the Theory of Constraints (recommended reading: “The Goal” by Eliyahu Goldratt).
It is very easy to organise your teams around job titles – putting developers in one group, testers in another, product designers in a third, etc. This can be devastating because these teams all have local goals. We want the structure to reflect our global goal as closely as possible. If you treat this as a guiding principle, you’ll find all sorts of goodness starts happening.
Illustration by example
We have always employed dedicated test engineers at Sumdog. For a long time we had developers working in one department and testers in another. Our developers would submit a feature to the test team who would document the defects and return it to the developers.
As might be expected, the test team’s workload was spiky. Sometimes several developers would deliver their work at the same time. Some features also required more testing than others. This meant that sometimes the test engineers were very quiet, whereas at other times they were completely swamped and had a huge backlog.
As managers, we want predictability and accountability from our team. It makes sense to ask your team when a feature is going to be released. At the level of the developer however, this was an unfair question because of the unpredictability of test. The organisational structure forced us to ask the developers when the feature was going to be ready for test instead. So, we started building milestones and interim deadlines around this and daily test prioritization became a chore for managers. In other words the structure was forcing us to align our developers to the local goal of getting code ready for test, rather than the (more) global goal of delivering the feature.
It retrospect, this had a huge impact. Last summer we changed the structure, putting the test engineers in cross-functional delivery teams of two or three developers. This allowed us to give the delivery teams the more global goal of delivering features to production instead of test. As a result, we have seen a dramatic improvement in quality, productivity and our ability to estimate projects. Some of the factors driving these improvements are:
- Developers are no longer incentivised to put features they know to be full of defects into test. Test engineers aren’t wasting their time documenting thousands of defects that are already well understood by the developers.
- Developers are incentivised to make their work easier to test (e.g. by build testing tools) meaning testing is not only quicker but also more thorough.
- When the team’s tester is busy or absent, developers in the same team will test each others work in order to get the feature out on time.
- Features are tested much earlier in the development life-cycle. (It is easier to fix defects before more code is layered on top of them.) Instead of spending weeks getting the full feature ready for test as quickly as possible, they now write automated tests before they write the first line of functional code! The first user stories are often ready for manual testing within a few hours.
- Features are rejected by test far less frequently during the development cycle because there is no rush to get them tested before they’re ready. This means our developers are significantly less distracted.
- It has been possible to remove layers of bureaucracy and process as the same small team are responsible for test and development.
- Overall quality has risen meaning there are fewer distracting production defects. The corresponding increase in focus has allowed us to become much more predictable and productive.
The best part is all this has resulted in a massive culture change. The friction between testers and developers has gone. The blame culture that once dominated (exemplified by comments like: “how did this get through test” and “the developers took so long we didn’t have time to test this”) has been replaced by strong team identities and a spirit of cooperation. Trust has improved between developers and the business and we’re able to deliver what we promise, when we promise.
Generalising the insight
The implications of this are much broader than simply “independent test teams are bad, integrated test teams are good”. It’s not that simple – you’ll have different challenges and your mileage may vary!
The insight is that you should replace local goals with global goals wherever possible and in order to do this your organisation’s structure matters. It applies to the developers and testers (we avoid organising them by specialisms like frontend and backend, but try and keep one feature to one team), product people (recommended reading: Lean UX) and DevOps people (recommended reading: The DevOps Handbook). Each of these need to be handled in different ways but the guiding principle of avoiding local goals remains the same.
If this sounds daunting (and it should, it isn’t easy to get right) you are lucky because there are some good “off the shelf” solutions. On a tactical level, Agile is an extremely powerful system (recommended reading: Agile Alliance Website). Don’t make the mistake however, of imagining Agile is a “developer thing” that you can safely ignore. To get the full benefit, it needs to be integrated at a very deep level into the whole product delivery function, from the people whose primary role involves talking to the customers, right through to the people who manage your servers.