Space to do whatever, at work

why it's important to make space for not-the-highest-priority things at your job

I hope you enjoy this free Tech and Tea post. If you’re enjoying the newsletter, please consider a free or paid subscription.

---

Last Friday, I was chatting with Luca of Refactoring, and the topic of the hierarchy of spaces applied to the workplace came up. I’m not sure yet if the entire hierarchy holds up to workspace needs, but we honed in on the topic of Space to do whatever, and how it shows up for engineers at work.

If you haven’t already, check out this post where I describe my hierarchy of needs, ranging from Space to be exhausted, to Space to do whatever, to Space to enjoy, and finally Space to create. The rest of this post will make a lot more sense!

(And stay tuned for my full interview with

Luca Rossi

— I’ll share it when it’s published!)

I was reminded of a time when I felt like I didn’t have any space to do something I chose at work. I would propose a product idea, and it would get shot down. Even small code refactorings or improvements would get picked apart — “well actually, someone else had other plans for that, so hold off on that.” It seemed like the only thing I could do was execute on tasks that were handed to me, prioritized and broken down by someone else.

It was a demoralizing time.

In this post, I’ll explore how Space to do whatever shows up in different companies, why it’s important, and how you can carve out space for it on your team.

Space to do whatever at work at tech companies

Hackathons are a very concrete way that companies make space to do whatever. They serve to inject a heavy dose of agency and creativity into employees, get people working in different combinations, and create some variety from business as usual. The premise is usually, work on what you want with who you want, for a day or a week.

Perhaps the most well-known version of codifying space to do whatever was Google’s 20% time policy, where employees were encouraged to spend 20% of their time working on whatever they felt like would benefit Google.

While these are often seen as company perks, the investment in carving out this space tends to pay for itself. Gmail and Adsense both emerged at 20% projects at Google, and many companies end up shipping hackathon projects that become quite meaningful for their business.

Why do whatever when you could work on the next important thing?

Quite simply, space to do whatever is important at work because it’s important for humans, and the people who work at work are humans.

I’ll continue to use engineering examples, but you could imagine examples in any function.

If engineers were machines, capable of the same exact level of output regardless of the type of work, you could create a prioritized list of everything that had to get done, assign a size to each item, and engineers would follow an optimized process to pick up whatever was next up in priority to fill in available time.

But this assumption of engineers as optimized resources doesn’t factor in variable such as:

• Human cost of context-switching

• Different levels of motivation for different types of work

• Work that is energizing vs draining — some work energizes people, and some work drains people. The same work that energizes one person could be draining for another person. The same work that energizes one person one week could be draining for the same person another week.

• Interpersonal dynamics with other teammates (Alice and Bob love working together, and any project they work on together is completed swiftly — and the opposite)

• What’s going on in their personal lives, which can affect their energy, state of mind, and what they want to get out of their work time.

Humans are definitely not machines, so engineering work more often looks something like any of these scenarios below:

• Engineer has something they’re excited about as a secondary stream of work, but surprise! It doesn’t detract from the higher-priority stream of work. Instead, their productivity goes way up and they complete both quickly.

• Engineer picks up what seems like a simple one-day task, but days later, they’ve still not completed it.

• Engineer builds momentum on a gnarly problem and chooses to find time outside their typical working hours to keep chipping away at it.

• Engineer avoids working on a specific task, but when they get to it, it only takes them 5 minutes.

• Engineer gets stuck and doesn’t get the help they need in a timely manner.

Because we are humans and the people we work with are humans, space to do whatever — which I am using to mean, not defaulting to always picking up the next most important item all the time — can fill an important role at work.

Also, BONUS: because we are imperfect humans, a prioritized list is never actually “correct,” and space to do whatever creates space for other people to work on something they might find important (though not always), which may take the company in an unexpected but positive direction.

Space to do whatever might fill different needs

People have many different needs at work, and space to do whatever can be a flexible way to fill some of those needs that perhaps aren’t being met by their main high-priority work.

Here are some of those needs and how they could be filled by some space to do whatever:

