Years ago, I asked my dad to review a piece of promotional copy I was hoping to use to sell my company’s services. He flagged a sentence that presented what I thought was a compelling benefit. It began, “You will learn to …”
“Don’t ever use “learn” if your goal is to attract customers,” he told me. “’Learn’” means you’ll make them work.” Nobody wants you to make them work.”
“What should I use instead?”
“’Discover’! ‘Discover sounds interesting and enjoyable.”
I’ve been publishing Keep the Joint Running and its predecessors once every week since the ball dropped in Times Square signaling the beginning of 1996. In that time I’ve … discovered … a few insights into How Things Work I’ve shared with the KJR community.
I discovered that process optimization is both simpler, more difficult, and harder than it usually gets credit for. It’s simpler because few processes are so complicated that they can’t be cleaned up through a Theory of Constraints loop – find a bottleneck, fix the bottleneck, find the next bottleneck, rinse and repeat.
It’s more complicated because while most process diagrams look like box-to-box-to-box flows of work, they’re really queue-to-queue-to-queue flows.
It’s harder because processes fail if all of those responsible for process steps don’t trust each other. If they don’t the result is massive amounts of rework.
I discovered that leadership is hard. Not hard the way neurosurgery is hard. Hard the way digging a ditch is hard. When I’ve led leadership seminars, after explaining the eight tasks of leadership the question that stymied participants the most has been finding the time to undertake even a few of them.
I discovered that, Adam Smith notwithstanding, money is a lousy motivator. Used well, though, it’s a highly effective communication channel.
Tell employees you value something they did and you’ll be likely to get an eye roll in reply. Give them an Amazon gift certificate and explain that it’s your way of thanking them for going above and beyond and they’ll conclude your expression of appreciation is sincere.
Another discovery: IT focuses so much time and attention making sure its solutions will scale that we fail to notice when our solutions won’t scale down.
Project management is a fine example. The official disciplines truly will help your teams build skyscrapers and nuclear submarines. Use them to build a house for your dog and they’ll choke you in paperwork.
Helping those responsible for small projects scale their methodologies down is what I wrote Bare Bones Project Management for. Based on my correspondence at least, the world needs scaled down project management far more often than it needs the scaled-up version.
Something else I discovered: Things that are fun succeed. Those that require sweat and gruntwork are more uncertain.
In the PC’s early days they were fun. GUIs were prettier, but the early PCs, for which a broad assortment of hobbyist-grade customization tools were readily available, were more fun.
PCs succeeded. So did the world wide web. In its early days, putting together web pages was fun. Now? Fun isn’t part of the job description.
Except, perhaps, for some of Agile’s variants. As I dug into Agile … an approach anticipated in these pages two years before the Agile Manifesto was published … it was clear that the early versions of Agile tried to restore fun to application development.
It worked and worked well.
Then scaling happened, Agile became heavily proceduralized, and the fun is draining out.
Perhaps the most important KJR discovery was that, at the risk of looking like I’m trying to sell books, there’s no such thing as an IT project. I came by this insight honestly – by ridiculing Larry Ellison and his 2001 assertion that Oracle could deliver global CRM in ninety days.
Sure, it might be possible to install and maybe integrate Oracle’s CRM solution in 90 days. But managing customer relationships better? That would require everyone who touches a customer to change how they go about it. In 90 days? Not a chance.
What else have I discovered over the past 28 years? That in the end it’s always about the people – those pesky human beings who, as it turns out, have a greater impact on organizational success than all the process designs, technical and business architectures, and so-called “best practices” that seem to have dehumanizing the business as their central operating principle.
Over the next few weeks I’ll be turning over the reins to my friend and colleague Greg Mader. I’ll give him a more formal introduction as part of that process.
It’s been fun. And more than fun, it’s been a privilege.