Lowering the Barrier

Making programming (everything) more accessible

02 Aug 2021

Leading When Everyone Has a Say

Before I led teams or had kids, I thought leadership was a personality trait. Something you’re born with.

It’s not. It’s a role. Get two or more people together to do something and at least one of those people will have to decide what to do first, make sure the others don’t get distracted, keep spirits high, and so on. If no one steps up, the group coasts or dissolves.

Leading means taking responsibility. It doesn’t mean always having the best ideas. In small groups, the biggest contributor can also have time to lead. That works out great for everyone. If you have a question, you can talk to the expert and the boss at the same time!

Past a certain group size (and this point always comes earlier than you want it to), all the responsibilities of leadership become a full-time job.

Leading when you’re not the expert feels strange at first. Your own output doesn’t matter anymore. It’s all about your team’s output. If you’re doing a good job, what the outside world will see is other people doing their job well.

The strangest thing is that your team probably knows best what’s possible and which projects will move the needle most. When this first sunk in for me, I asked myself “Then what am I supposed to do? Sit around and look pretty?”

Turns out there’s a lot. Figuring out what the most important thing your team could be doing comes first. You have to work backwards from what your team’s customers (regular folks, other teams, executives, the team itself) want. That doesn’t mean you go out and do all the user research yourself and come back with a report saying “let’s do this.” Instead, talk to people one-on-one and as a team and ask, “what can we do for these people?”

Making sure the team measures progress towards its goals is also your job. It sounds obvious. I’ve known this for years. Yet I still say “we should do X, Y, and Z!” in meetings with little to back it up. Data keeps you honest. Which is probably why people avoid it. It limits your ability to just go and do what you want.

Leaders also have to have the gumption to say when something’s not working. Politeness can slowly strangle teams by letting them continue working on projects that aren’t succeeding or won’t have as much impact as other projects. This is hard. Like all hard things, you’ll feel better after you do it. If you’re regularly talking about what your customers need and how your metrics compare to your expectations, then people will realize for themselves when something’s not working out.

No one sat me down and explained all the above lessons. Yet I’ve been living this way for so long that what I’ve written sounds cheesy and tautological to me. Doesn’t everyone already know this? When I talk to people in other fields, the answer is clearly “no.” And, at first glance, this style of leadership seems specific to software development. Most people on earth do not have the luxury of quitting their high-paying job and moving to another high-paying job, so why should management take their input into account? Also, plenty of people simply don’t care.

If people understand why they’re doing what they’re doing, they’ll do a better job at it. So no matter what you do, no matter your title, explaining where your team is headed and why can only help the people around you. At least it’ll help you. And if you’ve got the wrong idea, someone else will set you straight, and you can stop living a lie.

Also, whether we like it or not, this way of working is coming for us all. Not because software is eating the world, though that contributes. It’s that everyone can see how your team is doing. So you want to lead assuming that everyone has access to the same information you do. It’ll be incomplete. It’ll be incorrect. But you have to prepare yourself to lead people who know more than you do (or at least think they do).