The Work Around the Work
Have you ever ended a work day feeling like you were so busy, but that you got very little actual work done?
That’s because your day was full of “the work around the work.” It’s the administration, coordination, changes, and surprises that appear around every project.
This “work around the work” is costly, and your customers don’t want to pay you for it.
In today’s newsletter I’ll define the framework, show why “the work around the work” is costly, then give examples from my new solo operator life, then close with the implications for you as a leader.
What is the work around the work?
You’re probably pretty clear on what constitutes “the work” for your profession.
If you’re an bookkeeper, the work may be categorizing and reconciling transactions.
If you’re in communications, it may be writing a press release.
If you’re a data scientist, it may be writing some Python (or R!) code.
You might have a vague sense of all the other stuff you might do in a given week, but probably lack a taxonomy for it, and also very likely do not have a clear sense of the ratio between “the work” and “the work around the work.”
A guy named Dave Stewart has done the best job I’ve seen at representing this idea visually, and I’ll reuse his visuals for you here. He generated this in doing a post-mortem on a project that went way over budget, and he wanted to figure out why. See his article here.
He describes many of the other things you have to do outside of the work: ▪︎Admin - Meetings and reviews.
▪︎Acquisition - Research, scoping, pitching.
▪︎Preparation - Configuration and setup.
▪︎Iteration - Debugging, refactoring, iteration.
▪︎Changes - Adjustments, scope creep.
▪︎Problems - Contingencies, disasters, surprises.
This is a really informative framework, but why does it matter? Why should I care about “the work around the work”?
Issue #1 - Customers Don’t want to Pay For It
Your customer only wants to pay for the work. The rest is inefficiency. If your competitors can do the same work with less inefficiency, they’ll likely move their business over there.
To see the cost, let’s look at an illustrative example for a large department inside a big public company.
Imagine a 100+ person team that has to prioritize their work.
To prioritize their complex set of work, they’ll need a common leader to look across the options and make decisions about what’s in and what’s out. This leader doesn’t know all these items intricately, so the project teams prepare material to educate the leadership team so that they can make educated decisions about priority.
To be fair, they need to establish a method for the prioritization. What factors should they consider? How does each project rank against these factors?
If the 100 people inside the team take up to two hours each to write out material about their project, that’s $60K (using tech company salaries). And the two hour estimate is conservative!
On top of that, there are 15 people who meet across four days for 30 minutes each to establish a prioritization method - and generate another $10K in cost.
The leadership team has to read the material, then meet to run through the prioritization, and send out some follow ups for the team - generating another $30K in cost.
That’s $100K spent, and all you have is a prioritized list of what to do. No customer value has been generated.
Can you imagine sending a customer a $100K invoice for a prioritized list that took you a month to create? They wouldn’t pay for that.
Issue #2 - Employee’s Disengage
Put yourself in the shoes of someone at the front lines in the example above. They know what needs to be done, and they’re ready to go do it.
You hired smart people, and they’re ready to crack their knuckles and type away on the keyboard. Can they?
No. Not yet.
They need to convince someone a few levels up the chain of command that this is a good idea. They need to be on call in case a follow up comes through during the prioritization process. They need to wait for the go ahead.
If, at the end of the waiting, they get a green light, it’s annoying because it took a month and 5-10+ hours of additional meetings and work to get to the same conclusion they had at the beginning.
And if they get a red light, it’s annoying because they could have used that same 10+ hours of “work around the work” to just do “the work”!
All that rigamarole and corporate theater feels like such a waste - and they’re not wrong.
It can be very frustrating to work in an environment that has a large amount of “work around the work”, and it causes employees to disengage.
If you’ve worked in a corporate environment for any length of time, you’re familiar with all the meetings, the debates, the pitching, the back and forth. It may be annoying, but it all probably just get lumped into a feeling of “work”.
But now that I’m working as a solo operator, the difference between “the work” and “the work around the work” is stark, and it’s hugely important to my own productivity and profitability.
I’ll show you how this shows up for me in fixed bid and retainer-based work.
Example #1 - Fixed Bid Work
I’ve done a few fixed bid projects, which means the client and I establish a total price for the work to be done in advance. This can be great for me as I’m incentivized to work faster, but it can be really dangerous if I get my estimates wrong!
Armed with this framework, I make estimates for all the non-work items. I think through customer meetings, QA and support, project management, status updates, and all the other little stuff.
In doing so, I can whittle down cost with a client.
If I set a price, and let them know that I can reduce it by $1000 if they commit to fewer coordination meetings, then the customer is happy because of the lower cost and higher speed, and I’m happy because I like doing “the work” more than “the work around the work”.
Curious how much time is “the work”? For me it often starts at around 20% of a project. That means “the work around the work” can be 4x as high as “the work”!
Again, by being transparent and efficient, I can reduce the non-work costs and move “the work” up to 30-40% of a project or more. It improves speed, and that increased work density is really valuable to a client.
Example #2 - Fractional COO Speed
The practical implications of this framework are even relevant in a retainer-based fractional COO engagement. Here, I’m paid every month for my work, just like when I was an employee, but the expectation of value delivery is high.
As such, my work density needs to be high! I want the client to feel like staying with me is a no-brainer.
That means I work really hard to minimize things outside of “the work” as best I can.
For example, we’re introducing new software to the team. In my old corporate world there would have been a ton of research. A lot of debate. Numerous meetings. I’d have written a position document to clarify the problem, articulate multiple options, think through risks and their mitigations - and so on (so expensive!).
There’s no time for that here.
If I only have five hours to dedicate to a client each week, I can’t fill all of that up with research and debate. That’s not solving the problem I was hired to solve! I won’t be adding value, and it’ll be hard for them to justify paying my invoice next month.
Instead, I have to do a different risk and cost/benefit analysis. I have to move everything through a decision quickly (remember our recent newsletter on decision rights?). I document what we decided and why. I move fast to get the software purchased and installed so we can get into change management - which is finally when value starts to be realized.
One last point here is that savvy clients already know this and are thinking about it before hiring me! I recently wrote a proposal for a process re-architecture, including new software, and mentioned that one of the deliverables was going to be a process map and assessment. The client expressed concern that it would be overkill. I had to assure them that I understood, and would only do as much as needed to move us forward.
These clients may not know about this framework, but they do know that what they’re paying for is “the work” that drives an outcome for them.
Knowing this framework, there are two big implications for you as a leader:
Implication #1 - Cut the Fat
I recently listened to Cal Newport’s podcast, and he mentioned studies of four day work weeks where they had no loss in productivity versus a five day week.
How could that be? How can you work 20% less and not produce less?
Easy! Because they cut the fat and reduced “the work around the work.” Like me going from the corporate world to the independent world, incentives changed, and productivity increased.
As a systems architect, you owe it to your team and your customers to minimize “the work around the work”. Don’t assume it needs to be there, and don’t assume it’s serving a strong purpose.
As an example modification, can you set a decision threshold based on time?
If “the work” is less than x hours, the team is allowed to proceed. They still need to align with other teams if needed, for example, but they don’t have to submit their idea for formal review. They don’t have to write pitch decks. They can just…work.
Find other creative ideas to improve your team’s work density.
Implication #2 - Make Better Estimates
Just like I did with my fixed bid project example, you can use this framework to make better estimates of work effort.
Many projects are woefully under-estimated. This is likely because they quote something near “the work” and don’t give enough weight to “the work around the work.”
If you want a rule of thumb, assume “the work” is only 20% of the overall effort. In my small examples, and in author Dave Stewart’s retro, that’s the estimate we both noticed.
If you want to get more precise, you can start to estimate each type of “work around the work.” How much admin? How much support? How much scope creep to assume?
Whatever you do, recognize that “the work” is not the total effort, and make your estimates more accurate as a result.
Call to Action
Start small this week, and just calculate the cost of a meeting. If you’ve got a meeting with three or more people this week, take the people, times the hours, times an estimate of hourly rate, to get the total meeting cost.
Would your customer pay you for that?
If your CEO got a receipt after the meeting, would they be happy with what was produced?
If you want to go further, begin to look at your organizational architecture with this framework in mind. Categorize efforts into the different buckets. From there, what could you begin to reduce? How could you set up your policies or procedures in a different way to increase your work density?
This is one of those really simple frameworks that can have a large impact on your business if you do the work.
If you’ve got any questions about this, just let me know: kevin@catalyst.group18.co.
Kevin