The Flawed Project-as-a-Ship Analogy
It is common for a project leader to see his or herself as the captain of a ship. The project is seen as the ship, and the developers are the crew. When storms hit- the project is behind schedule, over-budget, below quality, falling short of projections and expectations- the captain doubles down and starts to behave more captain-like to stabilize the ship.
There are many bad practices software development captains use to navigate stormy seas. Perhaps the worst of them is to silence dissent and remove “poor performers.” The idea is that by silencing dissenters and removing poor performers, you create smoother sailing for the ship overall, to help ride out the storm.
Unfortunately the ‘project as ship’ analogy is fundamentally flawed. The project is not the ship. The people are the ship. When you remove dissenters, you are ripping out vital structures. You are destroying your sails and your rudders. When you remove “poor performers”, you are throwing out vital reserves that you should instead be better utilizing. You are ripping holes in your hull. When you ‘cut back’ on investing in your people, you are foregoing essential maintenance and leaving your ship in disrepair. The project itself- the artifacts people create- has no place in the ship analogy. The project is a result of an equation of people, not a factor in it.
Focusing on stabilizing the project in times of trouble, rather than growing and nurturing the people that create it, doesn’t make for smoother sailing. It makes for a sinking ship.
Don’t like it either. That one always makes me think of Captain Bligh, or Ahab, and we all know how their projects ended. Maybe it’s better to think of it as in ‘Nam. Smoke, confusion, gunfire, panic and pain, but we’re gonna pull through it and leave no-one behind.
But then again, why think along the lines of analogies at all? No project is the same. And no analogy will ever be applicable in exactly the same manner, except maybe if you’re really sailing a ship through a storm. By thinking of analogies you focus on the problems of the analogy, rather than the ones of the real project because the analogy simplifies – it makes it easy for you. Ship. Storm. Men. Easy. But that’s not your project. That’s the analogy. Your project is most likely different, it has different issues, different people, different scope, different complexity and different depth, beyond that of a ship in a storm. So best forget about it and deal with what’s happening in the real world instead!
[…] as problems get worse. I’ve written about the importance of the malcontents on this blog before, and as a manager it’s always been a yardstick. If malcontents and metathinkers are leaving, […]