Introduction
I think one of the most important and underestimated skills in the IT industry is understanding stakeholders.
Especially because many technical problems are not purely technical.
Very often they are connected with:
• communication,
• expectations,
• priorities,
• misunderstandings,
• emotions,
• business goals,
• or conflicting interests between people.
Interesting, right?
At first glance software development may seem mostly about:
• code,
• frameworks,
• architectures,
• deployments,
• and systems.
But if we look deeper, almost every project is actually network of relationships between people trying to achieve different goals at the same time.
And this is exactly where stakeholder awareness becomes extremely valuable.
Who is stakeholder?
I think many people unconsciously reduce stakeholders only to managers or clients.
But honestly — stakeholder is anyone influenced by project or capable of influencing it.
This may include:
• developers,
• designers,
• QA engineers,
• product owners,
• managers,
• customers,
• support teams,
• marketing,
• sales,
• investors,
• recruiters,
• or even future maintainers of codebase.
Interesting thing is that each stakeholder usually sees project through completely different perspective.
And none of these perspectives are automatically wrong.
Different people optimize for different things
One fascinating thing about projects is that people rarely optimize for exactly same priorities.
For example:
• developer may optimize for maintainability,
• designer for user experience,
• stakeholder for business value,
• QA engineer for stability,
• product owner for delivery,
• customer support for reducing frustration,
• investor for profitability.
This creates natural tension.
And honestly — many workplace conflicts appear because people assume everyone sees situation exactly same way they do.
But reality is usually much more complex.
Technical perspective vs business perspective
I think one of the most common tensions inside the IT industry exists between technical and business perspectives.
Developers often focus on:
• scalability,
• architecture,
• code quality,
• long-term sustainability.
Business stakeholders may focus on:
• deadlines,
• market timing,
• costs,
• customer acquisition,
• or competitive advantage.
At first these perspectives may seem contradictory.
But interestingly — both sides are often trying to protect project success from different angles.
This realization changes communication dramatically.
Because instead of:
"“They don’t understand technology.”"
we may start thinking:
"“They optimize for different risks than I do.”"
Stakeholders and communication
I think identifying stakeholders is deeply connected with communication.
Because different stakeholders usually require different communication style.
For example:
• engineer may want technical details,
• executive may want concise summary,
• customer may care mostly about usability,
• investor may focus on business impact,
• designer may need emotional and behavioral context.
And honestly — one of biggest communication mistakes is assuming same message works equally well for everyone.
Emotionally intelligent communication adapts to context without losing authenticity.
Hidden stakeholders
Another interesting thing is that some stakeholders are invisible at first glance.
For example:
• future developers maintaining project,
• users who never give feedback directly,
• customer support handling complaints,
• or team members emotionally affected by decisions.
Interesting, right?
Sometimes decision which seems efficient short-term may create huge invisible cost for hidden stakeholders later.
This is why systems thinking becomes extremely valuable.
Because projects rarely influence only people visible during meetings.
Psychological safety and stakeholders
I think psychological safety strongly influences stakeholder communication too.
In unhealthy environments people may:
• hide concerns,
• avoid difficult conversations,
• suppress feedback,
• or pretend agreement.
Why?
Because they fear:
• conflict,
• criticism,
• rejection,
• or political consequences.
And honestly — this creates dangerous communication gaps.
Important information disappears.
Real risks remain hidden.
Assumptions increase.
Healthy environments encourage stakeholders to communicate concerns honestly before problems become crises.
Stakeholders and emotional intelligence
Another fascinating thing is that stakeholder management is deeply emotional process.
Not manipulative.
Human.
Because every stakeholder usually has:
• fears,
• expectations,
• pressures,
• limitations,
• and emotional needs.
For example:
manager under pressure from leadership may communicate differently than calm manager with stable environment.
Developer afraid of burnout may resist additional scope differently than someone with more emotional capacity.
Understanding emotional context improves collaboration dramatically.
Alignment
I think one of the healthiest things teams can do is creating alignment between stakeholders.
Because without alignment people may unknowingly move project in different directions.
For example:
• product wants speed,
• engineering wants refactor,
• management wants visibility,
• marketing wants launch,
• users want simplicity.
Without communication this creates chaos.
Alignment does not mean everybody fully agrees all the time.
It means people understand:
• priorities,
• trade-offs,
• expectations,
• and shared goals clearly enough to cooperate effectively.
Ego and stakeholders
I think ego also influences stakeholder relationships strongly.
Especially in environments built around expertise and performance.
Sometimes people stop listening because:
• they want control,
• validation,
• influence,
• or intellectual dominance.
This reduces collaboration quality quickly.
Emotionally mature professionals usually become more curious about:
"“What is this person trying to protect or achieve?”"
instead of immediately assuming incompetence or bad intentions.
And honestly — this small shift improves communication massively.
Observation and systems thinking
One thing I appreciate more over time is observing projects as systems rather than isolated tasks.
Every decision influences:
• people,
• communication,
• emotions,
• priorities,
• timelines,
• and future consequences.
Stakeholders are part of this ecosystem.
And understanding ecosystem usually improves:
• decision making,
• communication,
• leadership,
• and conflict resolution.
Especially in larger organizations where complexity increases rapidly.
Final thoughts
I think identifying stakeholders is one of the most valuable soft skills in the IT industry.
Because projects are never only technical.
They are deeply human systems containing:
• different priorities,
• emotions,
• incentives,
• fears,
• and perspectives interacting constantly.
And honestly — understanding stakeholders improves much more than communication.
It improves:
• empathy,
• leadership,
• collaboration,
• decision making,
• and emotional intelligence itself.
Perhaps maturity in professional environments is not about forcing everyone into same perspective.
Maybe it is about understanding enough perspectives to create alignment between people moving toward shared goal together.
Even if their motivations and priorities differ underneath.
Because after all — technology may connect systems.
But communication connects people behind these systems.
Soft Skills series
Part 18 of 32. Read more on the Empatalk blog or take the Communication DNA survey at empatalk.app/survey.
Sources and further reading
• Daft, R.L., & Lengel, R.H. (1986). Organizational information requirements, media richness and structural design. Management Science. https://doi.org/10.1287/mnsc.32.5.554