Abstract Management Interfaces

Chris Schillinger
Oct 5 · 7 min read
Image for post
Image for post

Over the last two years at Flatiron Health, I’ve been lucky enough to manage a rapidly growing team of amazing engineers. This growth has meant that, for the first time, I’m now managing other managers. This is both really exciting and slightly terrifying! The blast-radius of an underperforming or rogue engineer is limited, but the blast-radius of a manager of a team/org/division can be huge.

I’ve found myself thinking a lot about questions like:

  • How will I hold this manager accountable for the things that I care about?
  • How will I collect the right feedback to both avoid disaster and help them grow?
  • How would I know if our values weren’t aligned?
  • Are there ways to help them self-evaluate whether or not they’re doing a good job?

Flatiron provides some really great training for us managers so I had a good head start, on top of which a new process started forming in my mind. I’m calling that process “Abstract Management Interfaces.” In this post I’ll walk you through how this process helps answer the above questions in a way that also scales across multiple teams.

Image for post
Image for post

In Practice:

Sprinkled throughout this post you’ll find anonymized stories from other real engineering managers across Flatiron Health, highlighting situations where an Abstract Management Interface was, or would have been, useful.

What is an Abstract Management Interface?

Simply put, your Abstract Management Interface is a set of outcomes that you expect from the manager you’ll be managing. You walk through this interface together and they should explicitly agree to meet (implement) all of those expectations. As in programming, this interface lets you stop worrying about exactly how they will implement the interface, as long as they satisfy the agreed-upon outcomes.

The important points are that you focus on outcomes rather than solutions, and that your direct reports raise any questions or concerns about your expectations so that the two of you reach at least commitment (and ideally agreement.)

Management theory often talks about the need to set expectations and empower, but isn’t always clear about how to do this. This process aims to give a clear set of steps for achieving both. Note that, while this post is using the interface programming terminology, the general process could be applied to management of any function. Those less familiar with programming interfaces can think of it like a “team contract.”

Show me some examples!

Chris’s Front-line Manager Interface : This is a cleaned-up version of the interface I use with my current sub-team managers and leads at Flatiron.

Chris’s Manager-of-Managers Interface : This is a cleaned-up version of the interface my supervising manager and I worked out together.

Image for post
Image for post

In Practice:

“The first time I managed a manager, it was a strong individual contributor I asked to step up. They had great business instincts, were strong technically, easy to get along with, and had the respect of the team.

“Nine months later, team members were deeply dissatisfied, and the manager and I were both at our wits’ end. They ended up moving to another team to become an IC again.

“In my head, long-term team health and viability were paramount; for this new manager, the day-to-day was overshadowing. I had thought we had implicit agreement, and I wasn’t experienced enough to recognize the problems as signs that we were on different pages. We agreed that the product must go out on time, but were pretty far apart on everything else.”

What’s so great about an Abstract Management Interface?

Makes expectations clear on both sides

  • Shows managers who report to you exactly what you expect them to own
  • Shows them what you think “good” looks like

Focuses on outcomes, not solutions

  • Empowers managers who report to you to own the problem
  • Reminds you to coach them when talking about team details, and to hold them accountable when talking about team outcomes

Helps spot values misalignment

  • e.g., What if your direct report doesn’t think your “Team is happy” outcome is necessary or important?

Can help counteract unconscious biases

  • The more objective and intentional you can be about your expectations for someone’s performance, the less chance that unconscious bias can influence your evaluation
Image for post
Image for post

In Practice:

“I had been acting as interim tech lead for one of my teams while it was growing, so I knew the code and problems well. Eventually, my org grew too big and I had to hand the team off to a new manager.

“The first few months of the handoff were rocky, I had a lot of opinions about how things should be handled and 1:1s with my new manager were often tense.

“Sitting down and defining an abstract interface for managing the team really helped me step back and focus on the outcomes, rather than the solutions. It still helps me maintain that perspective today.”

What are some tips and tricks for implementing this well?

To get the most out of this process, I recommend customizing each Abstract Management Interface for your specific management style and organizational circumstances. It’s an iterative process.

Ask yourself, “What should absolutely be true about this team?”

  • You can try starting from one of the interfaces linked above

Then ask yourself, “What could go wrong even if all of that was true?” Repeat until you feel satisfied that all risks are covered. As an example, assume you define:

  • Outcome 1: Deliver on time -> What could go wrong? Team is unhappy.
  • New Outcome 2: Team is happy -> What could go wrong? Team isn’t aligned to company values.
  • New Outcome 3: Team is a champion of company values -> What could go wrong? … etc.

Sleep on it, then double-check that you didn’t let any solutions sneak into your interface. Even well-known solutions like retrospectives should be off limits!

Previewing the resulting interface with your supervising manager one level up can help spot any areas you may have overlooked.

After you have your interface, sit down with the manager/s you manage and go through every point, and dig into any disagreement areas. Remember, the goal is shared commitment and understanding across the board.

  • This is a good opportunity to refine your interface based on feedback and conversations
  • Revisit the interface from time to time (career check-ins are a good opportunity)
  • If you have multiple teams in your organization, see if you can make the interface generic and repeat this process with all of your teams’ managers/leaders

Keep evolving the interface over time as you spot missing outcomes. Do this together as well, it’s a great way to put identified gaps into context.

Encourage the managers you manage to draw on this interface when drafting their individual goals.

Use the interface as a source of questions in your skip-level 1:1s (you are doing skip-level 1:1s, aren’t you?) This helps you get exactly the type of feedback you and your managers need the most.

Image for post
Image for post

In Practice:

“I recently had an IC who was transitioning to become a Team Lead on a different team. They had done a lot of reading on their own, so had a good picture of what a Team Lead looked like in theory, but were struggling to translate that into action on the new team they were joining.

“Specifically, they were struggling to integrate their theory of leadership into a team which already had cross-functional members running many of the team’s processes, and existing team members already owning complex problem spaces.

“A senior member of the new team and I sat down and put together a document explicitly laying out the responsibilities we saw. It had a ‘general TL responsibilities’ section, as well as a ‘translated to team X’ section. The IC appreciated the explicit translation and it helped reduce their stress about taking on both a new role and a new team at the same time.”

Any gotchas to look out for?

Resist the temptation to use this interface as a team survey or structured retrospective. Your interface will be necessarily high level, resulting in a low signal-to-noise ratio for any survey-style ratings. And if everything is currently going well, it makes for an incredibly boring retrospective.

In closing

By taking the time to sit down and explicitly agree on what success looks like, you’ll jumpstart your working relationship and help the manager/s you manage to focus on their team’s success with clarity and confidence.

Flatiron Engineering

Thoughts from the Engineering team at Flatiron Health.

Chris Schillinger

Written by

Software Engineering Director at Flatiron Health

Flatiron Engineering

Thoughts from the Engineering team at Flatiron Health. We're building technology that enables cancer researchers and care providers to learn from the experience of every patient.

Chris Schillinger

Written by

Software Engineering Director at Flatiron Health

Flatiron Engineering

Thoughts from the Engineering team at Flatiron Health. We're building technology that enables cancer researchers and care providers to learn from the experience of every patient.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store