How to scale your impact across multiple teams as an individual contributor

When I first made the step up to Staff engineer at Monzo I was given a great performance review, along with the feedback that 80% of how I worked would need to change to maximise my impact.

At any level, you have to make decisions about where to put your time, but as my remit expanded beyond a single team, there was a step-change in how much thought it took to get this right. In this blog I’m going to share my portfolio based approach to optimising for impact beyond a single team.

A portfolio based approach

As a senior member of a single team, I would read almost everything produced in that team and most adjacent teams. I’d engage with every strategy conversation, review most PRs, and feedback on most proposals. This was a great way of grabbing opportunities with both hands and being a big part of that team’s success.

However, as my remit expanded, doing this resulted in an unsustainable amount of context switching. One of my mentors at the time described how they viewed their work as a portfolio, where in practice there was only room for at most 4 things at any one time. They proactively thought about whether adding something new would mean having to hand something else off, and tried to maintain consistency in where they invested so that their portfolio wasn’t changing week-on-week.

I’ve refined this approach over time, and today I build my portfolio with this 4 step approach

1. First define your remit. This is all the areas where you might take accountability for an outcome. You should collect signal over at least this remit, and ideally beyond it.
2. Then list out the potential bets you could make. Each bet should be made up of a goal, possible engagement modes, and exit criteria.
3. Build your portfolio with a subset of these bets, make your level of accountability clear. Consider if some of the bets you aren’t taking are a great opportunity for others.
4. Execute on your plan, then reflect and update it. Never stop collecting signal.

We’ll explore this approach in more detail over the following sections.

Collecting signal

Gathering context on what people are doing around you helps you to identify potential opportunities for you to have impact. How you do this is quite personal, but I find a healthy mix of proactively reading documents produced by other teams (particularly product reviews at Monzo), speaking one-to-one with people, and attending “team days” for your remit works well.

You can dial how much time you spend on this up and down over time, sometimes you might accept reduced visibility over your remit while you deeply focus on solving a problem you’ve already identified. I find this averages out at about 10% of my time (half a day a week) between reading product reviews outside of the teams I’m currently working with, and 1:1s with people who are particularly good sources of signal for me. This can easily double during planning cycles, and trend to zero during crunch times on high-impact projects.

Here’s some tips for getting the most out of your signal gathering

• Make it a first-class investment — it’s ok to make explicit time for reading and engaging with new people who you think will help you gather signal. Don’t attend a presentation then multi-task through it, ignoring the content.
• Be selective — if a particular person is a fantastic source of signal for you, spend more time with them, regardless of their level or position. The same applies to documents and team days, they aren’t all created equal. You’ll often get more value from reading more deeply into one thing that’s going on and catches your interest than skimming three decks half-heartedly.
• Separate it from your “bets” — it can be tempting to get involved with things unintentionally during signal gathering. This often manifests itself as engaging in drawn-out debates in comments, or booking additional one-to-ones to get into the details. There’s a fine line here, because sometimes sharing your opinion in a best-effort fashion whilst signal gathering can be valuable, but take a minute to stop and think before investing additional time.

Types of bet

It’s easy to view a bet as a project, as this is often the form they will have taken when your remit is one team. I’ve found it useful to define my bets in terms of

• A focus e.g. a person, project, or process;
• A goal e.g. enabling somebody to become an effective tech lead, or getting a project to a specific milestone;
• Exit criteria that need to be true for you to be able to choose to swap this out for another bet, this is your acceptance test.

When placing a bet, you first need to determine if this is something you’re accountable for, or whether it’s best effort.

• If something you’re accountable for goes wrong, you either need to invest more to turn it around, or accept accountability for the failure. You’ll generally get attributed a large share of the success for these bets.
• Best-effort investments can have a high impact, but ultimately somebody else is accountable for the outcome.
• It should be clear to others when you’re accountable, and you’ll often need to agree this with peers, or your manager.

Once you know your accountabilities, you need to choose an engagement mode

• Hands-on will be familiar, it means doing a lot of the work yourself or in close collaboration with others.
• Consulting requires you to work through others, for example by reviewing strategy or technical proposals, but not being a day-to-day part of the group working on the project. I use this term broadly to cover coaching and mentoring as well.
• Delegating means making somebody else responsible for the work, without significant, direct involvement from yourself.

