Steak and Salami

Ever had the feeling you're working constantly and getting nowhere? Specifically, the one where you've got a dozen things to do and none of them are getting done? Did you find that the more you worked, the worse the problem seemed to get?

This is something endemic to the modern, hyper-connected workplace. It's down to the type of work it encourages. To illustrate, I'm going to categorise two approaches to work:

• Salami is work from multiple workstreams and priorities, all sliced into small parts that can be done now. Small, easy to fit between meetings and other commitments, and don't require any preparation.
• Steak is work from a single workstream or priority, considered as a single large piece. Its defining characteristics are that it needs preparation, it needs dedicated concentration time to get it right, and you treat it as one decently sized chunk.

This is related to the rocks/pebbles/sand idea, except somewhat less kind to the environment. But there is a difference - while steak is often analogous to the rocks in that model, there's the added connotation that it has prerequisites. You probably have a tray of salami right there in the fridge. All you need to do is lift the lid and pull out the next slice. If you wanted a steak, you'd have to go out and buy one. Season it. Preheat the pan. Cook it. Prepare some sides...

Herein lies the workplace problem. I have 20 minutes until the next meeting. I need some information, but the team who can provide it are busy. I'm working late at night and the people I need to collaborate with are offline. Am I going to go for the steak, or the salami?

Trouble is, I can eat all the salami I like and I won't have had a satisfying meal. Likewise, I can send all the e-mails I want, move all the easy-win tickets I can and reply to 1,000 Slack messages without ever getting anything done, just rearranging some items on a wheel of busywork and rotating it to the next person.

What I need is steak. And steak is really hard to get to in modern work environments:

• We don't have simple problems you can work on alone or "throw at tech" (or indeed any other team). Work requires multiple people from different functions to get together to quantify and solve problems. Unless you are very lucky with organisational design these will not always be all together on a single team.
• The definition of "what" is difficult, and will change anyway once you build your first prototype and figure out all the ways in which your first idea of "what" was wrong.
• It's rare to build something truly self-contained, you will have dependencies on third parties and external systems that will throw up impediments and blockages.
• Even if you have your cross-functional team, and you understand what you're building, and you've resolved all the dependencies... you still need to carve out some "leave us alone so we can concentrate" time in an environment where you have at least three different communication tools and hundreds of potential distractions.

Most people cope by turning it all into salami, small tasks that represent such tiny pieces of progress they may as well not exist: Set up a meeting with customer services to find out what they need. Review the API documentation. Extend the system to support multiple providers. Chase customer services who seem to be busy for some reason. E-mail support about the unexpected 401 response from the API. Rewrite our multiple provider support approach as we've learnt it won't work that way. Find out customer services only wanted a simple tyre swing.

Of course, this is slow and has long wait cycles. So once you have one project's worth of salami, you start thinking, "well, I guess I should work on my other project while I'm waiting". Set up a meeting with sales. Quantify the customer demand. Design some screens. Review the screens. Realise this all interacts with the work you're doing for customer services. "I guess I should start on the salami from the third project"...

It feels like this ought to work just like multitasking; everything will eventually get done, just slowly with a lot of task switching cost. In reality, it's more like using my oldest laptop when five background updates all start competing over the same slow hard disk - no meaningful progress at all. Except instead of locked processes being restarted, you get the real-world equivalent of a timeout: those screens you designed for Project 2 are no longer valid because you started the consultation for Project 5, the usability refresh. You can't merge the new payments provider because you added a new statement method in the meantime. You're doing so many context switches half the work is quantifying the same thing over and over where nobody can remember what's going on.

Rather than breaking big things into tasks to understand them, we've started with the tasks as our unit of work in the hope they will somehow resolve into something big. This doesn't happen. You can't mash together salami and claim you've got a steak.

The art of working on steak is setting things up so you're not doing all this task chopping. You start with the big thing as your unit of work. Tasks are a by-product, not the input. What you need is to be able to work on one thing in a single contiguous chunk, without the inbuilt need to pause for dependencies:

• Have enough to start: this could be a whole article in itself but this is a brief which makes sense, rules clearly stated and some kind of idea of what the output is.
• Get the obvious prerequisites in place. This is hard, as you need to go from salami mode ("can we try guessing at things until we have the API documentation?") where getting the important prerequisite is just another task, to steak mode ("we shouldn't start this until we have API documentation to work from.") where you understand just how important and urgent that prerequisite is.
• Know who needs to work together on something and make sure they all have time to do so. Also who needs to be available. An example of something effective teams do in steak mode is ask third parties for ways to get instant help with dependencies rather than rely on weekly catchups or slow e-mails.
• A goal that is clear, satisfying and coherent. "When we have finished, we will be able to automatically send new order notifications to this partner". It has to expressed as a key increment. "Complete 35 tickets" is not a goal, it's just more salami.
• Expectations on what the team is doing and - more importantly - not doing. I find the easiest way is to set expectations on when "this" and "other things" will happen: "we will be working on review notifications Monday to Wednesday, the design reviews and any planning meetings for Project Topaz will need to be Thursday or Friday".

Old-school scrum practitioners will find a lot of familiar tenets there, and I think the core idea of getting everyone who needs to collaborate together to work on one coherent thing is pretty similar. (Ironic therefore that much of the current trend to salami-style working has come from fumbling attempts to adopt "agile", mostly by treating it as a week-packing approach rather than a feedback-handling approach)

The reason for doing this? It's effective. A good team running in large-chunk mode can finish something in the time most salami-slice teams spend on endless meetings to re-contextualise. They need to use disciplines like Toyota-style inspection and resolution of problems on the spot rather than letting them drag on as an endless source of yet more salami for the pile. Most importantly, you find yourself finishing things during the working day rather than sitting up at 10pm still starting yet more tiny slices of work that never lead to anything satisfyingly done.