How To Influence Your Development Manager

A guide to building rapport

Introduction

I get it. You have a great idea and you have told your manager about it for months but nothing seems to change. The machine keeps moving and you don't have any influence on it. Tough luck. Well maybe not... Joe Schmo over there seems to get his ideas adopted regularly and his ideas are crap! What gives?

Logic would tell you that the best ideas should rise to the top. The person with the best arguments should have their ideas adopted and if you have crap ideas those should be thrown out. The most capable people should be promoted and the less capable people should stay where they are or get fired. This unfortunately is not how the world works. People don’t make reasoned decisions. In fact people are more likely to make emotional decisions and then back fill it with reason. So how do you get your ideas noticed in an environment like that?

Build a Relationship With your Manager

People are relational beings. We weigh the opinions of people we like higher than people we don’t like. If you understand this basic principle you will be able to do two things. One is to realize that you need to build a relationship with your manager. Go out for a beer or coffee. Talk about things you are both interested in that are not work related. You should do this not to be ingenuous but to help the team by being someone who the boss trusts. While you should take advantage of this inclination of people to bias advice from people they like, you should guard against it for yourself. Make sure you vet decisions even if they come from trusted sources. You should also be willing to listen to advice from people you dont like. That way you make sure you not discounting good advice because of the source.

Check Your Timing

You should understand that a manager is juggling multiple inputs. Your idea may come after 3 meetings in which the manager was asked to do other things. So while your idea may be good it has to fall inline with a dozen other priorities. Don’t bring up an idea to change architecture right after product planning or in the middle of a fire storm. Make sure that, to the best of your knowledge, you find a time when your manager is receptive to a new idea.

Leverage the Power of the POC

I cannot stress this point enough. A proof of concept shows that you have a handle on the topic. You should include enough to answer the basic concepts that the idea will entail. If, after presenting the POC, your manager pushes back on an idea not in the POC ask for permission to extend the POC to include it. Technical people like to have something to look at and play with to get an understanding of the idea. You should leverage this desire and make sure ideas include a simple POC on how the concept will work.

Help Your Manager Set Small, Incremental Milestones

Let's say your idea is to adopt a new architectural pattern. What you have works but you think a new pattern could be simpler and improve efficiency. After presenting your POC you should suggest a set of small steps that can be started that will get the product moving in the direction of the new architecture. Maybe you say that all new services follow the new pattern or you pick a small piece of the product and move it over to see how it goes. If you can prove that this works, getting the rest of the product moved over will be a lot easier.

Demystify New Technology and Patterns

If your idea involves new tech you may be surprised that your manager may be adverse to that. New tech is a gamble and unless your manager is comfortable with it they may not be willing to stake their reputation on that gamble. Your POC presentation should try and educate your manager about the new tech and convince them that it will be easier going forward.

Use "And" not "But" When Talking About Existing Code and Infrastructure

Here are two statements. Which feels more inclusive?

Our current architecture is working but these new changes would make it easier

Our current architecture is working and these new changes would make it easier

It is a small distinction but the point is that you dont want to setup the situation as what we have is crap and we need to change it. Using "but" creates a contrast but using "and" acknowledges the current state and frames the changes as a continuation of the platform.

Include Other Members On Your Team

No decision should be made in a vacuum. Make sure you present your POC to other members on your team. You should be eager to get their criticism of the idea. Remember the goal is to make sure the team is making the best decisions not just to get your idea through. So make sure you are building relationships on your team and presenting your POC to them to make sure it is a good idea and that it is the best version of the idea that you can possibly arrive at.

Connect the Change Back to Business Value

Often times, if the idea is large and will take multiple sprints, your manager will have to sell the idea to their manager and so on. Connecting the idea to concrete measurable outcomes will help. This may require thinking outside the box and doing a little bit of research. You should be able to talk about how your idea could impact the business in a positive way. If you can measure that with data that would have the most impact.

---

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.