Why Even Decentralized Teams Need Centralized Coordination

Even decentralized teams need centralized coordination. At least they do if they want to ship something users will use on a consistent basis.

I’m guessing this is an unpopular sentiment in crypto. Yet I do believe it. I’ve lived it through two Mainnet releases and counting.

PMs for Centralized Teams

The centralized software world realized the need for centralized coordination a while ago. That’s why project and product managers exist.

Still, PMs are not always welcome additions to even centralized teams. Often we’re seen as unnecessary overhead.

I’ve lived this reality for years, too. I’ve learned to accept it. It’s one reason I apply the lightest touch possible in the work I do. I also believe the lightest touch is the most effective one.

Centralized teams have existed long enough to experience the benefit of PMs. Many have learned by trial and error. Even Mozilla, the open source poster child, hires PMs.

PMs for Decentralized Teams

Decentralized teams are a recent manifestation. They’re often comprised of very talented, yet somewhat inexperienced, developers.

They are inexperienced from the perspective of working within larger teams, toward defined goals. Many don’t have experience working in more centralized environments.

As a result, many take a binary approach. Rather than see any decentralized development as an improvement over existing centralized structures, many view any centralization as something to be avoided at all costs.

Yet these teams also want to ship. They realize the tools are available to now build and ship software that can have a positive impact on the world, to an extent never before possible. Many of them now have investors and communities of supporters counting on them to ship.

Teams have written papers and sometimes have developed prototypes. Now what?

Now they start building toward a loosely defined set of ideas. An early product release or prototype may or may not happen in the first few months. This is where decentralized development models start breaking down.

The next 6, 9 or 12 months keep rolling along. Because these teams aren’t in danger of running out of funding, there’s a good chance they don’t notice the passing of time. Attending all the exciting and feel-good crypto events makes it easy to miss the passing of time too.

The teams may start to experience frustration though. They may feel like their wheels are spinning, that they should be farther along by now and the return on their effort is very low.

Their community may start growing impatient or losing interest. The next shiny new crypto thing is always right around the corner to capture their attention.

Many times the team will work harder. Without some degree of centralized coordination though, increased effort only amplifies the frustration. The level of effort increases, yet produces ever diminishing returns.

PMs as Coordinators and Guides

These are the reasons even decentralized teams need some degree of centralized coordination. Centralized coordination synchronizes a team by moving it toward a common goal.

It also increases efficiency. Done well, this coordination provides the fuel to ignite a project and propel it toward agreed-to milestones.

The right PM providing coordination acts as a guide. I view the role as channeling the team’s energy and effort into a unified direction.

Sure, that direction may ebb, flow and adjust. Yet it’s flowing together in the same direction. Individual efforts get amplified. The team moves together toward a synchronized horizon of outcomes.

This is what’s necessary for builders to ship on a consistent basis. It’s shipping that will unleash the power of what’s being built into the world. It’s only once this power’s released into the world that it can begin decentralizing the current centralized power structure.

And isn’t that what we’re #BUIDL'ing toward anyway?

P.S. - This was first published in my Blockchain PM newsletter here. Subscribe to free to receive posts like this and PM jobs listings about once a week.