Finally, you need to agree on your exit criteria with the team you’ll be working with. As an IC in one team, this is usually coupled to the success of the project as a whole, but once you start optimising across multiple teams, your specific objective may be more nuanced.

• When seeding a new project, it might be having agreed a roadmap, and handed over to the team which will deliver it.
• When consulting with a team working on product growth, it might be clearly defined metrics, a habit of reviewing them, the first few experiments shipped, and a backlog to continue working on.
• When stabilising a team that’s struggling, it might mean solving a specific urgent problem, coaching the team lead, and onboarding some more support with them.

It helps to make this explicit up front, and talk about it openly with the team you’re working with.

Building your portfolio

I want to maximise my overall return on my time invested, so that means focusing on the expected value of my bets, rather than the guaranteed value. One of the reasons to have senior individual contributors which span multiple teams is that they can spot opportunities that you might miss from a narrower remit, but inherently these are often higher risk and require more cross-functional collaboration.

However, I also need to stay motivated and happy. This will be personal, but for me this means setting a floor for the amount of time I spend hands-on building products, and a bias for exploring things I’ve not done before.

The mix in my portfolio changes over time, but I’ve generally found that I’m both happy, and having a lot of impact when my portfolio

• Is not entirely made up of best effort bets
• Contains at least one hands-on bet, even if its best effort
• Involves at least 50% of my energy being focused on one goal

It’s a good sign if your portfolio has some stability, with bets slowly cycling in and out over the course of several months.

Prioritising can be very challenging, but failing to do so does not create more hours in the day. Get started by laying out the opportunities you’ve discovered, and the specific value you think you could add, and have a conversation with your manager. If you find just one thing you wouldn’t have worked on otherwise, or an investment that would make a better opportunity for somebody else, then you’ll be in a better position than when you started.

Anti-patterns

Now that I’ve outlined how I approach building my portfolio, let’s look at a few ways it can go wrong.

Doing it all at once

Having a portfolio of bets doesn’t mean you need to do them all at once. I find it helpful to be clear what my top priority is at the start of the week, this is the thing I’ll drop anything else to achieve. I’ll also list one or two secondary priorities which I can make progress on if this top priority is blocked.

This gives me a high degree of focus on any given day or week, but where that top priority is will move between bets over weeks and months, achieving widespread impact without rapid context switching.

A nerdy analogy is acting as a single-threaded multi-processor, giving the illusion of doing a lot in parallel, whilst only focussing on one thing at once.

Going outside your team for the sake of it

I commonly see engineers at Monzo given feedback that they aren’t having impact over a wide enough remit to progress. This comes from observing that many of the more senior engineers do have impact over a wide remit, but what gets lost in translation is that this comes from

• Raising the bar for the expected impact of the work they do
• Gathering signal over a wider remit
• Choosing the highest leverage opportunities available to them

If you artificially find work outside of your current remit, you’re likely to drop the ball on something higher value and closer to home. Often the first investment you need to make is into people you already work with, delegating more and coaching them to free up more time for you to explore the opportunities in a wider remit.

Not embracing the void

When you start to raise the bar for the expected value of the work you pick up, you might find yourself with more free time. Resist the urge to fill it with lower-leverage work, this is the time you need to invest in a signal gathering habit which will surface higher value opportunities to you.

Start by reading that proposal that you’ve had saved for a week, or by choosing one person adjacent to your team to think of some questions for so you can learn more about the current issues they’re facing.

Not following your exit criteria

It can be really helpful to agree your goals, and exit criteria with the team you’ll be working with when you take on a bet. You might need to remind them of this, and when you’ve reached them, it takes some discipline to cancel the recurring one-to-ones, and stop attending rituals you’ve become a de-facto member of.

It can be the right choice to start with a more hands-on bet, and then follow up with a consulting investment on the same project right after it, but don’t fall into this pattern by default when there’s higher leverage work elsewhere.

Stepping away also creates the space for others to step-up and take the lead.

Kudos

Thank you to Markos Mylonakis for co-creating this framework with me. Markos was my manager during my transition from a single team remit, to multiple business units at Monzo, much of the advice in here is his, and I’m grateful for how openly he’s encouraged me to share it.