It has been a few years now since I moved into the role of Software Engineering Management. While there may be various reasons for one to move to this role, it is a change that comes with very little training and no guidebook. In this blog, I will go over a few areas that I felt are areas to keep an eye on when in this role (a lot of it is relevant to non-manager lead roles too).
This is a role that is hard to document with a defined list of responsibilities. Like many other roles in software engineering, it evolves with the changing times (and in tech, that pace is fast). I also want to suggest watching this great video from Lena Reinhard – GOTO 2019 • What Engineering Managers Should Do (and Why We Don’t).
Your best support structure is to have a couple of mentors/coaches who are in that role for a few years
Engineering Managers have many different dimensions to their responsibilities. I will list a few to help you get a flavor as you decide whether to start this journey or if you are a new manager.
People (…Development)
I start with People because this is the most critical area to focus on. Whether it is mundane tasks like approving timesheets or larger decisions such as – building teams, providing feedback, hiring, retaining, performance management, formal goal-setting, setting expectations, periodic 1:1s to keep a 2-way conversation going; this is where you will (rightly) spend a lot of your time. If you are a new manager, realize this is a serious commitment. Getting coaching from experienced managers and educating yourself on standard HR practices for your company is recommended.
Being a good listener, exhibiting empathy, and being authentic are essential traits. I recommend spending some time reading and digesting the 6 core needs for humans (Paloma Medina) – BICEPS.
Setting clear expectations at each level and measuring against those is essential. This is an area where many organizations do not put a strong focus on. We have to articulate what the role expectations are for a junior engineer vs. a mid-level vs. senior vs. staff vs. principal software engineer. I found an excellent competency matrix from CircleCI, which has been open-sourced (and there are others out there). This should give you a good starting point to help define expectations for engineers. These are common sense items and hopefully should not create HR conflicts (but run it by them if in doubt). Refer to https://circleci.com/blog/why-we-re-designed-our-engineering-career-paths-at-circleci/. Specifically, the matrix is at CircleCI Engineering Competency Matrix [public version]
Be ready to step back and let the team take over. If you are a new Manager, this may be tough to get used to initially. Nothing can be worse than you micro-managing your direct reports. Focus on stepping in for a directional alignment, setting expectations, setting sensible guardrails (if needed), and then step back to allow the team to execute independently. The team also needs to be aware of the goals and timelines or any other relevant business/organizational constraints. Remember, some of those constraints are not in your control, so transparency is essential here. Hiding them (even if the team disagrees) will not serve us well.
Finally, be ready to have tough conversations. If that is something you do not enjoy then this job is not for you. Seriously, this is true.
Delivery Management
As humans, we tend to see and value the world through the lens of our own role (not all roles below may be relevant to your place).
- The architect visualizes things in conceptual architecture diagrams
- Software engineers see value in the code they write
- QA sees testing as the key
- Product management sees them driving direction
- UX designers see them leading the vision of customer experience
- Scrum Masters might see Agile (and things like SAFe) as the key to organizing the development.
- Business values their features being available yesterday or if generous – tomorrow (how the team technically implements them is not their primary concern)
- Operations are concerned about managing the production systems and prefer stability vs constant change.
- Enterprise Architecture (and InfoSec) set safe guardrails and mandates.
- Program Management may be required when navigating a complex web of integrations across teams.
- …and so on…
Your role as an Engineering Manager is to bring all these value viewpoints (all right in their own space) together into a cohesive working unit to deliver the intended business value (building new solutions or keeping lights on for the current systems). All the while you will keep an eye on budget, timeline, and quality (a very delicate balance).
To this, add in maintaining sanity in the team when there is stress. Often a hard deadline is driven by factors not controlled by tech management. This creates a tension between delivering business value, team health, culture, quality, and aspects within the 6 Core BICEPS needs for humans.
Autonomy (hmmm and Empowerment)
Another important area you can influence is how the team operates and what type of empowerment they have. Dictionary definitions are needed here first…
- Empowerment – “authority or power given to someone to do something”
- Autonomy – “the capacity of an agent to act in accordance with objective morality rather than under the influence of desires” or “the right or condition of self-government“
There is a difference between the two. With Empowerment, you are given some rights by management (or higher authority) and you can make decisions within that realm(s). With Autonomy you let the team do what they feel is needed from their viewpoint, without requiring any consent from a higher authority. In enterprise environments, it is hard to just let folks do what they want and be Autonomous. What do I mean? Say if your company decided to use Azure Cloud services and one team wants to instead use AWS (or vice versa). Such decisions are not made on a whim at the enterprise levels. Using the other Cloud provider might not be an option and something a fully Autonomous team cannot do. Now can they go make a case, a sure thing, and should not be stopped for doing such.
There is no right or wrong answer here, but you can have flavors of autonomy. A lot of this depends on your organizational culture and the values you want to encourage. This has an important relation to hiring & retaining talent.
- All-Access Autonomy – Team of engineers who take in a business need and independently build the system. They own all aspects of the engineering puzzle. They own the decisions and outcomes. If they make the wrong design/architecture decision, they hold themselves accountable and fix it. Experimentation is the norm, and the organization culture welcomes failures as far as the team takes ownership.
- High Autonomy – Team of engineers who have complete autonomy within a set of defined guardrails and a senior technical engineer (on the team) might need to review the design informally. The enterprise has a set of tools/practices that you have to operate under, but otherwise, all technical decisions are owned by the team. The team can still perform experiments, and the culture might support limited failures. There may be specialized structures like EA or InfoSec that may have to be consulted.
- Medium Autonomy – You may have a specialized Architect or DBA who can influence or drive decisions, along with Enterprise guardrails that need to be aligned with. There are specialized structures like EA that must be consulted and their advice must be adhered to. Experiments can still be done but might need discussions. Failures are frowned upon.
- No Autonomy – This is the most restrictive kind. All kinds of decisions are handed to you by siloed teams, and engineering teams have to execute on that. Every critical technical decision requires approval from another team. Experiments and failures are not welcome.
None of the above 4 are good or bad. I stress that. For example, 3 & 4 may be appropriate if you have a highly complex product and/or a globally distributed team working on the same product set. #1 or #2 may be appropriate for a startup or a company that prides that culture.
Engineering Practices
10 years back, Cloud was in its infancy. Today that is the default. Whether AWS, Azure, GCP, or your own custom Cloud, you have to know these things to a sufficient level to have tech conversations with engineers. The same goes for trends in frameworks and practices in your spaces. Not endorsing anything specific here, but things like ThoughtWorks Tech Radar should be on your reading list. Being hands-on with many of these tools is recommended (at least do the hello worlds to know a bit). If your org/culture/time allows, then contribute to the actual development. There are so many avenues to keep learning that there is no excuse not to. Earmark some hours every week and make it a habit (and yes, most probably it will be time outside of your regular working hours).
Finding your path to learning is critical in our field. An often overlooked way to learn is to learn from your team (and other engineers). Be on the lookout for that. If the team is picking up new tech, you can spend some time reading up on it or reviewing the code or better do some hands-on learning by writing code. If they are doing a brown bag, you can join that. This applies to both tech tools/practices and also new ways of working that your team may experiment with.
DevOps
DevOps is about adopting a set of practices towards realizing business value in the fastest possible time without compromising on quality and safety.
This requires…
A commitment to the highest possible engineering practices, open & collaborative culture in the way individuals & teams work with each other, empowered teams, embracing CI & CD, automation, test & learn culture, and an acknowledgment that failures are a learning opportunity
Whether you live in an environment where Ops is a team vs. you own the service from birth to life in production (and taking the 3am calls); operations is something you MUST care deeply about as an Engineering Manager. You will need to define & implement strategies to measure, review and optimize the efficiency of your system. I call this out since, with the changing times, the shift for teams to own Operations is happening everywhere.
Tune your hiring practice to set Operational expectations right then. It is a bad situation if you hire a new engineer and then tell them they will be on production support rotation and they are like – no I cannot do that. Set this expectation early during the hiring process or during internal job transfers interviews.
How you go about playing your part in influencing, adapting, and collaborating to implement this approach to working will be another area you as an engineering lead should focus on.
Culture
Peter Drucker – “Culture eats strategy for breakfast”
Culture is how people feel when they come to work every day. Do they feel safe, do they feel recognition & rewards are fair, compensation fairness, promotions are given to those deserving it, diversity, equal opportunities, are leaders being honest, sense of purpose related to the work they perform every day, does the org care about you, empowerment, etc. You cannot use a guidebook and “implement” it. But if you are a keen observer/listener, you can sense it when you see a team working well (or not) and is happy (or unhappy & stressed). And culture is never static. It keeps changing every day as we all collectively perform our work and interact with each other. An Engineering Manager has a big part to play here since he/she is the first line of formal management leadership. You can influence the culture to some extent within your immediate sphere of influence (your team and your direct org). But there will be areas you have no control of. For example, you may recommend someone for a well-deserved promotion, but the corporate process may not align to get that approved. Does not make the Corporate process evil; just means there are constraints that do not allow moving forward (whether we like those constraints or not).
In closing, there is no magic answer on “how to become an Engineering Manager”. My advice is to be patient, listen, provide honest feedback, be authentic, learn from your peers and have a growth mindset.