• Predictable progress - if an engineer is working on a very complicated problem and it’s a bit of a slog, a secondary project or space to pick up something that’s more of a quick win can be motivating.

• Scratching an itch - sometimes people just have areas they will always gravitate to. For one engineer, it might be code cleanup and refactoring (see Life-changing Magic of Deleting Code). For others it might be visual polish, or tooling for a better developer experience.

• Learning and growth - if an engineer’s growth is more stagnant than they’d like in their main work stream project but you really need them to work on that project, having some space to do whatever can be important in fulfilling their need to learn and grow (which can also help with retention).

• Agency and ownership - space to do whatever can give engineers some project to carve out and make decisions around, when they might not have the same level of agency in other areas of their work.

• Recovery and decompression - space to do whatever could explicitly follow a push towards a feature release, giving engineers some time to breathe before jumping into the next project.

Implementing Space to do whatever

Ok but you can’t really have all your engineers literally doing whatever, right? You wouldn’t want engineers off making random changes to core functionality.

If you lead a team, you might imagine one engineer who you’d be generally fine with doing whatever and making sound decisions.

But depending on the engineer and depending on what the “whatever” is, this idea may make you feel a bit uneasy. Or if you’re the engineer, you might want some guardrails and guidance so you know that what your “whatever” is, is actually something you can actually work on.

I’ve found two things to be true:

1. People generally do want to work on something that has impact — if you hire reasonable people, they’re not going to be off doing some super random thing that is completely unimportant.

2. People don’t necessarily have the need to be able to literally do whatever. People are hired into a role, and they expect that their work is roughly going to align with their area of expertise.

What people do need is space to have some agency and control of their work and time, to not have every decision they make be critiqued by 5 different people, to not have every minute of their calendar be dictated by meetings and the next most important task. When people don’t have a bit of space for this, they grow resentful and frustrated. They stop taking initiative. And their work grinds to a sloooow pace.

Here are some ways that a team can make more space to do whatever with some guidance and guardrails, thereby improving employee happiness and motivation, which feeds directly back into quality and output of work.

• Make priorities clear. If you’re days out from a high-priority launch, people should be working on whatever’s needed for that, which probably isn’t code cleanup. But, incorporating regular space to do whatever when you’re not in these time-critical situations also makes it easier for engineers to switch into an all-hands-on-deck mode for something timely and important.

• Develop a backlog of nice-to-haves. Each item may not all be highest priority, but if someone is especially excited to work on something, they can pick it up and run with it. Within these guardrails, an engineer can pick up something they want to do and choose to do, and it’s also something that’s good for the business (but not so important that it would have been prioritized and staffed). The bonus of this situation is that when someone chooses to do something because they want to, it usually gets done at least twice as fast as if you prioritized and staffed it. Win-win.

• Explicitly label what can be engineering-driven. Major new product release? You probably want product and design to work on discovery and strategy before bringing in engineers. Well-spec’ed product tweaks, internal admin tooling, developer tools, or settings page improvement? Probably safe for anyone to pick up and run with it.

• Encourage engineers to take initiative. If you hear people complain about stuff or talk about things as though someone else who knows more than they do should do something about it, use your best judgment. If you believe that it would be safe enough for this person to take a stab at it, encourage them to do so. That is, encourage them to feel ownership over how things are done, but don’t set someone up for failure by nudging them into a space that’s out of their depth. More often than not, I’ve seen people hold back from taking initiative with the assumption that someone who knows more has a better plan — when it reality, especially at startups, anyone could take a reasonable and common-sense approach and at the very least, kick things off.

• Plan for regular space to do whatever - Whether it’s regular hackathons, bug bashes, or regular post-launch cleanup periods (my team at Google called a week in December “Hygiene Week”), it’s helpful to make explicit space for people to pick up what they want.

Hopefully some of these tips are helpful, or if they seem obvious because your team is already doing all of them, even better!

What are the things you’re drawn to when you have space to do whatever at work? What needs does it fill for you?