This insight arrived on me recently too, and it is the “parallelism vs gestalt” blog post I started kicked at the other day. Projects are teams are projects, until a certain level of design maturity and management maturity is reached.
---
RT @isntitvacant
I'm beginning to believe that it's impossible –or at least, very difficult– to add people to a team before they have the nubbin of a simple, working proof of concept.

For a large-sc…
twitter.com/isntitvacant/statu

It’s a bit more than the mythical man month problem, which says that adding people to a late software project makes it later, because of communication overhead. When you add people to a project still in bringup phases, you add new entire dimensions of comms overhead.

When the design is in flux in somebody’s head, or in the collective heads of a handful of people who’ve been tightly aligned for a while, newcomers are a huge distraction.

Teams are (as you know, Bob) immutable. New people —> new team. Lose somebody? New team.

The upheaval in communication patterns that follows kinda has to have good management in place to guide it. But adding huge comms overhead during design phases is costly.

Follow

The shape the project team needs to be might not be clear yet: what kind of team is needed to do it? what kinds of people? glue, comms, work horse, systems thinker… who knows?

Sign in to participate in the conversation
Life raft.

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!