Influence, part 3 of 5: Yourself

 This is the third 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. 

Yourself

Know & grow your credibility

There’s a large difference between working with people you know well and people who you have just met. Once you’ve worked with someone for a while you’ll have a sense of how they work — the hours they keep, what they’re especially good at, what they like doing.

Building this sort of relationship is easier if you’re working with someone frequently but it’s tricky when you’re just starting to work with them.

There are a few tricks that work well to get this started on the right foot — one of the best is to have someone who knows both people introduce you. Don’t be afraid to ask someone to do this as often it lends you a small amount of instant credibility.

Train your weaknesses, apply your strengths

The bullet point is from triathlon training — you always want to work on what you’re bad at, but when it’s time for an actual race you want to make use of what you’re really good at. The same principle applies here: if you can decide how to approach a problem then by all means do so in a way that plays to your strengths.

Seek constructive feedback and train yourself to process it effectively. This isn’t easy and really dings one’s ego, but is one of the most effective ways to improve.

People are inclined to say nice things to each other, so you have to work to get people to do the kind of thinking that will help them isolate where you need to improve. However, it’s good to pay attention to getting critical feedback when it’s not things are going well, so that you have tools to handle your particular weak points when you are at a point where you need to rely on them.

If a project succeeded then it’s hard to know precisely what caused that, but if it failed then you can probably see why.

Accept failures

Projects will fail to happen or be cancelled. They might be technically infeasible; there may be other things that are higher priority at the moment; the political landscape may change and the backing for a particular project may go away; it might be that you made a mistake. Or there might be a combination all together.

Accept that this is going to happen to you. It’s never very pleasant, especially if you’ve invested a lot of time into a project. Try to learn from this, though — why did the project fail? What would you have done differently? Were there any warning signs along the way?

Write a postmortem, even if it’s only for yourself. You can make occasional mistakes and not completely derail your career. Try especially hard to tease out your mistakes from what wasn’t under your control.

See Patience.

Pick your battles

You’ve reached an impasse deciding something. Do you escalate? Live with it? It could be as simple as code style or as complex as whether to even do a whole project. It’s important to think about how much time you’ll end up spending on this if you push on it and what effect it’ll have on the people who disagree with you. You’re likely still going to have to work with them.

For things that are small, often the best strategy is to just let them go. By all means make your point, and get it on the record if you want, but know that you can’t be right about everything and good now is better than perfect never.