Juggling software projects

There is a lot of information out there on how to level up in your career as a software engineer. Usually, the main suggestion is to sign up for more projects and leadership opportunities. The goal is to incrementally experience and then master the responsibilities of a senior technical lead or engineering manager. Eventually, so the advice goes, your increased scope/accomplishments satisfy the requirements of the company’s career ladder and you receive the promotion to the next level.

(I’ve written previously about how company career ladders are imperfect representations of expectations at each level. It can be easy to get tunnel vision on these so-called “requirements”, ultimately developing skills that are hyper-specific to that particular organization and not generalized to the larger tech industry. Level advancement therefore may not be as straightforward or smooth as the advice implies.)

Putting career ladders aside, the major thing I notice is missing from the conversation around becoming a senior engineer is how broader technical scope adds to your mental load. It’s not possible to sustainably take on more projects and responsibilities without fundamentally changing your approach to engineering work.

For folks early in their careers, much of the learning curve involves improving the craft of engineering itself. Getting better at coding and debugging increases the efficiency of completing feature work, which means freeing up time to take on more projects. But eventually, the beginner’s gains in software knowledge tapers off and there are no more significant time-saving techniques to learn. There is only so much time in a workday–linearly increasing the number of hours worked is not sustainable and is a surefire recipe for burnout.

At this point, most advice columns propose delegation as the solution to the increasing seniority issue. You can theoretically tackle more projects by having other team members responsible for the execution (writing and shipping code) while you drive the work from a higher level. However, in practice, I find that just delegating the execution part does not dramatically increase your individual limit for additional or larger-scoped projects. The majority of the complexity in delivering software occurs at the higher levels, such as breaking down an ambiguous problem into concrete step, adapting to unexpected edge cases, or handling shifts in business priorities. Your charter as a leader is to take on the cognitive complexity and shield/unblock the engineers doing the actual building. In fact, skipping the execution component can result in a more stressful overall experience, since you don’t even have the satisfaction of successfully implementing the project yourself.

Given that we cannot simply do more work ourselves or delegate the straightforward project elements alone, there needs to be a shift in mentality to become an effective senior leader. Here’s where the metaphor for juggling balls is useful:

Imagine that you are juggling a set of balls, each which represents an important project that needs to be completed. To add more balls, you need to start throwing each ball higher into the air so that you have more time before you have to catch each individual ball.

While you’re not touching it, the ball is under the influence of gravity and out of your immediate control. The better you can account for the forces on the ball when you release it, the less you need to pay attention to it while it is traveling through the air. But the longer the ball is in the air means small errors are magnified. Understanding that a higher ball will naturally be more likely to go off track and need corrections is critical in order to effectively throw the balls, thus juggling more balls overall.

This is a great metaphor because it really clearly demonstrates the change in working style that is required to “juggle” more projects. Because there is a physical limit to how quickly you can catch and throw a ball, you need to be able to come up with other techniques to increase the time the ball is out of your control, but in a way that ensures that you are ultimately able to still catch it. And in the same way, we need to be able to find ways to increase the time that software projects can be progressed without direct supervision.

What are some ways that we can increase the air time for software projects?

• Documentation. Concise, well-written technical documents are important for enabling asynchronous communication for projects. Other stakeholders and project members can consult the written documentation and even have discussions through comments without requiring your immediate attention. There are also plenty of other benefits, such as creating a lasting record of the project and creating a better remote work environment.
• Growing the team’s ability to handle ambiguity. Another way to the active management of projects is to empower the team with the knowledge of how to make decisions and solve complex problems themselves. Rather than trying to define every edge case from the start, you can deliberately leave areas of the project undefined to allow the team to fill in the gaps. Instead of just answering undefined technical questions directly, explain your reasoning or challenge your coworkers to try to answer it first. By distributing the technical know-how and context among the team, you can scale your own decision-making powers and enable others to help keep projects on track.
• Push vs. pull updates. A non-trivial part of the cognitive load for leading projects involves monitoring progress to make sure things stay on track. You always know the current status when you are solely responsible for the end-to-end project. When people transition to hands-off project leadership, they often default to a “pull” model for project status by personally checking in on the team. You end up running a constant mental subroutine to remind you to ask about the current status, which adds a lot of mental overhead. But paradoxically, it can feel easier to ask for updates, since you don’t need to explain your internal model of priorities and concerns. Shifting to a “push” mode is key to freeing up your own mental bandwidth. It requires active education and context-sharing with the team on when to notify you. It’s not enough to implement new processes (such as meetings/standups/async updates) share information since unexpected issues can arise in the interim. The team needs a similar mental model of priorities and concerns so they know when it’s appropriate to pull you in.

There is also a key emotional component to changing your working style. It can feel very stressful to (temporarily, deliberately) stop paying attention to ongoing projects in order to work on more things. As engineers, we’re used to dealing with logical and structured elements of programming. Knowing that errors will definitely occur because you aren’t in control creates a ton of anxiety.

We need to accept that some balls will be harder to catch or might end up on the ground. Building this mental fortitude is the only way we can ultimately achieve the goal of increasing our ability to juggle more balls. It is an important evolution in one’s engineering career to be okay with error, trust in our teammates, and slowly add in tolerances to the company culture/processes so that we collectively can recover from large mistakes and build even more great software.