There’s a reoccurring phenomenon right now, which I last saw when the pandemic hit. The best leaders around aren’t those who throw their hands up in despair but precisely those who find new ways to leverage the current situation. No matter how dire things might seem, I’m working with executives who had to lay good people off yet are full of optimism. After all, if we’re already going through this crisis in the tech industry, it’d be a shame to let it go to waste. The minimum you can do—and what you ought to do for your team—is to ensure you will all emerge from it stronger and more resilient than ever. Otherwise, you’ll see someone else steal your lunch.

That sort of growth and improvement does not happen spontaneously. You have to take steps with intention toward the future you’re imagining. How do you crank up the pace in this slow/no-growth environment where the people in your team are likely all you’ll have for the next few quarters? Obviously, engineers cannot try banging on the keyboard faster to get more code out. But I’ll let you in on a secret: most average teams can triple their impact per engineer.

I’m holding my big live stream event of the year soon, and it will be precisely about this. Because of that, I thought it’d be nice to share some of my thinking as I prepare for it, so even if you won’t be there, you can get a sense of some of the things I see working for companies right now. And, of course, you are more than welcome to sign up; it’s free: Surviving to Thriving: Capitalize on the Crisis & Create a Strong Tech Team.

Stop Allocating Tech Debt Time

So many good teams I meet have gotten used to default blocks of time for tech debt or engineering nonsense that they protect vehemently. The problem is that when these are taken for granted, we no longer have to justify our actions. That’s why we’re wasting ungodly amounts of engineering hours on things that barely matter. That’s tech for tech’s sake.

Am I saying you can never improve your system? Certainly not. Admittedly, we have to make things better from time to time. However, as I had recently discussed with some of the best engineers and great thought leaders I value in a conference, “tech debt” is thrown around without much thinking. For example, if this is work needed to complete a feature on time or well, make a case for the work to be done as part of that. Yes, that might mean you won’t do the whole thing and only refactor what’s currently needed. That’s healthy prioritization and precisely how we drive more impact per engineer.

Further, stress the need to spend time on innovation, creating new capabilities, and amassing tech capital. These are much more impactful than another refactoring in a corner of the code base that no one really touches regularly. You can get an in-depth guide for injecting innovation into your team by downloading the free sample chapter here.

Don’t Speak in Tasks

Similarly, when we want to focus on impact, tech teams cannot merely act as feature factories. When your team acts as an order-taker and delivers tasks, it is not operating at the right altitude. Instead of having a service mindset, try shifting behavior, so your organization is positioned as a peer on equal footing with others in the company.

For example, change your culture and introduce empowered teams. These are cross-functional teams with product managers embedded in them (or working closely with them as peers), and they are not given a backlog to execute on. Instead, their planning revolves around business goals or problems to be solved. Thus, they have much greater wiggle room to determine the right path forward and focus on the most critical parts. That is how you establish insight-generating teams, where each iteration drives further learning (more on that below).

Expose Impact

The previous item is already helpful in this, as the team should be able to judge its own performance by witnessing the results of its work. However, such exposure to their impact is priceless and can be leveraged even further. For example, let the team see which metrics have been improved, what users are telling customer success, and check out usage analytics to understand the personas and value they get from their work.

This is important for two reasons. First, it helps the team remain motivated. The worst feeling is when features seem to be deployed “into the void.” That is when teams just crank out features and run to the next one, never seeing the loop closed and realizing the value of their work in users’ hands. Second, it gives teams a better understanding of the users and value and, thus, better impact instincts. These are then used for descoping.

Praise Diligent Descoping

When we’re on a push for impact, every line of code not written means less time wasted. Suppose we’re genuinely trying to triple impact-per-engineer. In that case, we have to reduce to a minimum the amount of non-impactful work performed and ensure that whatever we do is the most valuable thing possible at any point in time. Teams that wield the descoping scalpel to cut down on fluff have a leg up here.

A peer relationship with the product team, and the ability to speak business with stakeholders, will make this descoping more than the regular pushback on scope we’re used to. This isn’t simply about not implementing animations and similar silver plating features because sometimes delight is an essential part of the feature. However, when the engineers are connected to the impact of their work, they can spot elements of features that are not currently needed. When they speak in business goals—because that’s what an empowered team does—they can find a hypothesis and implement that before deciding to invest more effort in any specific direction. Yes, you have to experiment as a startup. You cannot expect every line of code to result in a feature clients are excited about. But you should have a pretty good hit rate. Descoping is how engineers help get there.

Minimize Multi-Sprint Features

Naturally, you cannot deliver any feature within a couple of weeks. That means that we often have projects spanning many iterations. The problem is that we never seem to decide on how important something really is as it unfolds. Therefore, something that went through some descoping and seemed reasonable first might continue and on even when the originally estimated couple of sprints turn into three or four.

Ideally, most features or projects the team commits to should be chunked so that they result in meaningful results and value to clients within a single iteration. Sure, you might continue improving it, but when work is “packaged up” at the end of a sprint, it is a lot easier to judge the benefit of additional work as opposed to a never-ending task that is binary: it’s not done until all of it is done.

For those bigger tasks that cannot be chunked, define appetites: product leadership should state how much time a specific capability is “worth,” and the team should work to create a solution that fulfills the business need within that time budget. Thus, something that is not delivered within the six weeks allocated is deemed a failure and might have to be shelved if it is not deployed. Such commitment helps teams focus on the impact core of any bigger project.

Strategize

Lastly, any impact merely driven by the next milestone that’s always a month away is too myopic. It is ridiculous that many startups have done away with any real strategy. At best, the founders pull some numbers from the air and put those as OKRs that they communicate to the board without really having a reason for why those numbers or how to get there.

As part of the executive team, you are responsible for ensuring the company defines a clear strategy that represents the company’s goals and how the company will get there. That is, what are your strengths and unique properties? Such a strategy does not have to be compiled in a huge binder no one ever looks at. A five or even three-year strategy is useless for a startup. Nevertheless, a strategy aimed at 6-12 months into the future is incredibly valuable in creating a focus effect and driving greater impact.

So, start by defining such a strategy in case you haven’t yet. I help my clients with Sentient Strategy® sessions, but you can choose your preferred methodology. Once that’s done, communicate the strategy. Everyone on the team should be able to understand your goals and the reasoning behind them and see them tracked. Your strategy should be used daily in the dozens of micro-decisions software teams make daily.

Some of the items on this checklist are more challenging than others. Again, you can check out my live stream about this to get some extra help as well as extra free bonuses for those who attend. And, if you require more help, you can always talk to your peers in my community for execs in tech, the Leading Edge Club.