Photo by Sammy Williams on Unsplash

Back in 2015 I built a new payments processing backend with a small team of engineers. The new system worked very well but by 2020 it became clear to me that it needs a major overhaul to keep up with the demands of a growing business moving billions of dollars every year.

At the time I was working for a company that practiced promotion-oriented culture which rewards people for shipping new services and creating new features, not for fixing old systems or making them run better. This meant that it was much more beneficial for everyone with authority over the future of this system to focus on other things. Building new features, making new integrations, or creating new ancillary systems to cover up issues with the payments processor were all better for engineers’ and product managers’ careers than actually rebuilding the aging system. It didn’t matter how much I argued or tried to convince the powers that be that rebuilding the system will unlock a lot of potential and improve most of the metrics we all cared about in the long term. There always seemed to be more pressing short term needs that took precedence.

This situation is nothing new. It plays out in various forms in many corporations. I needed to influence the organization to do what I wanted without the authority to direct people’s work, because my role is not managerial. Influence without authority.

The first thing was to figure out exactly what I wanted to do. The only way I might be able to convince management to let me embark on this project was if they also got something out of it. It was too difficult and time consuming to add new external connections to new payment processors with the existing system, and creating a design that will make it easy and fast was sure to grab management’s attention.

One of the keys to getting the project started was having a strong team of engineers assigned to work on it. But what to do when everyone is already busy with what the planning process considers as the most important thing for them to be doing?

The key is using the same promotion-orientated culture against itself. For example, I knew of an engineer who had been steadily growing in his scope of work that needed a significant tech lead role to help him get promoted to the next level. I also knew his team had no appropriate projects for him to give him that opportunity, and that his manager was eagerly looking for such opportunities. I laid down the details of what I wanted to build. I was transparent about the opportunity for the engineer, but also transparent about the risks of working on an as of yet unapproved and essentially experimental project. Both the engineer and his manager were excited to join and were ready to take on the opportunity with the associated risk.

What this meant was two additional people that really want the project to succeed. And because one of them is in a position of authority and can make time for his report to work on the project I was one step closer to making the project a reality.

In this way I slowly assembled a small team of engineers that all saw the project as a good investment of time and a worthwhile risk to be taking. I had to find the right engineering managers and product managers to get excited about the project. With every new recruit it became easier to convince the next one. Once the project was on its way it was much easier to bring it to the formal planning session and just report on its status rather than to ask for resources to get it started. It turns out that the hardest thing is to get a project started. Once it is going, it is much easier to keep it running.

In summary:

  • As an engineer, you sometimes need to exercise influence without authority.
  • It is sometimes easier to keep a project running than to get it started.
  • Use promotion-oriented culture against itself.
  • Example: Give a leadership position in your project to an engineer that needs to demonstrate leadership to get promoted. Get their manager on board with that.