Engineering Management Puzzle

Defining team size

Team right sizing is between 6–8 engineers during steady state; this gives managers enough time for active coaching, coordinating, and furthering their team’s mission by writing strategies, leading change and so on. Managers of managers should support 4–6 managers. If you need to create a new team, grow an existing team to eight to ten, and then bud into two teams (avoid creating empty teams).

Improving team performance

“Improvements” depends on the current stage of the team:

• If it is falling behind (each week their backlog is longer than it was the week before, the list of bugs and feature requests outstrips the team’s ability to offset them with releases and morale is low), hire new people and increase capacity.
• If it is treading water (they’re able to get their critical work done, but are not able to pay down technical debt or begin major new projects), consolidate team efforts to reduce work in progress until able to begin repaying debt; learn to say no “correctly” when the team is with lot of work.
• If it is repaying debt (they’re able to start paying down tech debt, and see its benefits), add time to pay debt and to avoid going back into treading water.
• If it is innovating (their technical debt is sustainably low, the majority of work is satisfying new user needs and morale is high), maintain enough slack in your team’s schedule so that the team can build quality into their work.

Dealing with growth

When you need to increase a team capacity, keep in mind that adding new individuals disrupts the team, as it requires training of new hires, interviewing, rotations, etc.; at high enough rates, the marginal added value of hiring gets very slow, especially if your training process is weak. It is better to have rapid growth periods followed by consolidation/gelling periods (Companies do major investments in both new-hire bootcamps and recurring educational classes).

In addition, beware of when moving people from team to team, as sustained productivity comes from high-performing teams, and moving one person can shift an innovating team back into falling behind; if it’s possible, shift scope instead of rotating people, or move individuals for a fixed period into areas that need help.

Migrations are needed on rapid growth to tackle tech debt, finish them and celebrate. Systems may survive one magnitude of growth (10x), so design your software to be flexible to avoid additional rewrites; if your company is doubling every six months, then you’ll have to re-implement every system twice every three years. On migrations, the real productivity killer is not the system rewrite itself, but the subsequent data and system migrations that follow up those rewrites.

Product Management

Many engineering organizations separate engineering and product leadership into distinct roles; however, as an engineering leader, you may have to cover both roles sometimes.

Product management is an iterative elimination tournament: problem discovery (populate the problem space based on users pain, benchmark, competitive advantages, etc.), selection (narrow down to a specific problem), and solution validation (prefer experimentation over analysis).

Supporting Managers

When jumping to supporting managers alignment may be difficult to handle and it may be difficult to remain effective without understanding their day-to-day tasks. Some mechanisms to alignment at scale are:

- Metrics: align on outcomes while leaving flexibility around how the outcomes are achieved; they are an extremely effective way to lead change

- Visions: ensure that you agree on a long-term direction.

- Roadmaps: align on problem selection and solution validation; validate that your teams’ efforts are valuable.

- Weekly staff meetings: You can do brief updates from each attendee, at most a couple of minutes per person, and then move into group discussions on shared topics, like running effective sprints planning, career development or whatever else proves useful.

- Performance reviews

- Skip-level on-on-ones: ensure that there are direct, open channels for feedback about your managers and your teams.

Setting good goals

Goals may help you decouple the “what” from the “how” in your planning process. Good goals must have a target, baseline, trend and timeframe; there are two kinds of goals: investments and baselines. Investments describe a future state that you want to reach, and baselines describe aspects of the present that you want to preserve. The best way to avoid unintended outcomes is to pair investment goals with baseline ones (countervailing metrics).

Decision making at scale

As organizations grow, there is a subtle slide into inconsistency. When the problem becomes acute, people tend to reach for a centralized, accountable group; the two most common flavors are “product reviews” to standardize product decisions and “architecture group” to encourage consistent technical design. Some of these groups take on an authoritative bent, becoming rigid gatekeepers, and others become more advisory, with a focus on educating folks toward consistency. There are two mandates:

• Top-down: The approach is decided centrally, prioritizing consistency and velocity.
• Model, document and share: The approach is presented and experience of following it is shared; this has often led to higher adoption than top-down mandates, but is adopted gradually and still needs some natural authority and the respect of the peers.

Tackling re-orgs

If there is a structural problem, with a reorg you can increase communication, reduce decision friction, and focus attention. Once you have your headcount clear based on the needs, define your manager-to-engineer ratio (if engineering managers are expected to do hands-on technical work, it should be 3 to 5 engineers; otherwise, 5 to 8 depending on the experience level) and manager-to-manager ratio (you should generally round up the number of managers). Example: 35 engineers, 7 engineers per manager = you need 5 managers, and 1.8 managers of managers. This is 5 to 6 teams, and maybe one to three groups. When defining the teams, write a crisp mission statement for each one and think if you would be excited to be a member of each of the teams, as well as the manager of each of those teams. Finally, staff the teams with already team members, internal transfer from within your company, or external hires.

Organizational change is resistant to rollback, you have to be collectively committed to moving forward with it, even if you run into challenges along the way. Key elements to a good rollout:

• Explanation of reasoning driving the reorganization
• Discuss with impacted individuals first
• Ensure that managers are prepared to explain the reasoning behind the changes
• Documentation of how each person and team will be impacted
• Send an email out documenting the changes
• Availability and empathy to help bleed off frustration from impacted individuals
• Be available for discussion
• Double down on doing skip-level one-on-ones

Presenting to senior level

Leadership presentations tend to quickly detour, so practice isn’t quite as useful; prepare a lot and practice a little. Prepare instead getting deeper into the data, details and principles. Start with the conclusion, with what’s important, instead of building toward it gradually. Tie the topic to business value and why your work matters to the company. Deep in the data. and spend time exploring it.

Time management

Time management is the enduring meta-problem of leadership. The most impactful change you can do to manage time are:

• Hire until you are slightly ahead of growth
• Decouple participation from productivity: Don’t fall into the trap of assuming that attendance is valuable; stop doing things but alert your team and management chain that you won’t be doing it.
• Focus time: Add three or four two-hour blocks scattered across your week to support more focused work; being busy is not the same as being productive.

Culture

An inclusive organization is one in which individuals have access to opportunities and membership. Some ways to create and distribute opportunities may be learning programs or rotating project leaders for critical projects; useful KPIs: retention, usage rate (how often people are selected in project selection), level distribution, and time on level. On the other hand, belonging is a prerequisite for membership, and it can be forged with off-sites, coffee-chats, team lunches, etc.; useful KPIs: retention, referral rate, attendance rate and the quantity and completion rate of coffee chats.

Interviewing

• Be prepared and show interest
• Be kind; take breaks between many interviews if you are burned
• Set clear expectations/goals
• Be at least two looking at signals
• Take real code issues
• Demo your product
• Ask for feedback
• Prefer referral over sourcing
• Source yourself
• Partner with your recruiter
• Monitor funnel metrics: measure first, and optimize second; instead of ending the funnel at closing candidates, you may add more phases as onboard, impact, promote and retain.

If you want to go deeper into this topic, you can read the book on which this post was based: “An Elegant Puzzle: Systems of Engineering Management” by Will Larson