Startup CEO’s Productivity Hack: Extreme Single-Tasking

How to take context-switching avoidance to the next level

Being a startup CEO is one of the most multi-faceted jobs.

Unlike big-company CEOs, early startup CEOs have to manage people in every role and personally fill in all the skill-set gaps until an executive team is in place.

A startup CEO may have to speak with a customer, interview a job candidate, close the monthly books, and review a new product feature specification – things that would normally span a variety of roles – all in one day.

The CEO’s personal productivity is critically important for startups with limited resources, yet it’s one of the hardest jobs to do productively. You have to juggle a wide variety of responsibilities, and context switching between them carries significant overhead.

After doing this job for over a decade, the single greatest productivity hack I have found is this: only work on one thing at a time, and take it to an insane level: what I call extreme single-tasking.

With regular single-tasking methods like the Pomodoro Technique (working in uninterrupted 25-minute bursts), you block out distractions to work in focused chunks.

While helpful, these methods don’t address blockers or interruptions at the organization level, which are typically beyond an individual’s control.

Extreme single-tasking involves structuring the entire organization around single-task work as the highest priority so that the CEO and everyone else can be as productive as possible.

Very few companies prioritize workflow efficiency to this degree. It takes a lot of effort and that effort doesn’t directly yield revenue.

However, long-term commitment to extreme single-tasking has enabled me and my colleagues to outpace competitors several times our size.

This article looks at the most common impediments to single-task work and shares tips for adopting extreme single-tasking in your organization.

Build a single-tasking culture

The cornerstone of successful single-tasking is building a culture that values it.

Some leaders make the mistake of optimizing for their own workflow while disregarding the impact on others.

If you reach out to people directly with questions or small tasks and expect an immediate response, you might get your current task done faster, but it will have a ripple effect on other work that ultimately leads to a net decrease in single-tasking across the organization.

This also creates a culture where each level of management amplifies inefficiencies beneath them to make their own lives easier. Once you get down to the individual level, the work environment becomes toxic.

At the end of the day, this approach circles back to leaders and ultimately prevents them from efficiently accomplishing their goals.

Another anti-pattern occurs when leaders invest in process and system improvements to support their own single-task workflow, but don’t empower others with time and budget to do the same.

To create an organization that prioritizes single-tasking, leaders need to send the message that everyone should make it a priority, and that they should strive to reduce context switching across the whole organization.

This means that everyone must respect each other’s workflow and not interrupt or block other people just to help themselves, starting from the top.

Leaders also need to make everyone responsible for productivity optimization as a main part of their job. Managers must give people the resources they need and hold them accountable during one-on-ones and performance evaluations.

A healthy culture is a necessary precursor for all of the tactics that follow.

Reduce task sizes

The number one way to work on one task at a time is to make each task smaller. The longer and more complex a task, the greater the likelihood is that something else comes up requiring your attention before it’s finished.

This is a deep topic and there are multiple levels of tasks from individual work items to higher-level deliverables and projects.

For more in-depth guidance on reducing tasks sizes, see What Every CEO Should Know About Software Planning (which is relevant for non-development work as well).

Leaders should continuously strive to reduce task sizes for themselves and the larger organization. They can do this by supporting improvements that reduce fixed costs for tasks and by incentivizing everyone to create plans that minimize task sizes.

Personally, whenever I have the instinct to bundle tasks together that could be separate, I stop and ask why. Is it because I’d spend time waiting on a slow build process or review? Whatever the cause, fixing it becomes a top priority.

Cut engineering out of the process

In a software company, tasks that require code changes usually take an order of magnitude longer than those that only require configuration updates.

Chris Espinosa famously built an application that let Steve Jobs design the first Apple calculator app without having to go back and forth with engineering for each change.

Investing in domain specific languages, content management systems, and admin interfaces that enable new functionality without deploying code is one of the highest-impact decisions that leaders can make. It greatly increases the set of tasks that people can complete in one sitting without having to wait on engineering.

At minware, since we created the minQL formula language, I can now build reports myself in a few hours that used to take the whole engineering team a week. This has been incredibly helpful for handling customer requests the same day rather than scheduling them as part of the regular development process.

For more in-depth advice on how to cut engineering out of the process, see Everyone Needs Their Own Programming Language.

Establish SLAs for all time-sensitive work

When people hear about service level agreements (SLAs), they usually think of response times for urgent customer tickets. However, SLAs are important for every task that has a time expectation, including slack messages and emails.

Without an explicit SLA in place, people don’t know how quickly to handle urgent requests. They may respond faster or slower than they should, either needlessly interrupting their own work or delaying someone else.

SLAs empower everyone to minimize the impact of urgent issues on single-tasking.

To establish SLAs for day-to-day communication, every organization should create a working agreement that lays out how quickly people should expect a response in each channel. This lets senders choose how to communicate based on when they need an answer and minimize unnecessary interruptions.

Larger urgent tasks that go beyond a simple email response should all go into a ticketing system like Jira, and they should have an explicit priority field that is tied to an SLA.

Want To Ship Features Faster? Fix All Your Bugs goes into more detail about how to implement a ticket SLA and shares the prioritization scheme that we use at minware.

Essentially, we have statuses for “stop everything and do this now,” “start on this by the end of the day but otherwise don’t interrupt your current work,” and “do this by the end of the next week.” These statuses come with SLAs of 1, 3, and 14 days.

This makes it easy for me as CEO to set a priority label and know when something will wrap while minimizing the impact on other people.

Don’t tolerate bad planning

