You’re a software engineer with many years of technical experience, and you’ve decided you want to kickstart the process of working towards becoming an ‘Engineering Manager’.
So what do you need to know? Let’s discuss…
- Team Leader
- Incremental Steps
- Manager Cheat Sheet
As a software engineer you have a few different paths available to you for career progression:
- Senior Software Engineer
- Staff Software Engineer
- Principal Software Engineer
- Tech Lead
- Engineering Manager
Note: the role hierarchy can change per organisation
You may notice some of these roles are not like the others 😉 It’s worth recognizing that there is a slight separation between the last two roles (Tech Lead, Engineering Manager) and the rest of the roles, in that the last two are more closely related to management than the other roles.
I’ve grouped these roles together like this because they tend to be the progression path for a lot of engineers. They exhaust all possibilities as far as ‘engineering’ as an IC (individual contributor) before finally residing themselves to a management role.
This doesn’t have to be the case though. You might decide to make that shift to a more management role before progressing through the more senior engineering roles, but you may find some organisations will expect a certain level of engineering experience.
When moving up the career ladder you’ll typically find that between roles there is a fair amount of cross-over responsibilities, but for the purposes of this post let’s focus in on the last role (‘Engineering Manager’) and what that entails.
Below I have listed a few different areas of responsibility (as I see them) associated with an Engineering Manager role, and of course these responsibilities can change depending on the culture of where you work.
Meaning it’s a good idea, when interviewing for an Engineering Manager role, to ask clarifying questions in order to help you understand the expectations of that role (in the specific context of that organisation).
Note: to learn more about what to talk about during an interview, read my post ‘Interview Topics’
For example, some companies have dedicated ‘Project Managers’; meaning an Engineering Manager doesn’t have to worry too much with that aspect of the job, and can instead focus on technical leadership responsibilities.
Another example is the role of a ‘Tech Lead’; some organisations use this name and ‘Engineering Manager’ interchangeably, while others treat them as distinct roles (and in some cases a less management/more code oriented role than an Engineering Manager).
Note: see also my post ‘Project Management in Five Minutes’ which discusses Lara Hogan’s venn diagram of various leadership roles, as well as a project management checklist.
A good engineering manager must be committed to building great software, great teams, creativity, careers, and general welfare of the team members.
With that in mind, the following list feels like (to me) a reasonable breakdown of the various jobs you (as an Engineering Manager) will be expected to look after…
- Team Leader
- 1:1’s (read my post on better 1:1 practices)
- Career development
- Technical Lead
- Define and communicate with non-technical stake holders
- Guide the architecture and technical design
- Resolve conflicts around technical discussions
- Write code and work with the engineering team
- Project Management
- Define technical requirements
- Work with non-technical stake holders to define user stories
- Breakdown large tasks into smaller tasks
- Prioritise work and revise priorities when necessary
- Establish schedules, estimates and milestone deliveries
- Run and guide the technical aspect of the project
- Up: team/project status and health to upper management
- Down: updates/decision making to your team and direct reports
- Across: identify, engage and collaborate with other teams
- Work with recruiters to define required engineering roles
- Screen resumes
- Interview candidates
- Assist onboarding new recruits
The most important skill you’ll need, if you are to be effective as a manager of people (e.g. your direct reports, your managers, your stake holders: both technical and non-technical), is communication.
You need to be able to build strong and trusted relationships with these people. You need to be able to challenge them and push them to do better, for their own success, not the business.
To elaborate further: helping people to reach their goals, to be happy and to help them find doing what they enjoy doing (while still challenging them) will ultimately yield better value from the work they do, and as a side-effect the business will benefit more greatly than if you push someone down another path designed with the business in mind.
This means caring personally about the people you are interacting with and doing what you can to bring out their best. It also means recognising when someone isn’t a good fit for your team, and in extreme cases ‘letting them go’ can actually work out better for both them and the business.
Patty McCord discusses this topic in-depth in her book on culture building at scale “Powerful: building a culture of freedom and responsibility”.
In essence let’s help people work on things that will realize their ambitions, but not at the expense of the business, more in co-operation with the business. But if your ambitions don’t fit with the business, then maybe it’s best for you and the business to separate ways. I like that as a healthy way for both sides to either work together for a common good or separate ways for an equally better outcome.
When building relationships you should be mindful of not falling too heavily on one side or another with regards to ‘professional vs personal’. Find a balance, and if unsure err on the side of building a respected professional relationship, as friendship and a greater sense of personal appreciation/understanding (in some cases) will naturally occur.
Below I’ve listed some useful resources for learning how to communicate effectively (these are all highly recommended):
- Authentic Communication by Fred Kofman.
- Radical Candor by Kim Scott.
- SBI: Situation, Behaviour, Impact a methodology developed by The Center for Creative Leadership.
- The Hard Thing About Hard Things by Ben Horowitz.
Note: ‘Authentic Communication’ is actually taken from a larger work called Conscious Business: How to build value through values.
As someone who is going to be mentoring and supporting a team of engineers, it is important you understand the motivations and what drives your team. In doing so you’ll be better equipped to find them the right roles within the organisation that brings out their best work and allows them to grow in the areas that matter the most to them.
It’s also important to sometimes think as an ‘engineer’ again. When you design and develop large scale systems you identify bottlenecks and ways of working that reduce complexity and support certain services to scale. Now think about that when you’re handling management duties.
Do you find yourself handling tasks, or using processes, that take up a lot of time? This might be ok for now while you’re responsible for a small team but how will that work out for you once you start taking on more teams and more responsibilities? Be mindful of the tools and processes you use and refine them constantly.
The single biggest question you should now be asking yourself is:
“Why do I want to become an Engineering Manager?”
This is really important, and requires you to be very honest and open with yourself (not only will you suffer the consequences of a bad decision, but so will everyone else who is relying on you).
If you answered the question with any one of the following (or more), then you need to seriously consider an alternative future career path; simply because you truly won’t be happy in this role otherwise:
- I want more money
- I want a promotion
- I want a better job title
- I’m bored of writing code
To me, a good reason to want to progress towards being an Engineering Manager is when you deep down know that your enjoyment comes from helping people and having a positive impact in their ability to do great work and helping them to progress in their career.
If that is your motivation, then you have the right mentality for this type of role. If that’s not your intent, then that’s OK (don’t worry) but you will need to consider alternative options and really figure out what it is about working in tech/engineering that you enjoy, and do what you can to move more in that specific direction.
Ultimately if you want things like more money or a promotion or a better job title, that will require you to have more impact at work, and to do that means you need to lift your head up from your laptop and engage more widely with the organisation and the teams within and start demonstrating more broadly the potential positive impact that you can have.
Note: see also my post on ‘Architecture Interviews (and other thoughts)’, where I cover what I look for when interviewing an Engineering Manager candidate.
You might not be quite ready for a straight jump up to Engineering Manager, so what can you do in the meantime to help you move towards that goal? Here are some ideas…
- Most companies have a mentoring program, and even if not it doesn’t prevent you from reaching out to colleagues and offering them your help, guidance and the benefits of your experience (if they choose to accept it)
- Take Responsibility
- Get involved with cross-team discussions
- Create a working-group for a topic you care about
- Support your team and reach out on their behalf if you’re able to
- Take the responsibility of leading a project
- Beyond that take the opportunity to lead a team
- Help non-technical stakeholders understand the team’s work
Manager Cheat Sheet
BuzzFeed recently hired a new Engineering Manager 🎉 🙂
Her name is Svetlana Bozhko and she kindly shared with me a ‘cheat sheet’ (of sorts) that helps her stay on-track/focused.
I know of other Engineering Managers/Directors of Engineering (some of whom work for a few of ‘the big 4’) who use a similar approach, and it’s something I personally like.
Here’s an example of what such a ‘cheat sheet’ might look like:
- Am I ready for today’s meetings?
- Can I reduce the length of those meetings?
- Can I cancel any of those meetings?
- Recruiting, Hiring, Interviewing
- Candidate follow-ups
- Sell the company, its vision, roles etc
- Close great candidates
- Observe team health
- Casual feedback sessions
- Daily standups
- Am I ready for these standups?
- Any important company-wide updates?
- Are we on track with critical projects?
- Any docs/guides needed to be written?
- Any PRs waiting my approval/feedback?
- Should I step in on any engineering tasks?
- Have I setup my goals for this/next week?
- How do I progress with my goals?
- 1:1’s and enhancing their strengths
- Who needs additional feedback?
- Any tasks I can delegate?
- Review all tasks in backlog
- Any design/architecture discussions?
- Divide tasks into smaller ones
- Plan team retrospectives
- Give status reports to my managers
- Who else do I need to update?
- What do I need to do to be more successful in my role?
- Any training I can do, mentoring I can give, books I can read?
- Ensure team vision is aligned
- Ensure team expectations are understood
- Any team events we should consider?
- 1:1’s focused specifically on career growth
- Anyone moved into new roles?
- Do I need to set new expectations?
- Any changes to the career ladder?
- What changes would make it more fun to work here?
- Challenge and question existing processes
- Are the current sprint metrics still useful?
- Any strategic ideas to improve current projects?
- Do we need a new project?
- Dow we need to stop a project?
- Any strategic hires needed?
- Budget and capacity planning
So what do you think? Is there anything here that you disagree with, or something you feel I missed altogether? Let me know on twitter!
But before we wrap up... time (once again) for some self-promotion 🙊