LinkedIn Posts — task2vec

Series arc: Phase 1 (posts 1–5) — the data findings · Phase 2 (posts 6–10) — the hidden risk · Phase 3 (posts 11–15) — the trajectory answer · Phase 4 (posts 16–20) — the offer
Rule: link goes in the first comment, not the post body — LinkedIn suppresses links in post text.

Post 1

The Staffing Shift

The 39%→5% finding + 15-year trend carousel

● Ready Document carousel

AI won't make your engineering team smaller.

It will make it harder to staff.

We analysed 69,000 Jira tickets and 11,000 Git commits from the Spring Framework — one of the world's most-used Java projects, 20 years of history.

In 2005, 39% of the work was routine enough to safely delegate to AI.

By 2020: 5%.

The easy problems are gone. What remains is architecture decisions, concurrency bugs, and cross-cutting design questions that need hard-won experience.

That creates two problems most engineering leaders haven't thought through:

1. You need more senior engineers, not fewer
2. You no longer know how to grow them — because the apprenticeship path (start with easy tickets, build up to hard ones) is quietly disappearing

Swipe to see the 15-year trend →

Next post: what does an expert-in-training actually look like in the ticket data?

#EngineeringLeadership #SoftwareEngineering #AI #Jira #DeveloperProductivity

📄 Attach: linkedin_carousel.html — print to PDF → upload as document

First comment

Full research + interactive explorer: task2vec.com/research
Commission a study on your own data: task2vec.com/commission

Post 2

AI didn't kill junior jobs. It killed the path to senior ones.

Career trajectory data — 72% of juniors grew into hard work

● Ready Document carousel

AI didn't kill junior jobs. It killed the path to senior ones.

We tracked 57 Spring Framework engineers who started as juniors — low on complex work, learning the codebase.

72% of them grew significantly into harder work over their careers.

Here's what the career arc looks like in the data:

→ Year 1:   17% complex tickets
→ Year 2:   32% (the biggest single jump)
→ Year 3–4: 38%
→ Year 10+: 44%

The first year is the on-ramp. What they worked on mattered.

Here's what surprises me: they didn't start with documentation fixes and dependency bumps.

Their early tickets were mostly Assist-tier — framework tooling enhancements, content negotiation issues, MongoDB mapping problems. Bounded, domain-specific work that required real understanding. Enough to learn. Not so hard they drowned.

By late career, those same engineers were handling JSF integration, class-loading issues, and cross-cutting architecture problems.

The on-ramp worked. But it depended on a supply of Assist-tier starter tickets.

That supply is now the first thing AI disrupts.

The "Assist" tier is exactly where AI is most useful — draft a solution, human reviews it. As teams adopt AI for this tier, junior engineers go from "I write the first draft and a senior reviews it" to "the AI writes the first draft and I review it." That's a different skill. Not obviously easier to develop.

The question isn't whether AI helps your senior engineers.

It's whether your junior engineers are still on a path to becoming senior ones.

(Next: how do you know the learning actually happened — and the signal that disappears when AI does the work)

#EngineeringLeadership #SoftwareEngineering #DeveloperGrowth #AI #Jira

📄 Attach: post2_carousel.html — print to PDF → upload as document

First comment

Full methodology: task2vec.com/research
Run the career arc analysis on your own data: task2vec.com/commission

Post 3

The real 10/20/70 rule!

11% growing · 20% coasting · 70% no effect — 378 engineers, 45k commits

● Ready Document carousel

The 70-20-10 rule is one of corporate L&D's most trusted frameworks.

70% of professional learning comes from on-the-job experience.
20% from colleagues.
10% from formal training.

We decided to look for the 70% in the data.

We tracked 378 engineers across three Apache projects — Camel, Spark, and Hadoop — using 45,000 linked Jira tickets and git commits, 15 years of engineering history.

Here's what the on-the-job experience actually produced:

→ 11% — growing: rising complexity, faster resolution, broader codebase impact over time
→ 20% — coasting: drifting toward simpler work, getting slower even as the tasks got easier
→ 70% — no measurable effect. Work experience neither built nor eroded their complexity ceiling.

The number rhymes with the rule. The meaning is inverted.

The 20% who are coasting are the most alarming part of this.

They're not underperforming in any obvious way. They close tickets. They ship. They look fine in every sprint review. But if you track the complexity of their work over years — the number of modules they touch, how close to the core codebase they operate — you see a slow drift toward simpler problems, and slower resolution of those simpler problems.

That's not specialisation. That's coasting in slow motion.

The 11% who are genuinely growing share one pattern: the work kept getting harder. More cross-cutting problems. More modules in play. More people consulted per ticket. The work itself was the curriculum.

The question nobody is asking: whose job is it to make sure that happens?

Swipe to see the full breakdown →

(Next: the signal is already in your data — and how companies can use it to design the learning environment instead of hoping it happens)

#EngineeringLeadership #LearningAndDevelopment #AI #SoftwareEngineering #Jira #DeveloperGrowth

📄 Attach: post3_carousel.html — print to PDF → upload as document

First comment

Full data and methodology: task2vec.com/research
Run the learning distribution analysis on your own data: task2vec.com/commission

Post 4

Three things you can do to help engineers grow — all readable from Jira.

What 21 statistical tests on 239 engineers actually found

● Ready Document carousel

We analysed 239 engineers across three Apache projects — 45,000 tickets, 15 years of data.

Here are three things that actually predict whether an engineer grows. All readable from Jira and git.

─────────────────────

1. Give them whole problems, not fragments.

Growing engineers handle sub-tasks at half the rate of their peers.
7.7% vs 13.9% of their workload. (p=0.02)

Sub-tasks are someone else's scope. Growth needs ownership of the full loop.

─────────────────────

2. Escalate the difficulty deliberately.

Growing engineers' resolution time rises +54 days over their career.
Non-growing engineers: +8 days. (p<0.001)

That gap isn't slowness — it's harder work. The signal is scope expanding, not performance declining.

─────────────────────

3. Create a range of difficulty, not just a high floor.

Hadoop tickets are 6-18× harder than Spark's.
Hadoop has zero significant growth predictors. Nothing.

The data can't prove causation. But the pattern is consistent:
in the two projects with wide complexity variation, growth is measurable.
In Hadoop, where almost every ticket is hard, no signal survives.

A uniformly hard environment may not be a growth environment.

─────────────────────

The signal is already in your data.
You just haven't been asked to look at it this way.

(Swipe for the evidence →)

#EngineeringLeadership #LearningAndDevelopment #SoftwareEngineering #DeveloperGrowth

📄 Attach: post4_carousel.html — print to PDF → upload as document

First comment

Full paper and methodology: task2vec.com/research
Run this analysis on your own data: task2vec.com/commission

Upcoming posts

Post 5

The specific ticket types that built expertise — and what's disappearing

Post 5

What healthy looks like — the 11% pattern and how to build more of it

Post 6

The expert bottleneck — when 70% of tickets need a senior engineer

LinkedIn Series