(n) toxicity (the degree to which something is poisonous)

Management of an organisation that is quite obviously based around products but chooses to see everything as projects creates a mismatch between how an organisation is run and what they try to accomplish. The structure in use to enable the accomplishment of work defines the foundation which future work is built on.

You would not, I hope, build a sprawling villa on ground that does not carry, lest you do not seek to repeat a classic scene from Monty Python and the Holy Grail:

“When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built it all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that’s what you’re going to get, Lad, the strongest castle in all of England.”

There are several lessons to be extracted from that quote about trying and failing, iterating, feedback loops, starting over, et cetera. Our focus is on the obvious one; do not build on unstable foundation.

A project by definition is something that should be accomplished with a fixed amount of resources within a fixed timeframe. When the goals are achieved the project is dee-oh-en-ee:  done.

Ergo projects have limited lifespans, which is something products do not. A product strives to live as long as it can. If it cannot pay for its own way in terms of further development and operational costs it is proven to not have a place in the market in its current form.

A few trends that emerge every time I work with an organisation that has structured themselves around projects can be summarised by this little tale about a man collecting sticks.

At first he can collect sticks he finds in one hand. Then, under his arm, and following that he lashes sticks together in bundles and carries them on his back, leaving his hand once again free to pick up sticks and the cycle can repeat itself.

If the man continues without any success/fail criterias he would never build his fire, never cook his meal and never reap the benefits of his work. He would keep collecting stick after stick and carry them until his back breaks from the load. Naturally a man has psychological and physiological inhibitors that would cause him to stop long before his back breaks, but an organisation does not have these self-regulating functions and can quite easily pave the way to its own demise as a result.

Structuring work around products instead of projects grants us these inhibitors, purely through a different approach in building the model applied throughout.

As you can see neither man nor organisation can in practice get rid of projects, and they probably should not attempt to do so either.

Think about how the two organisations approach projects. The former uses projects to manage everything, and even though a couple of projects are going well; on time and on budget, several are not going so well for various reasons and overall the organisation suffers. Their projects that aren’t going so well contain key functionality that other projects are constrained by which eliminates the choice of shutting down some of the bad projects. So more money is pumped into the failing projects, more people is added to the teams, and miraculously; something gets delivered — not as intended, not as designed, and not as planned.

By the grace of a dedicated and hard-working team that burns itself to cinder, tirelessly and ruthlessly cutting corners and Getting It Done … A cycle that many good developers have burned themselves out on, preventing them from doing good work for long stretches of time.

The second organisation is a little bit different. It has the same amount of projects that are not going according to schedule and the product these projects are run under cannot sustain itself when it’s being dragged down by these projects. This product is dying, and it can be strategic to let it die, which we will get into in a bit.

On a project-level the reasons the projects are failing are the same as for the first organisation. The difference is how the inhibitors work so it doesn’t damage the entire organisation and all other projects making better, or worse, progress. Right now, there is a choice between a new beginning and an end. We know that the product in trouble is not sustaining its own development and operational costs. We may not know why, we may have a clue, or a hunch. We might have data that tells us the market fit isn’t right, data that tells us users are not using it as intended, we might have a lot of things, but we know it is not self-supporting.

Prepare the pivot.

Or the axe.

I am not saying that amputating a product is a pain-free procedure but much like amputating a gangrenous limb it might very well save the patient. A project that is believed so necessary for the organisation that there exists no possibility to cancel it, is a project with a high amount of inherent toxicity. The project is very poisonous and there exists no known anti-venom. It will linger. It will spread to other projects no matter how well isolated they seem to be. The edges become fringed and productivity drops. Technical debt amasses, workarounds are implemented and this festering thing causes project after project to slide without no seemingly good reason. The developers get blamed for lower effectivity now versus a year before. Nothing else has changed — it has to be demotivated employees. Cogs are exchanged, moved around, shuffled like a deck of cards in hopes of a change in the daily grind will yield a boost in morale.

But the beast has taken hold.

Once an organisation has been dragged down far enough the stakeholders demand action. Someone is fired. A new face takes the reigns and tries to ride the beast. The beast claims another victim. This cycle repeats itself until the replacement has mandate to restructure the organisation in his image. The beast has finally spawned an offspring in his image, further spreading poison up the chain, the project with the ultimate level of toxicity: the project every CEO in a sick organisation undertakes in an attempt to impress stakeholders with bravado.

…

Cue the drum-roll.

…

The organisational restructure.

/v.