Anyone who's been part of a rapidly growing team understands that growing a team carries a lot of stress. A major component of that stress is the fact that your skills have to constantly adapt to new environments and challenges. If you stick to the same tactics you used with 10 people when you reach 100, it's not uncommon to find yourself disoriented or even drowning.

There are several ways in which the stresses of growth mode manifest, but today I'm going to focus on some important ways to protect and manage your time when you provide services to your team. Providing services to an organization is tricky, especially when that work represents only a portion of your overall responsibilities. Time pressures, unpredictability, mental load, and prioritization all get pushed to their limits when you are responsible for managing inbound requests from the team.

The typical path looks like this: early on when the team is small, someone asks you for something and you're able to respond in short order. This is one of the great parts of being on a small team - it feels so productive to just think and do. This works great when the request load is small - say, no more than a request per day, usually with same-day turnaround response.

As the team grows, the number of inbound requests increases as does the complexity. That same-day turnaround becomes next-day or later, and the number of requests-per-day varies daily, up to several. This is the tipping point where managing inbound requests can no longer be ad-hoc, you need a "system", or things start falling through the cracks.

Everyone hates this tipping point. That hyper-productive feeling gets washed away into process that feels slow and bureaucratic - it's less "startupy". When you reach this point, it's important to remember you're learning new skills with different purposes - rather than focusing on speed of response, you're focusing on increasing capacity to respond. In technical terms, this is a switch from latency (speed of total turnaround time) to bandwidth (total capacity for simultaneous requests).

What follows are a few tips I've learned from going through this transition over the years. Keep in mind there's no right or wrong way to do this. One of the best ways to keep the "startup" feeling is to pick only what you need in this moment and save the rest for later. No one in an early stage company wants a heavyweight process dropped on them.

Request Tracking

This is the first step of the transition, and probably the most important. It's simple: write requests down in a consistent and organized fashion. This is now your "system". This can be as simple as a spreadsheet you maintain on your computer, or as complex as a ticket tracking SaaS system you subscribe to. Anything is better than nothing, and I recommend starting simple unless there's a specific motivation otherwise. In the process of growing, you'll learn a lot about why your current simple system is failing and what is necessary of the next system you grow into.

It may seem like this is obvious advice, but it's actually quite common to miss this. It's the boiling frog syndrome - people get used to managing everything without having it written down, and they just don't notice that the number of requests exceeds their mental capacity. Those flagged emails start lining up and it's easy to lose sight of the big picture. If you find yourself in this spot, don't kick yourself for not thinking of it sooner - you're not alone.

Speaking of mental capacity, that's why you're keeping a list. Even if you're capable of remembering every request without a list, you'll be thankful once you start, because it will free up mental space for other important things. There is no need to have 10 random requests bouncing through your head all day and waking you up in the middle of the night. When it's written down, tracked, and systematized it's easier to rest without feeling a sense of danger.

Prioritizing

Now that you have a systematized way of tracking requests, it's easy to add a priority to each one. The only question is, how do you define priorities?

One of the challenges of defining priorities is that people across an organization define priority on different axes. Jeff from accounting thinks his request is urgent because he needs to pass audit. Jane from marketing thinks her request is urgent because she needs to align it with an upcoming product announcement. Jerry from strategy thinks his request is urgent because he's in daily contact with the CEO.

I find it helpful to define a vocabulary for discussing priorities that you socialize with your team. Create a few levels of priority (five is good, no more than that) and assign a word or two moniker for each level. Then define in words what each level means in a way that provides common ground across the departments you service - impact. For example: revenue impact, customer experience impact, or operational impact. What happens if I'm unable to get this done?

Here's an example from my world, bug reports during product development:

• Blocker: The product is not usable in its current state. Significant customer impact and revenue loss if left unaddressed. Stop work on all other initiatives and extend work hours until fixed.
• Urgent: Critical product capabilities are severely impaired. Workarounds may be possible, but are untenable over the long term. Customers are negatively impacted and some revenue loss will occur. Prioritize above all other work and fix as soon as possible, but no need to extend work hours.
• Important: Non-critical product capabilities are broken or severely impaired. Customers are inconvenienced and minor revenue loss may occur. Prioritize fixing within the current development sprint.
• Useful: Minor inconvenience, but noticeable. Customers may be mildly irritated, revenue loss unlikely. Prioritize fixing in coming sprint.
• Trivial: Little customer impact but worth addressing. Customers may not notice, no revenue impact. Prioritize fixing when convenient.

Again, every situation is different so your priority language may be entirely different. But you need a language so you can get on the same page with your counterparts quickly. It's hard to beat a one-word description in terms of efficiency. Back-and-forth discussions about what-it-means rather than how-to-fix-it are entirely unproductive.

It's worth noting: the reporter's priority is not the same as your priority. The priority they assign is a communication tool to help you understand what they need, but it's not a rule. You (and your chain of command) are the arbiter of the actual priority.

