Most software engineers were attracted to the job by a fascination with problems and puzzles and the chase of endorphins that comes from knocking them down one after the other.
Getting good at the job involves seeing and solving (and sometimes creating!) a ton of problems and then pattern matching new problems to past problems you’ve successfully solved one way or another.
Most software systems are solving the same problem again and again, and there are rarely novel problems to solve, so this pattern matching tends to serve software engineers well.
But here’s the trap: when you hand an engineer a solution instead of a problem, you short-circuit this entire process.
Whether you’re a manager assigning work, a founder talking to your tech lead, a senior engineer mentoring a junior, or a product manager writing tickets – if you’re telling someone how to solve something instead of what to solve, you’re robbing them of ownership and potentially missing better solutions.
I’ve been in enough lunches and after dinner drink sessions to hear many engineers complain about “stupid” decisions they’re being made to implement. Sometimes, they’re “stupid” only in that they didn’t come up with it.
So, here’s my advice:
Don’t give engineers solutions. Give them problems.
Even if you’ve already solved it. Even if you can do it faster and quicker. Even if it seems simple. Even if there’s a time crunch.
Don’t solve the problem before you hand it to an engineer – solving problems is what you pay them for.
More to the point, there are three things that can happen when you give an engineer the problem instead of your solution:
1. They come to the same solution you did, but now think it’s their idea.
This is the baseline outcome. You still get your solution implemented, but now the engineer you presented with the problem has ownership over the solution – they think it’s their idea (and it is!).
This means they’re far more likely to buy into the solution and care about its outcome. They own it, not you.
Also, this helps ingrain a new pattern to match for their future career.
An engineer’s growth comes from the surface area of problems they solve, the bugs they fix, the features they implement. Each time you let them solve the problem, you give them a new data point to match against in the future.
This is how engineers grow, with each problem they see and solve.
Presenting them with the solution instead of the problem doesn’t give them an avenue for growth, doesn’t add to their career pattern set, at least when it comes to code.
The thing is, engineers tend to pattern match not just code – but also businesses and bosses.
And you don’t want them to pattern match you to the bad bosses they’ve had in the past or the feature factories they’ve worked at in the past.
Become a new pattern for them – one that trusts them to solve problems on their own and gives them the opportunity to grow.
2. They come up with a better solution than you ever could have.
When you solve the problem, you’re matching it to the patterns you’ve seen in your own career, the problems you’ve seen in the past.
When you present the solution to the engineer and ask them to implement it, you’re cutting off their pattern matching to the problem and cutting off their past experiences and problem solving techniques.
They might have better techniques or better ways of thinking of the problem than you do. They might be more plugged in to the current codebase or current technology than you are and have better, more straightforward ways of tackling the problem at hand that you have fallen out of touch with.
When you propose a solution instead of a problem, you short circuit all of this context and thinking. Instead, you trigger resistance in many engineers – thinking through all the ways your solution won’t work instead of all the possible ways a solution could work.
The goal is to build or hire engineers who are better at solving problems than you are – it’s how organizations grow past individual capabilities.
Solving the problem for them robs the team of a chance to see and solve more problems, and it robs you of a chance for them to surprise and wow you.
Always remind yourself: You have a team that is here to solve problems. You should give them problems to solve.
And then smile when they blow past your imagination.
3. They need help solving the problem.
Say the problem isn’t landing. The engineer isn’t getting it, and the pattern matching isn’t firing.
This is the land of whiteboards and teaching.
It’s also where you might need to work the most at tamping down your frustration and impatience. Especially if you’ve already landed on a solution to the problem.
Remember point one: It is always better if they think it is their idea. It increases ownership, builds a new pattern to match against and ultimately helps the engineer grow.
So, your goal or challenge is to increase understanding, to get the light bulb to switch on before your frustration and impatience boils over, and you cut off the learning by mandating the solution.
Check first for understanding. Do they understand the problem at hand? Ask them to put it in their own words and correct, if necessary.
Propose your solution – if you have one – in an optional way. “What if we did …”
Ask for downsides, ask for gotchas, ask what you’re not thinking of.
Be explicit about needing help identifying flaws in the solution, or not being certain about it – even if you are.
Sometimes, what stops an engineer from solving a problem is fear – fear of being wrong or being judged.
Showing uncertainty or trepidation yourself helps to lessen this fear and to model ways to work through the fear.
In my experience, an engineer who doesn’t participate in the problem-solving is either checked out completely or scared to death.
Sometimes both.
When you reach your frustration or impatience limit, you have two choices:
Take a break: Ask the engineer (or engineers) to think about it and get back to you. Many engineers don’t think well on the spot and might need space to ponder and let the gears turn. Giving them this space can unlock a later understanding – sometimes light bulbs only go off in darkness.
Mandate and move on: If you go down this road, try to keep an opening for a better solution to pop up later. Think of it as, “Until we come up with a better idea, let’s do this …” Even if you’re frustrated beyond belief, always leave open the possibility for a better outcome to be found along the way.
This is part of my Editorial framework, a set of modular tactics and strategies that help software companies ship with speed, alignment, and safety at the same time.