Designing a "How We Work" API to Minimize Thrash

Written by Adrienne* and Alexis

When you run into a challenge working with others, it’s easy to get frustrated and jump to thinking it comes from incompetence - e.g. maybe it seems like they’re coming to you for help on every tiny problem or they’re pushing seemingly random changes to the codebase that is breaking features. Often, however, many of these problems can actually be fixed by something in your control.

I realized that many of these issues that arose that I thought were coming from people, were actually coming from not having a clear communication API.1 And when this API wasn’t clearly defined, I ended up forcing my way of working on others, expecting them to mold to it, and then running into bad outcomes.

Other teams can jeopardize your product launch

A few years ago, when I was working on launching a product at Tesla and needed to work heavily with another team, the beginning stages were really rocky and jeopardized our product launch. We were working together on a highly technical product, and the other team didn’t have technical team members. The team seemed to frequently request that my team’s engineers build complex tooling that didn’t seem necessary, and they also made changes to our machine learning model without first notifying us, which would unexpectedly break features of the product.

While I was first frustrated, I realized that because I didn’t understand the context they were coming from, I was forcing my mode of operating onto them, expecting them to bend towards me, and then being disappointed. I realized that instead, if I approached the beginning of every relationship defining a “how we work API” where we would negotiate how we’d work together, it would lay a stronger cement for working together -- even though it seemed uncomfortable and unnecessary at first.

How to negotiate the “How we work” API

Step 1: Gather background context

In order to be a good partner, I needed to understand them and the context they were coming from, instead of forcing my own context onto them. I see myself as a doctor going in to diagnose the situation, and the kind of team I will be working with. I ask:

  1. What are the team's capabilities?

    1. Backend

    2. Front end

    3. ML

    4. Operations

  2. How does the team make decisions?

    1. Top down

    2. Bottom up

    3. Each teammate on their own -> may lead to a lot of thrash

  3. Who are the main players?

    1. Who is the decision maker?

    2. What role does the PM play? Does the PM just consult? Work with EM?

    3. How new are the team members?

Step 2: Define the API

Once I understood the context, we could work to define our API together. An API consists of three things:

#1: Align on the goal

  1. My team’s goal

  2. Other team’s goal

  3. Joint goal
    Define a joint goal. If this joint goal is doing well, then both of our top-line goals are doing well. We are going to marry each other so our interests are intertwined, rather than in conflict.

#2: Define the decision-making framework

  1. This is how we make trade-off decisions
    If your metric is going up and mine is going down, what do we do?

  2. This is how we will unblock each other on technical work.
    Example: The other team was constantly making changes to the machine learning model, which made it difficult to track down changes when something wasn’t working. So we defined a way of updating the model: we onboarded the team onto our Github repo to submit and track changes so both teams were aware, minimizing downstream bugs.

  3. Who to talk to about what.
    This avoids confusion and conflict when there are multiple decision-makers.

#3: Define the enforcement mechanism

  1. Regular cadence of meetings

  2. Shared communication channel to commit to
    E.g. It’s OK to email for X things, but for Y things you should check the group

Using the API in action

Later once I better understood the other team, we were able to work more smoothly -- because I had a handle of things such as what their capabilities were, how they made decisions, and how we could work together. I understood the context they were coming from. For example, once the other team knew how to create pull requests in Github, it was much easier to track all changes happening to the machine learning model, and we had less surprise bugs downstream.

All relationships work smoother when expectations are clear and explicit. For example, when the other team kept requesting my engineers build features, instead of forcing the other team to adopt my way of working and telling them I can’t build all these features they are requesting, I defined a way of working together. You can say:

I'm excited to work towards shipping this product together. I noticed your team is making a lot of requests to our engineering team, and focusing on some of these could take away from our successful product launch that is 2 months away. What are you expecting in 1 month vs 3 months vs 6 months?

After negotiating, you and the other team decide on a set of prioritization guidelines to help guide decision-making on how you spend time building. 

If you expect others to adopt your unspoken implied expectations, you’re, in essence, demanding that others be able to read your mind in order to be in an effective relationship with you.2 This implicit approach can breed a lot of resentment. Translating implicit expectations to explicit ones makes any differences clear and obvious so you can navigate through the bumps.


An API is a computer science term, meaning Application Programming interface; it’s a set of rules that dictate how one set of code should communicate with another set of code, useful for integrations.