It might be about introducing an alternative tool. Or it might be about changing a process or policy. But I’ve found that engineers in particular fall into a pattern: they spot a problem, decide on a solution, and then try to convince everyone their solution is right.

When others don’t immediately agree with their solution, the engineer feels frustrated, and they go back to their daily work feeling disheartened and resentful. This frustration builds up into actions that often work against them and limit their impact.

As engineers, there are steps you can take to get out of this cycle. Here are the three common traps that are likely limiting your impact and what you can do to avoid them:

1. Failing to build context and understanding

I remember working on a project when a new starter made a lot of noise as they started browsing the codebase. They said things like, ‘I can’t believe you’re still using this version of the Spring Framework’, ‘Ugh! This is a hideous bit of code’, and in a sarcastic tone, ‘Whose great idea was this networking implementation?’

As they continued to make similar comments, I could feel my cheeks flush with embarrassment, unsure if they were looking at the code I wrote. I was also certain I wasn’t alone.

While I felt mildly embarrassed, other team members reacted more strongly with anger. I noticed this when the new starter asked for help and upset team members responded in the shortest and most unfriendly way. They provided minimal information to questions. And when they saw the new starter visibly struggling with a task, they did not offer help.

I’ve seen this pattern repeat itself many times with new engineers. Many think they know best and want to show off their knowledge, but they fail to build context and understanding. Instead, they jump to conclusions and make plenty of noise about their opinions. Although they may have better ideas or insights, their communication style generates resentment that will limit how much impact they can have in the future.

If you want to have more impact, remember to apply the Retrospective Prime Directive. Simply put: ‘Believe people did the best they could given the circumstances and don’t jump to conclusions.’ Ask people about the events, decisions, and options that led to the way that the system was built.

Before suggesting and pushing for a new solution, draw on the principle of Chesterton’s Fence and discover the forces that led to outcomes that you see today. You’ll not only build bridges with people by seeking understanding, but you’ll also end up with a more robust solution.

2. Focusing on (only) highlighting problems

No environment I have ever worked in is entirely perfect. Although I’ve worked in high-performing teams where we did great work, accomplished a lot, and achieved some great goals, there was always something that needed improvement. Software is an excellent example of this in that all real-world production systems always have some level of technical debt.

You probably know that engineer who always points out poor decisions, painful parts of a system or development process, or just someone who likes to complain. Some technical folks fall into the trap of focusing only on what’s wrong or only highlighting problems. Complaining might feel fun, cathartic, and help others express their frustration, but you’ll likely isolate yourself as others label you ‘opinionated,’ ‘a troublemaker’, or ‘whiny’.

Spotting problems isn’t difficult. Highlighting problems for others to solve is a quick way to limit your impact. This is why you might hear some managers say, ‘Don’t bring me problems. Bring me solutions.’ No reasonable manager expects you to have a perfect solution but wants you to consider the problem and potential solutions. More information and options lead to a richer discussion. It’s also good to avoid having a single solution because you’re also likely missing context and trade-offs that may influence the final solution.

To grow your impact, start by clarifying the problem by writing a memo or wiki page. Make sure to include data and observations. Check with others to see if your problem is a big problem to solve. Identify and summarise potential solutions, including their trade-offs. Use these solutions to spark discussions on what could be done, gain more context, and generate more buy-in and commitment to change.

3. Forgetting about the when, not just the what

Some people are very good at spotting issues and problems that don’t fall within a team’s scope of work. You might have spotted an issue such as friction between several teams using a shared Kafka messaging stream or a slow-platform tool affecting everyone’s developer productivity.

These are typically the tragedy of the commons problem, which you might sometimes hear as, ‘Everyone owns it. Thus no one owns it.’ In software systems, these problems don’t get the same care and feeding like technical debt clearly within the scope of a single team.

When you spot a clear problem, you might even have ideas about how to fix it. However, now the problem is finding the time and resources to allocate to this. I’ve seen countless engineers frustrated because they have identified a problem and know the solution and see it as ‘simple’ to address the issue. They forget about the ‘when,’ not just the ‘what.’ If the engineer doesn't get immediate attention or agreement to solve the problem, they escalate by repeating and getting louder about their issue. The engineer complains and criticizes managers and might even threaten to quit because they don’t feel listened to. Feeling frustrated that you have no immediate support limits the impact you will have.

To increase your impact, realize that identifying a problem and an ideal solution is only the start of successful change. Organizations have more work than they can do, and all stakeholders see their work as the most important. In some situations, shifting efforts may literally not be an option because the effort needs to go to work that generates cash flow and keeps the whole company afloat. In other situations, fixing your issue might allow more significant and more problematic issues to continue to grow.

If you have identified a problem and solution, follow this three-step process to escalate it effectively:

1. First, focus on awareness. Do key decision makers know there is an issue to solve?
2. Build a business case that allows them to prioritize this. Where does this sit in priorities relative to other work?
3. Be patient but persistent. Ensure the work doesn't drop off the backlog and that someone prioritizes effort at some point. Expressing frustration might be personally satisfying, but it probably won't change anything

Having a broader impact is about more than being right

If you want to grow your impact as an engineer, it’s not enough to have what you think is the right solution. Remember that relationships matter. If you’re going to get buy-in and support for both the solution and change, you must first build context and understanding. Avoid throwing problems at others to solve. Take ownership of one issue and involve others to build solutions. Finally, if you have arrived at a solution, be patient. Identify and engage key managers who make decisions around priorities. Appreciate there will always be trade-offs and limited time and energy and that there is no such thing as a perfect environment.