In the previous part, we listed common failed approaches for managing non-feature work (i.e., architectural changes, bugs, tech debt). Following up, this article will delve into the principles that should guide tech leadership in coming up with the right way to keep these under control.

Principle: Impact First and Product Involvement

The failed approaches often stem from the idea that Product should be side-stepped to allow Engineering to handle non-feature work. By allocating time, leadership hopes to secure time investment without having to justify it. The problem is, of course, that all work done should be driven by the impact it provides or enables. Otherwise, teams are going to perform useless work—in that it will not matter that they spent their efforts on something.

Having the prerequisite that work must deliver impact then makes it evident that Product must be involved and not avoided. Whatever approach is taken has to go hand-in-hand with the principle of Product Partnership. Executives I’ve worked with that try to shy away from this partnership were always stuck fighting an uphill battle.

Bugs that affect the customers are no different than new features, which get prioritized by Product. Bigger endeavors often require a real investment of time and effort, and so, your team must learn to communicate its agenda in biz-speak. Don’t just say, “we should rewrite to use $SHINYTHING.” Instead, make the case of what is there to be gained from the effort. Help consider all the different business tradeoffs and decide on the right amount of time investment to ensure a good ROI. Will it make development faster? Allow getting the best talent? Necessary due to regulatory needs? You and your entire team should be providing arguments like adults, and not just lie on the floor in the middle of the store yelling, “but I wanna!”

This also ensures that tech executives do not abuse the vast power they have.

Principle: Engineering Autonomy

With that in mind, I still believe that to create world-class engineering teams, one must provide them with freedom and autonomy. This, in turn, allows the team to foster an overarching sense of ownership, Product Mastery, and enable self-actualization.

You might think that this principle is at a clash with the previous one. I can hear you thinking to yourself, “what autonomy is he talking about if everything has to go through Product?” The key is to provide autonomy for things that are under the Purview of a remarkable engineering team and in a framework that keeps the focus on impact.

Technical Capital instead of Technical Debt

One example of autonomy that’s important to foster is allowing the team to focus on creating capital rather than just minimizing debt. You cannot join an engineering all-hands without hearing people talk about technical debt. Of course, your debt should be managed and minimized when possible. But, what about the creation of capital? I’m not merely talking about adding new features, but about the creation of force multipliers.

For me, technical capital consists of capabilities and tools that allow the team and organization as a whole to gain a consistent edge in some aspects. For example, I’ve seen companies that remain ahead of the competition by specializing in a specific niche of bleeding-edge tech that allows them to do things no one else in their market can. Relying on bleeding edge though means that you’re going to get cut every now and again—for them, it’s an investment worth making.

Another example of tech capital is creating tools that then act as force multipliers for others in the company. I often see engineering teams that are busy creating “value” in the form of churning out tasks related to different emails, notifications, and marketing collaterals. There’s no denying doing that is valuable, but every email updated—by copying a sentence from Slack and pasting in the email template—is a small improvement. Instead, the best companies I work with turn these into capabilities. An autonomic team might decide to spend time to create or integrate an email CMS that then allows non-engineers to manage things without the middle-team and free everyone to do what they’d rather be doing.

Allowing Product Preemptions

The other side of the autonomy coin is that these Engineering endeavors cannot chain the organization. How many times have you been part of a discussion that said: “We already started the database/frontend/language/framework migration, and even though we were supposed to be done a month ago we cannot stop now and have to push back over things a few more weeks until we are done”?

It’s excellent that Engineering has initiatives—it’s a must if you intend to create a remarkable team—but it cannot come at the cost of holding the entire company hostage until those initiatives are done. As a tech executive, you should create a culture that’s focused on bite-sized changes, even for significant technological changes. It might require more work upfront to allow for a hybrid mode—but would you want to be in the middle of a colossal rewrite when a pandemic (or its second wave) hits?

Principle: It’s Not a Sprint if It Never Stops

This principle might feel unrelated to non-feature work but bear with me for a second. We often call our work iterations “sprints” without thinking about the meaning of the word. If you’re sprinting, by setting stretch goals and working hard to get them done on time, what do you do at the end of the sprint?

Most teams have a couple of hours to do retrospect and plan the next sprint, and off they go sprinting again. This is, effectively, sprinting forever, never taking the time to allow the team to recuperate. That’s not to say that teams require a week off between sprints.

However, allowing for regularly scheduled times of work with less stress will enable the team to become more resilient. And that more lax period of time is a great candidate for non-feature work (I told you I’d get around to our topic eventually). Some of the best product companies in the world—such as Basecamp—employ these methodical periods between sprints.

Summary and Next Steps

We saw the fallacies of the failed approaches in the previous part and covered the principles that should guide our path if we want to achieve an exquisite equilibrium. The next (and final?) part will cover the successful practices to strike the right balance. Subscribe below to make sure that you get it!

Update: Part three is now available here.