Problem Solving

For two decades I’ve led engineering teams, ranging from scrappy startups to established tech giants. And in all that time, I've noticed a consistent pattern: we spend way too much time debating how to solve problems and not enough time actually solving them. We chase the latest methodology, the perfect process, the silver bullet… and often end up with frustrated engineers and unsolved issues.

The truth is, robust problem-solving isn’t about finding the right methodology. It's about cultivating the right people and creating an environment where they can thrive. It's about recognizing that the biggest bottleneck isn't usually a technical one, but a people one.

The Illusion of Process

We fall into the trap of believing that a new process will magically unlock productivity. Agile, Scrum, Kanban – these are all powerful frameworks, but they're tools, not solutions. They can facilitate problem-solving, but they don’t solve the problem.

I've seen teams paralyzed by process, spending more time talking about how to solve a problem than actually tackling it. For example, I once worked with a team that spent two weeks refining a sprint planning process, debating estimation techniques and story point assignments. By the time they were “ready” to start working, the initial problem had become significantly more urgent, and they’d lost valuable time. They got bogged down in ceremonies, estimations, and retrospective action items that didn’t translate into meaningful progress.

Think about it: when one person is consistently blocked by poor management, everyone notices. They quickly lose faith in "the process" because the real problem – a lack of support, unclear expectations, or inefficient decision-making – remains unaddressed. As some teams say, “methodologies don't work” – they just highlight where the real problems lie.

The constant debate over which methodology is “best” is like arguing over whether to drive on the left or right side of the road, or how to spell “color” versus “colour”. It’s a distraction from the fundamental challenge: unlocking the potential of your team.

Beyond Ability: The Power of Interest

So, what does work? It boils down to two things: ability and interest.

Your engineers need the skillset to tackle the problem. That's where technical training, mentorship, and creating opportunities for growth come in. But equally crucial – and often overlooked – is interest. People are far more likely to creatively and effectively solve problems they find genuinely engaging.

Finding work that excites your team isn't simply about matching skills to a list of known issues. It's about understanding their individual passions and aligning them with the needs of the project.

Consider this framework:

• Skill Assessment: What technical skills does each team member possess?
• Passion Mapping: What types of problems genuinely excite them? (Frontend, backend, data science, performance optimization, etc.)
• Alignment: Where can these passions and skills intersect with the current priorities of the project?

I remember one engineer, Sarah, who was initially assigned to a routine bug-fixing task. She was competent but uninspired. When a new project involving data visualization came up, she eagerly volunteered, explaining her personal interest in the field. Her enthusiasm was contagious, and she not only delivered exceptional results but also motivated the entire team.

This isn’t always possible, of course. Balancing individual interests with project needs can be challenging. But making a conscious effort to understand what motivates your engineers and assigning tasks accordingly can yield surprising results. I’ve seen engineers go above and beyond when given the opportunity to work on something they truly care about.

Coevolving with the Problem

A key part of fostering this environment is embracing the idea that problems aren't static. They evolve.

Often, we attempt to define a problem completely upfront, creating detailed requirements and specifications. But this can be counterproductive. It creates a rigid plan that doesn't allow for new insights or changing circumstances.

Instead, encourage your team to approach problems iteratively, treating them as learning opportunities. Focus on breaking down complex issues into smaller, manageable chunks, and validating assumptions along the way.

This requires a mindset shift. You’re not just trying to solve a problem, you’re trying to understand it. And that understanding will evolve as you gather more information and experiment with different solutions.

The Manager's Role: Removing Obstacles & Building Trust

As an engineering manager, your primary responsibility isn’t to solve the technical problems. It's to remove the obstacles preventing your team from solving them.

This means:

• Providing clear direction and context. Ensure everyone understands the “why” behind the work.
• Empowering your team to make decisions. Trust them to own their work and find creative solutions.
• Protecting them from distractions and interruptions. Create a focused environment where they can concentrate.
• Providing constructive feedback and support. Help them learn from their mistakes and grow their skills.

Ultimately, cultivating real problem-solving isn’t about finding the perfect methodology. It's about building a culture of trust, empowerment, and continuous learning. It’s about recognizing that the biggest leverage point isn’t a technical one – it’s the people on your team.

And that, in my experience, is a far more sustainable and rewarding approach to engineering management.

Try This Week:

• Schedule a 1:1 with each team member to discuss their interests and skills.
• Identify one process that's consistently causing friction and brainstorm ways to simplify it.