The Micromanager’s Guide to Self-Organizing Teams
This is part 1 of 2. Part 2 will help self-organizing teams work with micromanagers. Well, it’ll try.
Those “Agile” people are always telling managers how they should run things, as if they knew better. Allow people to form self-organizing teams, let them take ownership of their work, give them a prioritized list of objectives and the resources they need to get the work done, and get out of their way. Then the magic will happen.
That advice can be pretty counter-intuitive for a traditionally-minded manager. I wonder if the problem is the way those “Agile” people talk. They describe everything in glowing terms, all covered in sugar. Let me see if I can describe the same thing without the sugar coating. Maybe that will help.
Anecdote 1
Years ago, I was on a team that supported a large application. One day, a senior manager breezed through. On seeing a list of the “screens” in the application, he remarked, “There are too many screens and programs. Don’t add any more screens or programs. Keep the design simple.” Then he headed out to the golf course. New functional requirements continued to arrive on a daily basis.
When he next visited our office, he noticed some screens he hadn’t seen before.
“I told you people not to add any more programs!” he huffed.
My colleague explained, “This isn’t a new program, boss. I just enhanced an existing program.”
“I told you people not to add any more screens!” he puffed.
“There’s only one screen here, boss.”
“But I can see the screens changing!”
“Not at all, boss. It’s the same screen as before, but now it’s a cube. The program is just rotating the cube.”
So, my colleague could honestly assert he had not broken the boss’ rule about adding new programs and screens. That single program now had logic jammed into it for six distinct sets of functions.
Question: How many principles of software design does that violate?
Bonus question: What’s the effect on total cost of ownership over the application’s lifetime of organizing the code in that way?
Bonus bonus question: Whose fault was it?
You: But Dave! Those “Agile” people said it wasn’t about assigning blame!
Me: I told you I was going to scrape off the sugar coating.
Anecdote 2
A former colleague who had served in the Army before learning software development told us a tale from his time in the service. He worked in vehicle maintenance. The instructions for maintaining a certain type of vehicle included, “Tighten each lug nut one-quarter turn clockwise.”
He and his comrades dutifully fulfilled the letter of the law. They placed side bets among themselves on how many maintenance cycles it would take for a stud to snap off. When it happened, they laughed.
Question: How many principles of common sense does that violate?
Bonus question: How much unnecessary waste of taxpayer money did it cause? (Remember to multiply by the number of vehicles and maintenance teams.)
Bonus bonus question: (Well, you know.)
The moral of the story
If you’re a manager of professionals or of skilled workers, pick one:
- Hire people you trust to function as professionals, and then step out of their way so that they can do so; or
- If you want to tell people exactly what to do, make very sure you understand exactly what you’re telling them to do.
The choice is yours. Just remember that when you choose your management style, you’re also choosing the outcomes for which you will be rewarded and remembered.
Technical folks reading this are probably smiling. Smile while the smiling’s good. Part 2 is coming.