Gallup's State of the Global Workplace: 2023 Report is a good read for anyone passionate about improving the synergy between engaged employees and successful workplaces. The report specifically underscores the role of a manager in amplifying that synergy. One regularly sees the positive impacts of that amplification, as well as the negative ones, when it is degraded. As such, I deeply care about harnessing the power of effective management, firmly believing that “there are no bad teams, only bad leaders.”
That said, this isn't another article about leadership principles. As an engineering leader, I've worked with, observed, and learned from the successes and failures of many engineering leaders and managers. My reflections from coaching and mentoring various engineering managers have guided me to share my perspective on being an effective leader in a software R&D team.
Who should read this?
Those who are already engineering managers and others who'd like to be.
I really enjoy what I do, and believe that Engineering Management is a terrific career choice. It exerts way more influence than many realize. I hope this article helps someone take this path with eyes wide open. As I write this, I am aware that perhaps I offer a contrarian view to a broader industry trend of “flattening the organization” by “optimizing” the management layer. I suppose as long as the optimization fits the needs of the organizations attempting to do so, we shall be all right.
What will be covered?
I'm not going to spend too much time discussing the platitudes of this role, such as:
- Focus on breadth vs. depth
- More time spent in meetings than you'd want
- Needing a strong multitasking muscle
- Reduced time to perform “deep work”
- Constant interruptions to attention, etc.
Although they are true and come with the territory, I'd like to discuss the key facets you must focus on. Think of it as a general-purpose operating system scheduler that takes care of both priority and fairness. You might find yourself prioritizing one or the other facet of this role at any given time, but if you are not fair, i.e. you neglect some other aspect for too long, you'll find your effectiveness in this role wane.
These facets are:
- People management
- Process management
- Technology management
- Delivery management; and
- The elusive, hard-to-quantify or qualify, ethereal aspect of keeping the team together “The Glue”.
The time you spend on these facets will depend on your ecosystem (organizational maturity; team’s needs and maturity; etc.) As your career grows, i.e. you manage multiple teams (or managers), it will even vary by team. But regardless, these are the facets you’ll deal with regularly, and you gotta prepare and train yourself to be effective in these.
Org design - It's really important to align closely with business priorities and have a point of view on what's coming in the way of your team's effectiveness. That might be in your own team or another sibling team - e.g. your team's effectiveness on frontend engineering might not be optimal because of a lack of UX designers in the design team or a lack of SRE bandwidth, for that matter, or a product manager. In your own team, you might have “ratios” in mind - e.g. your target ratio of SWEs to SDETs, as well as how many direct reports you, or a manager under you, (should) have. In relatively smaller organizations, the overall organizational design might be your manager's purview, but a good manager would definitely seek and value your feedback. Be prepared to provide it and discuss or debate it with your manager.
Hiring - you are lucky to be provided a req (requisition), and next would be to navigate the Talent Acquisition (TA) world to get it tracked and listed. Then, the hunt begins. You will be spending time writing a Job Description (JD); creating an interview planner; prepping the interviewers; working with the recruiting coordinators; making time for yourself and your team to interview the person; running calibration sessions with the recruiter; reviewing the applicants, which could be a firehose; conducting debriefs with the panel; getting offer approval; creating onboarding plan; and finally, spending time training / onboarding your new team member.
If your organization leverages contractors for staff augmentation or SoW-based projects, that will likely be a separate workstream for you. You can also imagine corollaries of hiring, e.g., building your “engineering brand” to stand out from the pack, which might involve writing tech blogs, presenting at conferences, and attending local networking events.
Performance management - there are some interrelated aspects here - career planning for your team; goal setting / alignment/reviews, if you are one of those organizations that use goal setting frameworks for performance measurement or bonus / variable compensation (think OKRs); calibrating / assessing general performance of your team and reporting using frameworks such as 9 Box; writing and delivering performance reviews. You might be having “difficult conversations” and managing sub-optimal performance using performance improvement plans, which may lead to a termination, for which you will likely need to maintain and provide sufficient documentation.
Some of these might be continuous, while others happen at a cadence. Many companies perform reviews and assessments twice a year. That might sound manageable, but you will find that when it happens, it is fairly taxing/involved because it comes when everything else is also taking place. You might find yourself with a relatively large number of direct reports because of sub-optimal organizational design or because one of your subordinate managers left. Be on the lookout for such an “unfortunate confluence of events.”
Compensation planning - this is an important aspect, worth discussing separately. In relatively smaller organizations, your manager might take care of this, but I'd highly recommend engaging in this process regardless to build your muscle. More or less it boils down to you getting a fixed dollar amount (budget) to provide raises to your team. That budget almost inevitably never feels sufficient. You might need to make crucial decisions, such as allocating that budget based on individual performance. These are truly crucial decisions because they can and will influence retention and attrition rates.
Fortunately, tools / human support should be available for comp benchmarking, depending on your organization's HR maturity. I have found that it is essential for a manager of managers to involve the managers in this process directly. This is a good learning opportunity to prepare them to make hard decisions and defend them.
Staying in touch - with regular 1-1s with your direct reports and even skip-level. Appropriate consideration should be given to the amount of time you allocate for this - e.g. with your tech lead or team lead or architect or a subordinate manager, you might spend more time than others on your team. Lateral and upward 1-1s are also important for building professional relationships with those who might need your help, or you might need help from - invest time to leverage in times of need.
You might also be mentoring someone outside or your team and/or getting mentorship from someone else. All of this takes a fair amount of time. Remote working cultures only make this harder while underscoring its importance.
Team meetings - I have found that as a manager, your perspective while sitting as a guest in meetings needs to be quite different from when you are not managing a team. You are not only ingesting information for yourself but also taking notes on what you need to distill from a meeting for your team members who might not be in a meeting. This aspect is super important to manage what I call “information silos” that inadvertently happens when a manager attends a meeting with the mindset of an IC.
In addition to your 1-1s and your Agile development rituals, you might consider hosting a regular “staff meeting” with your direct reports to make sure that you are keeping them informed of what's happening broadly at the company or a change that might be coming that might impact the team's ways of working. It is best for your team to hear about the change and “the why” of the change from you first than from the “change agent.”
Evangelizing your team's work - actions might not, and, in the modern era, often don't, speak louder than words. You / your team might be doing everything “right” and meeting / exceeding the expectations, but you might still feel like you are missing the spotlight/recognition. I don't like this aspect, but I have often found that to be true. Ever heard of “squeaky wheel getting the grease”? I am definitely not suggesting you become the squeaky wheel, but the opposite actually, i.e. be a smooth wheel, but don't just assume that keeping things going smoothly will be sufficient.
You will need to wear a marketing hat for your team. You might need to consider evangelizing your team's work by publishing regular newsletters/updates, taking a speaking opportunity in an all-hands meeting, ensuring that the team is doing demos of what they are building in a broader forum, publishing KPIs, etc. You might also nudge people around you to support you in this - for example, nudge the product managers supporting your team to share regular “release news” on new capabilities that your team is churning out.
Processes get a bad rap! Fundamentally though, I see them as “how we work” and nothing more. I generally find that a good way to think about processes is to map them to the classic DevOps lifecycle, as shown below.
As an engineering manager, you might take each of these phases and use the framing to establish and document your ways of working.
For example, under code, you might say how your team manages repositories, does branching, code reviews, pair programming, does version control, and tooling, such as IDE, etc. If your team uses Agile methodologies for development, then you would want to standardize your Sprint rituals (standup; sprint planning; backlog grooming; sprint demo; retrospective) by stating the cadence at which these syncs take place, their core purpose, the day of week, and duration.
Clearly outlining the participation expectations would help you manage the group's collective time better. Not every team member is required to participate in every Sprint ritual. Think about their role (engineering manager, product manager, UX designer, architect, tech lead, developer, tester) and which rituals would be helpful for them to contribute to or derive value from.
Unplanned work management - Experience has made me realize that unplanned work management/scrubs being a first-class citizen in Agile rituals is essential.
A typical SaaS team will be exposed to the following unplanned sources of work: customer-reported defects; security vulnerabilities; incident postmortem actions; internally reported defects; and ad hoc requests/tasks from other teams. I encourage engineering managers to keep up with those regularly and ideally scrub these in a dedicated “unplanned work scrub” meeting with key stakeholders, such as your PM and/or tech lead. Having this scrub as a backstop to your “normal handling” will help you ensure that these don't balloon to a point where your planned work gets impacted, your stakeholders (e.g. customers or customer support or security team) are vocally dissatisfied. If it does come to that, consider conducting a “clear the field” type motion, where you might tackle the unplanned work by planned “bashes” e.g. customer customer-reported bug bash or security vulnerability bash.
Other top of mind things in the process arena are to use the methodologies and frameworks provided in your department for tracking engineering KPIs / metrics and guide your team accordingly. BTW, metrics around your team's productivity will also help you keep your stakeholders informed. Examples of key metrics include product usage; data center/cloud spending; volume/backlog of unplanned work that might've piled up; deployment/release frequency; change failure rate; incidents, etc. On incidents, having a finely tuned incident management process, including on-call / paging system configuration/incident command/drills/ root cause analysis creation/action item tracking will serve you well.
Gathering the above in your team's wiki space, organized using a sound information hierarchy, will go a long way for you. As a manager of managers, I value seeing the managers who have well-organized wiki spaces for their teams and are constantly finding ways to spruce up those. To me, it shows a deep pride of ownership.
If you are a department leader or a manager of managers, you might want to spend some time thinking about the “span of standardization”, i.e. the processes you'd like all of your autonomous teams to follow consistently, and those where you leave it to the team's engineering manager to decide. In many countries, governments are structured so that certain concerns/powers are at a federal/central level (e.g. military), while others are at a state level (e.g. schooling). In the same way, you might standardize incident management across all your teams, have recommendations for Sprint rituals that your teams may or may not adopt, and leave others completely open/undefined. It would be helpful for you as the department leader to clearly state how each process is governed.
As an aside, it was an “aha” moment for me when I noticed how the DevOps lifecycle is a good representation of the SaaS world. The Dev side is basically representative of the first 'S' of SaaS, i.e. software development, and the Ops side of the second 'S', i.e. service operations. Was I late to that realization, or did you, too, just have a eureka! moment here?
This perhaps would come naturally to you, as many (most?) engineering managers come from a technical background and were engineers themselves once. In this part of the role, you might find yourself architecting/designing a system/component; writing code and/or reviewing code; and writing and/or executing test plans. You might be administering the tools your team uses - e.g. Jira workflows for your team's project or Pagerduty / Opsgenie schedules for your team. Or you might be brainstorming with your team on specific implementation details, or with product management on requirements, or with architects making technology decisions. As an engineering manager, you might come from a software development background, software testing, or infrastructure engineering. As such, you might provide a more pronounced lift to the team in your specific area of expertise.
I generally value tradecraft. Not saying that there are no exceptions to it, but a rule I am mindful of is that engineers are generally passionate about their tradecraft - a developer about software development, a tester about software testing, a reliability engineer about software reliability, an infrastructure engineer about systems and networking, and so on. The key is to find people who are “classically trained” in a certain discipline and are passionate about it, and then let them thrive in their role in an autonomous team. Another way to look at it is that I generally steer away from “the handyman model,” and instead, I let a plumber do plumbing and an electrician do electrical work. The expertise and the output shines. A “full stack team” of engineers fares better than a team of “full stack engineers,” in my experience.
I find that the best way to think about this part is that Delivery Management is not something that you can or should chase but rather something that you will auto-magically derive if you manage to harness the powerful combination of people + processes + technology management. Not chasing it feels odd and uncomfortable, though, because at the end of the day, a typical engineering team's success is measured by their delivery output - results matter. As an engineering manager, you've got to overcome that discomfort while managing stakeholder expectations. Where there are gaps and challenges, don't hide them from your stakeholders; instead, lean on open communication, lead with vulnerability, and don't hesitate to ask for help.
There are some specific aspects and practices here, though, that you'd want to master. The practices would vary by your company ecosystem and are hard to generalize. For example, you might be in an organization that does short-term (e.g. quarterly) roadmap planning and delivers using fortnightly Sprints or in one with no short-term roadmap planning. Accordingly, you might find yourself planning your initiatives and projects, participating in stakeholder reviews, forecasting completion dates, resolving inter-team dependencies, surfacing risks, balancing delivery plans with unplanned work, ensuring acceptance criteria, etc.
Just like two things - death and taxes - are certain in life, the expectation for delivery timelines is certain in life at work. Embracing that, and aligning your delivery practices with that in the modern world of iterative software development, would go a long way towards your team's success.
As I stated earlier, this part is elusive, hard to quantify/qualify, and an ethereal aspect of keeping the team together. As such, I can't find many things to outline here, and for the most part, I'll let it be. It could be anything you need to do at any time - you might find yourself coding/testing/documenting, talking to your customers, or resolving conflicts & disagreements, i.e. building alignment to move in a tight formation - basically, acting as an owner of your team and always in control of its success.
I come from a school of leadership that is constantly focused on “improvement of the function, vs. just cruising.” If everything looks alright and in a good place, look harder - you've likely missed something. Or, if even after looking hard, you don't find anything, perhaps it's time for a change of scenery (think Peter Principle). One thing that I've found particularly and uniquely effective for becoming a better / stronger glue for your team is to read management & leadership books. My top three book recommendations are:
- Extreme Ownership: How U.S. Navy SEALs Lead and Win
- The Five Dysfunctions of a Team
- Crucial Conversations: Tools for Talking When Stakes are High
(And I dare squeeze one more in - after all it is my blog: An Elegant Puzzle: Systems of Engineering Management.)
Created partly with humor and mostly sincerity, the illustration below indicates the life of an Engineering Manager in a real and thriving R&D environment, the name of which, for the sake of confidentiality, I can only state rhymes with pretty good privacy.
I have not seen the use of this recently but distinctly remember early in my career when I decided to transition from a technical lead to an engineering manager - my colleagues “congratulated” me for moving to the “dark side!”
Maybe that is the topic for another blog - “The Dark Side of Engineering Management”. I digress, though. On the other hand, if your manager is not trying hard enough, perhaps you might encourage them to focus on one or more things I shared in this article. A good manager would sincerely value that feedback. Thanks for reading (or scrolling down) till here!
