We want to talk
Bob and I are starting a podcast today for Engineering Managers. We first met in May 2022 at Talon.One, Berlin, where we worked together for a few months. He...
We want to talk
Bob and I are starting a podcast today for Engineering Managers. We first met in May 2022 at Talon.One, Berlin, where we worked together for a few months. He was a consulting management professional when I joined as a full-time Engineering Manager. I can’t even say that we clicked immediately, because he clicks with everyone. He is a universal friend. Apart from his obvious positivity and happy-go-lucky attitude, what struck me the most was his immensely constructive and collaborative leadership style. If you have a plan, he knows how to execute it effectively. That’s an asset I lack. It took us more than three years to figure out an initiative to partner on. I’m so excited that it has finally begun.
A promising partnership
I am an introvert, an extreme one. Bob is an obvious extrovert. But we both are ‘almost’ altruists. Well, that might come across as self-praise, but what I mean by ‘altruist’ is that there were times when we unknowingly put others first. Accidental goodwill does not qualify as altruism, but it is cute. Don’t you think so? Jokes aside, Bob is an expert on people and processes, and I find myself going deep into technical topics. Again, something we both know very well is how to strike the right balance between fine technical implementation and practical development processes. We both hope and pray you enjoy what we produce together, with a promise of nothing but our sincere efforts.
Why this podcast?
We both have different reasons.
When Bob stepped into leadership shoes earlier in his career, he had to be self-taught. There were books on partial topics and vague guidelines available, but no concrete playbook. In every manager’s job he took on, he had to define his own role and responsibilities. He drives the point home by convincing that the problem still exists, but he feels more fulfilled in his role. That’s why we need to share and build a knowledge base that serves as a one-stop shop for all Engineering Manager needs. If you’re an Engineering Manager who has ever felt there’s no clear playbook for doing this job well, this podcast is for you.
Unlike Bob’s experience of not having a clear role definition, my frustration comes from something else entirely. After more than two and a half decades in the industry, I see many, if not most, software teams struggling with age-old problems that have long been tried and tested. Many questions seem outdated to me:
- Should we do the standup every day?
- Do we really need unit tests?
- Can we have a four-week sprint?
- Why aren’t my colleagues reviewing my PR in time?
- Who should write the task description and how?
- Shouldn’t we have a dedicated Scrum Master? And the worst,
- Should we use Scrum, Kanban, or something else?
Neither should our approach be dogmatic, nor is there a single right solution for all problems. But standards and best practices haven’t come out of nowhere; they exist for a reason. They provide a great starting point from which one cannot stray far from the desired direction. The real challenge lies in managers and senior members not knowing these standards and best practices well enough to apply them in practice. And this is what I wish to work on with Bob to provide you all.
The name - Management Engineering
Engineering is nothing but a practical application of science. Just like Sales Engineering or Quality Engineering, the Management function of the Software Development can also be viewed as an Engineering discipline.
To provide a toolkit for software team leaders, we need to define the Engineering Managers’ responsibility areas across high-level categories, then go deep into each category with a hierarchical breakdown. For the podcast series, we will need to maintain a flat list of topics and reprioritize the sequence based on audience interest and demand. Each topic will be backed by historical data points, adequate references to demonstrate how specific techniques work, approach evaluations that consider their advantages and disadvantages, domain expert opinions, evidence from our past experiences, and, finally, strong logical reasoning. In short, we wish to look at this field of management with a ‘scientific’ outlook.
My reason, in detail
The performance of a development team depends on the quantity and quality of the delivered output (the number of effectively solved customer problems) and their enjoyment along the way (which leads to continued performance). As engineering managers, our job is to help teams spend as much time as possible (focus) on these two core areas: building effective solutions and enjoying the collaborative process. That should be obvious, right? Here is a shocking revelation: ‘Repeatedly discussing what an enjoyable approach to building effective solutions’ might often turn into a poor use of limited time. Especially when this becomes a recurring theme. Many teams enjoy defining their own processes. There is undeniable emotional satisfaction in defining one’s own processes. In practice, defining our own processes tends to be time-consuming, incremental (often never-ending), and gradually pulls focus away from the core work. What makes this especially costly is that the same pattern appears not only in development teams but also within management groups.
The key to focus is reduction. Noise reduction*. Any activity that does not directly contribute to solution-building adds noise to the system. If we want to remain focused on continuously delivering value to customers, we cannot routinely spend time on defining our processes (including development best practices). Choosing the right processes and appropriate best practices as a one-time discussion, then setting a routine pulse check to improve, is absolutely fine. Choosing does not have to mean defining from scratch, and it should not become a recurring, open-ended routine. Neither the software development processes nor the respective management challenges are new. Most of these challenges have been addressed before, often repeatedly, over many years. Of course, major dimensional changes, such as AI and remote work, affect execution and management strategies, but the same principles and values still act as our anchors. Individuals need care and growth. Teams need a culture of innovation. Products need continuous evolution. Customers need effective solutions. And businesses need increasing profits. The responsibility of the leadership team, hence engineering managers, is to build and foster an environment that ‘synchronously’ facilitates all these needs (in their respective scope of influence). Only then can each group remain aligned with the organizational goals.
* Please note that ‘reduction’ doesn’t mean ‘removal’.
Reduce the noise to the minimal. Complete removal is neither possible nor the aim here.
This is why I want to work on the clear separation of noise and then its reduction. There is nothing new to this knowledge. These solutions have existed for decades. The only newness is in the formation or structure of the information. We want to view management as an engineering discipline. The science of management already exists. We want to formulate and present it for the practical applications of engineering managers.
Concluding appeal
A definite challenge that we will face is the one that all leadership guidance topics face: If you provide a framework, it becomes too generic, losing situational applicability, and if you provide specific examples, they become too contextual. Hence, by no means is the knowledge we share meant to be definitive or final. On the contrary, treating management as an engineering discipline requires continuous feedback, challenge, and refinement. The ideas we discuss can only improve when they are tested against real-world experience, questioned openly, and extended by others. This is why participation is not optional but essential. We invite you to challenge our assumptions, share your own observations, and help evolve this knowledge base into something that is not only consumed but continuously engineered by the community itself.