When I started my journey as an Engineering Manager, one of the first pieces of advice I was given was to try and define my own formula for engineering management, by experimenting with different approaches, comparing the outcomes and reflecting on what worked for which uses cases, and why. After a few years of trial, error, and reflection, this is my best attempt to amalgamate all the learnings into something coherent, simple and effective.
While every engineering manager has their own approach to managing teams, I’ve found that most of the things I spend my time on, fall into 5 key categories, and that keeping these in mind form the foundation for effective engineering management:
Planning
Set realistic expectations and identify potential issues as early as possible.
“If you fail to plan, then plan to fail.”
Goals
Validate that we are prioritising the most impactful things
“Goals guide us to what matters, not just what’s urgent.”
Culture/ Environment
Motivate individual contributors to perform their best for the company.
“Motivated employees = more productive employees.”
Processes
Avoid unnecessary bottlenecks and misalignment
“Excellence is a continuous process and not an accident.”
Technical Excellence
Ensure your tech resources are performing optimally
“Perfection is not attainable, but if we chase perfection we can catch excellence.”
All of the above attempt to clarify expectations, reduce risk & drive productivity; the fundamental goals that we should try to achieve with our initiatives; as the combination of these allows for teams to self organise, and function autonomously in an agile, fast-paced, organisation.
A self-organizing team is a team that has the autonomy to decide how they will work together, assign tasks, and make decisions about how to accomplish their work. Instead of waiting for direction from a manager, they manage themselves and their work flow, fostering a more collaborative and agile approach. This model emphasizes team ownership, collaboration, and continuous improvement 1.
This is important as a manager because there will be a time where team members, or god forbid, you, are not available (vacation, illness, offsites, training etc), and the machine cannot grind to a halt when the inevitable happens. Whilst this can take time to achieve when building a team, there are some approaches that can help move the process along more organically, and I plan to share some of those that have worked for me in the following sections.
Organisations/ teams are systems made up of human resources, just as APIs/ services are systems made up of technical resources. I have found that many of the approaches that work for one, are equally effective for the other.
For example, you may be familiar with the shift-left testing strategy…
“Shift left” refers to the practice of performing testing and security checks early in the software development lifecycle (SDLC) rather than waiting until later stages. This proactive approach helps identify and resolve issues more quickly and efficiently, leading to better software quality and reduced development costs 2.
This approach of testing and validating assumptions as early in the development cycle as possible, can be applied to project management more generally, for example, investing in the hiring process and prioritising “team fit”, can avoid a new joiner negatively affecting team performance in a previously high performing team, and the lengthy process of replacing them; or implementing comprehensive monitoring and observability early in the development process, can help with debugging and catching issues before they reach production.
Another example of applying our technical approaches to human systems, might be the benefits we get from diagraming a system, to better understand and optimise it; highlighting bottlenecks and imbalances.
There are many more examples, and I’ll explore some in more detail in other sections, but hopefully you get the idea…
My intention is not to describe all the underlying concepts, as they are well documented, and it would take forever. I instead want to highlight those I feel it’s important to focus on/ be familiar with, and explain “why”.
The approaches shared here, should be an intro to the role, for aspiring engineering managers to better understand the role, or “food for thought” for existing engineering managers. They are by no means a rigid framework that I believe works for every organization. The goal is to outline some industry standard approaches that I have personally experienced to be effective, in hopes that they can act as a starting point, or inspiration, when defining ways of working that fit your organization, given the nuances of it’s structure, growth phase, needs and limitations.
Interested in finding out more? Read on to deep drive the 5 focus areas…
Footnotes
- What is self-organizing team in scrum (Visual Paradigm) ↩︎
- What is Shift-Left Testing? (Sonar Source) ↩︎