The LeadTech Diet - Issue #6

Engineering Management III | Better Meetings | Sphere of Influence

Mar 19, 2021

Engineering Management (Part III)

What does an Engineering Manager do?

In this issue we’ll continue our series on the different aspects and responsibilities of engineering managers and talk about Operational Maturity.

If you have no idea what I’m talking about, have a look at the Engineering Management pillars below for reference to previous and future (once written) issues on the topic:

Let’s get started.

Operational Maturity

Having the right people who are technically excellent is a good start. However, the real journey begins once your customers put your product through its paces in production.

Without a high degree of operational maturity, bugs, incidents and other issues can cripple a team’s ability to deliver - not to mention your users’ increasing frustration.

But what is operational maturity?

Realistically it means different things to different businesses. I like to think of it in terms of being able to answer the following questions:

How robust and performant does the application need to be?
How often is failure acceptable?
How fast do we need to restore service when it fails?
How easy is it to deploy the application? Does it take days and/or manual effort?

The answers to the above depend on the criticality of your product or industry:

The diagram above is a fancy way of saying that nobody cares if your prototype fails - life goes on - you’re optimising for speed, not robustness. Now if the systems that control railways, electrical grids or traffic lights are down, there is significant economic loss and increased risk of physical harm.

Once you understand where in that scale your product sits, as an Engineering Manager you can drive Operational Maturity by asking questions such as:

What are the possible failure modes for the service, and how well does the service handle them?
How are we going to monitor this service?
Which end-user metrics can we use to identify performance bottlenecks and problems?
What runbooks are available to Engineering teams during an incident?
Is the team aware of and trained in the incident response process?
Have effective SLIs / SLOs / SLAs and relevant benchmarks been defined for this service?

Note that businesses don’t sit squarely on either end of the scale. Think about established organisations that still innovate - each department and product’s needs may be different.

Use these questions as a guideline to define how much operational maturity you need as well as to track progress over time.

LeadBytes

Better meetings

Bad meetings are a pet peeve of mine. They are such a big topic that there is even a book about it (possibly more). Very few things are more frustrating than to spend an hour in a room - virtual or not - and feel like nothing was accomplished.

But how do you know you’re in a bad meeting? Here are some tell-tale signs:

The invite was sent 20min prior to the meeting happening.
The meeting’s purpose is unclear.
The meeting has no agenda.
Once the meeting is done, nothing has changed.

So what’s the alternative? The first step is to decide if you even need a meeting! Start by asking yourself these questions:

Are you looking to communicate information to a group of people and/or ask for feedback on said information?
Is it solely a status report meeting?

If the answer to either of these is yes, don’t call a meeting. Send an email instead.

For all other times where a meeting would be helpful, I try to use the following techniques:

Crowdsourced agendas

One of the regular meetings I have is a fortnightly catch-up with my leadership team. It serves as a reset point as well as a forum to discuss any topic we believe is pressing and relevant for the coming weeks.

In order to make the most of our time together, I prepare a meeting notes template (we use Confluence) ahead of time and send it to all attendees so that they can add discussion topics to the agenda. Each topic will have the presenter’s name next to it as well as the estimated time needed to present it.

Crowdsourced agendas keeps us in check and focused on what matters as attendees have time to prepare beforehand. So far I find that this works really well.

Agendas as questions

The second technique I wanted to share is to turn your agenda bullet points into questions. Meetings exist so that a decision can be made: you either keep doing what you’re doing or you’ll change direction based on the outcome of the meeting. It’s that simple. Therefore, instead of bullet points, try to frame your agendas as questions.

Let’s look at an example, so this becomes actionable. Suppose you need to discuss the approach for a new project you have been asked to lead - say, launch a new mobile application. Ordinarily, the meeting agenda might look something like this:

Agenda:

Discuss MVP scope
Agree team structure
Agree start date

To be honest, that’s a pretty good start already. But let’s go one step further and turn these into questions:

Agenda

Here’s a link (provide pre-read) to the proposed MVP scope. The goal is to agree to it by the end of this meeting.
We need 1 x product manager and 2 x engineers with A,B,C skills. The rough budget ask is $X for Y period of time. Can we get approval from finance? What other options do we have?
We’re looking to start on Z date. If we don’t, the launch date will be compromised - is marketing aware of the trade-offs and willing to accept a delay?

Note how attendees looking at this revised agenda might alter their prep-work for the meeting - especially decision makers. I think this second version has a higher likelihood of driving a good outcome and move the team closer to its goals.

Give that a go and please let me know what you think!

TechBytes

Sphere of Influence

Most tech companies have implemented a dual-track career path as part of their ongoing performance discussions. One of the driving forces behind this is the acknowledgement that a technically competent engineer shouldn’t have to become a people manager just to advance their career.

In a nutshell, this created a number of senior engineering roles with titles such as Staff Engineer, Senior Staff Engineer, Principal Engineer and Distinguished Engineer - we’ll call these Staff+ roles.

This is absolutely brilliant because it gives people the ability to advance - if they so choose - doing what they like and are good at.

Conversely there is still the confusion that since folks in these positions don’t have to manage other people they get to write code all the time. That is far from reality.

When I get asked that question - particularly in the context of someone aiming for one of those senior leadership roles - I talk about the individual’s sphere of influence.

Your sphere on influence starts small. As a graduate or junior engineer you barely impact your own work. You’re learning every day, and progressing very quickly. As you gain experience, you start impacting and influencing your own team by contributing with code, pull request reviews, feedback on systems design discussions and more.

Once you reach Senior Engineer you’re also expected to engage with and influence people outside your immediate team and specialty, such as product managers, designers and, of course, other engineers.

As your seniority increases, so do the expectations for your sphere of influence: it should be big enough to influence multiple teams and, sometimes, entire orgs.

But what does that look like? Resources in this area are scarce to say the least but now there’s finally something good I can point people to:

Will Larson’s book Staff Engineer includes concrete advice from people who are in Staff+ roles at various different companies, including Slack, Dropbox and many others. If reaching Staff+ is a goal of yours, read Will’s book. It’s the best resource on the topic out there.

If you have a question for me or a suggestion for the newsletter , please submit it here - I’ll address as many as possible in coming issues.