10 Lessons Learned after 3 years at Babylon
This post is sponsored by Program Hire.
Looking for your next program or delivery role in Technology? Visit Program Hire, where the team of in-house experts find the best roles in tech, so you can back to shipping the products of the future. Sign up for job alerts here.
Over the past three years working at Babylon, I’ve moved from working within an individual team to leading the agile delivery function. I’ve seen the company scale-up from £20m a year revenue to £1.1bn, double its employees, IPOing, and then making cuts and driving towards profitability. Here is what I learned.
- Scale engineering organisations vertically, not horizontally
At Babylon, we went from having an engineering team of 200 to 400 within the space of a few months. Whilst teams can increase linearly, the complexity in terms of operating effectively moves exponentially when scaling at speed. The natural tendency is that we want to develop a new product, so we hire a product manager, delivery and an engineering team to work on this issue. Suddenly, engineering has doubled, but is also working on double the number of things. This means that nothing goes faster, and development has actually got harder as coordination is across a team double the size. We learned this the hard way. In future, I will focus on increasing the number of engineers working on existing products, and be cautious about spinning up new products with new team members.
2. Small teams win
The best teams I’ve worked with at Babylon have had 2–5 very committed engineers. This is enough that progress doesn’t stop when an engineer is on leave, but small enough for the team to work effectively together. Whether a team has less or more engineers within this range should depend on the seniority of the engineers. This is where I’ve worked in the teams that have shipped the most value fastest.
3. Domain modelling teams is difficult with multiple business models
At Babylon, we began as a UK business. We expanded very successfully into Canada, a collection of APAC countries, Rwanda and then the US. During this we maintained the domain model, e.g. one team responsible for the onboarding experience across all regions. Whilst this helped maintain consistency, we had challenges with focus as there were different demands from each of the regions. In some case, this led to constantly changing to build features for different regions. I would consider in future the value of separating out some of these domains to separate teams. This also builds good practices of inner source.
4. Be problem led in your agile methodology
I joined Babylon as a purist in terms of implementation of Scrum methodology as the way for high performing tools. I quickly had a level of push-back from engineering on these methods I had not experienced. It taught me to make sure that each bit of process we add is demanded by the team and serves a specific problem. In general, delivery is about bringing your skills and experience to solve the key problems engineering have. More details here: Problem-Led Agile
5. Bring your reporting into the tool of work
Reporting is always a tricky thing to get right — to give your stakeholders enough detail for the updates to be meaningful, without drowning them in noise. One thing we tested at Babylon that worked well was moving our updates into JIRA, rather than having them externally in spreadsheets. Having a ticketing system helped the quality of updates, and it allowed us to connect directly to the work. In future, I would again try and bring the reporting into the tool of work rather than the other way around.
6. Remove dependencies, don’t manage them
One of the delivery manager responsibilities at Babylon is to manage dependencies between teams. Whilst this is important and will always be required to some extent, it more often than not represents a failure of the way we are organised / systems are architected in a couple of ways — either the team doesn’t have the skills needed to deliver value or it can’t contribute towards another team’s repo (either due to process, cultural or architecture reasons). I’ve found it more effective to spend my time trying to tackle these reasons and remove the dependencies than come up with long term dependency management tactics.
7. You can have too much change
In my previous experience, the key goal was to generate change and encourage teams to be less rigid in their plans, encouraging responding to feedback and making adjustments. At Babylon, the challenge was the opposite. Constant change and adjustment of direction every few weeks made it extremely hard to complete projects and release value. In this case, the role of delivery changed to protecting the teams and trying to keep away the distraction of potential change of direction in order to finish the current work. This constant change can be very detrimental if the team does not have an effective shield.
8. Longevity is crucial to developing high performance teams
Moving from a consultancy to a tech company, the rate of attrition at Babylon was considerably higher. I had previously underestimated the value of engineers who have spent 6 months + working on the same code repository, in terms of their accumulated knowledge and understanding of how best to implement changes. The constant changing of context by individuals who are new picking up a code base and/or engineers inheriting new domains is a key problem.
9. Apply the same delivery rigour and practices to your role functions
Typically, the communities of practice that exist for delivery, user design, product etc have mixed effects in both creating community and driving change. We saw real impact in using Scrum to run the actions and initiatives for the agile delivery team. This meant we kept running for over a year, making a series of important changes to the way that agile delivery was done at Babylon. It gave us the space to log actions and ensure they were followed through, as well as a regular cadence to review progress. I’d highly recommend this for role functions in the future.
10. Focus on your people’s long term ambitions
When I took over the agile delivery team, I knew I had a mixture of people at different points of their careers. What I did not appreciate was quite how different the directions and motivations were of the team in what they wanted to do next. Having this conversation helped me to focus on concrete steps for their careers to get towards those long term goals, and was the single most impactful tool for me to be an effective manager.
In summary, all of these lead back to the key goal behind successful delivery and teams — focus. I will take a renewed energy into my next role of driving focus and eliminating distractions within my teams to help them be effective.
This was originally posted on my newsletter, Velocity Agile. Subscribe to receive more posts to your inbox!
