But the real problem isn’t the number of frameworks, it’s that we’re often not clear about why we’re using them. Even when a team chooses a framework thoughtfully, people may still disagree about what they’re trying to accomplish. Are they trying to teach skills? Create shared language? Bootstrap a team? Ensure quality? Without alignment on the purpose, even the best frameworks fall flat.
Frameworks are great guides, but too often people treat them like they’re the final word. This article does such a good job breaking down the real point: frameworks are only as useful as the clarity behind why you’re using them.
In big companies or the government, you need more frameworks. Ironically, they actually work better there because they’re built for that kind of environment. But in startups or more organic teams, frameworks can feel heavy-handed or awkward, because those environments need flexibility first. Loved how this post made me think more critically about when a framework is helping vs when it’s getting in the way.
This clicks for me—thank you for that. I realize I did believe this already but never expressed it and found a slightly different job.
Frameworks are expected to provide a sense of certainty in a moment of uncertainty. That’s often translated into a story of competency before we know it — maybe due to the ‘fundamental attribution error’ bias. Competency can be addressed/expressed in terms of our well-worn framing of education.
If true, I’d agree on 4 jobs but within that framing:
Framework as self-education
Framework as teaching
Framework as norms
Framework as governance
Teaching has a collaborative co-creation path vs hostile path that uses frameworks slightly differently.
Norms isn’t my favorite way to say this but want to be clear it’s not necessarily enforced — translates to me as social contract theory meets flow engineering.
Governance is when enforcement comes in. But I’ve also worked in enterprises for a while so that won’t click for startup friends.
As someone who’s spent a good part of their career getting parachuted into teams on fire, let me suggest this: You don’t hire a framework. You hire a smokejumper.
We bring the JTBD tools with us — strapped to our backs, sharpened, field-tested, and ready.
The real question isn’t:
“Which framework should we hire?”
It’s:
“Who can identify the fire we’re in — and know which tool to grab first?”
Because the wrong tool at the wrong time?
Just adds fuel.
I know, because I have the singed jockey shorts to show for it.
That’s an interesting observation and like the logic of it once something is on fire. It explain that pattern well.
What I read here is before that. No one wants to start a fire. So how do we prevent them? That’s the above, and you offer a great way of thinking about what happens next.
I think one of the pattern problems has always been that they are primarily targeted at experienced people who understand the patterns-to-pick-patterns (the meta patterns?). They love them! But in the learning mode, this can fall flat unless you learn from someone about how they pick the patterns.
As a software engineer in test, I've come to marvel at how much a "test framework" can influence a team's productivity and capabilities. At best, a light agile framework helps deliver results reports repeatably. But a some teams are still stuck on old tools like TestNG, while other teams have made up in-house tools with giant blind spots.
Frameworks are great guides, but too often people treat them like they’re the final word. This article does such a good job breaking down the real point: frameworks are only as useful as the clarity behind why you’re using them.
In big companies or the government, you need more frameworks. Ironically, they actually work better there because they’re built for that kind of environment. But in startups or more organic teams, frameworks can feel heavy-handed or awkward, because those environments need flexibility first. Loved how this post made me think more critically about when a framework is helping vs when it’s getting in the way.
Nice to see you here. I am new to this platform just getting to know it.
This clicks for me—thank you for that. I realize I did believe this already but never expressed it and found a slightly different job.
Frameworks are expected to provide a sense of certainty in a moment of uncertainty. That’s often translated into a story of competency before we know it — maybe due to the ‘fundamental attribution error’ bias. Competency can be addressed/expressed in terms of our well-worn framing of education.
If true, I’d agree on 4 jobs but within that framing:
Framework as self-education
Framework as teaching
Framework as norms
Framework as governance
Teaching has a collaborative co-creation path vs hostile path that uses frameworks slightly differently.
Norms isn’t my favorite way to say this but want to be clear it’s not necessarily enforced — translates to me as social contract theory meets flow engineering.
Governance is when enforcement comes in. But I’ve also worked in enterprises for a while so that won’t click for startup friends.
Early thought inspired by your — wdyt?
As someone who’s spent a good part of their career getting parachuted into teams on fire, let me suggest this: You don’t hire a framework. You hire a smokejumper.
We bring the JTBD tools with us — strapped to our backs, sharpened, field-tested, and ready.
The real question isn’t:
“Which framework should we hire?”
It’s:
“Who can identify the fire we’re in — and know which tool to grab first?”
Because the wrong tool at the wrong time?
Just adds fuel.
I know, because I have the singed jockey shorts to show for it.
That’s an interesting observation and like the logic of it once something is on fire. It explain that pattern well.
What I read here is before that. No one wants to start a fire. So how do we prevent them? That’s the above, and you offer a great way of thinking about what happens next.
Some really great insights! I share similar over on my stack!
I like this, thanks.
Would you say that standards and pattern libraries have the same four jobs?
I think so. It *feels* right ... especially with patterns. What's your thought Jurgen?
Yeah, same.
I think one of the pattern problems has always been that they are primarily targeted at experienced people who understand the patterns-to-pick-patterns (the meta patterns?). They love them! But in the learning mode, this can fall flat unless you learn from someone about how they pick the patterns.
It might be helpful to mention that tool selection matters too.
If I show up to fix a door with a chainsaw instead of a coping saw,
I've already biased the conversation toward demolition — not repair.
As a software engineer in test, I've come to marvel at how much a "test framework" can influence a team's productivity and capabilities. At best, a light agile framework helps deliver results reports repeatably. But a some teams are still stuck on old tools like TestNG, while other teams have made up in-house tools with giant blind spots.