I originally published this as an article on LinkedIn. I thought Iâd post it here too.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F94ea375c-ffff-46bb-98f3-26cf770bfc6d.heic)
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:
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.
Review skills database. Weâd review the skills folks have and the skills they want to grow.
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).
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.
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.
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.