We analysed 45,000 Jira tickets and git commits across three Apache projects and tracked whether engineers actually grew into harder work over their careers.
1 / 7
Slide 2 / 7
The study — Apache Camel, Spark & Hadoop · 2007–2022
We matched Jira tickets to git commits and tracked complexity over career
378
engineers with 10+ linked tickets
45k
tickets matched to git commits
15yr
of engineering history
Complexity score per ticket: how many modules were touched, whether core files were changed, breadth of impact across the codebase. Then for each engineer: is their complexity score rising, falling, or flat over their career?
2 / 7
Slide 3 / 7
Here is the real rule.
11%
Growing
Took on progressively harder work — more modules, more core codebase, and got faster at it over time
20%
Coasting
Drifted toward simpler work — fewer modules, less core, getting slower even on easier tickets
70%
No effect
Work experience had no measurable impact on the complexity they could handle
3 / 7
Slide 4 / 7
The 11% — what growing actually looks like
The work got harder. Then they got faster.
1
Repetitions in one area
Engineer works on similar ticket types repeatedly — same cluster, same module. Resolution time starts to decline. Pattern recognition building.
2
Velocity improves, scope expands
Tickets take less time AND touch more files, more modules. Getting faster while handling broader scope — the transfer signal.
3
Complexity ceiling rises
Cross-cutting problems, core modules, more people consulted per ticket. The work itself raised the ceiling.
The growth curve is measurable before the advancement happens — it can be designed, not just hoped for.
4 / 7
Slide 5 / 7
The 20% — coasting in slow motion
Productive. Closing tickets. Coasting.
Complexity score
— — tickets closed: unchanged
Yr 1
Yr 2
Yr 3
Yr 4
Yr 5
Yr 6
Yr 7
→
Ticket count: normal — closing work at a steady pace, no red flag in any dashboard
↘
Complexity declining — fewer modules per ticket, less core codebase involvement each year
↗
Resolution time rising — getting slower even as the work gets simpler
5 / 7
Slide 6 / 7
The implication — growth can be designed, not just hoped for
The answer is already in your own data
◎
Who is in which trajectory?
Your Jira and git history already shows which engineers are growing, stagnant, or drifting. No new tooling required.
◎
What work would stretch them?
The complexity map shows which modules each person has touched — and which adjacent ones they haven't yet.
◎
No training platform needed.
The 11% didn't learn from a course. They got the right tickets. That's designable.
Open source data from Apache — enterprise teams may look different. But the signals come from data every company already has.
6 / 7
task2vec
What does your team's 10/20/70 look like?
Your ticket history already contains the answer.
We can compute the growth distribution for your team and show you exactly who needs what work next.
Full data & methodology
task2vec.com/research
→
Run this on your own data
task2vec.com/commission
→
Based on 45,000 Apache commits · Camel, Spark & Hadoop · 2007–2022