Influence, part 2 of 5: Research

 This is the second part of a five part series on influence as a Staff+ Software Engineer (part 1, part 2, part 3, part 4, part 5).  I've ported this here from where I originally published it on Medium. 

Research

Understand what already exists

In large companies there may be several teams thinking about similar problems. It’s incredibly useful to understand what’s already out there and how much of it can be reused. It’s not easy to find though.

Once you’ve found something similar to what you want, you need to decide whether you want to reuse it as it is, or borrow pieces, ideas, or build something new.

My personal bias here is hugely towards not wanting to be oncall for a custom service so I far prefer to use existing infrastructure that another team owns. This doesn’t always work. One thing you need to be especially aware of is the reporting chain of an infrastructure team you rely on — if they don’t at least end up at the same Executive then you’re going to have limited ability to influence their direction if you need features or bug fixes.

See talk to people.

Learn from managers

There are manager training courses for a variety of useful things: how to have difficult conversations, soft skills, delegation, career planning, etc.

The funny thing is that these overlap hugely with soft skills that senior ICs have. At some point it’s all about talking to people. Even with people who work for them, managers can’t arbitrarily instruct people with little reasoning as people will disagree and may simply ignore the instructions or, at the extreme, leave their team.

This book is frequently referenced in manager training.

Understand who’s backing a project

What’s the motivation for doing this particular project? Who above you is supporting it? Is it universally supported?

When you take on a new project it’s worth thinking some of these through because it’ll give you a sense of whether you’re likely to accidentally tread on anyone’s toes. It’ll also tell you what will happen if one of the backers changes teams or leaves the company: if there was only one backer then this project may stop at that point but if there are many backers then it’s likely to keep going.