The type of interruption I find most frustrating when someone makes an urgent request, but knew about the requirement weeks earlier.

Strong leadership is important in this scenario. You don’t want the person being interrupted to feel the urge to say “no” just to avoid creating a moral hazard and protect their time. The interruptee should feel confident that the bad planner will be held accountable and discouraged from repeating the problem in the future, even if the right decision for the business is to complete the urgent task today.

Leaders should also keep a close eye on how work progresses on projects that don’t involve external dependencies. Whenever there is a lapse of activity on a project, it’s important to look at why that lapse occurred and whether the dependency could have been identified with better up-front planning.

Everyone should know that single-tasking is a priority at the level of larger projects, not just individual tickets or deliverables.

Kill all non-essential blocking workflow steps

As organizations grow, the number of blocking steps in workflows will naturally expand without deliberate effort to keep them under control.

These steps are usually related to quality control. They are often put in place to make sure that work doesn’t proceed if there is a serious problem. They may include things like specification approval, code review, QA review, automated build processes, product manager validation, etc.

While well-intended and sometimes necessary, these blocking workflow steps create interruptions that prevent people from single-tasking.

The first way to mitigate blocking steps is to provide an escape hatch so that someone can skip the step if they judge it to be unnecessary.

We have done this with all code reviews at minware. If the author believes that a change is sufficiently low-risk, they can tag a pull request as “low risk” and merge it before receiving a review. Code review is an important step for many changes but making it block trivial things like button color or text updates isn’t worth the workflow impact.

Another thing you should consider is whether it’s absolutely essential for blocking steps to be blocking, or whether they can happen after the fact.

Going back to minware’s code review process, we actually require code reviews still for low-risk changes, but they can happen after merging the change. There are a few cases where bugs have gone into production that were caught in post-merge review. However, this minor cost has been well worth the efficiency gain.

For each of your blocking workflow steps, you should seriously assess whether an escaped problem will truly cause irreversible damage. If you can back out of it with minimal impact (e.g., pushing a hotfix or canceling work on a project after a few days), then you will likely benefit from making it non-blocking.

Even if problems don’t cause irreversible damage, people sometimes impose blocking steps when the rate of escaped problems is too high. This is often the reason for making development tasks go through QA approval.

In this scenario, you should strive to eliminate the blocking steps through better automated mistake-proofing. Test automation is one way to do this for development tasks, but there are a lot of other tools that will automatically catch mistakes in various types of work (e.g., spell check even counts).

Checklists and templates can also help people catch enough of their own mistakes that it’s no longer necessary to subject their work to a blocking review step.

At my previous company, listing all of the common gotchas in our technical plan template (e.g., performance, security, etc.) allowed us to eliminate the requirement for engineering leadership approval before starting work.

Finally, it’s important for managers to trust employees and address repeated problems with individuals. Too often, blocking workflow steps exist that slow everyone down because of a few people, when the better solution is to help those under-performers operate better within a flexible process or move them out of their role.

Eliminate missing information

One common source of delay that can lead to context switching is waiting on a critical piece of information.

There are a few possible reasons for this, but it generally means that information is either stuck in someone’s head or not easy to find.

The default inclination people have when encountering missing information is to reach out and ask someone for an answer. As a CEO, it might be tempting to just require everyone to be available to answer your questions, even if that means messaging people when they’re off work.

To complete the immediate task, you might need to do this. However, doing it repeatedly destroys everyone else’s productivity and creates a toxic always-working culture.

Instead, whenever a leader encounters missing information, they should ask: why wasn’t it documented in the first place?

Leaders can permanently mitigate this type of delay by establishing processes that ensure every important artifact is documented at the time of creation. Common ways of doing this include recording and sharing meeting minutes, writing down plans in shared documents that include comments, tracking every piece of work in a ticketing system like Jira, and making sure artifacts are linked to a project or sprint plan.

Furthermore, you should foster a culture where information is made public by default and fight against private slack channels and documents unless absolutely necessary.

At minware, we make everything public within the company by default in Jira, Slack, and Google Docs. There is only one private folder for sensitive HR/legal documents, another location for sensitive customer data, and a password manager for sensitive credential access.

Finally, it’s important to prioritize improvements to information sharing based on their long-term impact. One short delay may be small, but missing information can be a substantial hidden burden over time.

Optimize blocking systems

One common source of delay that can lead to context switching is waiting on a system to do something on the critical path to completing a task.

For example, you may need to wait on software to deploy before letting a customer know that a bug has been fixed.

People tend to have an intuitive sense that waiting on systems is bad, but often underestimate the impact because switching to work on something else may make the time spent waiting not feel like a big loss.

It’s important for leaders to recognize this tendency to normalize wait time and aggressively optimize slow systems.

Whenever I wait on a system, I treat the full wait time multiplied by my hourly rate as the cost, even if I do something else in the interim. This may seem like it would overprioritize system optimizations, but it could be an underestimate if you account for the impact of context switching. In any case, it’s a simple heuristic that ensures sufficient investment in optimizing systems on critical workflow paths.

Conclusion

This article covered the most common organizational impediments to single-tasking and discussed how to eliminate them.

The most important thing on your journey to extreme single-tasking, however, is adopting the right mindset.

Having coached many people on workflow efficiency, the biggest hurdle is complacency. If you’re too focused on staying busy, you’ll never develop an intrinsic intolerance for multitasking.

It’s that intolerance that is essential for leaders to instill throughout their organization to drive change and fully realize the potential of single-task work.