Right Diagnosis. Wrong Prescription.
Or, good tools gone bad. Film at eleven.
Another entry in my irregular series on process management. Smart people acting in good faith can get it wrong. So imagine the capacity for cynical manipulation. Well, you probably don’t need to imagine.
It is possible to correctly identify and describe an issue, and then propose an entirely ineffective solution — or even one that makes the problem worse. I’ve seen this happen innumerable times. I’ve done it myself even more than that.
Sometimes this happens simply because we’ve inadvertently identified a symptom rather than a root cause. This can often be really hard to spot in the moment, but treating a symptom rarely actually solves a problem.
Other times, though, even when we’ve correctly identified the underlying problem, the correct solution is for some reason outside our wherewithal (time, resources, budget, whatever), so half-measures or symptom-abatement are the best we can do.
But sometimes…sometimes it’s because the solution being proposed is expedient for whomever is proposing it, for entirely unrelated — and maybe deeply cynical — reasons. It’s possible to prescribe the “solution” you want, and then retroactively invent the problem.
A Wrench In the Works
Over the years, I’ve engaged with a lot of training for both project management and team management. I love it! As I’ve said, I’m kind of a management geek.
Early in my management career I was exposed to a great deal of training in “waterfall” project and process management. I could build a Gantt chart to schedule anything. Later, I had extensive “Agile” training in several different flavors. Waterfall made a surprise comeback briefly in the late 2010’s.
I’m generally pretty agnostic about these things. They’re all just tools. But regardless of specifics, I’ve always been fascinated by how we can misuse them, or fail to understand how they’re supposed to be used at all.
Look, if you have a nut that you are trying to tighten onto a bolt, and you grab a hammer and start hitting it, it’s probably not going to work very well. Was a hammer the only tool you had? Did you mistake the nut for a nail? Or was looking busy and making noise more important than actually getting the job done?
At the same time, if you grab a wrench and then start hitting the nut like you did with the hammer you’ll have the same result. Right tool this time, but wrong use! You have to apply the right tool to the right problem, and you have to actually utilize the tool correctly.
If, that is, you’re trying to solve the problem you say you are.
I once participated in a multi-day offsite Agile training seminar that involved all of the senior management of a large project I was working on.
The exec who sponsored it was passionate that it was important — this was a critical project, the big bosses were hot on Agile, and this was our opportunity to really show we were on board.
The lead presenter at the seminar especially emphasized one particular point. They said, “If you take only one thing with you after this seminar, if I can impart only one useful thing, let it be this: this system only works if you take all of it. Often people learn these techniques and then cherry pick them. And then they are surprised when at best all they’ve really done is put a coat of paint on their existing processes, or at worst have added onerous and inefficient overhead to their work. Don’t do that! Better to not adopt the system at all than to try and just take bits and pieces.”
Come Monday, and we’re having our leads meeting. The sponsor of the training kicks off the meeting saying something like, “well, that seminar last week was intense, huh? What did everyone think?” Grumble, grumble, grumble from the group, until one team member speaks up: “I mean, fine, I guess, but most of it seemed like consultant mumbo jumbo. Don’t really see how a lot of it applies to us.”
And the response to that, which I’m sure will not surprise you, dear reader (though I admit I actually was surprised in the moment), was, “Oh, yeah, for sure. A lot of it isn’t really useful for us. But there were some key things in there that I think we should pluck out and use to improve our existing processes.”
Suffice it to say…as the moderator predicted, it didn’t really work.
Now, I don’t want this to come off like I think I’m some kind of smart guy surrounded by fools or something. These were really capable people interested in doing the right thing. And the key is: they were right. This really wasn’t a good approach for us!
It just seemed like executive leadership had correctly diagnosed that something was wrong in our practice…and then had prescribed precisely the wrong treatment for it. Why?
As hard as I tried to fight my own cynicism, I found it tougher and tougher to believe that the reasons the Giant Floating Heads wanted to move away from waterfall and toward Agile was anything but this: waterfall scheduling kept giving them answers they didn’t like, and Agile promised to give them answers they preferred.
Mind you, I didn’t believe that they thought Agile methodologies would give them better answers — more visibility into process, improved business intelligence about projects, etc. — no.
It just seemed like a report saying, “we’ve post-mortemed the sprint, groomed the backlog, and are scrumming the kanban” would be a lot more pleasing to the ear than, “we’re way behind schedule.”
The latter, of course, is actually useful information, and waterfall methodologies were producing it easily (albeit with alarming frequency). The former is…well, Agile methods have uniquely goofy jargon, but as a rubric, they are super useful for certain kinds of development. Just not the kind we were doing.
Nope, good old traditional waterfall was superior in surfacing issues around resourcing, dependencies, and calendar time for a project with a predetermined feature set and a predetermined (immoveable) end date. But the transition to Agile was pushed, nonetheless.
It fixed the “problem” of negative schedule reports, but not the problem that the team was behind schedule. In fact, it may have made it worse: grooming a perpetually growing “backlog” sucks up a lot of management time.
It’s possible the whole thing was an honest, good faith, misjudgment. Anything is possible.
RTW
I’ve been thinking a lot about this diagnosis/prescription issue lately as more and more companies institute draconian “return to work” policies in the wake of the pandemic-driven “remote work” phenomenon.
Putatively, this has been for the sake of “productivity.” I have not seen a lot of evidence that it is in response to any actual drop in productivity (or even slower growth of productivity). But since that’s the way it’s often justified, let’s give the companies the benefit of the doubt.
Maybe the people-managers on the ground are having a hard time getting visibility into their teams. They’re afraid that is hiding a drop in productivity. Or maybe the lack of visibility is hindering their traditional methods of measuring productivity and it’s making them nervous.
They felt better when they could see everyone productively beavering away in their cubicles. And they’re finding themselves ineffective in this new environment.
But what if the lack of visibility is a symptom not of a permissive “work from home” policy, but of ineffective managers? The company can treat the symptom by having everyone back in the office, but dollars to doughnuts it’s not actually going to solve the problem (the ineffective managers).
That is, even if there truly is an issue with productivity, this may very well not be an effective prescription to solve it.
Adam Grant always puts it best:
Only time will tell, of course, if returning everyone to the old ways of working was really the right prescription. For sure it’s one way — not the only way, and I doubt the best way, but one way — to address a lack of visibility for managers. But does it address productivity?
And is there even a problem to be addressed there, anyway? Or is it another case of a solution expedient for those proposing it? I have my suspicions.