The self-organizing team’s guide to micromanagers

This is part 2 of 2. Part 1 was an attempt to help micromanagers understand the value of self-organizing teams. Now we’ll take a look at how a self-organizing team can work with a micromanager.

Those “Agile” people are always telling teams how they should run things, as if they knew better. Don’t be a passive order-taker. Become an integral part of the value stream. Work as a partner with business stakeholders. Understand the problems to be solved, rather than just implementing whatever is requested. Then the magic will happen.

That advice can be pretty counter-intuitive for a team embedded deep in the bowels of a traditional organization. I wonder if the problem is the way those “Agile” people talk. They describe everything in glowing terms, all covered in sugar. Haven’t they ever been in the Real World? Let me see if I can describe the same thing without the sugar coating. Maybe that will help.

Anecdote

This is a story that pre-dates the Agile movement by a long stretch. There will be references to technologies the current generation of developers has never seen. Don’t worry about that. The same scene still plays out today, everywhere and always.

In the 1980s, I was part of a team that supported a large and complicated CICS application. This wasn’t a run-of-the-mill CICS application. It was a transaction processing application that “owned” three mainframe systems in three geographically-distributed locales.

It was conceptually analogous to contemporary microservices-based solutions in that operating system instances came and went while the application as a whole was operational 100% of the time. The technologies were different, but many of the challenges were the same: managing transaction integrity, data integrity, logging, performance and so forth across multiple distributed components while presenting customers with seamless, uninterrupted service; and the ability to deploy different components independently of one another in the middle of the day without an outage. Nothing new under the sun, I guess.

I like telling stories like that, because I enjoy reminding you young whippersnappers (you know, like under 45) that you didn’t invent everything in the universe last week.

Anyway, this story isn’t about the technology, it’s about the team’s response to a micromanagement request one fine day. It’s a story that still happens today. A lot. It probably happened to you yesterday. If not, it wil probably happen to you today.

Our manager came to me one day and said, “I want you to put the entire master file into a temp storage queue.”

I looked at her without smiling, and nodded. After a thoughtful pause, I asked, “Are you sure that’s what you want? What problem are you trying to solve, really?”

She hesitated, and explained, “Well, I’m looking for a performance boost. Eliminate some I/O.”

“Okay. That sounds like a good goal. Why temp storage?”

“I read that temp storage allows you to keep data in memory under CICS.”

“True. But note the name: temp. It isn’t meant to keep entire master files in memory and hammer them with updates all day.”

“But you can still load them up, right?”

“Sure. You can tell CICS you want such-and-such a queue to be in memory, or on disk. But here’s the deal: If you put too much data in the queue, CICS will automatically change it into an on-disk queue. Then you have much, much heavier I/O overhead than you would have with normal VSAM access. You’d achieve the opposite of improved I/O performance.”

“Oh. Let’s not do that, then. What are our options?”

“Well, CICS has another feature we could use. We can back up a VSAM KSDS in memory. IBM calls it a ‘Shared Data Table.’ It’s a cache mechanism. Recently-referenced records will remain in the cache. Other records can age out, so we can optimize the size of it. CICS will keep the cache and the actual file sychronized without impacting transaction performance.”

“Will it take long to do?”

“Nah. It’s just a configuration setting. No change to source code.”

“Okay. Do that, then.”

If you remember part 1 of this two-part piece, then you may recall the story about the soldiers who placed bets on how many quarter-turns of the wrench it would take to snap off a stud. We could have done the same thing in this case. We could have defined an in-memory temp storage queue and loaded it with the contents of the master file. It is technically possible to do that. Stupid as hell, but technically possible. Then we could have placed bets on how long it would take for the manager’s head to explode.

It seems those “Agile” people are right about the value of teams participating actively in the whole process. When we behave like passive order-takers, stupid things happen. So, when your manager tries to micromanage technical decisions, engage them in a discussion. Find out what problem they’re really trying to solve. Then you can use your technical expertise to explore viable solution options. Otherwise you’ll end up with broken studs.