Your team is wrong about what it can get done
“I’m not very interested in individual performance; I’m only interested in team performance. I can double a team’s productivity in a month, but an individual? That could take a year. And a whole bunch of individuals? A whole division? A whole company? That could take forever.” – Jeff Sutherland, Scrum
The unit of performance in organizations isn’t individuals; it’s teams.
A well-coordinated group of 8 people can get more done than 8 individuals working alone. This should be obvious, because it’s the entire premise of working in organizations. And yet — the way companies set goals (e.g. individual, department, or channel-by-channel targets), and manage performance (annual individual performance reviews) often doesn’t match the way work gets done.
But this isn’t an essay about how organizations manage performance. It’s about what happens when you try to change your approach to increasing the performance of your team.
I’m hoping you come away with the belief that your team can do more than you (or they) expect, if you manage them to their potential.
What would it look like to 5x output in 6 weeks? Here’s an example.
At my last job, we were trying to build a library of search-optimized templates (because people love templates) that could be repurposed across all of our marketing channels. There were a handful of these “free tools” already in existence, but not enough to bundle them together into an offer.
What I said to the team — “by the first week of June, we should be creating 5 free tools per week.”
How the team reacted — “umm (swallows nervously) ok.”
There’s a version of this advice that is shitty and stressful management. More on that later. For right now, here were some things I noticed about the free tools program:
This was a team of 8 people with all of the skills to execute each step of the program
It doesn’t actually take that long to make an individual free tool, but there are other steps in the process that slowed things down (design, SEO, getting it on the website, getting forms working etc.).
Some of the limiting steps could be solved by better coordination within my team, but some required more resources from other teams.
The first week of June was 6 weeks away, meaning there were 6 weeks of ramp time before we needed to be at the production goal of 5 per week
Setting a big production goal let me go to the rest of the marketing team and carve out more time for my team — if we could reliably get to 5 per week by the first week of June, we could deflect a lot of requests (IMO, time wasters) from the rest of the organization in defense of that objective.
Spoiler: the team crushed this goal. They almost completely self organized to get it done, and I was very clear from the beginning that I wouldn’t be making process decisions for them — they needed to coordinate themselves.
A sample 6-week schedule:
Week 1. One free tool and time building up the list of tools to work on in future weeks.
Week 2. Two free tools and working on the handoffs between SEO/landing page copy.
Week 3. Three free tools, continuing to work out kinks in getting stuff up on the site.
Week 4. Five free tools.
Oops, that’s only 4 weeks, because the team hit the number early.
With a big goal, it was much easier to get the work we needed from design and our email person. The team was also forced to create an organic process for how they worked together as a specific group of people, rather than one that relied on the manager to directly tell everyone what to do.
In this instance, the context of the org and the team meant that we were working towards a production target vs a result or a launch or something similar — but the key is that as the manager, you have more overarching ability to understand what your team is capable of if they work together.
When you call on your team to do big work, they will doubt themselves (and that’s ok)
Most times I’ve brought a big project to a team, I’ve gotten an “um, gulp” reaction.
And that’s because individual members of a team tend (at first) to think of themselves as individuals who get individual work done.
Once you manage more than a couple people, you’ll start to see these opportunities to execute bigger, cooler, more ambitious, more effective work, but your team won’t see it themselves (or will get nervous/talk themselves out of it). For new managers, especially managers who are used to managing production vs. managing outcomes, this is a skill to build as well.
Why do teams underestimate themselves when faced with a big project?
The scope of a big project is big! Individuals tend to think in terms of the amount of work they can individually get done, so they see the scope of a big project and think “whoa, that’s way more than I could do.” This is a natural mental habit, but it’s also the point of a big team project!
People add “nice-to-haves” to scope in their heads. A big project is going to have a lot of moving parts, but there are probably 1-4 things that absolutely need to go right for the project to be successful. It follows that you should spend most of your project time working on those things — but individuals often drift away from this in favor of tasks they like, personally value, or know well.
People tend not to drop their other tasks. If your team has a major objective, ask someone what they did each hour of a day (just once for illustrative purposes, not as a micromanager). You’ll find that people are holding on to smaller, unrelated, lower-value tasks that they’ve done for a while or like or care about, and that this is why they start to feel overworked.
Efficiencies will happen over time, but they’re hard to see up front. If you execute something repeatedly or work together as a team more often, you’re going to get better at it. You’ll be more resilient, find sticking points faster, identify and avoid miscommunications, get resources you need from other teams faster — everything just starts to work better. It’s like learning to read: at first you had to learn letters and sound out words, but now you can understand this text without thinking much about the words at all.
Big work is less clear and less certain, so it feels bigger than it is. If you’re executing a big project, you probably haven’t ever done something like this before. Your team is going to be apprehensive of the work because it’s less certain (prospect theory, etc. etc.), but that doesn’t actually mean the work is harder or more work.
People on your team get stressed out by big work, but that’s not a reason to not do big work — it’s information that you can bring to your approach to managing those people and setting them at ease.
Of course, as I said earlier there’s a shitty, monkey’s paw version of this advice. If you’ve worked in high growth businesses for any amount of time, you’ve encountered managers or executives who are pushing for impossible deadlines and unachievable targets. Their teams are overworked and stressed because their noses are to the grindstone and they have very little self-determination.
For best results, this management idea is applied with loose scope and generous time frames. Loose scope meaning that there are just a few crucial elements identified that make the project the project (and the team figures out how they want to do the rest). Generous time meaning that, once scope is explained and some of the divvying of work has started, people on your team realize “huh, you know what this looks like it’s gonna work.”
Someday when I feel like picking a fight I’ll write about why targets are a bad way to manage teams, but these are two things that targets tend to miss — they are very specific in a way that narrows thinking, and their time frames tend to be shorter than the payback periods of truly meaningful projects (e.g. who cares if we missed this month by 10% if we invested the time into a long-term project that could 10x the business).
In the meantime, here’s an article I like about the complexity of measurement.
Big projects are harder and take teamwork, but the results are magic. Here are 5 projects we’ve worked on this year, among other things.
This quote is almost a management cliche, because there’s a degree to which it’s overused and stupid.
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”
At some point, you’ll need to gather wood and divide the work. You probably also need some shipbuilders, or at least a person who knows what they’re doing.
At the same time, what happens when something goes wrong and your sail is made of the wrong canvas or something (I am not a shipbuilder)? Who’s going to fix that problem, go into town to get the new sail, realize that you need to have some sewing skill — which none of your team knows how to do — and through whatever method required get the sail up onto the mast? The team who is building a ship is going to do better than the team that’s individually executing orders.
Big projects are hard, but they’re also amazing because they really force people to solve problems together. Which should also improve your long-term capabilities.
When I look back at 2022, I can point to major projects for our marketing team that came out of this type of coordination — and largely this is the year where we work on this stuff for the first time (I’m very excited for next year). Here are a few examples.
We launched our very first customer community, picking up 1,600 members in two weeks (now ~3,000)
Ran three separate “fellowships,” where we gave prize money and training away to our customers, primarily independent creators (we had over 2000 applications)
Created a “creator friendliness index” that used objective ranking criteria to compare us and our competitors by how friendly they are to customers
Launched a free tier of our product, which included major website overhauls, changes to comparison pages, and revamped onboarding
Announced a “buddies” program where we pair creators with a partner for ~5 weeks, to work on their businesses together.
Everything on the list (and there’s more I haven’t mentioned) is targeting a core growth lever of the business. Some of these are pilots that we ran as tests to potentially expand on (and we’re not quite done for the year). And of course there are smaller bits of work we’ve tackled as well.
A key to this list is that these are big projects. They require all hands on deck. They forced us into better communication and better execution, which in turn will make us better at executing the next projects we tackled.
Plus, they’re cool. They feel good to work on, they have greater potential to impact core parts of the business, and they encourage everyone on the team to hunt for ways to create an even better experience for our customers (instead of mindlessly executing a mediocre “playbook” in an attempt to hit numbers).
That’s how I want to encourage you to think — how can you get your team to think bigger, understand what they’re capable of, and become capable of even more?