Players and Coaches

Imagine you're playing a soccer game. After about 15 minutes of play, your coach jumps on to the field and starts kicking the ball around. Nobody blows a whistle, and the game just keeps on going like nothing crazy is happening.

But...what the hell?

5 minutes of confusing play later, you get the ball, dribble downfield a bit, then pass it off to another player. Instead of receiving the pass and doing something with the ball, they let the ball fly by them, trot over to you, and start critiquing your pass. Your weight was too far back, you didn't lead them enough, and didn't you notice how there was a defender threatening the lane?

All of this would be absolutely insane--and obviously so--in any sports setting. However, it happens all the time in a business setting. It's one of the biggest points of friction between and among teams.

At startups, like Extra, it's even worse because all the processes are being built as we go, the teams are growing like crazy, and we just haven't had as much time working together in our new contexts--so it's hard to even identify the disconnects between us because of the assumptions we bring from other companies.

Let's all get on the same page.

The major reason it's so confusing in a business setting is because we're not all playing one single game.

The growth team is busy optimizing the cost of acquiring traffic. Product is figuring out how to create the best experiences for users. Customer service is slammed just trying to keep up with the flow of incoming user questions. The engineers are hardening the system for scale (as well as building whatever's next on the roadmap).

This is like being in the middle of a soccer game being played in the middle of a football game, with golfers playing through and boxing matches on the sidelines. Everybody is a player in (at least) one game, and they're all eligible to be coaches in every game they're not playing. It's all so chaotic that people often forget--or maybe never knew--which game they were actually there to play.

So what's it mean to be a player? In which game are you the player and which ones are you not?

The simple answer is: you are the player in the game where you own the decisions. That's the only game where you are a player. In every other game, you're a coach.

The first step in being a good player is recognizing that you are, in fact, the owner of the particular decision or business area.

If that's you--and you somehow fail to take ownership--then the entire org can suffer chaos around you. Other people may try to fill in, which blurs the ownership. The decisions may just go unmade--or maybe worse, get made, get reversed, and get changed yet again, thrashing anyone connected to that decision.

If you are tasked with being the owner, then do it. Players need to play.

What does that look like? Do the work. Make the decisions. Be clear about the decisions you've made. Document them and share them. Make them easy for others to understand. If you're not ready to make the decision (totally valid at times!) then let others know that too, and give them a timeframe that they can expect to hear back from you. (Do not leave the space empty. You need to set the timeframe, like leaving something to save your table in crowded restaurant.)

The second step is being open to feedback, like really open. If you're the assigned player--and you've owned the decision--there is nothing to fear from feedback. You just have to know how to take it and make the other person feel heard. Other perspectives can enlighten your thinking. They can identify edge cases you missed. They can point out better solutions.

However, they also often miss massive parts of the problem definition or get presented with a confidence that was never earned. How much should you really trust your data analyst's feedback on icons?

The key to receiving feedback is to treat them all as helpful suggestions, trying to get at the problem the other person is identifying, or even rephrasing the feedback as questions (as opposed to statements). However you go about it, you have to recognize that feedback is often phrased as an imperative command ("you should make it the icon green" or "you should be advertising on TikTok").

As the player-owner of the decision, you have to soften the commanding nature of the feedback and get at the kernel of their logic and decide if your solutions addresses whatever they've identified. If not, then you need to go through your process, incorporating the new information, and come up with a new solution of your own making. You never get to just punt the decision by saying, "The CEO said it had to be green, so that's it." (At least not at the best companies.)

It's worth reiterating: The above logic only applies to areas where you, in fact, the player-owner. None of the above is license to take over decisions that you don't own!

The first step in being a good coach is--unsurprisingly--identifying that you are, in fact, a coach in the current context.

Now, here comes the biggest thing you can do as a coach: make it clear to everyone that you're just a coach. You are not a player here! Then reinforce those roles.

Reinforcing "Not Player" Status

Reinforcing your "not the player" status--to yourself and others--is about preventing you from taking ownership where you don't have the authority, but may have the ability to do so anyway.

A common scenario here is that you are the player when it comes to implementing decisions made by someone else--but decisions themselves belong to that other person. For example:

• You're the designer, implementing a user flow specified by a product manager
• You're an engineer, updating the in-app text handed to you by a copywriter

Someone could come to you and ask you make a change--and this might feel natural. There might be no sense that a boundary has been crossed at all. What's the problem if the designer who's making the screens alters the flow a little to make it better? What's wrong with an engineer tweaking the text to make it a little more readable? After all, we all have the same goal in mind.

However, you've just commandeered ownership of a decision that wasn't yours. The changes might not even be visible to the actual owner. Maybe your solution works, but it's more likely that you're not aware of some part of the problem definition that caused the decision to land where it did.

The first step is: recognize that--as the implementor--you have a great perspective, but that doesn't give you ownership. If you have an idea, it needs to be given to the decision-owner as feedback, just like everyone else's feedback. The fact that you're actually making the thing work doesn't give you the right to commandeer it.

The second problem is--even if you recognize the above--others may not. You might have an executive or someone else in the org approach you and give you feedback (or just ask you to make a change). This is where it's critical for you to direct the request back to the actual owner. If you don't people will keep doing what works (for them, not the company) and areas of ownership will break down.

This is actually one of the biggest cultural challenges a growing company faces. In long-established corporations, the "not my area" sentiment can become too strong, such that people refuse to do things that are "not in their job description". In startups, everyone is willing to do whatever is needed.

The ideal goal for a growing team of a decent size (like at Extra) is that everyone should be aware of what's going on and giving feedback on what is/isn't working--but that feedback should be directed to the owners (players), not directly executed on by just anyone. That's the balance. Everyone cares about everything, but everyone only plays inside their designated scope.

Reinforcing Coach Status

While everyone should try to do a good job in delivering feedback, it's an especially important skill for managers and leaders. The more senior you are in the org, the more important this skill is. You want to be very explicit in your use of language to show you are, in fact, giving feedback and not taking over the decision.

When you're a coach, you do not own the decision here, and the worst thing you can do is talk and act like you do. The worst offenders here are executives. By the nature of their position in the company, they are used to people deferring to their judgement. If, as an executive, you start to forcefully share your "feedback" about decisions in a commanding way, it's a lot to ask of someone (who's career you control) to push back against you--even when you're way outside your area of expertise.

So as you get higher in an organization, you have to be extra careful to make it clear that you are giving feedback as a user or just a person--not as the "COO" or whatever your title may be.

How do you do that? Here are some options:

• Phrase feedback in purely diagnostic terms and avoid offering solutions
  • "That icon doesn't stand out to me" vs "The icon would be better green"
• Ask questions to probe if the player has considered your concerns
  • "Have you considered if you can use high contrast colors to make this stand out more?"
• Provide multiple alternative solutions, to make it clear that you're not giving a directive about what to do
  • "I think the color of the icon needs to be different, maybe green, orange or yellow--something that stands out from all the blue in the rest of the UI"

In general, it's a good idea to frame your feedback with language that tries to make it clear--overly clear--that it's just feedback and that you recognize who the decision owner is.

This is good practice for everyone, but it's absolutely essential that feedback from leaders be caveated this way. It's just too easy for an executive to think they're giving feedback and the junior person to take it as a directive. So the more the power-differential between the two, the more emphatically the feedback has to be "softened".

Some phrases I like to emphasize that:

• That's just my thoughts, but it's just my opinion
• DAU of 1 (meaning I'm saying this as a single Daily Active User, nothing more)
• That's what I think, but you're much closer to the problem
• I'd do it like this, but if you have another way to do it, I'm happy to defer to your judgement here

What If You Do Want to Make the Decision?

Sometimes you do, in fact, want to take the decision out of the player's hands and make it yourself. What then?

Well, if you don't occupy a position of at least some authority, you probably can't do this. So let's assume you do. You're the player's direct manager, skip level manager, or an executive who has clout despite lacking direct-line reporting authority.

First, ask yourself--why? Why do you want to own this decision right now? It may seem expedient, but it's robbing the player from the struggle that they need to experience in order to become better at making such decisions. You're sacrificing the opportunity to improve your org in order to get a particular outcome, this one time. Does this particular situation warrant that?

If you ask yourself that and come back with a yes, then ask yourself--are you sure you can make this decision well? Unless you have way more experience making these kinds of decisions, the player probably has far more detailed context and far more time than you do. How can you--with your limited view--expect to make a better decision in a fraction of the time?

Let's say you consider both these factors and decide to go ahead. Then be clear that this is what's going on. You are taking over this decision. Just say it. The other person should know that. They should also trust that you will not hold them accountable for the consequences of your decision. (They may still get stuck cleaning up your mess, but at least they won't also have to swallow their pride and call it their mess.) Hope it works out!

This is getting long, so I'll keep it simple.

If you don't know who's the player and who's the coach, ask. Ask the people you're working with. Ask your manager. Ask their manager. Keep asking until you get an answer or get to the top. Good organizational design with clear areas of ownership is ultimately a game where the CEO is the ultimate player.