An Elegant Puzzle- Systems of Engineering Management

Home > Other > An Elegant Puzzle- Systems of Engineering Management > Page 7
An Elegant Puzzle- Systems of Engineering Management Page 7

by Will Larson


  2. A number based on the “natural size” of your organization, if every team and role was fully staffed.

  3. A realistic number based on historical hiring rates.

  Then merge those into a single number.

  Unless you’ve changed something meaningful in your process, it’s likely that the historical trend will hold accurate, and you should weight that figure the most heavily (and my sense is that the list of easy changes that significantly after hiring outcomes is short).

  One of the goals of using the year-out head count number is to avoid optimizing too heavily for your exact current situation and the current individuals you’re working with. Organizational change is so disruptive to so many people that I’ve increasingly come to believe you should drive organizational design from the boxes and not from the key individuals.

  3.7.3 Manager-to-engineer ratio

  Once you have your head count projection, you need to identify how many individuals you want each manager to support. This number particularly depends on your company’s working definition of an engineering manager’s role. If engineering managers are expected to do hands-on technical work, then their teams should likely be three to five engineers (unless the team has been working together well for a long time, in which case things get very specific and hard to generalize about).

  Otherwise, targeting five to eight engineers, depending on experience level, is pretty typical. If you’re targeting more than eight engineers per manager, then it’s worth reflecting on why you believe your managers can support a significantly higher load than industry average: Are they exceptionally experienced? Are your expectations lower than typical?

  In any case, pick your target, probably in the six-to-eight range.

  3.7.4 Defining teams and groups

  Now that you have your target organization size and target ratio of managers to engineers, it’s time to figure out the general shape of your organization!

  Suppose that you have 35 engineers and 7 engineers per manager.

  35 / 7 = 5 managers

  Log⁷(35) ≈ 1.8 managers of managers, or second-degree managers

  In a growing company, you should generally round up the number of managers, as this is a calculation “at rest,” and your organization will be a living, evolving thing.

  Once you have the numbers, these are useful to ground you in the general number of teams and groups of teams you should have.

  In the first case, with 35 engineers, you’re going to want between one and three groups, containing a total of five or six teams. In the latter, with 74 engineers, you’ll want two to four groups, comprised of 12 to 15 teams.

  Once you’ve grounded yourself, here are some additional considerations:

  Can you write a crisp mission statement for each team?

  Would you personally be excited to be a member of each of the teams, as well as to be the manager of each of those teams?

  Put teams that work together (especially poorly) as close together as possible. This minimizes the distance for escalations during disagreements, allowing arbiters to have sufficient context. Also, most poor working relationships are the by-product of information gaps, and nothing fills those faster than proximity.

  Can you define clear interfaces for each team?

  Can you list the areas of ownership for each team?

  Have you created a gap-less map of ownership, such that each responsibility is owned by a team? Try to avoid implicitly creating holes of ownership. If you need to create explicit holes of ownership, that’s a better solution (essentially, defining unstaffed teams).

  Are there compelling candidate pitches for each of those teams?

  As always, are you over-optimizing on individuals versus establishing a sensible structure?

  This is the least formulaic aspect of organizational design, and, if possible it’s a good time to lean on your network and similar organizations for ideas.

  3.7.5 Staffing the teams and groups

  With your organization design and head count planning, you can roughly determine when you’ll need to fill each of the technical and management leadership positions.

  From there, you have four sources of candidates to staff them:

  Team members who are ready to fill the roles now.

  Team members who can grow into the roles in the time frame.

  Internal transfers from within your company.

  External hires who already have the skills.

  That is probably an ordered list of how you should try to fill the key roles. This is true both because you want people who already know your culture and because reorganizations that depend on yet-to-be-hired individuals are much harder to pull off successfully.

  Specifically, I’d recommend having a spreadsheet listing every single person’s name, their current team, and their future team. Accidentally missing someone is the cardinal sin of reorganization.

  3.7.6 Commit to moving forward

  Now it’s time to make a go decision. A few questions to ask yourself before you decide to fully commit:

  Are the changes meaningful net positive?

  Will the new structure last at least six months?

  What problems did you discover during design?

  What will trigger the reorg after this one?

  Who is going to be impacted most?

  After you’ve answered those questions, make sure to get not only your own buy-in but also buy-ins from your peers and leadership. Organizational change is rather resistant to rollback, so you have to be collectively committed to moving forward with it, even if it runs into challenges along the way (which, if history holds, it almost certainly will).

  3.7.7 Roll out the change

  The final, and oftentimes most awkward, phase of a reorganization is its rollout. There are three key elements to a good rollout:

  Explanation of reasoning driving the reorganization.

  Documentation of how each person and team will be impacted.

  Availability and empathy to help bleed off frustration from impacted individuals.

  In general, the actual tactics for doing this are:

  Discuss with heavily impacted individuals in private first.

  Ensure that managers and other key individuals are prepared to explain the reasoning behind the changes.

  Send an email out documenting the changes.

  Be available for discussion.

  If necessary, hold an organization all-hands, but probably try not to. People don’t process well in large groups, and the best discussions take place in small rooms.

  Double down on doing skip-level one-on-ones.

  And with that, you’re done! You’ve worked through an engineering reorganization. Hopefully, you won’t need to do that again for a while.

  As a closing thought, an organization is both (1) a collection of people and (2) a manifestation of an idea separate from the individuals comprising it. You can’t reason about organizations purely from either direction. There are many, exceedingly valid, different ways to think about any given reorganization, and you should use these ideas as one model for thinking through changes, not as a definitive roadmap.

  3.8 Identify your controls

  When I transitioned from directly supporting teams to instead partnering their managers, I struggled to remain effective without understanding their day-to-day tasks. My first instincts were to retain the same fidelity of context over a much wider area, and for the individuals working with me this was probably indistinguishable from micromanagement. Maybe it even was micromanagement.

  Thanks to a great deal of feedback and reflection, I’ve gotten more deliberate at identifying where to engage and where to hang back, a process that I call identifying your controls.

  Controls are the mechanisms that you use to align with other leaders you work with, and they can range from defining metrics to sprint planning (although I wouldn’t recommend the latter). There is no universal set of controls—depending on the size of team and your relationshi
