Easier Said Than Done

some of my experiences on influencing without authority

Nov 23, 2024

While I’m purely in the land of management overhead these days, I spent a good chunk of my career bouncing between manager and individual contributor roles. I enjoyed both for many reasons. As a manager, I like focusing on coaching and growing people, and building a strong engineering culture. I like helping a large number of people work together towards a common goal. As an individual contributor (IC), I like the freedom to dive into the hard problems the organization is facing; building community and bringing people together; and in general, improving how things run.

All You Have To Do Is Ask

After my last post, Jerry Pett asked the following question in a comment.

Is there something that ICs can do to get investment from managers who either don't know what to do with us or only give the chore type tasks and prevent you from doing what we're talented at? If that's too big a topic for a response here could you write a post on it?

…and here we are.

Jerry’s question gets to the heart of what many ICs struggle with: how to carve out influence and trust in environments where roles aren’t clearly defined.

A Familiar Topic

The short answer to Jerry’s question is that you have to start by building trust, then showing success - at first with frequent small victories, then with larger and larger wins. Other than my first few years at Microsoft where I was basically a code monkey, I spent most of my IC career there working directly for a Director or VP where I quickly figured out they rarely told me what to do. At best, I would get pointed in a direction, but as I took time to build a strong relationship with them, they trusted me (and counted on me) to figure out the most important technical (and eventually, cultural) problems the organization needed to solve - and then (either through my own work, or working with others), get those problems solved.

This role didn’t start with blind faith. It started with building a relationship with my managers, as well as my peers on the team. I never tried to solve the biggest problems first. I solved small things that helped the team grow. I often solved problems that the org didn’t know they had. Over time, my managers trusted that I would help the team grow - and that in doing so, it helped them focus on business or organizational issues without worry of the technical challenges or growth in the organization.

It’s also much, much more than just delivering a bunch of solutions to hard problems. I spent a lot of time understanding (and clarifying) the challenges my managers thought they had, then discussing, debating, and reiterating those challenges. I had to build relationships and trust with my peers (who were all senior managers), and their teams. I couldn’t - and never expected teams to work with me or do what I told them because I said so - I wanted them to work with me and solve collective problems because they wanted to.

Start Small - Think Big

The first time I found myself in this role, I didn’t know what I was doing (to be fair, I’ve been in a lot of roles in my career where I didn’t know what I was doing). I had (through my own choice) moved out of a management role back to an IC role - and thought I would just write a bunch of code and that would be that. I was very wrong. My manager pointed me at problems. He helped me grow my network. He told me what he was concerned about - but he rarely told me what to do. He left that entirely up to me. Some of the problems he found weren’t worth solving. I found that building relationships with a wider network gave me more perspective on problems thatn I had before, and I ended up using my own judgement and intuition to figure out where I should invest my time.

And it worked.

I fixed long-standing bugs. I helped optimize all kinds of things. I did a lot of the work that nobody else wanted to do. At one point, I took on the task of fixing several hundred static analysis issues (something I did many times in my career). The first time, however, was using tools from Microsoft Research (MSR) - which were good, but not perfect. My analysis of the issues and feedback to MSR led to lifelong relationships (and trust) with incredibly intelligent individuals.

The interplay between IC and Management roles taught me the importance of pairing technical insight with strategic alignment, enabling me to contribute meaningfully regardless of my formal title.

A Rose By Another Name

The last time I played the role of senior IC was just a few years ago. Despite playing this role many times, I wasn’t exactly sure what I was supposed to do. My manager at the time told me often that. “he wanted me to have opinions about how we developed and delivered software”. He knew that I had decades of experience and study behind me and knew I could have an impact. At first, I didn’t - because I didn’t feel like I had the credibility and trust to share my opinions. But as I got to know the team, I did have opinions and I did share them, and they helped the team.

Over time, my role moved very close to a chief of staff role. I read Consigliere by Richared Hytner, and learned / realized that I am a very good number 2 - I love being the Ryker to a good Picard. There’s some advice in here as well for those who want to be number 2s.

"How much time have you devoted to thinking about how to make your C’s job easier?"

I found additional advice in Tyler Parris’s Chief of Staff. This quote in particular spoke to me as it describes what I did during some of the most successful IC runs in my career.

"In many situations, you need someone in your organization with a reputation for getting things done; who can deal with as many issues as possible so that you don’t have to; who doesn’t have a particular departmental agenda; who has an analytical bent, can make sense of the unprecedented volume and sophistication of data you’ve got at your disposal, and translate it into options, proposals, and recommendations; and who can ensure that your strategic thinking is translated into action, measured, and adjusted over time. The chief of staff is perfect for this situation."

Other books like Will Larson’s Staff Engineer, or The Staff Engineers Path are packed with great advice on leading and influencing without authority.

One short line from Larson may contain the best advice I can give (or take) on Jerry’s original question.

"Never surprise your manager. Nothing destroys trust faster."

To summarize the above and to guild on the advice above,