Engineering Strategy. Delivery momentum.
Niki Belokopytov · January 31, 2024 · 5 min read
Part 2.
“Terminal velocity - steady speed achieved by an object freely falling through a gas or liquid. A typical terminal velocity for a parachutist who delays opening the chute is about 150 miles (240 kilometres) per hour.” — Encyclopaedia Britannica
At light speed.
When structure and process is introduced, it inherently means rules. Rules take time to learn and apply, at times it might feel that the more chaotic environment of the big team felt faster than the new, more regulated flow. If nothing else, now is when the project feels like it’s moving one step forward, one step back. It’s too stable.
Now that the team is working on different missions, there are always a lot of open branches. The more they remain open, the more chances of a conflict emerges. And even if the team is lucky and there are no conflicts - there’s always a risk of a regression slipping by. What do you do when a patch is required? Cherry pick, merge into master, then pull it to all the outstanding branches and hope that nothing breaks again.
When teams have focus and stability, it’s easy for the stakeholders to just start speaking to engineers directly, bypassing the rest of the team. Apart from all of the requirements that only a single person knows about, this approach also causes expert knowledge on the implementation of these requirements to remain with a single person. Imagine that not only you don’t know how the feature works, you also don’t know how it should work. What a nightmare, right?
To top it all off, while Feature flags allow the team to now have a steady stream of fixes arriving to the users, the big features themselves can still be delayed. Big refactoring initiatives are still not shipped. It always feels like it’s too early to pull the trigger on it — what if we iterate on it for a little more — wouldn’t it be even better?
And of course, if you don’t know if you’ll ever be shipping your technical improvement at all — maybe it’s worth to invest into something that’s either fun or interesting. Meanwhile, the impactful, but also painful changes will remain as grating for the team as before.
Referring to the earlier analogy of my friend Utpal — now we are not sinking anymore. But we’re not exactly moving either.
But why walk on ice when you can skate?
A scaled multi-team engineering org can still move fast even with a monorepo, if they introduce a structure that reduces friction between engineers and various teams.
One of such approaches is called Trunk Based Development. When taking to extreme, it essentially means that there is only one long-lived branch in your repo at any given time. All releases are being done by building a commit from that branch. All incremental changes to features are being committed to this branch. All fixes are pushed to this branch. This approach quite literally excludes Merge Conflicts by design. There can be no conflicts if there’s always only one branch present, right?
When teams identify that they have stable stakeholders with long lived projects, instead of human-sized silos, the smart thing to do is to create a team-sized silo — a project-channel, where the stakeholder will be able to send all the updates and requests dedicated to their feature. This will allow the team to pick up the project even if the feature owner will take the leave of absence and re-play all the most important conversations.
But even before creating such a channel — the team needs to stop relying on the principle of one engineer — one track of work. Breaking up each task into well documented, well decoupled, small tickets, no more than 2 “perfect” days of work each — will allow all engineers from the team to focus on one project. A nice side effect of this practice will come in a form of tighter bonds between colleagues and a sense of trust forming. PMs will also be happy about shorter delivery times. In fact, there is little to be said of downsides of such an approach, apart from the requirement to diligently invest time in advance for delivery planning and the requirement to design your implementation even before a single line of is written.
Well-designed implementations fit well into milestone planning — an approach, where every critical step of the project delivery (UX design, Tech Design, Implementation 1, Implementation 2, Testing, Rollout etc etc) has a date attached. In case if the team does not know when a certain step will be delivered — a concept of Date For Date is considered useful. Essentially Date For Date means the “day on which I’ll know enough to set an ETA on this milestone”. By using milestones, your team will know about a potential delay as early as humanly possible, way before it becomes critical and causes emotional waste for everyone involved.
Last by not least — the org can create a structure of horizontal cross team round tables (chapters, guilds etc) and their secretaries (guild masters, chapter/platform leads). Chapter leads can take care of documenting the most painful things that come up during chapter meetings, organise an initiative to address it, create a milestone plan for it and then, ultimately, keep all teams focused on slowly, but surely chipping away on the topic. Best chapter leads are excellent engineers themselves, but the real requirement here is to be empathetic, organized and observant. The role is about helping the others, not helping yourself.
Slow is smooth, smooth is Fast — the motto of Navy Seals.
High octane action looks good in Hollywood movies. In real life it means high risks, stress, mistakes, and scars.
Navy Seals are a US special force specializing in operations of extreme difficulty, requiring precision, teamwork, and expertise. Their motto is not Move Fast, Break Things. By being more structured, more intentional about their workflow, any organization can retain high speeds of delivery, without the unneeded stress.
