My beef 🥩 with resource allocations

Let's get better at staffing projects, y'all.

I originally published this as an article on LinkedIn. I thought I’d post it here too.

Falling image: @seb_agresti

Let me let you in on a secret. I haven't had many great experiences with resource allocations.

(I've had a few good experiences that I'll share too.)

Resource allocations is matching people to projects. “Jane is on this project at 50%. Charles is on this project at 30%.” Some firms call it staffing.

You are a pie that can be cut and split into different pieces, each piece being fed to a hungry project that always wants more pie. Bleh.

All organizations allocate resources (which really means you work on X for Y hours/week). This makes things predictable. We know who’s doing what. We know when so-and-so is available.

I haven’t had the best experiences with resource allocation. You might relate. Here are six resource allocation pains I’ve experienced.

🤷🏽♂️ Junior employees are promised support and training, but get put on difficult projects with no support.

When the business has more work than people available to do the work, we staff the folks who are available, rather than the folks best for the project. “Figure it out!” the manager says. “We don’t have time for learning and development.”

If the project fails, it’s seen as the junior’s fault (rather than the manager’s). “They’re just not a good fit.”

Consider that it might be the organization’s fault.

😰 Always being anxious about missing utilization targets

“Utilization” is a metric that both tech companies and client service businesses use. Firms and agencies make money from people on projects, especially if they bill hourly, so they need employees’ hours always on client work. Tech companies use utilization targets to keep their developers busy, because if their devs aren’t on work, “we’re bleeding money.” (Yes, I’ve heard a leader literally say that before.)

This leads to anxiety. Developers are anxious when they aren’t put on a project, because if they aren’t utilized, they may get laid off.  (Although some of your devs want to get laid off. Potential severance is the new golden handcuff.)

Utilization is a means to help make good decisions on how to remain profitable. But when it becomes the metric to control for, it’s just another case study of Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

😮💨 No breaks

“Done with your project? Great. I have a new one for you. Oh, you had a vacation planned after your project wrapped? Well, we just sold to a large client. I need you to fit in time for this enterprise feature, even though you’re maxed out.”

Justin Jackson writes that good businesses have margin. Good resource allocations also have margin.

🏋🏼 Constantly tinkering with allocations because of new work

I’ve been a part of conversations where allocations needed to be updated daily. If we need to readjust daily, can we address the root cause here? Instead of incessantly keeping our table updated?

I’ve also seen allocations get thrown out the window because of a big sale. “We need bodies on this project ASAP!” Abandon ship on current work. We got a Big One. (But… did you ask for a later start date?)

🫨 Too much context switching

“Angeli shouldn’t be working more than 40 hours a week! She’s 10% on Feature A, 15% on Launch Project B, 30% on the CEO’s project, 25% on Feature D, and 20% on mentoring other developers. How could she possibly be overworked?”

The more projects you’re on, the more time you spend context switching. This is why people hate having tons of meetings on their calendars.

Good video by John Cutler on this here.

🪤 Time allocated ≠ time actually spent

Have you ever been staffed 100% on a project that only required 30% of your time? I have. It’s great.

Have you ever been staffed 30% on a project that actually needed 100% of your time? I have. It sucks. Now you have to ask for more allocation on a project while being worried about being seen as incompetent.

🌱 Better ways to allocate

I don’t believe in there being the best way to do anything. But I do believe there are better ways to go about resource allocation. Here are thirteen options.

To folks who allocate people to projects (product managers, design operations, leaders):

🌳 Root your allocations in strategy

At garden3D, I and a few coworkers advocated for engineers to be allocated to the discovery phase of a project. Engineers usually weren’t a part of discovery, so that they could be 100% allocated toward engineering work. But we found that our projects could’ve been better scoped. Engineers faced tight timelines. And some of the features agreed on with strategy, design, and the client just weren’t feasible. Our engineers had to constantly advocate for more time to launch sometimes but had very little negotiating power since the launch date was the launch date, which was decided without them in the discovery phase.

So moving forward, we started allocating a tech lead in our discovery work. That way an engineer would help shape the feature requirements and timelines alongside the PM. PMs were able to learn whether a certain feature a client liked wasn’t exactly feasible, and both the tech lead and PM would collaborate to think of alternative ideas that would be more feasible yet still satisfy the client’s goals behind the desired feature.

