F — Fairness
Perceived equity. In IT — scope prioritizations, promotion decisions, allocation of „interesting” tasks vs. „grunge work” — Fairness is the most powerful dimension when violated.
- Understand that Fairness is about PERCEPTION, not objective truth
- Communicate visible criteria for any prioritization decision
- Recognize when „efficiency” becomes „inequity” and reverse course
Studies (Tabibnia, 2008) show that perceived „unfairness” activates physical pain regions more strongly than any of the other 4 dimensions. In software teams, this happens daily: someone always gets the „cool” tasks (greenfield), another is always on „bug fixes”. One is invited to architecture review, another isn't. One gets credit at the demo, another doesn't.
How Fairness shows up in IT
Three zones where BAs/POs/EMs violate Fairness unknowingly: (1) Scope prioritization — someone's request gets in, another doesn't, without visible criteria. (2) Task allocation — patterns of „who gets what” that aren't discussed. (3) Recognition — at demo, in retro, in 1-1s — who's mentioned and who isn't.
What activates Fairness (toward)
- Explicit rules, applied equally to everyone (including yourself).
- Transparency in decisions: „I chose A because [specific criterion]”.
- Recognition of contributions in proportion to actual effort (not visibility).
- Applying the rules even when they disadvantage you — no „political” exceptions.
- Explicit rotation of unpopular tasks (oncall, bug fixing, support).
- Public documentation of prioritization frameworks (RICE, MoSCoW).
What threatens Fairness (away)
- „Exceptions” for certain stakeholders — even small ones, publicly visible.
- Decisions without explanation („because the CTO said so”).
- Disproportionate recognition (someone gets credit for another's work, or a quiet person is invisible).
- Different processes for similar people (e.g., A was interviewed 1h for promo, B 3h).
- Patterns in „greenfield” vs. „grunge work” allocation favoring the same people.
- Retroactive rule changes („this no longer counts”) after someone qualified.
4 Fairness moments in IT
Which of the following violate Fairness? Click your answer.
PO announces: „Marketing's request goes in this sprint, even though it came in yesterday. Sales's (from last week) is out.”. No explanation.
EM assigns Mihai the „re-architecture” greenfield task. You, BA with the same seniority, get the bug fix backlog. 3rd week in a row.
PM tells you: „we can't have standup at 9am — Mihai has to drop his kid at daycare”. You have the same situation but never said anything. PM accepts for all.
At demo, the manager says: „Team A did excellent work!”. Your team delivered the same, but nothing. All quarter.
Redesign: opaque prioritization announcement
Below is an announcement a PO posted in the team channel about re-prioritization. It's opaque — and has already generated 12 DM messages. Rewrite it to be transparent without becoming a long email.
Write your version. Then see a hint and a suggested rewrite.
Audit: the last „no” you gave
Recall: the last time you said „no” to a request (scope, feature, change). Did you communicate the criteria? Could anyone argue it was unfair?
Note: to whom you said „no”, context, what you said. Then: what criterion did you use? Was it visible to the other party?
- How would they have reacted if you'd explained the criterion? Would it have changed anything?
- Is there a framework you can use consistently (RICE, ICE, MoSCoW)? If yes, is it public in the team?
2 stakeholders ask for urgent features. You decide in favor of one. What's most important?