Leadership is a never-ending quest where there’s always more work to do. In Greek mythology, Sisyphus was a king who evaded death twice. Hades, the god of the underworld, punished him by forcing him to push a boulder up a hill. Once the boulder reached the top of the hill, it would roll back down, forcing Sisyphus to start again. Leadership can feel similar to the story of Sisyphus because there is always something more you can do, and your tasks rarely ever feel “complete.” 

Constantly improving but never perfect

Leaders are constantly expected to improve themselves and their teams. Directors ask engineering managers (EMs) for more productive teams. VPs of engineering ask their directors for more remarkable outcomes with less headcount. The CEO expects the CTO and VP of engineering to achieve faster results with better quality. Because of these multifaceted expectations, technical or organizational debt can easily accrue. 

To avoid friction building up with C-suite members, leaders must find ways to continually excel and improve upon their methods. Teams should run retrospectives to identify areas of improvement, and managers should conduct engagement surveys to better understand where to boost efficiency. 

Technical leaders must set expectations for a certain amount of "toil" budget to address the continuous stream of technical activities like patching security issues, upgrading dependencies, and automating small repetitive tasks. Teams need time and space to think of improvements and implement them. Retrospectives and engagement surveys give you new input on areas to improve but be sure to follow up. Toil budgets give teams permission to spend time on small improvements without always asking for permission.

Great leadership ensures the team always has a regular time to improve their tools, processes, and work environment. Sometimes it’s easy to get caught up in wanting things to be perfect, but remember the well-known saying, “Perfect is the enemy of good.” Striving for perfection is ideal, but ultimately unattainable given limits on time and budget. Get comfortable with the fact that you will never be done improving, and instead celebrate the improvements you make every day.

Continually shipping new features

For many teams, an endless stream of work can feel like working in a feature factory and be demotivating. Engineers get especially frustrated when users ask for more enhancements which makes an optimal design more challenging. 

Yet, despite a study showing that 80% of features in the average software product are rarely used, people will always ask teams to build new features. 

To avoid feeling like your team never makes progress on an ever-growing backlog of work, connect people to the value each work item brings, and be sure to celebrate success on a regular basis. Get your team to spend time with users or customer support to see the challenges they face or what they struggle with and how each new feature can address this. Involve your team in the prioritization process to hear why chosen work has higher value compared to unprioritized work. When team members know what value their work brings, each task will be much more motivating.

To avoid feeling like running in a hamster wheel, be sure to celebrate progress and success. One great way to celebrate is to use whatever planning cycle you have to highlight achievements and not simply move on to the next work item. For example, at the end of an iteration, let your team see their impact by observing customers use their newly built features, or run your team through changes in product metrics to connect their actions to the business impact. Perhaps, at the end of a quarter, encourage people to talk about their work at a company town hall, where even internal recognition for an interesting feature or implementation imparts a sense of progress. 

An endless stream of work doesn’t need to be demotivating if people can see progress and the value they bring.

Flying high but staying low

Great leaders need to operate in two different horizons: strategic and operational. Working strategically means stepping back and identifying environmental trends to ensure a team moves in the right direction. For example, an EM having the contextual awareness of the infrastructure team moving away from their cloud provider and back to self-hosted services to optimize new work for the internal data center. Another example is learning that the email delivery vendor’s contract expires in six months and working with the team to migrate to a different vendor more efficiently when the new contract is finalized. If you know what the long-term goal is, you can avoid rework or unnecessary work with each decision bringing you one step closer to the long-term goal.

It’s important to remember that thinking strategically requires meetings with other parts of the organization, which detracts from day-to-day tasks such as attending team meetings and knowing when a team member is blocked or requires help. And although you need to keep a bird’s eye view of the business, you also need to stay connected to the team you're leading. After all, you’re accountable for the timeliness and quality of your team’s work. Being too “hands-off” prevents you from identifying and managing risks, discussing task details with external stakeholders, and collecting concrete examples for feedback and performance reviews. 

Finding the balance between flying high and staying low requires leaders to manage their time and attention effectively. A chaotic week can draw you back into the team’s orbit, where you might miss vital wider, business developments. At the same time, remaining too distant creates a disconnect with the goings on of your team, leading to awkward or surprising conversations with other leaders about delays or issues. Allocate a time budget for strategic thinking (e.g. 10% of your week) and track how much time you actually spend on strategic thinking. 

Innovating while keeping consistent

Traditionally, software teams operated through projects with defined beginnings and ends. Larger projects allowed you to take on planned changes and implement them consistently. Today, product teams are incrementally learning and making changes, which means teams are constantly innovating but lack time to rewrite old parts of a codebase. 

A larger codebase increases the surface area that needs navigation when adding a new feature. Every new feature exacerbates the potential for inconsistency, making future changes more difficult and inviting unwanted side effects. Therefore, it’s important to keep a codebase consistent to ensure that adding new features is simple, but doing this successfully requires more time. This time element prevents a team from adopting new tools, libraries, or approaches that simplify problems or improve productivity elsewhere. 

To allow for innovation and maintain consistency, find a low-risk approach to experimentation. For example, rather than writing production code in a new programming language, try using it in an isolated prototype or test code (which is easier to rewrite or throw away). If you commit to a new approach, ensure all contributors know the long-term goal and have a step-by-step plan for moving forward. For example, if you're moving to a new testing framework, you might have a rule where people use this updated framework for the latest test cases, where each person also converts an older test in tandem.

Staying on a leadership path requires balance

Leadership requires juggling many different responsibilities and you must find the right balance to success. Individual contributors can focus on one task or goal at a time, but you don't have this luxury as a leader. Instead, you need to juggle many work items and demonstrate progress on each item within your limited time. 

Set aside 10-15 minutes each week to ensure you’re striking the right balance. In your allocated time, ask yourself questions like “What are you neglecting?”, “Where are you spending too much time?” and “What are we not doing that we should be doing as a team?” Your answers will tell you how to find the right balance for you.