28,79 €
Producing delightful and customer-centric digital products has become a standard expectation across businesses. Engineering managers are uniquely positioned to make a huge impact on the success of products and the software systems that power them. With the help of this guide, teams and companies can develop meaningful and maintainable systems.
This book facilitates you to find your footing as an engineering manager, develop a leadership style, balance time between engineering and managing, build successful and sustainable engineering teams in different settings, and work within constraints without sacrificing technical standards or team empathy. You'll learn practical techniques for establishing trust and authority, allowing you to create a cohesive and high-performing engineering team. You'll discover effective strategies to strike the right balance between contributing to technical work and collaborating with your team, ensuring optimal productivity and collaboration.
By the end of this book, you'll have the tools and knowledge necessary to thrive as an engineering manager. Whether you're just starting out in your role or seeking to enhance your leadership capabilities, this handbook empowers you to make a lasting impact and drive success in your organization.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 500
Veröffentlichungsjahr: 2023
An insider’s guide to managing software development and engineering teams
Morgan Evans
BIRMINGHAM—MUMBAI
Copyright © 2023 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Group Product Manager: Rohit Rajkumar
Publishing Product Manager: Himani Dewan
Book Project Manager: Sonam Pandey
Senior Editor: Rashi Dubey
Technical Editor: Joseph Aloocaran
Copy Editor: Safis Editing
Proofreader: Safis Editing
Indexer: Pratik Shirodkar
Production Designer: Nilesh Mohite
DevRel Marketing Coordinators: Nivedita Pandey and Namita Velgekar
First published: September 2023
Production reference: 1100823
Published by Packt Publishing Ltd.
Grosvenor House
11 St Paul’s Square
Birmingham
B3 1RB, UK.
ISBN 978-1-80323-535-6
www.packtpub.com
This book is dedicated to the memory of my mentor, J Sam Frank.
– Morgan Evans
Morgan Evans is an engineering management professional, mentor, advisor, and leader. She has worked in software development for the last 18 years as a coder, manager, and executive. She has led teams working on consumer products at scale in all sorts of circumstances, including multi-region and global teams across more than 30 countries. Morgan lives in New York City and runs a fractional CTO practice, where she lends her expertise to new ventures.
I want to thank Zebulon Holt, who, through countless hours of mentoring, first taught me what it means to be an engineering manager.
To Edward Cudahy, who taught me how to lead world-class engineering teams.
And to the team at Packt for their help and support throughout the writing process.
Leslie Borrell is a technology and product executive with over 20 years of experience, using agile values, principles, and practices to deliver products and platforms for companies at all stages. She has demonstrated a unique talent for building engineering teams that overcome obstacles and challenges to deliver above expectations and find simple solutions to complex problems. She combines her deep understanding of agile values, engineering ethos, and practices that promote early delivery with her core values of empowerment and accountability to nurture inspired engineering teams. Leslie has always been at the forefront of the technology industry, seeking out the newest areas where she can apply her experience, tackle new challenges, and expand her thinking. As a change agent, she has an organization-wide impact, championing efforts such as reducing time to market, improving diversity and inclusivity, and enhancing quality and stability through continuous delivery practices. Throughout her journey, she remains passionate about efficiently scaling support and operations through intuitive internal tools, data, and tight feedback cycles. Leslie is utilizing her skills and experience to establish her own company called Carefully, a platform for the caring economy. The company’s mission is to tackle a crucial global challenge - childcare.
Leslie’s specialties include agile principles and practices, lean thinking, distributed development, project planning and management, analysis, continuous improvement, and continuous delivery.
Will Olson is an engineering manager with a knack for web application development. For over nine years, he’s been deep in the coding trenches, and for the past three, he’s also led distributed software engineering teams.
He got his start with an electrical engineering degree from the University of Nevada, Reno. Afterward, he began a career in which he juggled everything from working at a travel agency, building a custom CRM, to co-founding his own start-ups. Today, Will leads a software engineering team at Procore, a top construction management software company.
When he’s not managing his team, you’ll find Will exploring the indie hacker scene, where he continuously expands his skills and experiments with different emerging technologies.
Tristan Jung is an engineering leader with 10+ years of experience at LinkedIn and Twitter. Most recently, he led the core products engineering organization at Twitter and was the Twitter Toronto site lead. He led teams that built product features across the Home, Tweets, Profiles, Notifications, Search, and Trends surface areas.
Outside of software engineering, Tristan enjoys spending his time practicing photography, leading event organizations for various gaming leagues, and live production for events.
Hello and welcome to the Engineering Manager’s Handbook! In this book, we usethe term engineering manager as a catch-all term for position titles such as software engineering manager, software development manager, and web development manager. Engineering manager has become the prevailing way to refer to these positions within the world of digital product development, so for better or worse, we will uphold that convention here.
There are excellent books that cover leadership topics in general and engineering management in particular, but there are not many that attempt to introduce as many topics as possible, including available research papers. This book endeavors to be that resource. In true handbook fashion, this book provides breadth more than depth, with the intention of conveying to you the appropriate terminology and concepts to build upon as needed. In touching upon important topics for engineering managers, emphasis is placed on how to think about the problems of management in order to arrive at reasonable solutions. I hope to convey why behaviors are important rather than just describing the ideal behaviors.
Comprehensiveness is an elusive undertaking, so I welcome any feedback you may have on what might further complete this text.
This book is for software development professionals who are currently in leadershiproles or who aspire to be.
This book is intended to be useful not only to new engineering managers but also to those with experience. Since no two managers have identical career trajectories, there are almost always ideas that a manager hasn’t been exposed to yet. In covering many topics, I hope to provide something new and useful to almost any engineering manager.
Additionally, this book is written to encompass strategies that apply to a wide set of workplace environments. Software development happens not only at tech companies but also companies of all sizes, growth stages, industries, and so on. Engineering managers who work within non-tech companies and non-product companies, such as those in corporate or small businesses, need strategies that work for them to provide good engineering management. This book is written specifically with these engineering managers in mind, providing differing approaches to consider under different circumstances.
Chapter 1, An Introduction to Engineering Management, poses the question, “Why do we need engineering managers?” and provides a rationale. It gives an overview of the obvious and not-so-obvious responsibilities of engineering managers. It provides foundational information on how engineering managers spend their time in different workplace contexts. Finally, it covers key concepts in the transition, from an individual contributor to a manager position.
Chapter 2, Engineering Leadership Styles, introduces what leadership styles are and where they come from. It reviews some of the most common leadership styles and how well they apply to different engineering team settings. It also describes how an engineering manager can examine and develop their own authentic leadership style.
Chapter 3, Common Failure Modes for New Engineering Managers, presents the common pitfalls and failure scenarios encountered by new engineering managers. You will learn why these failures occur and how they can be avoided.
Chapter 4, Leading Architecture, explains the engineering manager’s role in technical systems design. It differentiates between the roles of manager and architect. It explains the responsibilities of the engineering manager and those of the architect, including what to do when they don’t agree. Finally, it introduces Conway’s Law and the importance of considering team design during the architectural process.
Chapter 5, Project Planning and Delivery, describes the engineering manager’s role in the project and software delivery process. You will learn the key aspects of planning and delivering software, regardless of the project methodology used.
Chapter 6, Supporting Production Systems, presents the engineering manager’s role in providing technology robustness. It describes how to build reliability into your team culture. You will learn common industry approaches to supporting and maintaining live systems and how to manage the moments when they inevitably fail.
Chapter 7, Working Cross-Functionally, details the best practices for working seamlessly with product management teams, design teams, and any other cross-functional partners, maximizing the productivity of this relationship. It also covers conflict resolution across functions and teaches you how to use RACI charts to ease the stress of collaboration.
Chapter 8, Communicating with Authority, introduces communication as a key area of responsibility for all engineering managers. This chapter argues that communication is one of the biggest force multipliers that engineering managers can master. You will learn best practices, how to structure communication, and how to communicate with specific audiences.
Chapter 9, Assessing and Improving Team Performance, covers how to evaluate the health and operations of engineering teams. You will learn techniques to optimize for success at the individual and team levels.
Chapter 10, Fostering Accountability, introduces accountability as a key characteristic of high-performing engineering teams. It explains in detail how an engineering manager can create a culture of accountability for their team.
Chapter 11, Managing Risk, explains what managing risk is and how it is a core responsibility and skill for engineering managers. You will learn how, when, and where to manage risks for your engineering team.
Chapter 12, Resilient Leadership, introduces the importance of resilience on engineering teams and explains the engineering manager’s role in change management. You will learn why resilient teams perform better and how to instill a resilient culture in your team.
Chapter 13, Scaling Your Team, provides insider tips for scaling up an engineering team. You will learn about hiring best practices, techniques to onboard new hires, and how to manage a growing engineering team.
Chapter 14, Changing Priorities, Company Pivots, and Reorgs, answers the common questions of what to do if your organization has constantly changing priorities, unrealistic timelines, and a lack of focus. It details how engineering managers can lead with empathy during times of major change to improve outcomes for engineers and companies.
Chapter 15, Retaining Talent, walks you through a step-by-step plan to retain your engineering teams and create a great workplace environment.
Chapter 16, Team Design and More, presents basic concepts about structuring and operating engineering teams. You will learn the most common team alignments and the pros and cons of each. This chapter includes details on how individual characteristics affect team operations and how to consider Conway’s Law when designing teams.
This book assumes you have familiarity with foundational concepts in professional software development, such as unit testing and software version control. As such, software development terminology is often not defined so as not to be too tedious for the target audience.
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Once you’ve read Engineering Manager's Handbook, we’d love to hear your thoughts! Please https://packt.link/r/1803235357 for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily
Follow these simple steps to get the benefits:
Scan the QR code or visit the link belowhttps://packt.link/free-ebook/9781803235356
Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directlyIn this part, you will get an overview of what comprises the engineering manager role and why the work they do matters. You will learn about different approaches to engineering management and how to choose the right approach for your workplace. Finally, you will learn some common ways that engineering management can fail to produce the desired outcomes and how you can avoid those failures.
This part has the following chapters:
Chapter 1, An Introduction to Engineering ManagementChapter 2, Engineering Leadership StylesChapter 3, Common Failure Modes for New Engineering ManagersSoftware engineering and development teams are growing every year at an estimated rate of 25% (https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm). The digital transformation of businesses has led to steady increases in the number and variety of web and native app engineering positions. With the high cost of software engineers, all employers have a vested interest in the effectiveness of these teams. As software continues to consume the world, we have an increasing need for engineering managers to lead, inspire, support, and sustain our teams.
Many people have a hard time wrapping their brains around engineering management as its own discipline. When I tell others I am an engineering manager by trade, a common reply I get is, “Oh, like a project manager?” The skills of a project manager may be helpful to an engineering manager, but the work is different and requires a distinct skillset.
In this chapter, we’ll introduce why we need engineering managers and what those managers must achieve in order to be successful. We will learn why the transition from engineer to manager can be such a difficult and jolting change, and we’ll see why managing up is just as important to this role as managing down.
By the end of this chapter, you will understand which traits differentiate experienced engineering managers and what you must do to earn the respect and trust of your team.
This chapter is broken down into these main topics:
What are engineering managers responsible for?Introducing the four activities of engineering managersHow do engineering managers spend their day?How to prepare yourself for a career changeLet’s dive in.
An engineering manager’s position exists to provide engineering teams with day-to-day leadership and representation. They keep alignment within the team and serve as the team’s representative in cross-functional and leadership settings. In other words, engineering managers exist to produce long-term successful outcomes for engineers and companies.
When considering engineering manager responsibilities, you might think of a litany of tasks. Timely project delivery! Robust systems design! Mentoring! Hiring! The list goes on endlessly. The day-to-day tasks of an engineering manager are variable, but the broad responsibilities are the same: maintaining a team capable of serving the needs of the business, producing mechanisms to make the team self-sustaining and scalable, and owning the reputation and impact of the team.
This definition may leave you wondering: where are the fun parts? What about growing and teaching and building a strong engineering culture? While each of these things is important in its own right, an engineering manager should understand the order of operations: that these practices result from the necessity of producing good work, not the other way around. Your responsibility is not to produce good engineering culture; it is to produce good work that serves the needs of the business. Great engineering practices must result from the intention to produce great engineering work.
Let’s go through each of these responsibilities in turn.
Engineering managers set their teams up for success by understanding the business and organizational settings they are in and preparing their engineers to thrive in those settings. As illustrated in Figure 1.1, engineering managers interpret a variety of inputs to determine how best to direct their team. This responsibility may require attention to many areas, such as ways of working, technology choices, staffing, team culture, and cross-functional interactions. While we may only know so much at a given time, it’s helpful to consider anticipated future changes in needs as well as emerging technology trends:
Figure 1.1 – Engineering manager inputs and outputs
Here are some questions you can use to consider this:
Is my team working closely enough with business leaders to understand their domain and needs?Is my team capable of serving those business needs today or is it a stretch?Do we have the tools and processes we need to deliver?Do we have the talent we need on the team?Do we have the supporting cross-functional roles we need to do great engineering work?Do we have a shared vision to be inspired and make consistent choices?Do we have the support and guidance to grow and improve as engineers?Not all of these considerations may be under your direct control to change, but they are still helpful to identify. It may be that you will need to spend more of your time influencing factors outside of the engineering team to help your team and company be successful.
Engineering managers have a responsibility to optimize their teams. They improve engineering workflows and reduce dependencies and repetitive tasks. Self-sustaining teams minimize dependencies that hinder them in their efforts to achieve their objectives. Scalable teams minimize software delivery steps and eliminate bottlenecks. The mechanisms to achieve this may include the use of tools, conventions, documentation, processes, or abstract things such as values and principles. Any action that produces a tangible improvement in the speed, reliability, or robustness of your team’s work is worth your consideration.
Theme – continuous improvement
In this chapter, we will introduce traits shared by experienced engineering managers that serve as recurring themes in this book. Great engineering managers are obsessed with continuous improvement for themselves and their engineering teams. They believe that there is always room for improvement and are open to new perspectives to that end.
Here are some questions you can use to consider how self-sustaining and scalable your team is today:
What dependencies do we have on other teams?What dependencies do other teams have on us? Do we have clear contracts and interfaces that other teams can rely on?When we onboard a new engineer, how much time does that take from the existing engineering team?How much of our time is spent on manual interventions (such as responding to and resolving incidents)?Do we have the culture and values to be harmonious and productive?How do we respond to unexpected events? Are we resilient as an engineering team or are we brittle?Are roles and responsibilities clear for us and our cross-functional partners?Are we able to measure our work output and performance as a team?How many of our core processes rely on meetings?How many of our core processes have a single point of failure (SPOF)?Answer these questions for yourself, honestly and without judgment. You will have plenty of time to formulate a plan to address areas for improvement as you settle into the role of engineering manager.
Engineering managers have a responsibility for their team’s performance and output. They maintain awareness of the engineering team’s commitments and progress. They act as a resource to help engineers do their best work. They cultivate sources of information outside of the team to have a balanced view of how their team is doing.
Here are some questions you can use to consider this:
Am I currently aware of my team’s reputation? Is it a strong reputation?Do engineers on other teams know what my team does?Do engineers on other teams like working with my team? Why or why not?Do people outside of engineering know what my team does?Do non-engineers like working with my team? Why or why not?Is my team impactful? Does it find ways to innovate and deliver creative solutions that produce a competitive advantage?Does company leadership understand the capabilities and value of my team?Is my team celebrated?If you find that you don’t know the answers to most of these questions, that is okay! You now have some talking points and information to gather for later.
So, now that we understand the general responsibilities of engineering managers, let’s go through the activities and tasks that managers perform in service to these responsibilities.
An engineering manager’s work is made up of only four basic activities. Sounds easy, right? This is what they do:
EngineeringManagingTransitioningBig-picture thinkingHow much of your time is spent on these activities will be determined by contextual and personal factors we will learn about later in this chapter. So, let’s examine these.
Engineering—the planning and delivery of software for business needs—may be the bulk of your work as an engineering manager. You may contribute directly to these activities, coding alongside your individual contributors, but the primary role of an engineering manager in engineering activities is one of leadership, to guide and facilitate the best possible outcome and take accountability for decisions made. Let’s break down the elements of engineering leadership activities:
Leading architectureProject planning and deliverySupporting production systemsManaging—providing for the needs, well-being, and professional growth of your team—may be the bulk of your work as an engineering manager. This aspect of an engineering manager’s role is incredibly impactful and can’t be overemphasized in its ability to lead to great success or crushing failure from seemingly small changes. Let’s go through the elements of management activities:
Working cross-functionallyCommunicating with authorityAssessing and improving team performanceFostering accountabilityManaging riskTransitioning—guiding your team from one state of being to the next—is an inevitable eventuality for all engineering managers. Managers have a crucial role in preparing teams for change, contextualizing changes as they come, and providing teams with a sense of stability in an ever-changing world. Let’s break down the key areas of transitioning:
Resilient leadershipScaling your teamHandling changing priorities, company pivots, and re-orgsBig-picture thinking—is the time you devote to broader and more abstract questions of how to grow the utility and value of your engineering organization while retaining the progress and talent you have, touching on elements of all of the previous activities while thinking creatively to maximize impact and leverage. Key areas include:
Retaining talentTeam designI have organized this book around these four activities as parts and chapters. If you are particularly interested in one topic, you can jump ahead, but it is recommended to read the topics in order for the best understanding.
Now that you understand what engineering managers are responsible for and the activities they perform in service to those responsibilities, let’s go over how we might spend our day as engineering managers.
No two engineering managers are likely to spend their time in the same way because the work is both contextual and personal. It is contextual because expectations can be vastly different in different settings. If you are a manager at a company with 10 engineers, it will be very different from being a manager at a company with 100 engineers, and that will be very different from being a manager at a company with 10,000 engineers. Similarly, your work will vary depending on your company’s industry, leadership, growth stage, maturity, project, and supporting roles. These contextual factors combine in different ways to make every engineering manager’s job unique.
An engineering manager’s job is personal because individual skills and leanings vary. The technical background you bring to bear, your organizational skills, leadership style, personality, interests, influences, and beliefs will all play a role in the leader you become.
This means that successive managers of the same team are likely to have distinct approaches to their work, and your approach may change greatly from one position to the next. In this way, engineering management is as much an art as a science.
So, how do engineering managers know how to spend their day if there is no consistent approach? In this section, we will answer this question and teach you how to make these decisions for yourself like an experienced manager by going through thefollowing steps:
Start by askingDetermine relative importanceFill in the gapsBe a translatorThere may be many approaches to engineering management, but you should always start by asking!
As you start planning your days in a new position as an engineering manager, set yourself up for success by confirming the expectations of your leadership, peers, and team. Just as new engineers can deepen their understanding and progress more quickly by asking plenty of questions, curiosity can be even more critical to your success as an engineering manager.
Maybe you have a job description that clearly spells out the expectations of your position. If you don’t have one, ask for it. Now is a great time to make sure you have read over this in its entirety and understand every point. Sit down with your manager and ask them the following questions:
Should I take this job description literally or do you have another view?Can you clarify [points I have questions about]?I understand these items to mean [this]; would you agree with my assessment?In your view, what aspects of this are most important to my success in this position?Is there anything important to you that is not included here?How do you recommend I spend my day?Do you have any specific goals for me in my first week/month/six months?What do you see as the biggest challenges for my team to overcome?Sometimes it can feel intimidating to drill your manager with questions, but they are there to help you be successful and will generally be happy to oblige. Set the stage by doing this in a one-on-one or by scheduling time specifically for a manager orientation session with them. You can say, “I’d like to make sure I fully understand your expectations of me in this position, so I have a list of questions. I would appreciate it if we can go through these together.”
Theme – connection
Careful language is a powerful means of developing a connection with others. The ability to connect with those around you makes you relatable and helps others to view you with empathy and trust since they understand where you are coming from. Without sufficient time spent on connection, you may be distrusted, misunderstood, or viewed as out of touch. Connect with your engineers and those around you through your words, your writing, your reactions, and your sense of humor. Making strong connections involves a flow in both directions where you seek to understand others as much as you seek for them to understand you (see “Habit 5” from The 7 Habits of Highly Effective People: https://www.franklincovey.com/habit-5/). A mastery of connection allows you to influence those over which you have no real authority.
After touching base with your manager, it’s a good idea to cast a wider net in your survey of expectations. Devote some time to inquiring about what your team would like from you day to day. Use the change in leadership as a reset to ask natural questions about what they enjoyed about previous managers and what they wished they had more or less of. Add in any questions about their expectations and history specific to your context. It’s a good idea to make your intentions clear by saying directly, “I’m coming up to speed here and I want to make sure I understand your expectations of me, any agreements you may have discussed with past managers, and any immediate frustrations or blockers you may have. I’m here to support you and I’d like to start by gaining an understanding of where you are today.” Be wary of making promises at this stage since you don’t want to commit to anything you aren’t 100% sure you can deliver.
If you work with product and design teams, set up some time with them individually to connect and start a dialogue by asking whether there is anything not outlined in your product responsibilities documentation that they are expecting from you. Ask similar questions on what they have appreciated about previous engineering managers and what they wished they had more or less of.
Plan for similar conversations with any other teams, partners, and stakeholders you expect to be working with. This could be analytics, quality or site reliability, infrastructure, business development, or many others. You may check in with your manager and ask who they think is worthwhile for you to connect with.
As you go through these expectation-surveying conversations, be particularly wary of commitments and overcommitments. Some may see a change in leadership and your enthusiasm as an opportunity to pile an unrealistic or self-serving wish list on you. Gather information, but resist the urge to appease everyone on day one. Aside from any serious HR-level misconduct, the right number of commitments to make at this stage is zero.
If your company has a strong memo culture, you may be able to save some time by sending out your questions in a written format. Even if you do that, it’s helpful to do a bit of relationship-building and have a quick chat to ask any follow-up questions you may have.
Try to wrap up these conversations within a few weeks. By the time you finish your expectation survey, you will have a good idea of what everyone else expects from your time. Now, you can decide what you think about that. The purpose of gathering expectations is not so that you can blindly serve everything that everyone wants from you, but instead to raise your awareness. Your goal is to determine which expectations are duties you must fulfill and which need to be managed and adjusted.
So far in this section, we have learned how to survey others’ expectations, and earlier in the chapter, we learned about the four activities we may divide our time across. Now, you can combine these sources to gain an idea of how you want to spend your day.
Take a look over your notes from the expectations survey you conducted. Looking at your notes through the lens of the four activities, does anything jump out immediately? Your manager may have had a clear emphasis on engineering, managing, transitioning, or some combination of these. Cross-functional peers often focus on engineering activities but sometimes highlight managing. Your engineering team is likely to focus on the management aspects of your role. Take note if the expectations across these groups fall along the same lines or are more spread out.
It’s possible that the expectations are so spread out across the four activities that you are not sure where to start, or it may be that they seem focused on one area while you feel more passionate about another area altogether. How should you determine how to spend your time?
It’s a good rule of thumb that your job is to follow your manager’s lead, but your duty is to your engineering team. Start by following the advice you received from your manager and check in regularly that their expectations are being met. Leave yourself adequate time to serve the needs of your team. Keep in mind that you are a leader throughout this balancing act, and your sense of what is needed and good use of your time matters. Allow external factors to influence you while developing your own sense of time management.
Over time, you will develop more confidence and understanding of what the best uses of your time are. As you go through this process, keep in mind that since there are so many people depending on you, your time is precious! Be careful with it.
Let’s go over a few more ways of determining how to spend your day.
Another lens you can use to think about how to best spend your day is to think about your team’s overall needs and output and where there are gaps. Some things by necessity can only be done by you. Other things can be done by anyone, but there may not be anyone available to do them.
If your team is understaffed for its workload, you should absolutely take it up with your leadership rather than overwork (more on this in Chapter 5). Aside from that, experienced engineering managers are typically expert gap fillers. They take advantage of their flexible time and flexible skillsets to move seamlessly through their day, lending free moments to whatever needs a little extra support to be successful. This might be building an internal tool for your team, designing a smoke test, teaching an analytics person how to pull a complex report, or helping a junior project manager. It could also be noticing the team is stressed and hand-delivering team members’ favorite snacks with some encouraging words for a bit of relief.
Avoid the trap of filling gaps from a place of ego that only I can write this piece of code or only I can do it in a short amount of time. This type of thinking often leads new managers to sacrifice time that should be spent on leadership and management activities that only they can do, while depriving their team of a learning opportunity. You should be able to break down any work sufficiently and explain the right approach such that your engineers can tackle those challenges and grow their skills.
Theme – no ego
Engineering managers are there to guide teams, not dictate to them. This can be a mind shift for new engineering managers who may be used to doing everything their own way as individual contributors. We are all opinionated, but it is an important skill for engineering managers to be open to having their minds changed when new ideas come along. Strong opinions, loosely held is the rule of thumb. Not letting your ego get in the way of a change that makes sense is an essential trait of strong leadership. Over time, you should develop appreciation and respect for everyone’s unique point of view.
As leaders of product development teams, engineering managers are uniquely positioned to help the entire team meet and exceed its goals by noticing gaps and lending a hand. Develop your own sense of where you are most needed and apply yourself there.
Now that we have learned a few immediate and practical ways to plan our days, let’s move into more abstract territory.
For our purposes in this book, translating is the act of contextualizing information so that it can be understood by a particular group of people in the workplace. When you explain to product teams why it will take a long time to build a feature, you are translating. When you explain to an engineer why the company has made a change to project goals, you are translating. Anyone can be a good translator, but this is particularly relevant for engineering managers and is a key skill for impactful leadership.
So, how much of your day should be spent translating? The answer: more than you probably think. Translating is arguably the single most impactful thing an engineering manager can do with their time. The reason for this is the power of why.
Great articles, books, and talks have highlighted the power of why as a guide and motivator. Throughout your day, you may tell people what you want, what you expect, and what you recommend, but if the why isn’t understandable to them or does not resonate with them, you have lost an opportunity to convince them. When you can translate the why completely, you put yourself in the best possible position for your desired outcome.
Theme – give work meaning
Great engineering managers find ways to give work meaning and make that meaning broadly understood. They align the realities of the engineering work they are tasked with to the aspirations and beliefs of their team members. For more on aligning difficult work with aspirations, see Chapter 6.
For your engineers, translating the why in a way they can understand and accept is a powerful tool for alignment and guiding decisions in the direction you want. You will spend less time answering questions, resolving disputes, and reworking mistakes if everyone is on the same page about the various whys from programming languages and tool choices to product priorities.
Translating outside of your team and upward to leadership (managing up) is oftentimes the most impactful translation of all. It can be a hard lesson to learn that the very best work by engineering teams can easily go overlooked or unappreciated if there is no one translating the value of that work in terms that leadership can understand. Ask yourself how widely your team’s work is understood and who—if anyone—is doing that translating. Is there an opportunity for you to translate why your work matters to a wider audience? This is time well spent to gain awareness, adoption, and opportunity for your team’s work.
So, where can you start filling the role of translator? In addition to your everyday conversations, you can be a translator in writing and in team rituals. Newsletters, documentation, memos, update meetings, or all-hands meetings are all excellent venues for a bit of translating. Use your judgment to determine the best audience, but don’t shy away from translating your team’s work broadly when there is an opportunity. You can approach your leadership and say, “I believe the work we are doing on _____ is relevant to the entire company/department and I’d like to send out a monthly email update so that everyone can understand how this work can help them and the progress we are making. Here’s an example I put together.”
Spending part of your day as a translator pays dividends in all directions, helping others understand you, empathize with you, and become your supporters and friends.
You can use this concise checklist as a guide when starting with a new engineering team:
Gather expectations from your manager, cross-functional partners, stakeholders, and engineers. Listen without making commitments.Decide what is feasible and the best use of your time by blending expectations with your own judgment and intuition.Estimate how much of your initial focus is needed on engineering, managing, transitioning, and big-picture thinking. Start to reserve time in your schedule/calendar.Observe gaps that exist in your team’s work and workflows and consider how you might fill those gaps for your team.Make sure you are devoting some time to translating important contextual information between leadership, cross-functional partners, and engineers. Aim to consistently translate why.Continuously adjust as new information becomes available.Now that you have a sense of how you can plan your day, let’s go over some specific reasons why taking on the responsibilities of an engineering manager can be a shock to the system and what we can do about it.
It is important to set an expectation with yourself that you are going through a career change because of the magnitude of new skills and responsibilities you will be conquering. Engineers are accustomed to continuous learning, but the move from engineer to manager represents a move from finite and often well-defined goals (delivering features or owning a system) to what are more often complex and abstract goals such as keeping your team engaged or improving productivity.
This section focuses on preparing you to cross the chasm from engineer to manager without becoming burned out or overwhelmed by the weight of your new responsibilities. Let’s learn how we can approach this career change.
Many engineers take great pride in their ability to solve everyday problems with code. Engineers build confidence by repeatedly endeavoring to build a solution and then delivering on that intention. The feeling of knowing exactly what you can and can’t accomplish is a great one, but as you transition into engineering management, this comfortable feeling largely cannot come with you. When you lead a team, you will rarely have the same level of confidence because many factors will be out of your direct control.
It can be jarring and stressful to move from a world where you know all of your strengths, weaknesses, plans, intentions, and other commitments into a world where you have to try to ascertain those of several other people based on conversations and experiences. Even if you have worked with your team for long enough to know team members’ abilities well, you cannot see inside their minds to know which competing or conflicting factors may throw a monkey wrench into your plans. This is inherently scary and will take some getting used to.
Theme – bravery
Engineering managers face discomfort and fear often. To be successful, engineering managers must conquer fears, believe in what they are doing, and be willing to stand up for what they believe in. Great engineering managers develop a sense of when they need to take a risk to make a difference, and they have the courage to act on their convictions.
The immediate and practical approach to the additional uncertainty of team leadership is to proceed with additional caution. As a new engineering manager, you may feel the urge to impress your peers and boss, but being overcommitted is a nerve-wracking experience that may have the opposite effect of what you intended.
When taking responsibility for the work of others, you also must prepare yourself to give up control of specific implementation details that do not ultimately matter. It will be stressful when your engineers do some things in a different way than you would yourself. It is now your job to provide useful constraints for your team to work within, such as conventions, security practices, performance rules, style rules, or code-complexity ratings. It will take some time for you to figure out how to best define and express these constraints, but what you don’t want is to make your engineers feel like they have lost the ability to be creative and solve problems themselves.
At some point in your first year or two of working as an engineering manager, you will hit a wall. Although the work of an engineering manager can be very fulfilling and satisfying, the feedback loop is much longer compared to working as an engineer. This is an adjustment that all engineering managers must go through.
As engineers and software developers, most of the time we get to tackle a problem, design a solution, see that solution merged and released, and enjoy the fruits of our work and a sense of accomplishment, all in a relatively short period of time. This short feedback loop becomes its own reward cycle, encouraging us to press on and tackle bigger challenges. We are able to push through frustrations and difficult moments because we know soon things will click and we will find the right solution.
As an engineering manager, you will have moments of immense personal satisfaction and a sense of accomplishment from helping and empowering your engineers. There will also be times when you are giving your full effort and you question whether it is making any difference at all. This can be incredibly draining at first. Quick and easy solutions are rare in the lives of engineering managers. Progress is usually gradual, and it can seem like a long time before you see the benefits of your efforts. Hang in there, be consistent, and you will eventually see results.
In this chapter, we introduced the purpose and goals of engineering managers. We learned about the broad responsibilities of engineering managers and the activities we perform in support of those responsibilities. Here’s a recap of these:
Maintaining teams capable of serving business needsProducing mechanisms to make engineering teams self-sustaining and scalableOwning the reputation and impact of their teamPerforming activities and tasks related to engineering, managing, transitioning, and big-picture thinkingWe learned how engineering managers spend their days and presented steps for you to plan your own days, summarized here:
Get a baseline of how to plan your day by surveying the expectations of your manager, peers, and engineering team.Focus expectation surveys on understanding what others expect from you and not on making early commitments you may struggle to uphold.Gain insight into the relative importance of work you might engage in by comparing the four activities of engineering managers with the notes from your expectation surveys.Observe what your engineering team needs and what members do and don’t have time for to further determine how you can best contribute to the team’s success.Avoid taking on hard technical challenges personally since they can absorb too much of your time and deprive your team of learning opportunities.Be a translator. Your unique understanding of engineering and the business setting puts you in a position to provide invaluable context for your engineers and your leadership team.Lastly, we learned how taking responsibility for the work of others can be a stressful adjustment. Your goal is to find a balance between providing guidance and alignment without dictating or controlling. Progress as an engineering manager will feel much slower than progress as an engineer. Engineering managers must persevere without much feedback at times.
In the next chapter, Chapter 2, we will learn how to approach our responsibilities and activities with a style that fits the setting. We will introduce some of the most common leadership styles and how they apply to different engineering team situations.
For engineering managers, leadership style has become an essential way of establishing and distinguishing who you are and which teams you are suitable to lead. Because of this, leadership style has become a frequent topic of interest in engineering management circles, making appearances in writings and talks. But style can seem like a vague term that doesn’t convey a lot of meaning about what the concept includes or why it holds such a central role in the lives and livelihoods of engineering managers.
In this chapter, we will demystify what an engineering leadership style is and why it matters. We will review the origins of leadership styles and where they come from as relevant to modern software development. We will introduce common engineering leadership-style archetypes and discuss their effectiveness. We will close the chapter by learning how to develop your own style with intention and authenticity.
By the end of this chapter, you will have a firm grasp on what engineering leadership styles are and how to answer the question “What is your leadership style?” when it inevitably gets thrown your way.
This chapter is broken down into the following sections:
What is an engineering leadership style?Leadership styles and their originsEngineering leadership style archetypesWhat is the right leadership style for me?So, let’s begin with what defines a leadership style.
Whether intentional or not, every engineering manager has a leadership style. This is because an engineering leadership style is no more than salient beliefs reflected in actions over a period of time. Let’s break down this definition.
Leadership styles reflect salient beliefs. If your strongest belief is that engineering managers’ role is to serve their teams, you will develop a servant leadership style. If your primary belief or interest is in mentoring and teaching your team, you will develop a coaching leadership style. If your primary belief or concern is controlling your team’s actions, you will develop a commanding or micromanaging leadership style. Everyone holds many beliefs, some of which may be conflicting or competing, so it is the salient beliefs that tend to win out and define your leadership style.
Beliefs must be reflected in actions to become a part of your leadership style. Your actions develop and strengthen the abilities that support your leadership style. Practicing your beliefs cements them into skills and resources. If you believe one thing but act in a way that contradicts that, you may have some subconscious beliefs or drivers that are guiding you in a different direction. If you observe this happening to you, don’t be discouraged. It is quite common for new engineering managers to need to work through some of their subconscious beliefs to better understand their own reactions and embody their ideals. An engineering manager’s job is stressful, and it takes diligence and practice to act with intention.
Finally, beliefs must be reflected in actions over a period of time to become your leadership style. A leadership style is not defined by what you do once, twice, or occasionally. A leadership style is what you do consistently. It is what you demonstrate regardless of the circumstances or hardships.
Given this definition, you can develop your leadership style with intention by bringing awareness and active management to the beliefs you have about your role. Develop skills and resources to act on your beliefs consistently.
As a new engineering manager, give yourself time to develop your engineering leadership style. While you may hold strong beliefs that you work toward, you may initially lack the skills or experience to live up to those beliefs. This is an area where mentoring from a senior manager can help you gain perspective and progress.
Engineering leadership styles naturally evolve over time because beliefs and abilities evolve as you go through different experiences and receive new influences. You may also adjust your leadership style to different circumstances based on what you believe is appropriate for the setting.
Now that we have learned what leadership styles are and how to guide them with intention, let’s take a step back to understand some of the origins of leadership styles.
We have learned that on an individual level, leadership styles stem from beliefs and abilities, but what broader trends should we be aware of? Can the origins of leadership styles provide us with useful information today?
In this section, we will explore these questions and provide a brief overview of what we know about leadership styles from studies and writings. We will cover three foundational views of leadership styles and how you can incorporate the teachings from them into your efforts to develop an effective style for yourself.
We will briefly review the following:
Leadership styles in natureLeadership styles in philosophyLeadership styles in management theoryEach of these views has something to teach us about leadership styles and why they exist. Let’s start with leadership styles in nature.
Leadership is not unique to humanity; it can be seen across the majority of the animal kingdom. This means that leadership styles can be observed in all sorts of natural hierarchies, from ant colonies to migrating flocks of birds. When viewed collectively with what we know about human leadership and leadership styles, a few clear patterns emerge.
Nature shows us that the foundation of leadership is coordination (DOI: 10.1016/j.cub.2009.07.027). Leadership exists only where coordination is required. Not all species have leaders, just those that depend on groups for survival and so have a need for group coordination and social structures. With awareness of this, engineering managers can apply this knowledge to better understand the purpose and foundation of our roles. We can recognize that if our team is not well coordinated, our leadership style has fundamentally failed. Regardless of how it is achieved, an effective leadership style must optimize for group coordination.
