You can teach BPMN 2.0 to a competent graduate in a fortnight.
Tasks, gateways, events, pools, lanes.
Give them 3 months on a real program, they’ll be modelling processes as well as anyone.
The notation was never the scarce skill.
What’s scarce is someone who can take a group of analysts with that same notation, then get them to produce something accurate, on time, without burning out half the stakeholders along the way.
That’s a leadership problem wearing a technical costume.
🎓 Why the notation stops being the differentiator
Early in this career, technical competence feels like the whole game.
Learn the platform properly, know the standard, model cleanly, deliver on schedule.
All genuinely necessary.
None of it is rare past a certain point.
Most analysts on a mature program can produce a correct BPMN 2.0 diagram.
What separates the ones who get promoted from the ones who don’t is almost never diagram quality.
It’s whether people want to work with them, tell them things, follow their lead when a session goes sideways.
That’s EQ, under a less fashionable name.
🧠 What EQ actually looks like in this work
It’s not a personality trait, it’s a set of specific behaviours.
- Reading whether someone’s agreeing because they mean it, or to end the conversation
- Noticing who hasn’t spoken in a session, then following up separately
- Adjusting your approach for the detail person versus the decisive one
- Naming the tension in the room before it derails a workshop
- Knowing when to push a stakeholder, when to leave it a week
- Staying calm when 2 teams argue about whose version of a process is correct
None of that appears in a BPMN 2.0 certification.
All of it determines whether the certification produces anything useful.
👥 Leading analysts is a different skill again
Running your own workshops well is 1 thing.
Leading 4 or 5 analysts through the same body of work is another.
Each of them has a different level of confidence, a different relationship with stakeholders, a different tolerance for ambiguity.
Your job stops being about your own EQ, starts being about building it into the team.
A few things that matter here.
Match analysts to stakeholders deliberately.
Your calmest person handles the department that’s been burned by 3 previous projects.
Your most detail-oriented person handles the stakeholder who catches every inconsistency.
Getting this wrong wastes weeks.
Debrief after every session, not just the map.
Ask what the room felt like, not only what was captured.
An analyst who says “everyone agreed quickly” might have just witnessed a group that stopped arguing in front of their manager.
That’s worth catching early.
Protect the junior ones from the politics.
A junior analyst who gets burned once in front of a director becomes cautious for the rest of the program.
Cautious analysts produce sanitised maps.
Take the hard conversation yourself when it’s genuinely hard.
🗣️ Teaching a team to read a room
You can coach this, even in people who find it unnatural.
A few habits worth drilling into a team.
- Repeat the last few words of a thin answer back as a question, then wait
- Ask what am I missing, near the end of every session
- Say the awkward thing early, rather than hoping it resolves itself
- Chase “that’s right” as agreement, not “you’re right”
- Never argue faster when someone’s dug in, slow down instead
None of these are complicated.
They’re just not instinctive for everyone, particularly analysts who came up through a technical route rather than a client-facing one.
Practise them in low stakes sessions before the ones that matter.
⚔️ Where a leader earns their keep
Two teams disagreeing about how a process actually works is the single most common conflict on a program.
Your analysts will find these constantly.
What they shouldn’t do is resolve them.
Arbitrating between 2 departments puts an analyst in the middle of something that isn’t theirs to decide.
What a good leader does instead.
- Coach the analyst to write both versions down, without judgement
- Ask what each version costs, in time, rework, or risk
- Escalate the decision to whoever owns the process
- Stand behind the analyst publicly when a department pushes back
That last point matters enormously for morale.
An analyst who knows their lead will back them up in a difficult meeting takes more risks, asks harder questions, produces better maps.
One who’s been left exposed once stops taking any risks at all.
📊 Balance EQ with evidence
People skills get you the room.
They don’t replace rigour once you’re in it.
The best leaders I’ve worked under pair the 2 deliberately.
Data to make the finding undeniable.
Empathy to deliver it without making an enemy.
A process step adding 2 days while rejecting roughly 1 in 100 cases is a fact.
How you present that fact to the team who’s been running it for 8 years determines whether they help you fix it, or quietly resist for the next year.
🎯 Building this into the team, not just yourself
If you’re leading a group of analysts, the practical question is how you build EQ into people who may not naturally have it.
A few things that work over time.
- Sit in on each other’s sessions occasionally, debrief on tone as well as content
- Share what worked when someone defused a tense workshop
- Normalise saying “I got that one wrong” in team retros
- Reward the analyst who found the awkward truth, not just the one who finished fastest
- Rotate people onto the harder stakeholders deliberately, with support
That last point develops capability rather than protecting people from ever needing it.
Growth happens in slightly uncomfortable assignments, with a leader nearby to catch problems early.
✅ Where it lands
Notation gets your team into the room.
It’s the entry requirement, not the advantage.
What actually determines whether a program succeeds is whether the people running it can build trust quickly, read what’s really happening beneath the polite version, then lead a group of analysts through the same skill without any of them getting burned along the way.
That’s the harder qualification.
It’s also the one that decides whether the whole exercise was worth doing.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