This ended up being so great. Tech leads allocated in discovery allowed for career growth. Many engineers wanted to grow into being a tech lead. Our projects were a lot more realistic; fewer developers had to resent a tight timeline, more starting together, and more of a spirit of cross-functional collaboration. We always felt tempted to revert to no developers on a discovery project. But because this was a strategic goal — every discovery project having 20-40% of a tech lead’stime — we never lost sight of it. Root your allocation in strategy.

☁️ Limit work in progress

The more work in progress, the more time people need to context shift. The less work in progress, the more time people have to focus and go deep on the challenge. And guess what? Less WIP ≠ less work getting done. It means more work getting done at a faster rate.

For every individual, limit the work in progress. I suggest starting with no more than two projects or features at a time. Yes, two. Don’t negotiate. Use two as your constraint and witness your teams getting more done. More on WIP limits here.

🎲 Double your estimates

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Everything takes longer than you think. Your initial estimate isn’t enough time. Double your initial estimates. Give your team time to do a good job. Again, good teams build margin.

🧘🏽 Add context switching time

Say there are four projects: projects A, B, C, and D. Angelo is an engineer who can be allocated to any of them.

If Angelo's just on project A, their allocation is 100%.

If Angelo is on projects A and B, give them 10% of their allocation for context switching. So that

• 45% of their allocation is on A

• 45% of their allocation is on B

• 10% is a buffer for switching between A and B

If Angelo is on projects A, B, and C, give them 25% of their allocation for context switching. So that:

• 25% of their time is on A

• 25% of their time is on B

• 25% of their time is on C

If Angelo is on projects A, B, C, and D, run it back. Don’t staff someone on four projects. Again, we limit WIP.

📆 Build utilization rates based on a 4-day workweek

I’m lucky that my last company offered 4 days/week. I was able to prioritize the most important things, get the same amount of work done, plan my weeks more efficiently, and ultimately make space for things important to me outside of work.

I’m not alone. Hundreds of other companies have adopted the four-day workweek.

As a leader, you probably want your company to offer a four-day workweek. But you’re concerned about the company making less money, not hitting deadlines, not meeting velocity goals, etc. If that’s you, test out a 4-day workweek on oneteam or one project. Treat it as an experiment. Will this team ship at the same rate with one less day/week? Treat this team as a model for whether this could work or not at your company. Make space for this to be messy.

🫱🏽🫲🏾 Consider a two-way process

I used to be a part of a two-sided marketplace at The Ready. Tabea Soriano speaks to this:

Instead of assigning projects in a sequential, first-come-first-serve basis, we employ a marketplace model. This model empowers individuals to select projects they prefer, effectively decentralizing the staffing process. —Tabea Soriano, Head of Transformation at The Ready

When a project was just about to start, consultants would 🙋🏽 raise their hands 🙋🏽 if they were interested. Usually, projects were staffed by two consultants. I handraised on projects I wanted to be staffed on. I also knew who else was available and interested. If the main salesperson closing the project thought I’d be a good fit, they’d choose me.

💪🏽 Build in support systems for junior employees

Back in 2018, I was able to be a third consultant on a client, when our default model was two consultants per client. The Ready understood that this would help develop me as a consultant earlier in their career. And! The project got a third person, meaning we could divvy the work more and have a larger impact on our client. Everyone benefitted from a three-person team: I got to grow, my colleagues had an extra teammate who could help, and our client got more support.

When I became a studio lead at garden3D in 2021, I’d assign our junior product designers to existing projects that already had designers on the project. The point wasn’t to “make more money” on these projects by adding another designer. It was so that designers could learn alongside more experienced designers. Those experienced designers knew that a part of their job was to mentor, so they had a new avenue to grow too.

🧑🏽🍳 Create a skills database

Have your team list out the a) skills they bring and b) the skills they want to grow. Then ask your team to list out skills their teammates bring (oftentimes people are too humble about listing their own awesome skills!). Keep this skills database in your allocations database, whether that’s on Notion or some allocation software.

🗳️ Staff projects democratically

When I was a studio lead and had a bunch of new projects starting soon, I facilitated a voting process. Everyone gets to vote on who gets staffed on what. How we did it:

1. Project context. We shared context on each project and held space for clarifying questions. Sometimes sales would be on the call to share context, too.

