Getting things done: fast or efficient?

People tend to perceive speed and efficiency as complements to one other when they think about getting things done (or, less glamorously, project management). Something I’ve come to realize is that not only are they often at odds, but that one of your jobs running a project is to identify which you are solving for, because they way you operate should shift materially based on the answer.

Assume you run a product team at a software company. Your primary goal is (or should be) shipping product. Of course you want to ship products fast, but you also want to be efficient. For my purposes, I’ll define efficiency as high output per input hour and speed as the minimum time, from start to finish, that it takes to get something done. Some people will immediately see the tension here – the third factor in this equation is how many things get done in a given quantity of time. This seems obvious, almost painfully so, but in my experience, people do not recognise the need to adjust their actions between them. Of course when a team needs to get a high priority project done fast, they recognise that it may mean shipping less features or products this month/quarter/year. But what they don’t recognize is that they need to fundamentally shift the way they work to meet their new priority – speed. 

Running projects

Consider the example of an efficient team in a large org. The product managers speak to customers and prioritise new products based on what they hear. Either their boss or some group of people decide what will get built. That same team, in conjunction with engineering leadership scope the work and prioritize it. There are 10 initiatives getting built this quarter. Now, for each initiative, the work is cleanly divided between product managers who define requirements, designers who design, and engineers who build. Throughout the process there is engagement with compliance (few large companies are able to avoid this). Perhaps a central technology team needs to be included because an internal library or component will need to be upgraded. Perhaps it involves cross-border payments so you need to talk to your tax department. Most companies have an Operations function that will need to be consulted to ensure that existing processes support the new feature/product. Now, it would be nice if this was all sequential, but it isn’t. You can do a reasonable job of ticking the compliance boxes before you start building, but inevitably something will come up that wasn’t scoped at the right level of detail and you’ll need to make a change. Maybe central tech don’t have capacity to start the work as early as you’d like, and an implementation detail means a slight change to the engineering spec along the way. That has to be signed off with compliance, who request a change that involves a small UI update. You get the point. 

The reality is that running any moderately sized project, say anything involving >5 people who are not completely aligned (i.e., different teams / competing priorities) is a puzzle to be solved. How early should you bring in compliance? Too early and you risk wasting their time because the output isn’t spec’d sufficiently well for them to sign off. Too late and you risk having to rebuild some portion of the project. If central tech won’t be ready until mid-way through the build, do you risk working around them and building everything you can, knowing that if they’re delayed, the engineering team will need to stop halfway through and move to something else, leaving your project half-complete until they free up? What if central tech deliver on time but not exactly to the spec, because of some infra dependency, or due to an indosyncrasy in the library they’re extending? Throw in some third parties you need to work with and the issue compounds.

getting anything non-trivially complex completed is just much harder than people tend to assume

The point here is that managing even a relatively small number of people is hard. Now consider 10 teams instead of 5, with each one having their own resourcing constraints and priorities. There are many tradeoffs to make every day. Notice though, that every one of those tradeoffs is about being efficient. You are solving to get the project done using the least resources. That is the primary constraint of most companies for most projects. You’ll often hear about avoiding “wasted” or “throwaway” work. The default mode of operating is efficiency, and it impacts every decision you make, from who to include in the planning meeting, who to share the requirements with, who to involve in decisions, etc. And these decisions will occur daily, because getting anything non-trivially complex completed is just much harder than people tend to assume. Companies are at almost all times solving a sort of constrained optimization: how fast can we ship our products/features while maintaining some minimum level of efficiency. It’s baked into every assumption we have about getting things done day-to-day that we operate efficiently, and this is usually the right decision! But if you need to get something done fast, you need to rethink how you work.

A different way to work

Assume you have a new high priority project that comes up – something that has to get done fast. In my exerience, what most people try to do is to brute force their existing processes. We’ll have that next meeting tomorrow rather than next week. People free up their schedules by pushing other priorities back so the cycle time can increase. Instead of planning around when the central tech team will be finished, you tell them you need it done by the end of next week, other priorities be damned. All of these are reasonable and necessary steps to go faster. But where they fail is in the implicit assumptions they bake in. Becasue our default mode is the operate efficiently (high output per input hour) we stick with this method. We try to include the right people in the meeting but have it sooner. We try to sequence the steps: define requirements, then sign off with compliance after making whatever changes are needed, then work to have it designed and built, etc. My primary contention is that if you want to do soemthing really fast, you need to throw out these assumptions. Ask yourself, if my goal was to do this in as little time as possible, irrespective of how many input hours it takes, what would you change? Some examples that come to my mind:

• Write a detailed overview of what needs to get done, why, and include as much background context as possible, then share it with everyone who will be involved, even tangentially, so that there is no lack of alignment of clarity

• Rather than sequencing things over a series of 30 minute meetings, put everyone in a single room and attempt to go end-to-end in 2 days rather than 2 weeks

• Schedule a daily call with everyone where you give an update on what got done yesterday, what is getting done today, and raise any blockers (including potential future blockers). Allow anyone to chime in with information

• When blockers are identified, put everyone who might need to provide input or be aware of what’s happening in a room or on the same call and stay on the call until you resolve the issue

Notice how these violate normal ‘efficient’ operations. If you run a project this way, people will have more context than they need, and that’s good. The risk here is losing time, not losing efficiency, so you want to behave in a way that prices those risks correctly. Most of what is discussed on the daily call won’t be directly relevant to most people on the call, but you’d be shocked how often something seemingly irrelevant for Team X happens to be useful information for their work.

A simple example to highlight the difference. If you have 10 teams and the project manager needs to spend 2 hours with each team before work can start, that will take 20 hours of meetings, which will inevitably be spread out over 1-2 weeks even if you’re trying to move quickly. The benefit in an efficient world is that each of the 10 teams only spends 2 hours on the project, and the project manager spends 20. Assume each team has 2 key people in the meetings, so the total person-hours spent here is 60 (20 for project manager + 40 for the 10 teams). Alternately, if you scheduled 2 days of straight meetings, for 10 hours per day, you would be ready to start work in 2 days rather than 5-10. The tradeoff is that you’ve spend 420 hours (21 people for 20 hours each). Also note that this is the most punitive assumption, as it implies there is nothing shared between those 10 meetings, which is clearly untrue. In fact, if even one quarter of the content needs to be shared between all teams, the total person hours for the fast method drops from 420 to 325 (1.5hrs per meeting * 10 meetings * 21 people + 30 minutes of shared context that was previously completed 10 times and can now be done once). 

In addition, these approaches are not like-for-like. In the latter, having covered everything relevant to the project with everyone, there is tremendously more shared context. One the hardest things about running big projects with lots of stakeholders is maintaining a shared understanding of the project state. Vast amounts of time are spent making sure that team A knows what team B is doing. Something this is obviously needed because team As work requires it. Sometimes though it will be useful without anyone realising. As a project manager you are stuck with a challenge: do you spend more time building shared context at the expense of using additional resources (people’s time), just in case it ends up leading to an unknown number of better decisions. Clearly this doesn’t always make sense but my claim is that for projects looking to move with speed, on the margin the answer is yes. 

Summary

Clearly these are very different approaches, and the latter – spending 7x more person-hours in exchange for faster progress and more shared context – is obviously not the right decision in many cases. But my point is this: it is sometimes the right decision. People rarely consider how different these two are, let alone when they should use one versus the other. 

When you are trying to do sometime as fast as possible, you should be thoughtful and deliberate about how your team works. Switching from a mindset of efficiency to one of speed implies significant changes to typical ways of working and come with additional benefits like additional shared context. More teams should seriously consider this approach.