Imagine an architect designing an electronic circuit. It’s wonderful. Circuits like tree-lined avenues, transistors like refreshing fountains, capacitors like shopping centres full of sparkling goodies, resistors like safe tunnels and inductors like energizing attraction parks.
Or maybe it’s better if we have electronic engineers design circuits, not architects.
Why do train-wreck managers design the organizations meant to build software?
Who is a train-wreck manager?
They are easy to spot because they are almost everywhere. Their way to put things in motion and get results is old, as old as the 19th century.
To design a park is the architect’s job, but imagine having kick-me-hard managers do it.
Their parks are full of obstacles and it’s very hard to get to the other side of them. Why the obstacles? Why to make things harder? Isn’t it hard enough as it is?
Some parks they put together would be impassable, like Lewis Carroll’s Alice when she grew so big that she couldn’t pass through the door.
What they do is simple.
They take a task, maybe a very complex one, and chop it into pieces. They assign each piece to a person. When there are problems, they find the culprit and make sure that she feels very badly about her misdeed.
The two pillars of shoot-the-culprit management
They are pillars, they are carved in stone. Don’t you dare questioning them.
You shall believe that you can always break a complex task into small ones and assign them to individual workers who will be responsible for them. If everyone does his or her task well, the final result is guaranteed.
You shall believe that kicking the sinner hard will always improve results and that you don’t need to do anything more or different.
Unicorns leave tracks
We are trying to find a unicorn here, the way out to success for our software projects.
Unicorns leave tracks, like bears, horses and many other animals.
The first track is that people can think, and have to, when they try to solve the complex problems software development poses.
The second track is that creative endeavours like writing code need motivation.
The third is that communication is everything.
Can really people think? Do they have to?
Yes, we can think.
Schools are make-me-an-idiot management applied to learning. At school you are never allowed to ask yourself the question of questions.
“Why am I doing what I am doing?”
I’m pretty sure that it’s the very definition of intelligence.
But schools and give-the-misdoer-the-boot management want people obedient. You do what you are told. You don’t ask yourself that question. You don’t think, you just do.
I believe that it’s possible, not always but sometimes, to revert the damage schools inflict on us and restart thinking.
When writing software, to think is very important because there are complex problems to solve. Most of the times it’s not obvious what you need to do next, nobody knows, you have to figure it out, you need to think.
Motivation and why it matters
Motivation is the fuel that propels every creative activity, software development being one.
It’s when you talk with a developer and she turns on like a Christmas tree talking about the wonderful problems she solved. You see radiance glow on her face.
Make-me-stupid management is very effective at eclipsing that radiance.
Motivation flourishes in a cooperative environment where developers can choose how to deal with problems and decipher requirements.
Communication, the balsam that cools down the heat of misunderstandings
Communication is essential because clients (internal or external) never know what they want. Every person involved in the process of making software has a different point of view and all of them are needed. Projects succeed when people cooperate to merge these points of view into a coherent ensemble.
When members of the enlarged team involved in the project impose their point of view on others, expect disaster.
Where are you, my unicorn?
Or how scare-the-life-out-of-me management scrubs the unicorn’s tracks off making it impossible for our projects to find success.
Take developers who are not allowed to think.
There is a symbol for this. It’s a developer who beats a retreat to a hammock. She goes there to have some quiet time and think.
She can’t do it for long. It would draw the manager’s ire. Thinking is not productive. Banging on the keyboard at light speed is. A hammock is also risky. Managers can kick people more easily when they are there.
Motivation withers in toxic environments where people compete instead of cooperating.
If a developer is on the embers busy minimising the time he has to stay there, he doesn’t care about what his co-workers do, he doesn’t cooperate. Everyone around him is an obstacle to the maximization of his performance. His manager can’t wait to boot him if he doesn’t perform and will never stop to think that the assumption wanting global performance to be the sum of individual ones is badly wrong. His training made that assumption inviolable.
Managers are promoted because of their individual performance. They are heroes who rush to the rescue when disaster happens and everyone working with them strongly believes the illusion that good outcomes come from spectacular, personal acrobatics.
Motivation deflates when developers are micro-managed, have little choice, have no voice, are forced to allow managers intrude on everything they do, must participate to activities when they see no meaning in them, have to demean themselves by following practices that are on fashion but that they don’t need at all or are allowed to ask no questions.
Shut-up-and-do-it management is all about micromanagement and smothering the rebel who insists she wants some autonomy, it would be better for the project too.
How can the rebel expect to have her way when the manager himself knows there is a kick ready for him if he doesn’t succeed. How can the rebel pretend to make arbitrary choices that may bring doom to the project. The manager will make all choices for her and save the day once more.
“Better safe than sorry.”
You see it, you breathe it, you swallow it, you drink it, it’s everywhere.
It’s the shush-do-what-I-say manager’s motto.
Complex tasks must be split and silos must be built. Inside each silo there is a team member and managers must inspect and filter all communication so that wrong things don’t make it to the wrong person.
Sometimes distrust is just enshrined in contract clauses and there is little even managers can do. Most of the times it’s built-in in the environment.
Communication becomes hard or impossible and projects drown in a maelstrom of misunderstandings.
Do you have any hope of finding the unicorn?
You need to get rid of train-wreck management. Learn how Jack Skeels got rid of the managers he was assigned to form a team.
You can do the same.
Then you can start system thinking. You drop the old assumptions. The final result is not the same as the sum of the outcomes of individual tasks. It’s not people — each one doing their job properly — who make a project a success. It’s not any prima donna saving the day either.
It’s the system. The system brings projects to success or to doom.
It’s composed of people, processes, quality of communication, quality of environment, tools, expectations, agreements and relationships. Everything is interrelated and problems’ causes are hidden in the system. You have to perform a deep investigation.
Can you say this? “The system made this mistake, not John.”
Can you do it even if it really looks like it’s John who is letting the project down?
If you can’t, if you badly need to kick someone to feel in control, you may want to consider working in a different industry, one that doesn’t involve software or other thought-intensive tasks. If you continue your journey in the world of software development, you may be in for disappointment.
Photo by David Kovalenko on Unsplash