2. Review skills database. We’d review the skills folks have and the skills they want to grow.

3. Silent voting. Everyone wrote down the team member who they believed should staff the project. For every project. People could vote for themselves (we encouraged it).

4. Share votes. We all shared our votes in a round and explained our rationale. Some people would vote on a certainperson based on their experiences, others would vote based on their interest in the client’s industry, and others would vote because they think it’d be a great way for that person to grow the skill they want to grow.

5. Consent. People who were most voted for a project were asked: do you consent? Or not?  If they didn’t consent to the project, the second-highest-voted person had a chance to consent.

6. Final round. We’d do a final round to look at who consented to what. We held space for anyone to make any final suggestions. If there was someone who wanted to be considered for a specific project so that they could get experience in that type of work, we heard them out.

It does require a high level of psychological safety and knowledge of each other’s skills. This process always led to some great conversations. We adapted this process from Samantha Slade's article here.

🙅🏽♂️ Try no allocations for a month

What if you didn’t set any allocations a month?! Omg!!! Anarchy!

Consider this question: what can we learn if we pause our allocation practice for a month? How would we spend our time? What will we do with the time we get back when we don’t allocate? You’d have to pick the right month to do this and properly learn from it, maybe don’t choose the month before an important launch. But give it a go.

👂🏽 Ask your team members to challenge your allocations

Invite disagreement. “This is my best guess, but it isn’t absolute truth. I’d love it if you could tell me how this could be better as you progress your work.”

Make it clear to them that they’re always welcome to ask for more (or less) team members on the project. And always follow up. Were the initial allocations on point? Or do we need to adjust them?

🌱🌱🌱

To folks who get allocated (engineers, designers, ICs, staff):

🗣️ Be transparent when you need more allocation time

You intend to do your best job. But it turns out 30% on this project isn’t allowing you to do your best job. That’s all good. Communicate that to your PM/design lead/tech lead/direct manager.

What you want to hear:

• “Thank you for sharing. What can I do to support you? What do you need?”

• “Let’s extend our deadline.”

• “If you were me, how much allocation would you give yourself?

If your manager responds with:

• “You’re too slow”

• “I should’ve staffed someone more senior”

• “You need to work longer to get this done faster”

Find someone else who would better understand your perspective. (And maybe eventually, find a different manager.)

💆🏽 Build margin in your day

No one works eight straight hours a day, five days a week. People aren’t meant to sit in front of their computers eight hours a day. We take walks. We make lunch. We walk our dog. We go to the gym. We pee. Build margin in your day.

Also, if you get the job done say two hours faster than allocated, don’t spend an extra two hours doing busy work. Take a break. No one will mind. (And if you have great managers, they’ll encourage breaks.)

🌱🌱🌱

🤖 Traditional resource allocation is based on the premise that humans are machines

Your time is the resource the company uses. When time isn’t your only resource at their disposal.

But the problem is in the name itself. “Resource” allocation. We are resources to a company, not humans.

Much of resource allocation is based on the fact that humans are resources to a company. Which, of course, Tim, that’snot news. But instead of companies saying they want to create more humane workplaces and help people feel more authentic at work, we still plan in an inhumane, robotic, assembly-line-til-AI-takes-our-job type of way.

What would a humane way of channeling our time, headspace, and energy toward organizational goals look like?

What other resources do we have at our disposal besides people?

What aspects of resource allocation must we accept? And where could we be more humane?

🌱🌱🌱

Consider the above as a menu of options to resource allocate in a better way.

For managers, PMs, tech leads, and directors:

• 🌳 Root your allocations in strategy

• ☁️ Limit work in progress

• 🎲 Double your estimates

• 🧘🏽 Add context switching time

• 📆 Build utilization rates around a 4-day workweek (not a 5-day workweek)

• ↔️ Consider a two-sided marketplace

• 💪🏽 Build in support systems for junior employees

• 🧑🏽🍳 Create a skills database

• 🗳️ Staff projects democratically

• 🙅🏽♂️ Try no allocations for two weeks

• 👂🏽 Ask your team members to challenge your allocations

For folks who receive assignments:

• 🗣️ Be transparent when you need more allocation time

• 💆🏽 Build margin in your day

What have you tried that’s worked for you? Leave it as a comment.

If you’d like help trying any of these out, send me an email. I’d be happy to help.