This All-Hands Meeting was obviously going to be special. Instead of the usual sad snack bag, there was catering. Instead of our generic PowerPoint title slide, a beautifully rendered graphic. Something big was coming; the kind of big that made us sit up much straighter than our chairs deserved.
The meeting begins and the announcement is made: senior management has been heads-down for weeks building out our new Company Strategic Model! This model would synergize our disparate priorities, align cross-functional initiatives, drive holistic value creation, and operationalize key learnings (whatever that means) to leverage our core competencies so that we can circle back on—
...well, you get the point.
The new Strategic Model was full of things that give people in suits palpitations and absolutely devoid of, well, you know: actual strategy. We’d built a framework for thinking, but forgotten to think.
When The Template Replaces Thinking
We love frameworks because they make us feel like we're doing something smart, even when we aren't solving the right problem.
Remember the great Monoliths and Microservices kerfuffle? A few companies at massive scale (like Uber & Netflix) published their war stories, and suddenly every startup with two developers and a dream was splitting their code into a hundred tiny services. We told ourselves we were being modern. In reality, most of us were just cosplaying scale.
And it’s not just architecture... think about JavaScript frameworks.
A new one drops roughly every thirty-eight seconds, each promising to finally solve the problem of building frontends (as if that problem were ever purely technical). Each one gives us a comforting illusion: that if we just pick the right tool, the messy human parts of software (like communication, design, and compromise) will disappear.
But they don’t. They never do, because the problem isn’t our frameworks. It’s our need to find salvation in them. When the framework replaces thoughtfulness, we end up with...
Besides... seeing patterns where they don't actually exist sounds a little like conspiracy theorist territory, doesn't it? 👽😱
When Process Crushes Purpose
Back at the end of last century, software engineering teams pretty much settled on a Way to deliver their projects... a design phase where you answer all the questions you can think of, a coding phase where you build the product, a testing phase where you prepare to release it, and then you deliver.
But those rules were changing; as the popularity of the internet grew, software products looked less and less like products in the physical world. They didn't need to be delivered in boxes to sit on shelves. So in early 2001, some practitioners got together and agreed on some new principles for how to better deliver software.
Some of the process folks fought back against the new ideas as being "unstructured and unsustainable and unscalable" and lots of other "un"s. Over time, the new ideas began to win out, though... until finally "Agile" became an accepted way of thinking.
And Then the Process People Showed Up
Over time, people started building frameworks to help with Agility. Organizations were hesitant to adopt Agile practices because they were used to having extensive rules for operation, and they perceived Agile as too chaotic. Things like SAFe (Scaled Agile For Enterprises) sprang up.
The problem was that the original tenets of agility were completely antithetical to this kind of structure. The Agile Manifesto itself speaks to this:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
What's really happening here is that people are comfortable in structures. We don't like ambiguity, and so we avoid it whenever possible.
But that's where creativity and innovation thrive.
Rebelling against Frameworks: Collaboration as Craft
Early in my career, I worked for someone who held high esteem for The Process. Everything had to follow the manual exactly; I was not to lift a finger to begin working on something until I had (as Douglas Adams famously wrote in The Hitchhiker's Guide to the Galaxy):
"...orders signed in triplicate, sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters.”
My boss had his reasons for this. And they were actually not bad reasons. The problem was the psychological effects of his choices:
The Process was designed to slow people down. YOU have to go enter the request in the system. YOU have to jump through the hoops. YOU have follow the procedure. Every step of The Process put the responsibility back on the person who was asking for help.
As a result, no one liked to work with him. They were coming to our team in order to get help with things they couldn't resolve on their own... only to be sent away to fill out a form or something else mundane.
When he left the company and I took over the team, I knew we had a major morale problem to solve so I did something rather unorthodox:
I eliminated The Entire Process.
Do you need our help? Just reach out and ask. I'm not going to make you fill out a form for something I can do in half the time it will take you to fill out the form.
But Blink, how will you document your work? Think about what you just asked there. How will I document MY work? Not by making someone else do the documenting! If I need to track things, the responsibility is on me to track those things.
Doing this built goodwill with the teams who were asking us for assistance. It eliminated entire systems we had maintained to track the paperwork. It wasn't the textbook solution, but it worked tremendously to rebuild the reputation of our team.
When a Framework is The Right Move
Obviously there’s some value in them, or they wouldn’t exist, right? So when do we build frameworks and when should we allow a little chaos?
Frameworks don’t mix with unknowns. If you’re exploring new technology or trying something “off the beaten path”, you don’t need to build a framework. It will get in the way as you rapidly pivot and experiment… rebuilding the framework with every direction change will be expensive and slow.
Frameworks are for factory work. If you’re building a lot of the same kind of thing, a framework helps you skip the setup tedium and focus on the outcome.
Special Forces vs Regular Infantry. Think of the framework like standard infantry- an invasion is led by Special Forces teams and once they’ve established a foothold, regular infantry moves in to secure. You need them, but you don’t lead with them!
Wrapping Up: The Cost of Your Comfort Zone
As I mentioned earlier: humans love structures. They feel safe in them, they feel protected from "the unknown".
And that's okay.
What we're talking about here isn't abandonment of every form of structure; it's a plea for discernment. Realize that messy will exist, and be willing to get in the mess sometimes.
Stop making everything a Framework and just focus on doing good work. There's a time for deep templatization and a time to just get stuff done.
Top comments (0)