ps with its leaders, you’ll want to mix and match—but the controls structure itself is universally applicable.

  Some of the most common controls that I’ve seen and used:

  Metrics26 align on outcomes while leaving flexibility around how the outcomes are achieved.

  Visions27 ensure that you agree on long-term direction while preserving short-term flexibility.

  Strategies28 confirm you have a shared understanding of the current constraints and how to address them.

  Organization design allows you to coordinate the evolution of a wider organization within the context of sub-organizations.

  Head count and transfers are the ultimate form of prioritization, and a good forum for validating how organizational priorities align across individual teams.

  Roadmaps align on problem selection and solution validation.

  Performance reviews coordinate culture and recognition.

  Etc. There are an infinite number of other possibilities, many of which are specific to your company’s particular meetings and forums. Start with this list, but don’t stick to it!

  For whatever controls you pick, the second step is to agree on the degree of alignment for each one. Some of the levels that I’ve found useful are:

  I’ll do it. Stuff that I will personally be responsible for doing. When you’re going to do something, it’s better to be explicit and avoid confusion on responsibilities. Best used sparingly.

  Preview. I’d like to be involved early and often. This is probably an area where we aren’t quite on the same page and this will help us avoid redoing work.

  Review. I’d like to weigh in before it gets published or fully rolled out, but we’re pretty aligned on the topic.

  Notes. Projects I’d like to follow but don’t have much I can add to. Often used for wide-reaching initiatives on which we are well aligned, and I want to be able to represent my colleagues’ work correctly.

  No surprises. The work that we’re currently aligned on but requires updates to keep my mental model in tact. If I’m asked about a related problem, I want to be able to answer it correctly. This is particularly important for me, as my effectiveness is evaluated based on my ability to stay on top of new problems.

  Let me know. We’re well aligned on this, since my colleagues have done it before and done it well. I want them to let me know if something comes up that I can help with, but otherwise I’m totally confident it’ll go well, so we don’t need to talk about this much.

  Combine your controls and the degree of alignment for each, and you’ve established the interface between you and the folks you support. This reduces the ambiguity of how you work together and allows everyone to focus. It’s useful for agreeing on performance goals, and is also very useful for exposing alignment gaps between you and individuals you work with (For example, it’s a worrisome sign if you want to preview every bit of someone’s work, unless you just started working together.)

  Finally, this is a useful diagnostic for you as a leader to identify if you are micromanaging. If you simply can’t imagine a world where you don’t preview everyone’s work, it’s probably time to reflect a bit on what’s holding you back from letting the team thrive.

  3.9 Career narratives

  A peculiar challenge of management is trying to invest in someone’s career development when they themselves are uncertain about their goals. As a manager, you may have more experience and more access to opportunities within the company, but that represents a small slice of someone’s career possibilities. Our schooling often rewards us for being methodical, linear thinkers, but that approach is less effective outside the intentionally constrained possibility spaces.

  The options for approaching a career, particularly for those of us privileged to work in technology, are so extraordinarily vast that exploring them effectively requires a different approach. This vastness also means that you, as a manager, can’t simply give folks a career path: you’ll inevitably steer them toward the most obvious avenues and through avoidable competition.

  Flipping perspectives, it’s also quite challenging to plan your own career. I sometimes find myself walking from one meeting where I’m coaching someone on their career goals, straight into a second meeting where I struggle to string together words to articulate my own. The hardest bit is that most folks are always at the furthest point in their career, each change a step into the unknown, with limited visibility into the upcoming opportunities that their company can provide.

  The intersection that I’ve found between the individual’s and their manager’s perspective is the career narrative. I’ve explained these fabled documents a few times before, in “Roles over Rocket Ships”29 and “Partnering with Your Manager,”30 but given how useful they can be, it’s useful to expand a bit on the process of maintaining one.

  3.9.1 Artificial competition

  If you took 10 minutes to ask a dozen people about their immediate career goals, I suspect that for 11 of them it would center on either getting promoted or switching companies to reach the next evolution of their current job. This doesn’t mean that climbing the career ladder is bad—that’s what it’s designed for—but it has the side effect of funneling most folks toward a constrained pool of opportunity.

  What I’ve slowly but increasingly come to believe is that there is much more opportunity on career ladders than off of them, and by including those opportunities you’ll make and feel more progress. Better yet, you’ll find far more opportunities to partner with your peers, no longer competing for limited promotion slots.

  For example, if your long-term goal is to be the head of engineering at a mid size company, you could approach that linearly by trying to expand your role bit by bit at your current company on the track to becoming its head of engineering. That’ll work for roughly one person at the company, but for everyone else pursuing that same path it will probably be suboptimal.

  A different approach would be to instead work on identifying the gaps that would keep you from being a strong head of engineering, and then start using your current role to help fill those gaps. A prototypical head of engineering will be skilled at organizational design, process design, business strategy, recruiting, mentoring, coaching, public speaking, and written communication. They’ll also have a broad personal network and a broad foundation from product engineering to infrastructure engineering. That’s not even a particularly complete list of relevant skills! There are so many different aspects to build out, and you can find opportunities to practice all of them in your current role. There’s no need to convince yourself that your current role is holding you back—everything you need is here.

  Importantly, while generalized career paths won’t necessarily align cleanly with your goals, they are also unlikely to take full advantage of your strengths. An important part of setting your goals is developing areas you’re less experienced in to maximize your global success, but it’s equally important to succeed locally within your current environment by prioritizing doing what you do well.

  With all of this in mind, take an hour and write up as many goals as you can for what you’d like to accomplish in the next one to five years. Then prioritize the list, pick a few that you’d like to focus on for the next three to six months, and share it with your manager at your next one-on-one.

  3.9.2 Translating goals

  Once you’ve identified goals to pursue, the next step is to translate those goals into actions, and this is where your manager can be a leveraged partner in iterating on your career narrative.

  Managers tend to have a strong sense of the business’s needs, and that gives them the superpower of finding the intersection of your interests and the business’s priorities. That translation is a creative pursuit, so don’t leave this entirely to your manager: participate as well! Brainstorm projects, research how folks at other companies have pursued similar goals, and educate your manager on aspects of your goals that they don’t know much about. (For example, engineers often have more conference speaking expe
rience than engineering managers do.)

  Bringing your list of goals to this discussion helps ensure that it’s successful. If you don’t bring a rough draft, by default you’ll get steered toward the contested commons, and your career narrative will be a dull instrument for progress.

  This refined list of goals, aligned to your company’s priorities, then becomes a central artifact for how you and your manager collaborate on your career evolution. Every quarter or so, take some time to refresh the document and review it together.

  If you’re unconvinced that it’s worth your time to write a career narrative, you certainly don’t have to write one. Most folks get away with not writing one for their entire career and have deeply fulfilling careers despite the absence.

  That said, if you don’t, then there is probably no one guiding your career. Chasing the next promotion is at best a marker on a mass-produced treasure map, with every shovel and metal detector re-covering the same patch. Don’t go there. Go somewhere that’s disproportionately valuable to you because of who you are and what you want.

  3.10 The briefest of media trainings

  When I was working at Digg,31 I was fortunate enough to get five minutes of media training from my colleague Christine. As a testament to her, that brief training lodged deeply in my head, and I’ve found myself repeating it frequently ever since. Eventually, I realized that I should probably just write it up!

 

‹ Prev