Let me add a bit of context. Say you have a basketball team of six people. No coach. Who is responsible for making sure the team performs as well as they possibly can? And why does that responsibility exist?

One could assert that, well, it is the responsibility of the whole team. And that assertion would be correct.

One could also assert that it is the responsibility of the team members that have the most experience and knowledge of the game. This is also correct.

How can this be? Well, while each and every team member is responsible, the amount and kind of responsibility can vary substantially.

In this way, one might say that the responsibility of each individual team member is to “do whatever they can to make the team more successful.”

Taken together, the corporate team has a responsibility to arrange itself in such a way that maximizes its chances of success. In order to be capable of doing so, communication is required. The strengths and weaknesses of players must be considered, as well as their interests and passions. When interests conflict, negotiation must happen unto resolution. Resolution can come in whatever form that the team deems appropriate - some teams may choose to accept the authority of their most experienced member. Others may prefer voting, and still others may prefer favor-trading.

And thus, responsibility is compositional. “To whom much is given, much will be required.” And in order to maximize each individual contribution, a knowledge problem must be grappled with: of what is every person capable?

This knowledge problem is persistent, and a moving target. It is one problem to learn the strength and weaknesses of team members at one point in time - it takes a lot more attention to keep abreast of changes over a season. Attention, and effort. Team members have to keep this knowledge up-to-date enough in order to successfully collaborate.

It is with this understanding of responsibility and the knowledge problem that I approach any team of which I am a member.

Real talk - I’m not as young as I used to be. Compounding that, I’ve always had something of an aura of command, probably deriving from the focus and the seriousness with which I approach work. Put these two things together and its quite easy to get saddled with the role of “boss”, with all of its strange baggage (for more on that strange baggage, see my previous editorial Bossless).

As a senior and highly-capable member of a team, I bear special responsibilities. I have to look out for dangers that only someone with my experiences can see. Moreover, I have to pass on that knowledge to as many team members as possible, so that they can scout for problems successfully as well. I also have to make sure that I’m keeping my skills relevant enough that I can accurately bring my experience to bear, so that I don’t end up making out-of-date recommendations.

The problem? Well, when people see you as the Boss, they bring their problems, and many of their responsibilities to you. They want someone else to make decisions. They want a single point of authority to hold all the responsibility for strategic decisions, and all of the credit. Someone that can be replaced when things fail, such that the whole team doesn’t have to be swapped out ¹.

The truth is, at least in my line of work, decisiveness is a commodity skill. Moreover, being able to propose and execute a plan is a key component of computer programming - the business of writing precise, procedural instructions. Most day-to-day decisions simply don’t bring my unique level of experience to bear - by their nature, they are rare events.

Given that, when people push boss-ish-ness onto me, I turn the tables. If someone asks me for orders, I’ll tell them to come up with at least three different plans of action. If someone comes to me with a choice, I’ll ask them to make a recommendation, with an explanation as to why. If someone brings me a recommendation, I’ll ask the rest of the team to listen to the recommendation, and respond. And while listening, I’ll try to gently nudge the rest of the team to fully think around the problem. All of this before adding my own perspective based on my experience.

I want people on my team to practice self-consideration and self-management, and get good at this, and these techniques take the energy directed toward “doing what the boss says” and redirecting it toward exploring the whole of a problem. But additionally, I want them to understand this: the most important audience for far-reaching decisions they may make is not the boss - it is the team that will have to live with the decision. A bad decision that the whole team believes in is frequently better than a good decision that the team executes against their wishes.

This is because the team is invested in finding a way to make it succeed. And that extra little boost of effort can be enough to evolve a bad decision toward a good decision… one in which the team believes.

In situations where the team is in danger of going in a direction that my experience tells me is a dangerous one, I’ll work through the problem with them. Again, my responsibility is to bring and represent my experience to the team in order to raise the chances they’ll succeed, and like any other team member I have to make the case. I am subject to the same rules that they are. In times of conflict, the team will have to come up with a resolution strategy, including conflict with me. In situations where I truly stand alone, I have a decision to make: I may acquiesce, or I may leave the team.

Acquiescence implicitly says that I’ve counted the cost, and even though I may think the decision is a poor one, it will not be a critical problem in the future. Conversely, if I believe it will be a critical problem, I should not sign my name to it.

Situations like this, of course, should be extraordinarily rare. Part of my job is to educate and bring my team to an understanding of my misgivings, and having pivotal arguments like that is a sign that the team isn’t working together well, and I haven’t been able to do my job.

Essentially, I want all the interactions that team members have with me to model how they should be treating each other. Ask questions of each other. Slow down and teach. Collaborate, don’t dictate. Be willing to compromise. Be willing to try “bad” ideas, especially if the cost of the bad idea is low. Be willing to say “I don’t know, let us do some research.” Let people learn, and expect them to make decisions for themselves.

This might not be quite as reckless and free-form as it sounds though. In order to support this much freedom on my teams, I always have a few strong norms established:

Having strong, automatic test validation means that as long as the tests pass the system has not broken. And having faith in those tests means that there’s a lot of room for the team to experiment: the safety net will stop them from damaging the system.

This is potent. It allows both good and bad ideas to co-exist, so long as the system doesn’t break. It allows the team to practice rearranging and re-articulating how the system works incrementally, without breaking it.

But most importantly, it lets the senior members of the team know that, at the end of the day, the system is still ok. Which allows us to focus on our other responsibilities.

Having a “responsibility” mindset rather than an “authority” mindset is how I “deboss” myself. Will it work for everyone? I have no idea. But it has certainly helped me build stronger, more responsible team members. Team members that I think of as collaborators rather than subordinates. People that I know will be able to handle themselves without me.

There’s a common misunderstanding of the nature of team dynamics underneath this desire, but there are indeed situations where being able to swap out a leader to minimize damage to the team makes sense - principally when much power is explicitly granted to that individual. ↩