This is one of a series of essays about how to relate to some of the most common types of stakeholders and teammates. Here, I’ll provide some tips for working successfully with engineers.
- Know some shit about technology and programming. For real. Not a weekend bootcamp or a few YouTube videos. If you didn’t take programming in school, take a class online, and build something real. Simple html/css/js web sites are really easy to build, for example. One of the best ways to connect with almost any engineer is to have opinions about programming languages or tech fads. DON’T fake it, but also knowing what is hard for you, what you like or find cool in tech is great small talk and icebreaker fodder.
- The most important thing the PM can do to influence an engineer’s motivation is to give them context and provide reasons why. Explain the politics, if you have to make an “exec mandate” decision. Give them the data behind your decisions. Always be willing to share reports and product docs with them.
- Even in the most “top down, corporate controlled” culture, you must remember that software engineers are skilled, and often highly in demand. They are not your minions to build your beautiful visions; they are your skilled partners.
- Don’t let them refactor without reason. If engineers are asking to refactor or rewrite software a lot, get an understanding of why, how long or often this is likely to go on, and if there are other factors in play. One CTO co-founder of mine literally banned engineers from saying in stand-up that they were “re-factoring” something as their task that day. They had to explain what functionality was being changed and why. That seemed to result in a lot less refactoring, some how 😉
- If you have talented and valued engineers and they reject process and administrative tasks, don’t fight hard. If you can, simplify and do it for them. if they still reject participation and process, become a broken, polite, but insistent record. If that fails, escalate.
- Always treat standup as not optional for the team (including the PM). Showing up and participating in standup is the definition of being on the team. If you don’t take it seriously, you don’t take the team seriously. Especially for remote people or teams. Don’t ever let engineers skip stand-ups regularly.
- Never think of your engineers as interchangeable. Engineers have unique problem solving styles, skills and strengths. Managing a development team is like managing a baseball team. You can’t make a pitcher a 1st base slugger. Or in an orchestra, if you prefer a non-sport analogy, you maybe can get a viola to play violin, but if you need a French horn, there is not much they can do for you. Its not like the roles are 100% rigid, but players have some roles they can do, some they excel at, and some they can’t do. Know what your engineers are good at, what they like doing, and try to incorporate that into your planning and management.
- Every engineer has a multiplier. The multiplier is the difference between how long an engineers estimates are and how long their work really takes. Rather than point/velocity systems, I prefer to use these multipliers for planning. Basically when an engineer “takes up” a task or needs to size it up for planning, I ask how long it will take. When I first work with an engineer I keep track of how that estimate relates to the outcome. After a few weeks you should be able to pretty accurately plan delivery (modulo tech risk, scope change, etc) from the engineers estimates times their multiplier. I’ve worked with engineers who’s multipliers have been from 0.75 to 3 or more. Don’t try to get them to be more accurate estimators, and don’t flaunt you’re multiplication in their face. It could seem like you don’t trust them. Let this be one of those subtle arts of PM’ing.
- Some engineers, especially young, ambitious, ones, might be keenly interested in, or vocal about, product or design decisions or plans. If you can safely involve them, you should try to do so. If their ideas are bad, or their “product orientation” is detrimental to the team (rather than helpful, which it can also be), be direct about it with them. On the other hand if an engineer is not interested in business context, product theories, or the why of their work, and just want to work on task, respect that and leave them alone. The outcome is what matters, not the method.