For a while now, I’ve been saying that engineers go off to chase clever tech, shiny libraries, needlessly intricate refactoring endeavors, and tech debt crusades because it was easy. That’s their path of least resistance to exert control and autonomy. In fact, this is part of a broader phenomenon that also afflicts engineering managers and senior tech leaders. And I believe that it stems from a good place. By understanding this, you should be able to motivate your team and increase its focus more easily.

The Symptoms

Spotting this at the technical level is easy, as described above. How many times a day does the R&D team complain that it needs more time to address tech debt? Have you found yourself trying to orchestrate a herd of micro-services that would be a burden to maintain at a company ten times your size? This is often the case when engineers amass tech for tech’s sake.

We do things that make for a nice Engineering blog post or that could be the topic of a meetup talk. We set dogmatic standards that aren’t directly related to business benefits or outcomes. As a technophile, I’m to blame for doing this as well, and it is not always trivial to notice, especially as someone that’s part of a larger team and a particular culture.

For managers, it is a bit different. However, it is still expressed as focusing on different parts of their “craft.” One example is the leader that is hellbent on copying different procedures and processes from bigger companies, either from their own previous workplaces or things they heard about, even though it is premature. Another scenario is when managers obsess over particular methodologies, like Scrum or capital-A Agile.

It doesn’t have to be this extreme, either. Sometimes, we just allow ourselves to be entirely occupied with the Right Things, like team growth, communication, and productivity and lose sight of the bigger image. After all, no one is paying for an engineering department because they like the sound of keyboards clacking all day long. It’s about achieving specific results.

Understanding The Cause

Coming from a background of freelancing, I was used to being brought in to help teams that were in trouble. With time, I had become cynical, assuming that every company I saw wasn’t good. My mentor, Alan Weiss, taught me that it is never beneficial to come with prejudice that the other party is damaged. That seemingly small mindset shift really helped me see things differently. When you stop attributing malice or incompetence, you can see a better explanation.

The reason, in my experience, is that everyone is trying to do their best given what they see as possible. The “motivational pull” basically goes like this: Alice wants to do good. Alice looks around at the organization to spot opportunities to do good. Alice sees handling tech debt (for example) as an easy way to do it. Alice feels good. Repeat!

This feedback loop is then often left as it is for too long until things inevitably start drifting from the team’s core focus. We are just pulled towards where we feel like we can matter. Once you understand that and see it happening in your team, you can use this knowledge to your advantage and help people focus their efforts better.

Escape Velocity

Now, imagine that your organization’s culture is like those gravitational-space diagrams. Things like tech obsession have a bigger “pull” because of… reasons. They have many ICs and managers orbiting there because history has made them feel like this is their zone of genius. However, you’d like to see at least some come and join you around planet “impact.” How do you make them come to you?

Naturally, making this change requires active force or propulsion. People rarely change without any reason to do so. A mindful leader starts making the wanted behaviors more “attractive” but also works on getting critical mass there. For example, you can make managers focus more on impact by creating clear business-oriented objectives and assigning their teams the responsibility to come up with a way to achieve those objectives. Rather than limiting their scope to specific Jira tasks, let’s make them use their brains to their full potential and develop their own solutions.

I’ve had success using these analogies with teams to help people realize when they were focusing on the wrong things and creating a common language: “Bob, your team has been orbiting around those micro-services for almost three weeks now.” I think it’s time for lift-off.