BA (18/52): Systems and Overhead
Eid Mubarak to all those who are celebrating across the world. This short piece is coming from a family vacation, a first Eid since 1999 where my entire family has come together (4 generations) in one place so as you can imagine, I am a little distracted but I remain committed to my goal to ship an essay every week this year. So, apologies for the delayed delivery.
Systems operate on input and outputs.
Larger systems are a combination of smaller systems.
As systems come together, join powers, towards a goal, objective, or output, they are capable of self regulating the overhead (planning, strategizing, documenting, communicating, tracking progress etc) generated as a result of interconnections to share input and outputs. (aka Product, Design, Engineering teams and startups)
At a certain point, when complex systems grow too large, autonomous systems are required to assist or wholesale take on the regulation of the overhead (aka Ops and TPMs).
With each additional node or system added to the overall systems map, overhead increases by a factor.
One thing that all engineering and TPM leaders need to understand is that in software development overhead never disappears. Even when you were a small team or a startup of 2 people, overhead existed. The regulation of that overhead was easier and possible with the remaining functions expected of your team.
Often engineers will complain of too much overhead or the need to remove overhead. It is a natural response - any functions within a system that doesn’t add value must be addressed for efficient operations.
As TPMs, our goal should not be removal of overhead in its entirety, a fools errand, but rather smarter, automatic, efficient regulation.
Your most basic example of overhead in a software organization practicing some form of agile, say scrum, - the standup.
Remote and distributed workforce has led to more prevalent async stand ups over slack or some other tool with reminders and aggregate reports plus dashboards. (smarter, automatic)
As organization and teams scale, your stand up will go from two people to multiple groups of people. You will have to decide whether it still makes sense to have a single stand up or multiple standups and whether aggregation of individual team reports makes sense (efficient).
Any overhead can absolutely be removed. However, much like laws that govern energy, it doesn’t disappear but rather transfers into other areas/overhead costs.
Ex: you could decide that we don’t need design docs or 1-pagers to explain projects. Yes, that is less formal documentation but each team as part of the cross functional project will need to work twice as hard to ensure all teams (systems) stay aligned as they continue to make progress especially on things as primary as “when are we done?” - overhead on regular communication increases.
Take a look at how your organization operates; what overhead costs have you had to pay as part of scaling and continue to pay. See where these overhead costs can be optimized or made more efficient. See what overheads did you remove and whether you have started paying a higher cost elsewhere?
Systems are a fascinating thing.
Until next time. 👋🏽
-Aadil
What did you think about this week’s newsletter?