An Engineering Team Where Everyone Is a Leader

Regarding all these alternative ways of organizing, what's wrong with a leader taking responsibility, delegating it where feasible, and selecting for team members to whom they can delegate responsibility with confidence?

Taking direction or orders from a manager is only ever stressful if that manager doesn't take accountability for their decisions and directions. I'm not sure the solution to that is a new framework where managers can direct without responsibility or accountability. Set a bar for managers that includes ownership, and the ability to delegate responsibility while persuading staff to willingly take on their own level of ownership.

This "manager as peer," approach I have seen in a number of organizations is dishonest and seems to just mean forfeiting responsibility, while opportunistically cherry picking successes to take credit for.

Team members don't need to be "heard," or need sympathy from managers, they need confidence that their leadership understands the environment they work in, takes responsibility for decisions, and gives them direction based shared competence.

Of the problems to solve for, improving the quality and selection of managers seems smarter than contorting ourselves into new frameworks to work with ones who avoid responsibility.

If you want to be liked, just be nice. If you want to be respected, take responsibility.

> I suggested two options to them:

> 1. Either we have another person do the project management - and they have no say in how this will be done. Perhaps we even entertain the idea of an external hire - who is not an engineer. They won't have the engineering context, so they'll ask for more frequent updates, and have more regular check-in meetings. Also, anytime something seems to be delayed, they will have to come to the engineers to ask them how and what can be mitigated.

Not listing his "option 2" since the description for "option 1" is already so loaded that it's obvious the correct answer is "anything but option 1". I can't say I'm a fan of such manipulation.

> After this chat, everyone went with option #2.

Surprise, surprise.

Ultimately, the problem with these kinds of wisdom posts is that they suffer from the "everyone is the same, given the right chance or push" fallacy. We love it when the parts are all the same because it reduces our cognitive load, but that just doesn't happen in reality, especially with people. We can see from his "options" that he ran up against this problem, and solved it by forcing people to adopt the mold he'd set for them. Now everyone's a leader! Problem solved.

After thirty years in this industry, I've learned that in a good environment, almost any process or team organization will work, but in a bad environment, nothing will help. :/

The places I’ve worked at where “everyone is a leader” ends up with 1 person feeling adamant about something. And everyone else disagreeing, but then saying: sure whatever, we will do it that way.

Nobody wants to have conflict and nobody is in charge. Leads to a lot of very bad decisions imo.

My first dev job saw this fad come through the department one season. It went from "Here's your feature for this week, please implement it" to "Here's your feature for this week, you're the leader for development on this! Please implement it.". I understand that middle management has basically nothing to actually do, so it invents shit like this, but it pisses us off that actually do something to have this weird changing layer of bullshit smeared over what is a feature factory job. You can't shine shit with buzz words.

Title is a bit bs

Their is a difference between ownership of a project and leadership. When they asked senior developers with experience to lead they had the vision granted by experience to do so. When they asked the juniors to lead they lead the project into trouble as they don't have the experience to see problems and judge risk well.

The success came from giving every one ownership, a stake in the project and work. But when making every one the lead they ran into the too many cooks spoil the broth problem, the solution was to give the juniors the same responsibility (ownership) but more leadership in how to achieve.

This is the type of article that new engineering managers should bookmark and re-read every few months. Is the advice perfect? No, but it will probably bring some new perspective to some problems you'll have along the way. There is no one size fits all management strategy that works in every situation, but every manager should be aware of the common pitfalls on the growth path of engineering managers.

In my personal experience as an engineering manager and in mentoring new engineering managers, this is the tipping point where managers either succeed or spiral into burnout:

> I found myself and our product manager becoming the bottleneck in planning out who will work on what project, next, and who will be the lead.

If you find yourself bottlenecking the team, you're either micromanaging or your team has grown too large for a single level of management. You need to take the time to develop a new system that removes you as the bottleneck. Don't try to push through the issue by putting in more hours. That's not sustainable. Find a new system.

The "everyone is a leader" strategy described in this article is a good perspective on what every manager should be doing: Clearly defining ownership boundaries and expectations, while avoiding micromanagement. It's a common mistake to assume that because the manager is responsible for the success and failure of a project, the manager should also micromanage the critical decision making. That's the first trait that needs to be trained out of almost every engineer promoted to manager in my experience.

Some engineers instinctively reject anything that feels like a management responsibility. Others will demand promotions or raises for taking on basic ownership tasks. Often, these engineers started their careers in toxic environments where accountability was synonymous with "you're going to be fired if this fails". It's important to show these engineers that your environment really is safe, and that good things come from taking ownership. You have to back up your words with your actions, of course. IME, most engineers truly enjoy autonomy, ownership, and leadership once they can reasonably expect that it won't be used against them.

And of course, it's important to screen for these traits during the hiring process. It's also important to filter out engineers who can't or won't learn to take ownership of their work.

