In software engineering, we often move quickly from symptom to solution.
A delivery is late, so we talk about estimation.
A bug reaches production, so we talk about testing.
A meeting ends without a decision, so we talk about process.
Sometimes those explanations are correct. But often, they are only the surface and the real issue is hidden underneath. If we diagnose the problem poorly, even a well-intentioned solution can make things worse.
The first diagnosis is not always the real one
In the first article of GC Insights, I wrote that leadership often starts before there is a title attached to it. One of the ideas behind that article was that engineers lead when they help the team understand the problem before jumping into the solution. That idea deserves a deeper look.
In daily engineering work, many situations look simple from the outside.
A feature is delayed.
A requirement is misunderstood.
A team is not aligned.
A developer is struggling.
A stakeholder is frustrated.
A meeting ends without a decision.
A technical discussion becomes tense.
The easy reaction is to label the issue quickly.
“They need to communicate better.”
“We need more ownership.”
“The team needs to move faster.”
“This person needs to improve.”
“We need a better process.”
Maybe. But maybe not.
Before deciding what to do, it helps to understand whether the situation is mainly a problem of clarity, competence, or courage.
It is a lens for situations: a simple model that helps us slow down, think better, and act with more intention.
Is it a clarity problem?
A clarity problem exists when people do not fully understand what matters, why it matters, what direction to take, or what success looks like. In software engineering, this happens all the time.
The team is building something, but the desired outcome is vague.
The priority is not explicit.
The trade-offs are not discussed.
The technical direction is assumed, not aligned.
The definition of “done” means different things to different people.
People are working hard, but not necessarily toward the same result.
From the outside, this may look like low ownership, poor execution, or lack of focus. But the real issue may be that people are trying to execute without enough shared understanding.
A clarity problem is not solved by pressure. If the team does not understand what matters, asking them to move faster only creates faster confusion. The better response is to create shared context.
A few useful questions are:
- What problem are we actually trying to solve?
- What does success look like?
- What assumptions are we treating as obvious?
Clarity reduces wasted energy. It does not remove complexity, but it gives people a better way to navigate it.
For individual contributors, creating clarity might mean summarizing a technical decision, writing down assumptions, or asking the question nobody is asking.
For aspiring leaders, it might mean helping the team connect tasks with outcomes.
For engineering leaders, it means making sure direction, expectations, priorities, and constraints are not only present in your head, but understood by the people doing the work.
Is it a competence problem?
A competence problem exists when people understand what is expected, but do not yet have the skill, experience, knowledge, context, or support needed to execute well. The direction may be clear, but the ability to act is still developing.
This can show up in many ways.
A developer struggles to design a maintainable solution.
A senior engineer has difficulty influencing beyond code.
A new joiner does not yet understand the domain.
A team repeatedly introduces similar defects.
Someone receives feedback but does not know how to translate it into action.
A person is asked to own a complex topic without enough preparation.
The mistake here is to confuse a competence gap with a character flaw.
“They do not care.”
“They are not proactive.”
“They are not senior enough.”
“They should already know this.”
“They need to be more professional.”
Sometimes expectations are fair. But if someone lacks the skill or context to meet them, judgment alone will not create growth.
Competence problems are not solved by blame. They are solved through learning, coaching, mentoring, practice, feedback, pairing, better examples, and clearer standards.
A few useful questions are:
- Do they have the technical or domain knowledge needed?
- Have we given timely and specific feedback?
- What would help them grow into this responsibility?
This matters because leadership is not only about expecting better performance. It is also about creating the conditions for people to improve.
That does not mean lowering standards. Actually, it is the opposite. High standards become more sustainable when people are supported in reaching them.
Is it a courage problem?
A courage problem exists when people know enough to act, but avoid the conversation, decision, disagreement, escalation, or responsibility that the situation requires.
This is one of the hardest types of problems because it is often invisible.
The team knows the deadline is unrealistic, but nobody says it clearly.
People see a technical risk, but avoid escalating it.
A decision is needed, but everyone keeps waiting for more information.
A code review becomes tense, but the real disagreement is never addressed.
A stakeholder expectation is misaligned, but the team keeps trying to absorb the pressure silently.
Someone’s behavior is hurting the team, but people talk around the issue instead of about it.
From the outside, this may look like a process failure. So the organization adds another meeting, another status report, another alignment ritual, another template. But if the real issue is courage, more process may only give people a more sophisticated way to avoid the truth.
Courage problems are not solved by documentation or rituals alone. They require someone to name the tension with respect.
A few useful questions are:
- What conversation are we avoiding?
- What risk are we hoping will disappear?
- What is the cost of not addressing this now?
Courage does not mean being aggressive. It does not mean creating conflict for the sake of conflict. In leadership, courage often looks calm. It sounds like a clear sentence said at the right time:
“I think we are not aligned on the real priority.”
“I am concerned that we are treating this as a delivery issue, but it may be a product decision.”
“I do not think we can commit to this scope without discussing the trade-off.”
“I believe we are avoiding the harder conversation.”
“I may be wrong, but this is what I am seeing.”
Courage is not the absence of discomfort. It is the decision to act responsibly even when the conversation is uncomfortable.
The cost of solving the wrong problem
The reason this diagnostic matters is simple: Different problems require different responses.
You do not solve a clarity problem with pressure. If a team lacks clarity and receives pressure, confusion increases.
You do not solve a competence problem with blame. If a person lacks competence and receives judgment, confidence decreases.
You do not solve a courage problem with another process. If a group lacks courage and receives more process, avoidance becomes more organized.
This is why leadership requires more than action. It requires diagnosis.
In software engineering, we understand this deeply when dealing with systems. A good engineer does not only fix symptoms. They investigate causes. They look for patterns. They ask what changed. They inspect logs. They question assumptions. They try to understand the system before changing it.
Human systems deserve the same care. A team is also a system. Its behavior is shaped by incentives, trust, clarity, standards, skills, pressure, history, and communication patterns.
When something is not working, the first visible symptom is rarely the whole story.
A practical way to use this
The next time you face a difficult situation at work, pause before naming the solution. Try asking yourself three questions.
Is this a clarity problem? Do people understand what matters, why it matters, and what success looks like?
Is this a competence problem? Do people have the skills, context, experience, and support needed to execute well?
Is this a courage problem? Is someone avoiding a necessary conversation, decision, disagreement, or escalation?
You may discover that the answer is not only one of them.
A team may lack clarity and courage.
A person may need competence and clearer expectations.
A project may suffer from unclear direction, missing skills, and avoided decisions at the same time.
That is fine. The goal is not to force every situation into a box. The goal is to improve the quality of your thinking before you act, because better diagnosis leads to better contribution.
From insight to practice
This is the kind of reflection that becomes more useful when turned into practice. That is why I am also adding a companion resource to GC Insights: Clarity, Competence, or Courage Diagnostic.
It will not give you all the answers. But it can help you ask better questions. And in many leadership moments, better questions are where better outcomes begin.
Growth and contribution
Growth is not only about solving more problems. It is also about learning to see problems more clearly.
As engineers, we are trained to debug systems, trace failures, analyze causes, and improve design. As we grow, we need to apply that same discipline to collaboration, communication, ownership, and decision-making.
Contribution starts when our growth becomes useful to others.
Sometimes that means writing better code.
Sometimes it means creating clarity.
Sometimes it means helping someone build competence.
Sometimes it means having the courage to say what needs to be said.
The problem in front of us is not always the real problem. Leadership begins when we care enough to look deeper.