Back in my days as a senior engineer, I would put a lot of effort into stepping up my personal productivity or helping those around me become better. We all know that most 10x engineers achieve that by acting as force multipliers: They make other people better and don’t type really fast but drive to impact faster (e.g., by cutting scope or suggesting customer-minded shortcuts). This is all part of the focus on engineering velocity, just like some teams measure their velocity every sprint.

While that is definitely a worthwhile effort, as you progress in your tech leadership career, you cannot keep focusing on velocity. You should start thinking about the next level, moving from velocity to your organization’s acceleration.

The Limits of Velocity Optimization

The problem with attempting to do the same velocity tuning is similar to the problem with micromanagement. No matter how “good” you might be able to pull it off, there is a certain point that is your limit. Past that, you are handicapping the team (while for micromanagement, that point might be around a team of a handful of junior engineers, with velocity it can be stretched quite longer).

Perhaps it is not as straightforward to notice this personally, but you can surely see it happening all around you. Whenever I talk to tech executives, they’re all reporting being overwhelmed and drowning as they attempt to keep all the balls in the air. That is a telltale sign that their efforts are not at the right altitude. You can only work harder so much; after that, you are merely spinning your wheels and burning out.

Acceleration Exploitation

So how do you work on how fast your team is improving and not merely its current speed? You have to make the time to think intently about this and not just let your day be controlled by whatever people put on your calendar. When you finally sit down to consider what you can do, here are some areas to think about:

Evaluate Culture: High-velocity cultures are those where people provide feedback openly and fast. There is enough psychological safety to encourage team members to speak up. There are no silos; for example, engineers are brought closer to the business side and regularly maintain their product mastery. These areas often get lost in the day-to-day scramble to get tasks done.

Speed of Change: No team is perfect, and even if the way things are currently operating is pretty good—nothing lasts forever. Your team will grow, or some key people will leave. The market will change, or a pandemic will hit. Whatever it is, you will need to keep adjusting and iterating on how things are done. That includes the different processes and rituals but also seemingly minor things like how on-calls are scheduled or how meetings are held in an inclusive manner for those working remotely.

What many companies are great at is spotting where they need to improve. Some are even good at saying how that improvement can be achieved. The vast majority, though, do that and then promptly forget about actually doing the work. Your engineering tasks have a deadline; they are part of a sprint or are committed to in the roadmap. The work needed to introduce a change, track its progress, and then iterate? That is rarely done as fast as necessary. Give this attention, and you will increase your organization’s speed of change.

Create Velocity-Impacting Managers: Lastly, just because you are no longer focused merely on velocity does not mean no one should be. Healthy organizations have layers of management and leadership that take care of improvement at their appropriate scale. You will get compounding benefits if you invest in making your managers better. So consider, are your managers regularly growing? Are they given the tools needed to be effective managers in your environment? How can you enable them to do their work better and remove obstacles in their paths? Do this not from the viewpoint of making their days easier but of making them the best engineering managers possible.