A 50% productivity gain for People Tech teams that didn't come from AI

The biggest productivity gain our People Tech team delivered in the early years at Bolt did not come from a new HRIS, ticketing solution or agent. It came from a one-page methodology that has been used by pretty much every software engineering team on earth for the last twenty years.

Where we started

When we first went live with Workday, our HRIS, we ran the way most People Tech teams run support i.e:

Support: Tickets came in, we worked through them, we triaged the urgent ones, and the rest moved at whatever pace they moved at, often with various blockers and dependencies. There was no real cadence. There was no real ceiling on what got pulled in during a given week. And, if I am being honest, the loudest stakeholders tended to get served fastest, regardless of whether their request was the most objectively important one, or if it meaningfully moved the needle on a big-picture objective for us, the broader People team or the company as a whole.

Projects: Separately we were (from day 1) deploying entirely new functionality and modules and these were definitely done in an accelerated way, but still using the same base methodology drilled into us across the Workday ecosystem for phase 1 and phase X deployments (Plan->Architect->Configure & Prototype->Test->Deploy). These were transformational projects, typically over a few weeks to perhaps 6 months. We would use primarily our team and resources and occasionally where we lacked specific internal expertise, augment with an external solution architect to guide the team at least through design and upskill our internal team to take forward.

That was the system. Pretty much modelling what we were taught in consulting - provide end-user support via ticketing, and use waterfall style deployment projects to roll out new functionality.

What we changed - The Sprint

We borrowed two core ideas from agile thinking. The first was Scrum, run in one-week sprints. The second was a basic Kanban board to make progress visible in real-time and quickly surface blockers.

How This Looked Practically

• A Workday sandbox tenant that refreshed weekly and was therefore well suited to 1-week sprints
• A product backlog with diverse inputs that we maintained and prioritised intentionally (people tech product management meetings bi-weekly or monthly to keep the backlog fluid and in line with business and People team priorities)
• A sprint planning meeting on Monday where the team pulled work from the backlog rather than having it entirely pushed onto them
• A short (e.g. 15-minute), focused standup every day to clear blockers
• A sprint review on Friday to close the loop on what had been shipped, what it was and how it made an impact. We added a short retro to this also to continue to refine and improve the methodology and encourage feedback giving.
• A sprint master that could potentially change each week would be responsible for facilitating which items were pulled from the backlog, the daily stand ups and the sprint review. In practice it typically skipped between the same senior team members but occasionally others would step in and it would be quite a nice development opportunity.

I was initially sceptical of the daily standup. Coming from a consulting background, my feeling was that another recurring meeting was the last thing the team needed. I wanted to be a killer of pointless calls and presenteeism rather than a time suck to the team. In practice though, it became one of the most valuable rituals we had. It was short, it was sharp, it was focused on removing things in the way of work rather than reporting details on the work itself, and it set the rhythm for the day in a largely remote team that did most of the work async. Anything that needed deeper discussion went into a separate conversation. The standup itself stayed disciplined.

I was also sceptical if every piece of work could fit into a single week. However, we gradually became better at splitting larger pieces of work into 1 week increments that enabled you to deliver parts of the work at a time, whether directly to production or simply to stagger the pre-work.

The Result

The biggest difference was speed. Previously we were always talking in weeks and months before we could see what we were building in production. This gave us an engine to ship smaller items weekly. We immediately got great feedback on how quickly we could move on items with a very high impact across the org and when we were shipping increments of something larger, we now had a feedback loop to help with the remaining components. In short - we stopped acting like a People Tech team and started acting more like a product team.

We still had the large projects but we would largely break them down into 1 week components. We still ran support but any significant fix or development originating from a support requested would be routed into the product backlog and prioritised alongside other requests.

Within two months of running this model, the team's tangible output went up ~50%. I like to use the phrase "stop starting, start finishing." Rather than being lost in the noise and working towards outputs in the distant future, what we were shipping was creating small amounts of value every week and could be easily measurable. We did not change the team. We did not buy new tooling. We tweaked the operating model, and the throughput followed.

The bit I find most interesting about that number, looking back, is how unglamorous the ingredients were. There was no agentic solution. No expensive new Jira alternative. No super complicated new framework. We took a method that has been freely available for two decades and applied it to a function where, for whatever reason, not common practice in all orgs.

Why I Think It Worked

The biggest reason is that we created an engine to create and compound incremental improvements. It's not like we conjured up a bunch of extra capacity. We just broke down our big ticket items into bitesize one week chunks and started shipping. It turns out that over time, this seriously compounds. Part of this was also the tangible element, the team was working hard but we weren't able to easily quantify the outputs.

Three other things to note.

1. Prioritisation moved from "whoever shouted loudest" to "whatever is most important," because everyone could see the same backlog. We could tag requests if they were related to, or contributed to, larger objectives and KPIs for us, the People team or the company as a whole and show that we were working towards something rather than shipping a bunch of unconnected edge cases. We could also organise smaller pieces of work into larger work packages to be tackled incrementally in a sensible sequence so as not to duplicate work.
2. The team had genuine ownership of what they pulled into the sprint, which is a different psychological contract from being assigned tickets. We had go-to experts for different areas but gave some freedom to pull random tickets too, and also to work on passion projects for fun and development.
3. The standup created a forcing function for blockers, which in HR Tech support tend to come from the rest of or outside the organisation: a missing answer from finance, a pending decision from a Country Manager, a vendor that committed to fix a bug. Surfacing those daily is worth more than any individual person's time savings on a 15 minute call. We were able to quickly surface any blockers and escalate as needed.

The Takeaway

I am not romanticising Scrum. It is a tool, and like any tool it can be over-applied or applied badly (thoughts on our ultra basic methodology not welcome from Software Engineers! 😜).

But in a People function in a high-growth environment, the friction is almost always around capacity and focus (or lack thereof). Fixing the flow is often the highest-leverage move available with 0 cost attached. I would highly recommend trying out basic versions of this if you are not already doing so! Feel free to ping me for advice on getting started.

‍