Tracking Engineer Time To Allocate Engineering Teams Better

Problem

The number of requests on our engineering team was six or seven times our capacity. We were growing as fast as we could and brutally prioritizing, but we were upsetting everyone with our output.

We got into this situation because our company’s IPO was looming. As a long-time unicorn, our company’s founders (and many of us who worked there) were eager to be traded publicly. But this road meant executing on a number of company projects simultaneously -- growing revenue, improved controls ahead of the IPO, and dealing with a codebase that was designed at a lower level of operational scale.

At the same time, the team size was growing rapidly, as was the complexity of the codebase. We needed time to build a platform, which we didn’t have.

How do you balance these short-term requests with platform work? The company won’t push back its IPO to give you the time to build a better system. And, the more hasty changes you push in, the more likely you are to cause regressions in the live site, which takes time away from everything.

Actions Taken

First of all, you need to track where your time is going.

At the start, you could imagine our team’s time as a big fish-bowl full of money. Whenever someone asked for something, you just took some money out of the bowl, assigning an engineer to a project. And then the next project, you just reached in again until you ran out of time. And then we were stuck. We needed to be thoughtful about which projects we took on. And this started with measurement.

So to start, we just looked at the time spent each month across the following categories:

• Our own product roadmap -- i.e. improving our customers' lives and making the company more money Foundational work -- Work which doesn’t add any new features, but which makes the system more stable, easier to maintain, or reduces the cost of future projects
• Direct asks -- Someone else’s work. It’s a project the company really needs, but doesn’t advance one of your own goals (e.g. the sales team wants a sales portal. Does it need to be done? Probably. Do you need to do it? Probably not.)
• Unplanned work -- Anything you didn’t anticipate, such as a live-site issue
• Overhead -- Work about work, such as interviewing, sick time, the company review process, management overhead

If you pay attention to where your time is going, you can start to think about which investments are performing well, and which are underperforming.

Lessons learned

Looking at this just for a month, we found that 30% of our time was going to unplanned projects. This was totally nuts, and a clear place to make improvements.

If we could reduce unplanned work from 30% to 10%, we’d be able to move faster. But doing this would require an investment in foundational work, which is the one type of work that no one else was asking for. How do we push back and protect this time?

This is where the data collection came in super handy. We could show our internal stakeholders where our time was going, and explain that by reducing the amount of time dedicated to their projects now, we’d be in a much better spot to serve them 6 months from now. And that in the meantime, we could dedicate 2-3 engineers, say, to work on what was most important to them, but that was going to be it. So this invited them into the conversation more, and the meetings became less about “why can’t you do all of these things” and more about “which are the 2 most important things for us to get done, and what can we do about the rest?”

We ended up working with other divisions to bubble up decisions to the common leadership at the company. We empowered ourselves to make the decisions, in terms of how we can make a recommendation, and we could escalate if there was a conflict. What it really meant was that we could prevent other people from committing resources in other divisions if we couldn’t commit from our end. It all comes from tracking where our time spent was.