Skill Level Beginner
- In any product management role, it's likely that you'll be interacting with a group of engineers the most. If there's one group of people you would want to earn the respect of, it would definitely be them. Now, not to generalize too much here, but for the most part, engineers are lovers of detail. So when you're talking to them, emailing them, or otherwise working with them, you'll want to be as detailed as possible. I can't tell you how many times early on in my career that I failed to provide enough detail when talking to engineers or sending them specifications. For them to develop efficiently, they need to know things that other people don't, like what happens when the screen is displayed in another language, and what the error state should read if something goes wrong or there's no data to show.
Luckily, you'll get better at working with engineers as time goes on. You'll start to predict the types of information that they'll need and pull together briefings that actually add value. But in the meantime, I've got you covered. Here's some more tips for working with them. First, if something goes wrong, it's your fault. This is going to sound harsh, but it's true. As the product manager, you're ultimately responsible for the success of the product. If one of your developers made a mistake, it's likely that your specs weren't good enough or didn't explain yourself correctly. Don't blame them for a mistake that you made but rather try to understand where you went wrong so that you can avoid making the same mistakes in the future; futureproof everything.
When you're discussing a new feature, make sure you have a good idea of where it will go in the future. You need to consider what the minimum viable product will be and where it can be taken in later iterations, otherwise, development could stall. If you're able to give a full overview of how you foresee the future, they'll be able to plan ahead and futureproof their solution to avoid costly technical refactors. Do the work upfront. Check data ahead of time and go over logs, time sheets, and existing commitments before you ask an engineer to do something.
If you carry out some research up front, it shows your engineers that you respect both their time and their abilities and that they're not the only ones at the company who are working hard. Watch out for tech debt. Tech debt is a term used to describe something within the code or technology that will have to be fixed at a later date as a result of not being done properly the first time. Let's say that we're building a new feature that accesses a database. We might use an existing database to save some time, but if it becomes popular enough, then it will eventually need its own database, necessitating a long and complicated switchover.
Engineers hate tech debt because they're the ones that have to deal with it, and many of the problems are caused by managers who rushed them during the initial build. Don't be that person. Trust their advice the first time. Don't treat engineers like an agency. What I mean by this is don't work in a bubble without allowing your engineers to share their input. Don't just hand over a set of completed requirements and expect them to code something up. Always give them the opportunity to provide feedback. After all, though coding is their specialty, everyone has valid opinion on the product.
So there you have it. Don't learn these things by making the same mistakes I did. Follow this advice and I guarantee you'll have a more productive working relationship with any engineers you work with.