Give Engineers Problems, Not Solutions

A simple strategy to improve solutions and boost morale

Thomas A. Limoncelli

There's an episode of Star Trek: Deep Space Nine ("Starship Down," S4E7) that teaches an important lesson about managing engineers.

In one scene, Worf barks out orders to the engineering team in typically abrupt Klingon style: "You, do this! You, do that!" The engineers cringe, deflated and demoralized. Worf is confused by their reaction.

Chief engineer O'Brien pulls Worf aside and tries to convince him there's a better way. "They're not bridge officers," he explains. "They haven't been to Starfleet Academy. They're engineers. They're used to being given a problem to solve and then figuring out how to do it."

Worf is conflicted. Why can't people just do as they're told?

Later, as the crew prepares for an attack by the Jem'Hadar, Worf recalls O'Brien's advice. Instead of barking out orders, he assembles the engineers and says, "I require your assistance. I need a weapon," before explaining the particular requirements, posed by their grave situation. The fear of battle fades from their faces, replaced by excitement. One engineer proposes a solution, Worf approves it, and the team dashes off, eager to work on the problem.

Worf can't believe how well O'Brien's suggestion worked. O'Brien smiles knowingly.

Why This Works

When I describe this scene, I always get two reactions:

The first is: "Don't you mean The Next Generation? Worf wasn't on DS9."

Yes, dear reader, Worf, son of Mogh, did join Deep Space Nine in season 4. He relocated from TNG in a desperate ploy to boost ratings—a fact you might've missed if you stopped watching by then. He remained on DS9 until the series was canceled. Nielsen ratings, it seems, have no honor.

The other, more relevant reaction is about how well this technique works with real-life engineers. It works because engineers tend to be puzzle-solvers. That's the kind of personality the profession attracts. They get a sense of satisfaction from finding solutions, even if it takes multiple tries. They feel useful when they see their solution put into action.

Giving engineers a problem to solve allows them to be creative and encourages collaboration. Engineers crave the opportunity to invent, inspire, and work alongside others. It lets them demonstrate their expertise. Unlike being assigned a task to handle, it gives them a sense of ownership and purpose.

When you do the opposite, telling them what solution you want instead of what problem you have, you rob them of the satisfaction of being useful, creative, and collaborative. You rob them of the social aspect of problem-solving side by side with others. If your team seems to have morale issues, this may be why.

The problem-solving approach doesn't just boost morale—it leads to better solutions. When engineers aren't provided important details about the problem, they can't fully understand the issue or verify that their solution works. Misguided solutions, detours, and distractions can and usually do result. Explaining the entire problem conveys the complete picture.

Additionally, and this may be hard to accept, the solution you propose may not actually be the best one. You spent years assembling a team of smart, capable people with distinct but overlapping skills, so let them do their jobs. Research shows that a diverse team comes up with a better set of potential solutions and picks the best one. Prescribing a solution denies the team an opportunity to do that.

Also, when the boss presents a solution, it shuts down the team's creativity. Yes, they could suggest alternatives, but they've already unintentionally been sent a message to keep their mouths shut. Why? Because the boss just told them what the solution is, and that discourages further thinking.

Even in situations where only one solution exists, using this approach can still motivate the team. People feel more invested when they believe they're working on their own idea. And sometimes, what seems like the only solution isn't the only solution. You might be surprised by how much you don't know.

We build teams with diverse experiences and complementary skillsets. Don't stifle their creativity by signaling you don't need it.

Guardrails for Big Projects

More guardrails may be necessary when the cost of a wrong decision is high, when switching costs are steep, or when amending a solution will be difficult.

Adding guardrails, however, can backfire on very large or complex problems, which may end up overwhelming the team and stifling creativity. In such cases, a straw proposal can help make the challenge less intimidating. Also, asking a team to break a problem down into smaller components encourages analysis, leading to a deeper understanding and reduced fear.

Creating multiple prototypes can mitigate this risk. If there are N obvious solutions, ask for more than N prototypes to encourage less obvious ideas to surface.

Life and Relationships

This technique works outside the office too.

A friend of mine was trying to steer her relationship in a new direction. After months of fruitless demands for specific changes, she shifted tactics. She had a heart-to-heart about her unmet needs, and her partner responded by making not only the changes she wanted but also others she hadn't considered. Being part of the problem-solving process inspired him to stick with those changes—something that hadn't happened previously.

I've also had success with this method. I felt the hedge in our front yard was far too tall and wanted to cut it down by at least half. After several failed attempts to convince my wife, I changed tactics. I gave the issue some space by waiting a few weeks. Then one day I mentioned how pedestrians had to duck to avoid the branches when they walked by our house. She went outside, saw the problem for herself, and soon it was her idea to shorten the hedge.

Summary

This technique is about providing the "why" instead of the "how." Instead of dictating specific solutions, present the problem and desired outcome, and let your team figure out how to solve it. This fosters creativity, shared ownership, and collaborative problem-solving. It also empowers the team to strive for the best solution.

Whether you're tackling technical issues, building new products, improving relationships, or handling landscaping decisions, this approach works. Most importantly, it makes everyone feel good about their contributions.

If your team, department, or organization is struggling with morale, consider whether people are being told the "how" instead of being given the "why." Now you have a problem to solve.

Acknowledgments

Thanks to Teresa Dietrich for her input in writing this article.

Thomas A. Limoncelli is a site reliability engineer at Stack Overflow Inc. He works from his home in New Jersey. His books include The Practice of Cloud Administration (https://the-cloud-book.com), The Practice of System and Network Administration (https://the-sysadmin-book.com), and Time Management for System Administrators (https://TomOnTime.com). He tweets @YesThatTom and blogs at YesThatBlog.com. He holds a B.A. in computer science from Drew University.

Originally published in Queue vol. 22, no. 6—
Comment on this article in the ACM Digital Library

More related articles:

João Varajão, António Trigo - Assessing IT Project Success: Perception vs. Reality
This study has significant implications for practice, research, and education by providing new insights into IT project success. It expands the body of knowledge on project management by reporting project success (and not exclusively project management success), grounded in several objective criteria such as deliverables usage by the client in the post-project stage, hiring of project-related support/maintenance services by the client, contracting of new projects by the client, and vendor recommendation by the client to potential clients. Researchers can find a set of criteria they can use when studying and reporting the success of IT projects, thus expanding the current perspective on evaluation and contributing to more accurate conclusions.

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.

Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.

Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.