I recommend avoiding using deadlines to communicate priority. There are two reasons for this: first, as an employee your most important priority is to manage your time appropriately. When you allow others to set deadlines for you, you've now delegated a portion of your time management to other people - you've given up your own responsibility. Second, inevitably there will be a situation where you can't satisfy everyone - you have 3 items due by Friday and time available to finish only two of them. Which two do you pick? If all you have is a deadline, you have to go back and get more information, costing critical time at a moment when time is exceedingly precious. Better to have that information up-front.

Pushing Back

Above you may have noticed I mentioned that you don't have to accept others' priorities, and you own responsibility for how your time is spent. This is true, but also nuanced. We've all met that overworked teammate who is abrupt or rude because of the constant demands on their time. While I want everyone to feel empowered to manage their own time, I think it is important to do so gracefully.

That said, I'm going to focus on the empowerment side of the equation in this section. When people within the organization are making requests of you, it's more than just your job to satisfy them - you're helping them do their jobs, too. For that reason, you're not obligated to accept requests exactly as they're delivered to you. If you're handed something that's poorly defined or impossible to act upon without further clarification, it's not just OK to push back, it's actually an important responsibility for managing your time.

This is perhaps the biggest benefit to systematization of inbound request handling - it allows you to "push back" before anyone makes a request of you. If you set reasonable requirements for how requests are handed to you, and those requirements are properly socialized, then there's no harm in kindly and gently refusing the request until it's been properly delivered.

We all know it's the worst when you're handed a vague and ambiguous request. It not only wastes your time, but it also wastes the time of the requester because you have to go hound them to clarify their request. The more you can do to ensure incoming requests are scoped and actionable, the more you're doing everyone a favor.

Lead Times

This conundrum often happens at early stage companies: you have a new feature you want to sell, but you're not sure how the market will receive it. You don't want to put in the effort of implementing the feature if it doesn't get sold, but you can't get market feedback if you never try to sell it. How to resolve this conundrum?

A defined and well-communicated lead time can be a useful solution. Engineering says, "we need to know at least 6 weeks in advance if this feature is going to be sold." Once that's communicated, sales has clear guidelines about time frames under which the new feature can be sold. Everyone can move forward.

This is also a good way to mitigate certain categories of requests that are infrequent but disruptive when they land. The things that cause your whole team to shuffle their work during the infrequent times they come up. Communicate an appropriate lead time that allows your team to be flexible in addressing the request, and the disruption is mitigated .

The nice thing about lead times is that when you inevitably get requests inside the lead time window, as long as you've set the lead time size appropriately, you'll likely be able to finish it in time without excessive disruption, AND you get to be the hero because you exceeded expectations. Win/win.

Scheduling and Batching

Once you have a solid request management system up and running, you now have leeway on request turnaround and you can focus on capacity. You address urgent requests time-sensitively as-needed, but now non-urgent requests can be addressed in batches at the time of your choosing. You might even set a regular schedule and communicate it to the organization, so they can set expectations appropriately.

When inbound requests are batched they inevitably get faster. You can set up a work environment that gives you everything you need at your fingertips for dealing with requests. Humming along and checking things off the list, it's not long until you start seeing the time spent per request dropping, and you can fit more requests into the same time allocation. That's where the capacity increase comes from.

Misrepresentation

Inevitably as an organization grows there will come a time that request priority will be misrepresented. This can be intentional or the result of miscommunication. In either case, the above tools - priority definition, empowerment to push back, and the permission to decline to accept their priority as your own - give you everything you need to gracefully handle what can otherwise be a complicated stressful situation.

Maintaining the Spirit

In closing I want to rewind to the inherent change that sets in as teams grow. Every augmentation is an amputation, as they say. You can never quite recapture the creative feeling of those early days (e.g. consistent same-day turnaround), but you can maintain a spirit of creativity.

Stress is the ultimate creativity killer, and that's the danger that lurks at growing companies. Goals get set, plans get finalized, and everyone starts locking in their coordinates. One of the reasons process is considered a naughty word at many startups is because it feels like it kills creativity. And so many early stage companies avoid process in an attempt to maintain creativity, and promptly shoot themselves in the foot.

Process doesn't kill creativity, overcommitment does. And process is hated by creative types because its presence correlates highly with overcommitment. Creativity arrives in idle moments when unburdened thoughts feel free to come forth without putting you in danger. And so when you kill process in the name of saving creativity, you actually damn your creativity to the permanent dampening of being "busy".

Instead, if you sprinkle process in the critical areas where it's needed most, you reduce stress and free up opportunities to for creativity to emerge. A little goes a long way. Treat it like salt - just enough to taste good.

For that reason I hope you see the above advice the way I intended - lightweight guidelines to help reduce organizational friction. Reducing your mental load to focus on what really matters. Changing your focus from turnaround time to capacity, and nothing more.