At some point in your career, you’ll likely participate in a project that is a technical and implementation success but is still a failure. That’s because the wrong solution was implemented. For example, after weeks or months of hard work you might successfully deploy a client-based VPN solution, but because of application latency requirements a VDI or application publishing solution would’ve better met users’ needs.
In the face of project failure, some will declare victory regardless. They’ll claim they did their job by deploying a technically functional solution and wash their hands of all the decisions outside their control. However, the more reflective of us will wonder how such a costly effort, both in dollars and person-hours, resulted in no meaningful business outcomes.
While we can’t take responsibility for decisions outside of our sphere of influence, we can use the influence we have to ask meaningful questions that prompt discussion to shape the course of a project. In this article series, I’ll explore powerful questions engineers can ask and how we can use these questions to improve outcomes and work more effectively.
I’ll start with the most essential: “What problem are we trying to solve?”
This question should be asked in the architecture phase when business problems become married to technology solutions. If you’re lucky enough to participate in this phase of the project, one of your primary objectives should be to clarify the project’s goals and objectives. Everyone involved ought to be able to answer the same way when asked, “What problem are we trying to solve?”
Often though, as a project moves through implementation phases, the decision tree becomes unclear. People miscommunicate or misunderstand. Teams and individuals impose their misaligned priorities onto the requirements. By the time the project directives reach individual contributors, the goals may be indiscernible. The degradation of clarity will happen as a matter of course if you don’ not have systems in place to prevent it.
Ask, Listen, Document
What can you do when you’re mired in project ambiguity? First, you must be brave enough to speak up. If you’re going to ask for clarity, you’re admitting that, at some level, you don’t understand. This can be a challenge for engineers who spend years developing knowledge and building a reputation as the person with correct answers. Ask anyway.
When you ask, listen carefully to the response. If the answers are convoluted, rambling, or ambiguous, ask more questions. If no one provides a clear problem statement, create a blank document and share it in the meeting or go to the whiteboard. Write the words you’re hearing for everyone to read and ask the team to review them. Written words provide a focal point for conversation. It’s healthy for teams to grapple and debate in the early stages of a project. Stay focused and keep asking questions.
As people discuss the problem and possible solutions, edit the collaborative statement in real-time and ask if it accurately reflects stakeholders’ understanding. Capture the main ideas in a couple of sentences or a few bullet points. This approach will force a level of clarity and will also guide the team as the project progresses. If your organizational culture is highly formal, add the structure necessary and save this document as an official record. When you’re actively planning and communicating, particularly with non-technical stakeholders, the goal must be clarity, not a vocabulary lesson or technical deep dive.
If you’re a junior engineer, tread lightly. If a trusted senior is leading the effort, follow their guidance until you have enough context to ask informed questions — watch and learn. If there’s a void in technical leadership, you may need to fill the gap. Ask questions and piece together the responses. Why are we pursuing this path? How will solving this problem move us forward? What have we already tried/considered? What changed? Even as a sole contributor to a project, asking yourself these clarifying questions will help when you’re struggling to make progress. Write down your thoughts, then step away. Come back and review. Share with a trusted colleague.
In other scenarios, you may jump into an ongoing project or a troubleshooting inferno. In these instances, you cannot work effectively without clarity. Our question is especially valuable in a tactical context. Now, when you ask, “What problem are we trying to solve?” The response may be deeply technical and unambiguous. For example, someone might say “We aren’t not receiving routes from our BGP neighbor.” The problem is apparent, and you know where to focus.
I’ve seen more projects fail for want of clarity than technical capability. Once a team has clear objectives and team alignment, gaps in capability emerge as solvable problems. A curious, plain-spoken, and outcome-focused engineer will grow in influence and value to their organization with a rare combination of technical and leadership skills that are infinitely transferable.
