What would you say...ya do here?
Some have wondered what I do all day. And truthfully, even Engineering Managers don't always know.
As an Engineering Manager, and now Director of Engineering at Docker, it's taken some time for me to learn more about the role and craft, and some of being a great leader and manager is helping define my role based on what the company needs most.
I've met with 70+ people since February in coffee chats, and one of the more common questions has been about the evolution into and day-to-day details of the Engineering Management profession.
Being an engineer can be cut and dry: go write code. But if you become an Engineering Manager, you have more freedom and more opportunity to be proactive.
Instead of having certain responsibilities, you have "accountabilities". Being accountable, you have more leeway on how to approach the work. And the accountable areas often aren't specific and task-based.
You define and act on an approach to:
- Building the right team
- Putting together the right working agreements
- Helping the team and individuals grow
- Ensure the team is communicating and visible
- Execute projects
- Celebrate wins
Let's talk a bit more about what you are accountable for, some analogies, and other roles of interest.
The Who, When, and How
Product managers define the "why" and the "what" that engineers will build. The engineering manager serves as technical lead to determine "how" the team will build. Together you align on the "when" to deliver new customer experiences and lead your teams to success.
As an Engineering Manager (EM), I'm "joined at the hip" with a team's Product Manager (PM).
Especially in product organizations like Docker, the Engineering Manager works closely with a Product Manager, usually both assigned to the same team in executing on a team's mission, both in maintaining the responsible services of the team and in establishing and driving a roadmap of projects.
As a preface, the EM and PM should be highly aligned, such that each can represent the other in their absence.
Divisions in accountability are helpful to know:
- Who is making sure the ball isn't dropped in that area
- Who has the final say when there is a disagreement
Ideally, the two can act in a partnership where both feel equal voice and alignment in leading all aspects of the team.
Having said that, a common way to describe EM and PM accountabilities are:
- EMs: How, Who, and How Long?
- PMs: Why, When, and What?
Note that EMs may also be responsible for the Why and What as far as technical and architectural concerns. And this overall breakdown is simplistic and may vary between companies.
The customer data platform Segment describes it a bit differently:
Analogies to help explain the Engineering Manager role
Another way to understand the ideal implementation of the role is through relating to other concepts or roles.
- You are often helping others
- You act more as a peer than a "boss"
- At times, servant leadership requires acting more as a report to the IC, than a boss of the IC
As a servant leader, the roles can be reversed.
You do have some degree of guiding others and facilitating the processes. But you also are there to support others, doing what they need of you, and helping where people need you the most.
- Ensure everyone is communicating during execution
- Make sure people are in the right roles and have the right responsibilities
You often schedule and run meetings, and make them as fun and productive as a meeting can be.
That means sharing the leadership responsibilities. Allowing equal share-of-voice across the delivery team and other managers.
And contrary to what the role of power may lead you into, you should pick others and share the "power" and responsibilities with them, highly delegating what others are interested in helping with.
- Happiness and mental health
- Motivation and burnout
The first orders of management are the individual and the team. Ensuring the team has high trust and cohesion starts with each team member.
Expect that some team members will be purely business, and others may open up more about their personal lives.
That's fine, as long as there are no human resources concerns or conflicts of interest.
Finding and discussing happiness concerns both helps keep people motivated, and it can help pinpoint pain points on the team that affects more than emotional wellbeing.
- Guiding learning and growth
- Ensuring progression is visible to the individual and others
Coaching doesn't mean you have the be the expert in everything, as I thought when I first had direct reports.
Coaching means guiding the employee forward in their growth, pointing them to the right resources or mentors, and helping act as an "accountability buddy" to discuss progress with and share learnings.
It also means finding the right opportunities to lead projects, take on initiatives, or help with some of your management responsibilities that they share interest in.
- Fills in for other roles
- Project Manager
- Finds gaps in execution, makes sure they are filled
Finally, being an EM is about being the glue that holds the team together.
Ideally, the EM role ideally should differ wildly between teams and companies.
As an EM, you need to find what hampers execution the most, and what ways the team can improve. Take on or delegate some responsibilities that may fall outside of your job title that you think would benefit the company the most. There are often problems or opportunities that arise that others might not be considering and might not fall under anyone's role or responsibilities.
Will I enjoy Engineering Management?
When considering where you see yourself in 5 years, think through what you get the most satisfaction out of:
- Seeing a team happy and gelling well together, executing highly effectively, with high trust, psychological safety, and appreciation for each other, the product, and the company (EM)
- Building out a strong architecture or technical vision and aligning across teams (Staff+ Engineer)
- Thinking of cool ideas for a product and working with others across the company to see them come to life (PM)
In any of these roles, beyond Senior Engineer, it's going to require a shift to more communication and collaboration.
The question is also what you want to be accountable for:
- Technical vision, innovation, tech debt, and soundness?
- Direct reports and delivery teams (EM)?
- Product success and project launch feature adoption (PM)?
- Product marketing launch and materials (PMM)?
- Product adoption and brand image (DevRel)?
I've added an appendix describing some of these other roles you may be more interested in pursuing.
Breaking into Engineering Management
In the last 10 years, I've always approached new opportunities with the Engineer/Manager Pendulum.
You will have the best chances:
- Joining a scale-up, a company primed for growth, that would love to promote internally when new leadership roles become a necessity
- Starting there as an engineer, having the technical knowledge to help guide engineers.
If you're an engineer looking to become an EM, the good news is that most aren't.
Focus on managing up. Share information and ideas with your manager. Show willingness in working outside your engineering job description. Discuss career paths with your manager (bring it up if they don't in 1 on 1s).
I first became a Team Lead (with direct reports) in this fashion. Team Leads vary per company; there I was mostly a manager, but without some of the extra responsibilities beyond managing direct reports or a single project. It's a nice role that can propel you to Staff Engineer or Management roles, either one.
When it came time to decide on Team Leads, I went all in. I listened to the Manager Tools podcast, as suggested by my manager. I bounced ideas off of him in 1 on 1s about how to manage teams. I demonstrated a willingness to work with others.
You may even want to start proactively acting as a lead/manager would. Set up 1 on 1s with peers. Reach out to other teams. Help coordinate projects. As long as you aren't stepping on toes and are highly communicative, these are all great things to see from any engineer, no matter the role or title.
Adjusting to Engineering Management
Once you become an Engineering Manager (or Team Lead), think through what changes you need to make.
- Write less code
- Facilitate, don't dictate; drive conversation, let others decide
- Be in more meetings, and schedule more meetings
- Help facilitate async communication as well
- Be more proactive than reactive, thinking through pain points or future changes necessary to help the team and company scale
- Acting as a point-of-contact within the team, and being accountable for outside communications
Manager Tools is helpful in showing what your "tools" are:
- 1 on 1s
Most of all, you have to know how to scale your impact.
It's like thinking in Big-O notation. You can only scale yourself so far by doing it all yourself.
Your main focus must be the team: helping them help each other, communicate, learn, become highly motivated, feel recognized and rewarded, have the right context and mindset, and execute with the minimal processes that are necessary.
A final note.
Straddling the line between micromanagement and being absent isn't easy or apparent when you start.
This area may take the most time to learn.
Luckily, scaling your impact is the opposite of micromanagement. You should have buy-in from those you are helping–and special needs that will still result in scaling impact at the micro-level– if you're looking at involving yourself with others at the engineering level.
Through the list of Manager Tools, and having the right meetings and processes in place, you can be involved and present without being overbearing.
As a Director, this continues to grow in complexity.
It's good for the team to see your presence when you have time. Show that you care, and be there to answer questions, and be a fly on the wall.
But little tactics also can help. For example, turning my video off, letting people know I'm there for questions but multi-tasking, etc. I can be present in meetings (like Retrospectives) and be there for questions or input, without interfering and being overbearing, letting the team run the meeting and operate autonomously and asking questions or for help as needed.
Appendix: Other roles
Engineering Managers most often start as Engineers and may transition into Engineering Management often after 5+ years, sometimes with some type of Team Leadership role.
But there are other options to be aware of as well if you are looking at career options beyond Senior Engineer.
Technical Product Manager
As described above, the Product Manager role is in charge of the Why and the What.
In technology companies, the Product Manager may often benefit from being technical as well. Engineers with a background or strong interest and skill set in the domain and in working with others may do well in this role.
Whereas Engineering Managers manage people, Product Managers manage the product, creating a vision for what the product could be, and working with stakeholders to determine what requirements there should be to reach that vision.
They build a roadmap, which in its most basic form is an ordered list of product features, projects, and milestones.
Engineers most often will have a dual-track promotion system at a company, and even more so than Engineering or Product Management, they will look towards what comes next on the Individual Contributor (IC) track after Senior Engineer:
These are the next steps at Docker after mid-level Software Engineer roles:
- Senior Engineer: Making an impact team-wide
- Staff Engineer: Making an impact outside the team
- Principal Engineer: Making an impact outside the department
- Distinguished Engineer: Making an impact company-wide
Note that especially past Senior-level, these are all leadership roles in their own right.
You should expect to start writing less code in most cases, and you will have to work on your soft skills, as a manager would, if you want to move past the Senior Engineer level.
Moving from Senior to Staff, Principal, Distinguished requires looking at cross-cutting concerns outside the team, communicating on alignment and direction of functional areas (like frontend engineering) or technical domains that span team boundaries.
Like Managers, you start to become more accountable than responsible, and the leeway is high. Many are unprepared for the role and don't realize the amount of focus necessary on soft skills, learning to champion and sponsor initiatives and people, and how to lead with empathy, buy-in, and the people challenges you will face.
I'd recommend Will Larson's book for an in-depth overview of the subject: Staff Engineer: Leadership Beyond the Management Track
Project and Program Manager
A Program Manager is a professional who coordinates projects across an organization. They ensure everything runs smoothly and follows program goals while maintaining a high level of detail for each project they oversee throughout their workday. Workable
Project Managers focus highly on management over leadership, ensuring the projects are running to plan and are meeting objectives and targets.
Program Managers then focus across projects, and they also focus holistically on the quality of project management as a company. The management of projects often spans teams or departments with some alignment towards a "program" or a special interest of a company.
Many companies, especially smaller, don't have either role, and thus these responsibilities sometimes fall on the EM, PM, or delivery team.
Dev Rel focuses on marketing towards engineers, in a manner that helps build a relationship and community and helps promote adoption and perception of a product and brand.
While not a manager role in itself, there are manager roles available, and it is an alternative path for those looking at Product Management that is more interested in the Marketing aspects.
See Marino Wijay's short video contrasting with Product Management:
Product Marketing Managers
PMMs work with Product Managers on launch plans and materials of the projects the PM is responsible for.
More to come!
I plan on talking further about the Engineering Management craft and getting started in future blog posts.
ZoCodes and others have suggested future ideas they would like to hear about.
Feel free to comment or DM me on Twitter if you are interested in further discussion or topics!