An Ode to Problem Solvers
Why Hiring for Stacks, Certainty, and Heroes Is Quietly Breaking Your Organisation
Recruiting has become strangely disconnected from reality.
We interview for stacks, frameworks, certificates, buzzwords. We screen for pattern matching rather than thinking. We optimise for people who fit neatly into today’s org chart, not for those who can reshape tomorrow’s system.
And then we act surprised when organisations stall the moment context changes.
If the last decades in IT have taught us anything, it is this: technology cycles repeat, but problems do not.
CGI scripts become application servers. Application servers become containers. Containers become serverless. The names change. The tooling changes. The PowerPoint decks certainly change.
Yet the real challenges move elsewhere: regulation, compliance, scale, security, cost pressure, reliability, data gravity, trust.
The mistake is recruiting as if the tools were the job.
They are not.
The People Who Ignore the Box
When building teams or transforming structures, the people who matter most are not the ones who think outside the box.
They do something more radical.
They ignore the box entirely.
These are the engineers and leaders who do not ask, “Which framework should we use?” but instead, “What problem are we actually trying to solve, for whom, and under which constraints?”
They do not fetishise novelty, nor do they cling to legacy out of nostalgia. They are comfortable reusing old technology when it is fit for purpose, and just as comfortable discarding fashionable tools when they add no value.
What defines them is not a preference for the new or the old, but a ruthless focus on relevance.
They understand that reality always wins. And they actively seek contact with it.
Because of this, they focus on problems, not personal heroics. They deliberately avoid hero culture. Not out of modesty, but out of discipline: heroics hide system flaws, create single points of failure, and trade short-term praise for long-term fragility.
Fast Feedback as a Compass
Problem solvers do not validate their ideas in slide decks.
They validate them in production.
They seek fast feedback loops, not because speed is a virtue in itself, but because feedback is how truth enters the system. They ship small, observe impact, adjust, and repeat.
They are allergic to long theoretical debates detached from delivery. Not because theory has no value, but because theory untested against reality quickly turns into ideology.
This is why they tend to be pragmatic.
They are not interested in church fights between paradigms, architectures, or methodologies. They care about outcomes. About customers. About reducing friction. About making something measurably better than it was yesterday.
In practice, this often means wearing multiple hats.
Designing while coding. Operating while building. Negotiating priorities while delivering incrementally. They do not see this as chaos. They see it as ownership.
They also deliver solid, consistent code. Not out of perfectionism, but out of realism. Nobody with a real life wants to be woken up at night to fix an avoidable issue. Reliability is a form of self-respect.
This discipline is reinforced by empathy. Because they stay connected to reality, they understand who will operate the system, who will be on call, who will absorb the failure. They care, and that care shows up in the code.
Autonomy Is Not an HR Slogan
Autonomy is often misunderstood as comfort.
For problem solvers, autonomy is responsibility.
They are capable of operating without constant supervision because they have internalised a sense of purpose. They know why they build what they build. They understand the business context well enough to make trade-offs without waiting for permission.
In our work and in our book, Karol Kasáš and myself describe how platform teams can be streamlined by empowering engineers to surface, aggregate, and refine strategy rather than merely execute tickets. These engineers act as interfaces between technical reality and stakeholder intent.
They help negotiate priorities, clarify constraints, and expose consequences.
This only works if the people involved possess the meta-skill that sits above all others: problem solving.
Without it, autonomy collapses into confusion. With it, autonomy becomes leverage.
Comfort with Not Knowing
One of the strongest signals of a true problem solver is their relationship with uncertainty.
They resist analysis paralysis.
Analysis paralysis is often mistaken for rigour. In reality, it is frequently fear disguised as process, optimisation theatre presented as thoughtfulness.
They are not paralysed by not knowing everything upfront. They understand that waiting for perfect information is often a decision to do nothing.
They accept that clarity emerges through action. That learning happens by doing. That each iteration can simultaneously deliver business value and explore the next step. This is not recklessness. It is disciplined curiosity.
They frame work so that every increment is useful on its own, while still pointing toward a longer-term direction. They are capable of holding short-term value and long-term intent in the same mental space.
They can look at future, customer-impacting OKRs without losing sight of what must be delivered now to make progress tangible.
Fear does not drive them.
Fear freezes systems. Problem solvers move them.
Recruiting for the Meta-Skill
This is where most organisations get it wrong.
They recruit for certainty in a world that only offers change.
Skill-first hiring feels rational. It is measurable. Comparable. Reassuring. It creates the illusion of control. But in practice, it optimises teams for yesterday’s constraints.
The failure mode is structural.
When you hire primarily for tools, frameworks, or narrow expertise, you systematically select people who need a stable environment to perform. You build organisations that work only as long as reality remains predictable.
And reality never does.
Problem solvers, by contrast, reduce decision latency. They do not wait for perfect information to move. They make bounded decisions, test them against reality, and course-correct quickly.
They reduce coordination cost. Because they understand both the technical and business surfaces, fewer handovers are needed. Fewer translation layers. Less theatre.
Most importantly, they absorb ambiguity upstream.
They clarify intent early, surface trade-offs explicitly, and prevent uncertainty from cascading downstream into chaos, rework, and operational debt.
This is not a soft skill. It is an economic lever.
The Anti-Patterns We Keep Hiring
Most organisations do not consciously reject problem solvers.
They unconsciously select against them.
Common profiles look attractive on paper, yet consistently fail under change:
- The Stack Collector : Deeply invested in tools as identity. Brilliant until the problem no longer matches the tool.
- The Framework Defender : Optimises for methodological purity rather than outcomes. Turns process into dogma.
- The Permission Seeker : Highly compliant, low agency. Safe in stable systems, paralysed in uncertainty.
These profiles are predictable. Easy to manage. Comforting. They are also brittle.
Fear as a Hidden Selection Bias
Here is the uncomfortable part.
Many organisations recruit fear-driven profiles on purpose.
Fear creates compliance. Compliance creates apparent order. And apparent order feels like control.
Until conditions change.
Fear freezes systems. It delays decisions, inflates coordination overhead, and pushes uncertainty downward until it explodes where it is most expensive: production.
Problem solvers behave differently.
They are not reckless, but they are not paralysed either. They accept that learning requires exposure. That clarity emerges through action. That progress without feedback is illusion.
They trade the comfort of certainty for the discipline of iteration.
A Practical Litmus Test
If you want to recruit problem solvers, stop asking hypothetical questions.
Discuss reality. Expand the signal surface beyond tech.
Problem solvers are anchored in the real world. They draw insight from outside their immediate domain and reuse lived experience as raw material for decision-making.
Five signals rarely lie:
This is not about judging tastes, culture, or personality. It is about judging reasoning, attention to constraints, and the ability to extract insight from reality.
- Ask about a decision they reversed. Problem solvers speak comfortably about learning. Ideologues justify.
- Ask how they validated impact. Problem solvers reference production, users, regulators, or measurable outcomes.
- Ask what constraint shaped their last solution. Problem solvers think in boundaries, not abstractions.
- Ask about the last non-technical book they read. Not to test culture, but curiosity. Strong candidates extract patterns from history, biology, craftsmanship, or human systems.
- Ask them to praise a non-digital product they use daily. Listen for reasoning. Good answers reference design trade-offs, durability, ergonomics, maintenance, or trust.
A strong answer does not sound like marketing. It sounds like engineering.
For example: someone praising a simple kettle might talk about thermal efficiency, ease of cleaning, failure modes, and why a physical switch beats a touch interface when reliability matters. Someone praising a bicycle might mention repairability, standardised parts, and how constraints shape longevity. Someone praising a chair might focus on load distribution, materials, and long-term comfort rather than aesthetics.
What matters is not what they choose, but how they reason about why it works.
Optional but revealing:
- When was the last time a life experience changed how you solved a work problem?
- What assumption did reality recently force you to abandon?
If the answers orbit titles, frameworks, tools, or abstract narratives detached from lived experience, you have your signal.
A Final Word
Problem solvers are not always easy hires.
They challenge assumptions. They resist oversimplification. They expose weak reasoning early.
But they are the ones who carry organisations through regulatory shocks, scaling phases, and structural change.
Technology will keep recycling itself.
Reality will not.
Hire accordingly.
Member discussion