You know there’s a war on
In the midst of the Second World War, General Groves got the inspiration that he might encourage these pointy-headed geenyuses out in the desert by sending them a management engineer. We know them these days as scrum lords.
This poor fellow actually believed he could apply Scientific Management (Taylorism) to a ground-breaking (literally) effort to create the first atomic weapon.
Oppenheimer supposedly greeted the expert with all support and respect. He gave him free rein on the grounds, so long as he was accompanied by a nice soldier who would keep him from very classified areas. Unfortunately for this fellow, he chose to interview the theoretical mathematician first.
Chances are this was Dr. Stanislaw Ulam, one of the world’s foremost theoretical mathematicians. The guess is made based on his work later mentioned here.
Managers cannot imagine that any group could know when they’re doing well and when they’re not without someone with much less knowledge, experience, skill, and training telling them so.
So the efficiency expert met Dr. Ulam and asked his fateful questions: “What are your tasks, duties, and elements?”
“Vas?” replied Dr. Ulam.
“What is it that you do here,” the scrum lord asked in human terms.
“I’m so happy you asked,” Dr. Ulam gushed. “I’m attempting to prove that Locally Compact Sets are not dense in themselves in Hilbert Space.”
Gobsmacked by the answer, the efficiency expert rushed off to his books. They told him, “if the subject cannot adequately describe what he does, watch him.” So the management engineer did just that. Dr. Ulam drank coffee, looked in books, and wrote on a blackboard. These things were insufficient for the expert so he took the next step as his book directed: he went to talk to his immediate supervisor.
As you might expect from a largely egalitarian collection of the world’s smartest people, Dr. Ulam’s direct supervisor was Oppie. With hopes of finally uncovering his first nugget of managerial gold, the expert asked Oppie, “So what does this man do?”
“I have no idea,” said Oppie. “If I knew what he did I wouldn’t need him here, now would I?”
“How do you know,” inquired the time and materials guru, “when he’s doing a good job?”
“He tells me. He’s the only person in the country who can understand these theorems. If he says he’s doing it right, he’s doing it right. That’s why we have him doing it.”
Mosel, J. W., Group Relationships and Participative Management, a talk delivered at the Industrial College of the Armed Forces, September 26, 1967
We’re still fighting
Eighty years later we’re still fighting on the Taylorist Battleground. Managers cannot imagine that any group could know when they’re doing well and when they’re not without someone with much less knowledge, experience, skill, and training telling them so.
Yet, here we are. We’re programmers and developers and architects and all manner of allied technical professions and we do just fine without managerial interference. In fact, we do much better without it. Corporations refuse to believe it. Managers refuse to concede.
In small start-ups, programmers craft amazing new solutions on both a shoestring (and here’s the rub) without managerial oversight! Can you believe it? What’s the difference between small groups and larger groups? Size. Size and trust. Size and trust and fetters with the title, “manager.”
People who prey on managers have convinced them that the road to acceptance is paved with liberal usage of the word “agile.” If we call our new management shackles “Agile Doom” the programmers will beg their manager to use it. And so it goes.
Programmers have seen it. Vice presidents in charge of something very important have seen it. Sometimes, even observant managers have seen it. Adding managers to software development mars the effort, the quality, and the group morale.
Managers accept failure, corporately, rather than accepting that the group that knows best about technical performance is the technical group. Managers would prefer to interfere rather than accept that managers are an interference.
The battle rages. Programmers win on merit. And then managers usurp it back during the next golf game with the vice president of something very important.
Hint: programmers should take up golf.
And this is what we’re fighting
The pathway to solution development success seems to lead around managers. Managers, unfortunately, have been tricked into believing that complicated and formulaic management frameworks are how the modern solution development process is managed. This is false.
People who prey on managers have convinced them that the road to acceptance is paved with liberal usage of the word “agile.” If we call our new management shackles “Agile Doom” the programmers will beg their manager to use it. And so it goes.
Software developers never list speed of delivery as their priority. Experienced and skilled software developers rigorously pursue delivering the right solution, done the right way. Put that in your framework and graph it.
The truth is that complicated and formulaic management frameworks are how the modern solution development process can be turned back 150 years into industrial-age scientific management. I hope that’s what they wanted. That’s what they got.
Claims and counterclaims about management frameworks, tools, and ceremonies pepper the by-ways and alley-ways of the popular software management frameworks: “but our framework has been shown to deliver projects X% faster than the leading brand.“
Wanting to deliver projects faster is not a bad thing (even if the claims were true), but it is the wrong thing. The best thing would empower and liberate the software development group to produce the best software with the fewest defects and the greatest customer satisfaction. Frameworks do the opposite.
How will we know when the customer is happy? They’ll tell us.
Frameworks hijack control from the software developer and deliver it to the manager by reducing everyone to the lowest common denominator within the entire group. I’m sure this comforts management who cannot tell a good developer from a bad one (except by speed, but it’s not how the world works, and it’s not how software development groups operate). Good software is built through the knowledge and leadership of the most senior and skilled members of the software development group, not by the Procrustean Bed.
No one is an expert in everything. The ideal software development group has experts in many fields; some in design, some in security, some in services, and some in one language or another. The aggregate makes the group, and the most skilled in each area leads that area when the time comes.
Contrary to the egalitarian myth, only the very best technical contributors have any positive effect on code or solutions. And only when the majority of software developers have great seniority can anyone expect success; rather than have it drowned out by pressure to commit shortcuts, coming from time boxing, continuous estimation, and micromanagement hidden in countless ceremonies.
The claims and arguments pepper the by-ways and alley-ways of the popular software management frameworks: “but our framework has been shown to deliver projects X% faster than the leading brand.“
This is not a bad thing, but it is the wrong thing.
Software developers never list speed of delivery as their priority. Experienced and skilled software developers rigorously pursue delivering the right solution, done the right way. Put that in your framework and graph it.
This requires a completely fresh perspective of how software development groups succeed.
It actually demands a restructuring of the control hierarchy in a software development environment. This is dangerous territory, though. The very thought of it violates the manager’s creed: “Nothing is possible unless a manager controls it.”
I would like to repudiate the notion that absent managers (once absent) need replacement. Indeed, would you replace the boil on your nose with something else after the doctor lanced it?
No manager; no management framework; no tool has ever been shown to be the primary criterion for software outcome success. Contrary to all frameworks, processes, ceremonies, or certifications, successful software development correlates, proportionally, to the number and degree of experienced and skilled software developers in the group.
Period.
Behold, I am become autonomous, the destroyer of managerial jobs
Managers are, at best, an annoyance; at worst, an impediment to developing software solutions. Very experienced and skilled developers are the single best indicator of the probability of software development success. The greater the number of senior, skilled, and experienced software developers in the group, the better their chances for success. The more managers (scrum lords, coaches, managers, or albatrosses), the greater the probability of failure.
I’ve met one (1, uno, en, jeden, ett) manager who was the exception. My experience spans many decades. Except for her, all the rest just ranged the spectrum of horrible to insidious. There seems, then, the possibility, however unlikely that your manager is among the good.
Given those two, simple observations, what right, immediate, and obvious response should every software development customer demand? To hire more senior, skilled, and experienced developers and reduce the number of managers (scrum lords, coaches, managers, or albatrosses).
You get extra credit if you used the words, Promtly, Forthwith, PDQ, Directly, or ASAP.
But if we shed the managers, with whom do we replace them?
I would like to repudiate the notion that absent managers (once absent) need replacement. Indeed, would you replace the boil on your nose with something else after the doctor lanced it?
Why not give your senior, experienced, and skilled software developers autonomy and liberty? Ask them what they need. Ask them what they can deliver. (You may ask them when they can deliver it and if they’re smart, they’ll give you a Huckleberry Finn Furball answer.)
If any of them say something like, “we need a fixer, a helper; someone interposed between us and upper management – who can get us the things we need and keep the things we don’t need away from us,” then I might suggest a new banner for the former scrum lord, coach, manager, or albatross.
Don’t think of it as a demotion. Think of it as the universe offering you a place, rather than pushing you into the abyss.