Engineering Management

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 guide book. Your best support structure is to have a couple of mentors/coaches who are in that role for a few years.

This is a role that is hard to document with a list of responsibilities. Like many other roles in software engineering, it evolves with 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).

Engineering Managers have many different dimensions to their responsibilities. I will list a few to help you get a flavor.

People Management (actually 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 to, setting expectations, periodic 1:1s to keep a 2-way conversation going. 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 is 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 tracking against those is essential. This is an area where many organizations do not put a strong focus on. We have to define, clearly, what the role of a junior engineer is 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. This should give you a good idea of areas to measure for a Software Engineer. Refer to Specifically, the matrix is at CircleCI Engineering Competency Matrix [public version]

Finally, be ready to step back and let the team take over. If you are a new Manager (especially an IC moving into this role), this may be tough to get used to initially. Nothing can be worse than you micro-managing everything. Focus on stepping in for a directional alignment, set sensible guardrails, and 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.

Delivery Management

As humans, we tend to see and value the world through the lens of our own role.

  • The architect visualizes things in conceptual 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 see Agile as the key to the development
  • Business values their features being available yesterday
  • Operations are concerned about managing the production systems
  • …and so on…

Your role as an Engineering Manager is to now bring all these value viewpoints together into a cohesive working unit to deliver the intended business value (building new solutions or keeping lights on for the current system) as working software. All the while keeping budget, timeline, and quality in a delicate balance. To this, I want to add 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.

Another important area you can influence is how the team operates and what type of empowerment you can enable. There is no right or wrong answer here, but you can have flavors of autonomy (not exhaustive)

  1. Full 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.
  2. High Autonomy – Team of engineers who have complete autonomy within a set 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.
  3. Medium Autonomy – You may have a specialized Architect or DBA who can influence or drive decisions. 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.
  4. No Autonomy – This is the worst 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.

Tech & Engineering Practices

10 years back, Cloud was in its infancy. Today that is the default. AWS, Azure, GCP, or your own custom Cloud, you have to know these things to a sufficient level to have tech conversations with Architects and 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 dev. 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).


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 guide book and “implement” it. But if you are a keep 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). 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.

In closing, there is no magic answer. My advice is first to focus on your immediate sphere of influence to do your part to build a positive foundation, and that starts with being open & authentic with your staff.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.