The challenge with this is when you have a team with members that, by and large, wants to be led for various reasons (lacking motivation, does not want to lead, distracted with other priorities, etc.). In a team like this, there needs to be someone that “calls the shots,” as it were, while giving every team member enough of a voice to feel like they are heard and enough autonomy to do the right thing (provided they have the skills).

Speaking of skills, this leadership approach fails hard when you are handed a team of people that are low-skilled, for whatever reason. Some of these folks can’t be let go (too expensive to do so, usually). Micromanagement usually works in this instance, especially if you can’t train

In my experience, high-performing teams arise when every member has expertise that is acknowledged and respected by the rest of the group. As soon as you add skill+experience redundancy, performance will be hindered by jockeying to "be better than the others." If there is little growth opportunity in this skill area, it will have a much greater effect on performance as internal politics take over.

Clearly defined hierarchies are underrated, at least in this space. I really do not want to have seven bosses, or to be responsible for being part of some amorphous Valve-like leadership blob.

Setting up a clear chain of command, and, most essentially, following it, would perhaps stifle a few, but it works, and it works well, and it is a considerably less anxious and stress-inducing arrangement for everyone involved.

> where everyone can be a leader - and everyone would act as an owner

I suspect these are different things.

Everybody can have a sense of ownership? Sure (e.g. common goals, employee owned companies, options, etc).

If everybody is leading (at the same time), nobody is. It's good if anyone can assume leadership at any given moment, though.

Tacit leaders are more important (and respected) than explicit ones. Appointing a leader rarely works.

I am being in such a team and I tell you this is great. We are pretty flat, you can pick whatever title you want on your resume but here we are all engineers. My manager insists that he usually cannot make better decisions than we do, because we usually understand the problems better than him. His major request is that if anything gets stuck we need to raise it immediately so that it can be solved quicker and doesn't block others.

I've switched to saying "I'd vote for XYZ".

The most empowering form of leadership is pure democracy. I'm a bit dismayed that for all of our brilliant insights and expertise, we're so quick to replicate authoritarian power structures in our careers. There are some talks by Richard Wolff on YouTube about democracy in the workplace and I'd urge everyone here to watch them.

Any management strategy that is based on the assumption that everyone is the same and wants the same things and can act the same way is doomed to fail. I didn't see a single sentence about this person listening to and adapting to his team members as individual people. Some people might mumble the words, but aren't really interested in being leaders at all.

> Initially, my team was a team of eight engineers, from juniors to more senior members. Two years later, I have a team of triple the size, where most people have led a significant project, with mentorship/coaching support from a more experienced leader.

Huh. Two years. TBH that is not long enough to understand the sustainability of this approach. It's frustrating that people shout from the rooftops after one success like this.

There is some good advice in this post, but its hubris is galling. I would encourage the author of this post to continue growing and learning, maybe go through a failure or two, before speaking up.

Everyone is a leader implies a more flat organization, this isn’t that. This is just talking about effectively delegating and having layers of organization within a team. Ie manager splits up the projects to project teams and a project leader and the leader with the team gets autonomy to run the project their own way with mentoring.

I think it’s a good approach and for me at least orders of magnitude better than top down micromanagement. But the title I think just confuses things.

Imagine that instead of “leaders” the smaller projects were their own teams and replace the leader with manager title and it’d be the same thing.

EDIT: btw I see the lack of clarity around accountability play out at organizations. Where for instance on practice responsibility is split. Maybe the “leaders” set the direction and the team executed. But when it comes to accountability, like when something goes wrong, fingers get pointed to only the team or only the leaders without examining which piece (direction vs execution) failed.

Reading this article I was reminded of the book It's Your Ship, the motto used by one navy captain to empower the crew to turn around a poorly performing ship. Then I see that part of the inspiration for this post was... a book about a different navy ship.

I often think back to It's Your Ship, I'd highly recommend it.

Dee Hock, the founding CEO of Visa, described a similar approach as chaordic leadership.

http://www.griequity.com/resources/integraltech/GRIBusinessM...

It's better for everyone to be a leader than for the company to select the wrong leaders. But if the company is capable of picking leaders well, then that's better. But it's much harder than it looks and most companies get it completely wrong.

I wonder how this works for large scale engineering architectures and unified approaches. Seems like it'd lead to a lot of disjointed projects and pieces each with a different approach. That in turn adds cognitive overhead to an organization and lowers the bus factor.

The replies here are so telling, many would not survive on such a team. However, their perspective is critical to understanding who you must exclude to make this system work, and the kind of passion required for people to feel the sense of ownership needed.

Isn't this the same as DRI (Directly responsible individual ) at Apple?

this is a repost from less than 3 months ago. sorry i don’t have the url.

and sorry, but if you don’t have accountability you aren’t a leader.