I’ve recently become a mentor at the plato network. As part of that, I’ve worked with them to write down some stories about my experience at Auth0. I thought it’d be interesting to share those stories in my blog as well. Published initially here.

The Problem

As a senior IC, you don’t have a team of engineers. Instead, you will have to influence other people to make things happen. Your seniority helps provide some “respect” and a halo effect. However, you still have to make your case to Product Managers (PdMs), Engineering Managers (EMs), and execs. Sometimes what you believe would be beneficial is very different from their current priorities. They are accountable for their team’s execution, while you are — despite your seniority — more of an influencer.

I was interested in having our teams work on a few reliability-related initiatives that I thought would be valuable for our customers. What I was lacking were engineers to make my ideas a reality.

What I did

First, I looked at the data trying to grasp what the problem was and understand potential solutions. I analyzed past incidents, the overall state of our system, and customer tickets. I summarized the issue and tailored my message to different audiences: Product Managers (PdM) and Engineering Managers(EM), and executives/directors.

When talking to PdMs to add my proposed initiative to the backlog, I said: “If you do this, you will have fewer interruptions and work on product items uninterrupted.” Also, your customers will be happier because your product will be working all the time.

To EMs, I would usually explain how this would reduce reactive work and continuous fire fighting. It’d also result in a more stable product, which means that engineers are happier and more productive.

When engaging in conversation with executives, I would talk about brand damage, negative impact for the company, and how the system’s reliability needs to be on par with other features. I borrowed a hugely persuasive argument from one of my peers: “reliability is the one feature that everyone uses. If our system is down, no feature is working”.

Being aware that teams are usually time-constrained, I would pitch solutions in iterative steps, following the 80/20 rule. Instead of just throwing the problem at them, I proposed solutions that would dissect the problem into incremental parts. That way, they could make iterative progress and not consume most of their quarter. With a concrete plan in place, I met with each team and explained what we needed. I also told them I would be available for all of their questions throughout their work on the project.

Lessons learned

• Align your own goals with the organization’s planning cadence. In our case, it happens quarterly. We discovered much of the problem close to the beginning of the planning cycle. Thus, we were a bit late with presenting it to the teams, which made it harder for them to include it in their backlogs. The sooner you can show the problem to teams, the better. You want to get to quarterly planning with them knowing about your important work.
• Whenever you talk about improvements to non-functional requirements, it is advisable to tie things to business outcomes and customers’ needs. I framed the problem around faster and more reliable delivery, happier customers, and even potential upsell add-ons. I pitched a business case for the add-ons and provided an example longer-term roadmap. Attaching reliability improvements to tangible things like $$ makes it easier to make a case for them.
• Talk to all stakeholders separately. When lumped together, people tend to behave with a mob mentality and are more likely to resist changes to plans.
• Don’t leave any of the stakeholders out. If anyone is missing, people will start to speculate why that is the case. That almost happened to me, but then I rushed to talk to a person that I thought I could omit.
• Don’t just talk the talk, walk the walk. If something is important, make yourself available. I blocked time in my calendar to work on this, and reassured people that they could ping me anytime. If it wasn’t important enough for me, I can’t expect that it would be for them.

Conclusion

Influencing stakeholders and teams is time-consuming and requires patience, but is extremely important as a senior individual contributor. The more successful you are at this, the more likely your ideas are likely to see the light of day.

If at first, you don’t succeed, consider trying once more. Timing, audience-specific messaging, and emotional aspects play into the final decision whether to prioritize your work or not.