Engineering Strategy. Delivery quicksands
Niki Belokopytov · August 14, 2023 · 4 min read
Cold open
Imagine having a great team, full of energetic, responsible people who help each other as much as they can.
They have their value system and a smart tech lead. Still, the delivery is gradually slipping. While on paper the team is doing all they can, often with feats of heroism and late-night fixes, the outcome is terrifying - half of the releases become delayed. Dissatisfied with themselves, the team only tries harder.
The harder they try, the more interpersonal conflicts surface. Every delay creates even more sense of urgency, the team starts to compromise on quality. All consistent efforts to improve the codebase are met with mistrust and are only seen as distractions. Engineers are hyper focusing on their own code, on the next 24 hours of their lives and lose the sense of perspective.
In 12 months, ¾ of the team leave. There is no stress anymore, because there is no team anymore.
Stress free delivery
There are many factors that can cause stress. Slipping deadlines, changing requirements, incidents, broken promises – almost everything that goes not as you’ve expected cause your body to tense, alerts your nervous system and hyperoxiginates your blood. Under stress our minds focus on survival.
If you would like to fix your team’s setup – first, you need to get rid of the stress.
While none of the factors above seem critical by themselves, if a company scales and lets the teams grow organically – it’s very likely to check off most of these boxes at some point. When the team becomes too big too quick – many things get lost. Modules and features that previously have had a clear owner are now being touched by multiple people. When previously it was easy to find a helping hand, now seniors are giving a chance for the new people to respond first, while the new people believe that they have too little domain knowledge to give a proper answer. When previously it was easy to deliver features only when they’re ready, now the amount of people waiting for a feature is extensive and every small delay of one of the features causes a ripple effect across the whole release.
Growing companies also grow in ambition and introduce new products, causing the release pipeline to grow in complexity as well. While previously it was easy to keep the CI/CD going, now no one has the full picture of which tests still work and which are commented out. With a bigger team – no single Pull Request can be reviewed by everyone.
When finally, there is a minute of respite, to lift the spirits, the team experiments and has fun but there is never enough time to finish a proper refactoring that pay back the incurred tech debt.
How does one prevent this? We were speaking about this topic with Utpal Das, our Head of Mobile Product and here’s his quote on that:
Walking on water is easy if you freeze it.
To relieve stress from teams one needs to stabilise the environment first.
The crucial part of the stabilisation is the intelligent separation of team into independent sub-teams, each focused on their individual mission. Organically, these teams need to become dedicated owners of the subsystems and modules that they touch the most. With smaller team size – communication flows easier. If there are two people working together on each piece of code – if one asks the question – there is only one possible person to respond.
Smaller teams also have easier time to share experience between implementations of Android and iOS, eliminating the need for one platform trying to guess the logic that the other has implemented. Best case scenario – the smaller team implements any given feature in the same way, at the same time on both platforms.
Second recipe – dedicated capacity every sprint on Product tasks and on Tech tasks. Rain or shine – if the team knows there will always be time to fix leaks, redo tests, move things around – the team will organically feel more comfortable with doing it.
Third component of stabilisation should be a routine release. Both the CI/CD pipeline needs to be as simple, as sturdy as possible and the release schedule itself needs to become a boring tradition, which even the new team member can sleepwalk through. Just like with the tech improvements, rain or shine, there needs to be a predictable cadence to fixed things being shipped to the end users. If a feature is not ready or a refactoring is not finished – it’s isolated from the user and sealed behind a feature flag.
Yes, you read that right – refactoring also need to be sealed behind a feature flag or else the only kind of refactoring that the team will ship will be the smallest one.
To be continued…
