BA (14/52): The Rule of Silence and Technical Program Management
We Interrupt this regular programming...
I spent most of my Tuesday in the ER which threw a wrench in a lot of my work streams both personal and professional including this newsletter. This is why this edition of the newsletter is late and light. I am okay but surgery at some point will be needed. For now, I am doing well and the meds help. On to the main event…
The Rule of Silence and Technical Program Management
A colleague shared a fascinating quote from an even more intriguing website on UNIX development. As you can imagine, that quote has some meaning for me and technical program management 🥲.
The rule of silence, also referred to as the silence is golden rule, is an important part of the Unix philosophy that states that when a program has nothing surprising, interesting or useful to say, it should say nothing. It means that well-behaved programs should treat their users' attention and concentration as being valuable and thus perform their tasks as unobtrusively as possible. That is, silence in itself is a virtue.
How do you define good technical program management?
My take: Good technical program management is the one you don’t notice or see.
It is a contrarian view point. After all, if you are not noticed how do you get recognized and promoted up the hierarchy.
As any good program of system, we have to treat the time, attention, and availability of our engineering teams with respect. Operating silently, smoothly, and swiftly - that is our mission as TPMs.
When Silence Is A Virtue
TPMs are a system that operates as part of a larger system with our own sets of inputs and outputs. We interact with other systems, accept their inputs, process the information and output results. It is important that we be seen as the silent operators. Why?
Experience has taught that when TPMs beginning to create frameworks or process that makes them very visible (read: ineffective, and busy work), engineers no longer see them as valuable partners but obstructionists.
The processes we create, the meetings we schedule, the manner of our communication, how we collaborate with others, everything we do in service of the project and the teams we support must be smooth and silent.
There are exceptions to this rule, there are always exceptions: sometimes you must do things that you may not agree with or may make the team you support unhappy but it is in the service of the overall company/organization/vision. This is especially true when the deadline approaches and work still remains.
This is the curse we TPMs bear - we serve many stakeholders each with their own importance within the organizational hierarchy; the leaders without authority is what we are called.
In those moments exceptional moments, TPMs must make themselves visible not to shield the engineering teams, no I do not subscribe to this philosophy of shielding, but to help them understand and be honest with them:
What is happening?
Why is it happening?
The importance of the event
How you feel about it?
How the engineers should think about it?
The importance and value of the decision for us all and the future.
Never try to trivialize or sugarcoat the hard things.
Be like water my friend - silent and loud
The essence of good technical program management is being as if you are one with the team. Alas, when duty to the higher ups calls, we are the guiding hand to wayward Shepards lost in the fog of ambiguity that often roams the dominion of engineering.
Know when you need to be visible with your craft and when you need to operate silently from the shadows driving your teams to success.
As much as I enjoy turning a phrase like Dumbledore, I will make some corrections and additions:
Good technical program management…
... is the one you don’t notice or see until you need to.
... is we speak up when it is needed; influence when our voice isn’t important or will not add value to the conversation or to the moment.
... operates unseen, the invisible hand that molds the chaos that emanates from cross-functional complexity and blue sky visions.
... is the orchestrators that makes all the trains run on schedule and to destination.
... is the entropy molders and crushers - whatever the moment requires.
... operates in all realms and spaces in service of the teams, the projects, the company.
It did get a bit preachy in the end there, must be the meds. 🌝
Until next time, traveler. 👋
-Aadil
P.S.
This website is a gold mine filled with fascinating nuggets on UNIX development. Simplicity and form is just marvelous to read. When you can spare the time, pop on over → http://www.linfo.org/rule_of_silence.html
What did you think about this weeks newsletter?
🤯 Amazing