BA 32/52: Systems of Work
I think a lot about how engineering organizations do the work of doing work.
Everything from planning to development to production to maintenance, as a TPM, our’s is the discipline of "doing work".
Now, don't confuse this with "TPMs just focus on filing Jira tickets, doing sprint planning and harping about what is an epic or not", it is much much more.
We are an active part of the system that decides what a software organization chooses to work on, what we choose not to work on, the debt we incur in its many forms to achieve the objectives we set, the technical solutions we define for complex problems, the org scaling plans, the growth trajectory, the roadmaps, the decision making, we are a part of everything.
So, to be an effective TPM, it is important we understand the systems of work for our organization.
A system is a set of principles or procedures according to which something is done; an organized framework or method.
Every software organization operates using a system of systems - where multiple individual system of work come together, interconnected, to achieve outcomes: systems of work.
What are examples of systems of work:
Sprint planning
OKR definition
Demos
Executive reviews
Steering committees
Retrospectives
Root Cause Analysis
Incident Management
Test Automation
CI/CD
many more...
Now, like all machinery, apparatus, and.... systems, their effectiveness goes hand in hand with their optimal operation.
A system's optimal operation is governed by the maintenance of an equilibrium within that system. In a software organization, the two elements that need to remain in equilibrium are process and people.
You have probably seen these two terms in the agile manifesto where it states: individuals and interactions over processes and tools
My experience has taught me to look at it more as an equation, rather one or the other, that must remain in equilibrium: Process + Tools = Individuals + Interactions.
If you have too much process for the number of people, you will create unnecessary bureaucracy stifling innovation and hampering progress.
If you do not have the right amount of process for the number of people, you will create ambiguity and confusion as to what is the focus for the org and are you making progress towards the goals and desired outcomes.
Why should I care about this?
"I don't write tickets for my work. That tool overwhelms me when I open it up."
"I feel disconnected from the sprint planning. I am not sure if the work I am doing matters."
"I don't know what I am focusing on but I feel busy."
"I was never part that discussion, why did we make that decision?"
"This solution won't scale and will never work. Who was involved in this process?"
"We keep missing our deadlines despite so much planning and paperwork we do upfront?"
"We hit our deadlines but every time we have skipped steps to make it happen."
"Does the XYZ engineering team know what they working on?"
"I have no idea what the roadmap is. I am just trying to stay busy."
"Are we spending time and resources on the right goals?"
"The sprint planning is pointless, just tell me what we need to do and I will just write the tickets later."
"Nobody talks to us (test team) until its almost time to ship and then strong arm us to skip steps."
"I write OKRs last minute, honestly, because no one is reading them anyway."
"We have done this roadmap exercise three times yet we still don't have a focused trajectory."
"Our quality keeps dropping and its hard to focus on tech debt yet we need to ship features."
You as a TPM will face many of these situations and many like these not listed above. Engineers and leaders will come to you with these problems expecting you to have a solution.
In order for you to navigate these problems, taking systems thinking approach, it is important that you understand your systems of work and how they come together. Then, figure out two things:
Are the current systems operating in equilibrium?
If not in equilibrium, what is out of balance: process or people or both?
This is a far better method than just proclaiming "you are doing scrum wrong" or "you just have to write that status report because CXO wants it" or “the tool is what it is, I need you write those tickets”.
I find myself doing the following exercise more and more as we scale at Humane:
Describe what are the systems of work to a new hire. Is it easy to understand how work gets done?
When you look at your organization's systems of work, do you see an equilibrium?
The answers to above two questions helps me stay focused on:
where are the opportunities where we can add or remove process to balance it out with the people in the org at this point in time.
Where there is confusing hindering our progress towards our desire outcomes.
Where are the current points of frustrations for the engineering teams.
Until next time 👋 !
-Aadil
How is this week’s newsletter?
Too much process creates waste; too little process causes confusion. The right approach is to strike balance between them. Appreciate the insights!