Republished from MindTheProduct.com (https:\/\/www.mindtheproduct.com\/tips-to-collaborate-better-with-your-development-team\/)<\/p>\n\n\n\n
Why are development teams so hard to work with? You\u2019ve done your part\u2014you have your OKRs, roadmaps<\/a>, specs and designs in good shape. You\u2019ve made delivery commitments to stakeholders. Now you just need to build those shiny new features. But your software engineers are questioning the business value, being non-committal on timelines, and their deliverables are missing the mark. When you raise concerns, they bury you in tech speak and make you feel dumber than a Slackbot. What\u2019s a product manager to do?<\/p>\n\n\n\n Plenty actually. Here are a few tips to build a better relationship with your engineering team, from a developer turned product leader.<\/p>\n\n\n\n As product managers, we care about on time delivery of visible features that impact the customer or business. We often pay little attention to what\u2019s under the hood. Developers, on the other hand, take pride in how their solution is built\u2014the novel algorithm they used or how they were able to reuse components they\u2019ve developed before. The best engineers excel at this hidden stuff and want to be recognized for it as much or more so than for fulfilling the business requirement.<\/p>\n\n\n\n Even if coding isn\u2019t your thing, you can build a stronger relationship with your team by showing interest in their technical solution. Ask them to explain how they built the solution, how flexible it is, what tradeoffs they made, and what they are most proud of. Ask them how they improved that performance bottleneck. Have them explain the root cause of a bug and what they did to fix it. You will see that non-communicative developers warm up to you. You might even learn something.<\/p>\n\n\n\n More often than not, the engineers on your team don\u2019t report to you. Although your positive feedback to them is appreciated, it is appreciated much more if it is shared with their managers. With our busy schedules, it is easy to forget to formally recognize a teammate\u2019s achievements. Since I tend to be guilty of this, I explicitly add this as a step in my product process. Note the intent is not as a way to say thanks to the whole team. Rather it should be specific to individuals, their achievements, and positive attributes they demonstrated. Back your comments with specifics.<\/p>\n\n\n\n Also developers want to garner the respect of the architects and other senior tech people. Help by encouraging them to share their work with their peers. Support their efforts to promote themselves, allow some time for speaking at conferences or publishing in journals.<\/p>\n\n\n\n Make an effort to give them constructive feedback in the context of the work being done. Most will appreciate such tips and advice if it\u2019s done in the right way, and become stronger teammates. For example I might say, \u201cHey so and so, it would be great to hear more from you in our next design session. You bring a perspective that the rest of us don\u2019t have.\u201d<\/p>\n\n\n\n Just because it\u2019s your job to manage stakeholders<\/a> and drive the voice of the customer\u2019s efforts, your developers shouldn\u2019t be excluded from all such activities. Realistically, your engineers can\u2019t dedicate their time to all your customer interviews and business meetings. However they will certainly benefit from direct exposure to some of those that your software is serving. Engineers have often told me what an eye-opening experience it is to participate in a customer interview, because\u2014 as we product people know\u2014customers never cease to surprise us.<\/p>\n\n\n\n I often invite a couple of our senior architects to product brainstorming sessions. Presented with insights from our discovery process<\/a>, our architects come up with some of the best suggestions on how to improve customer conversion, retention, or other metrics. They help shed light on the technical effort required to solve a problem a certain way, and getting such information early will often streamline our solutioning process. And more than just improving decision making, involving engineers in solutioning sessions gets their buy-in and commitment up front, making the development process go smoother.<\/p>\n\n\n\n Your developers care a lot about technical debt, the sub-optimal state of the code base after repeated changes are made within typical project time constraints. While technical debt is unavoidable, your developers know how detrimental it can be to the long term health of your product. Your best developers will naturally want to prioritize reduction of technical debt over other things. But like with all prioritization, things aren\u2019t so cut and dry. Product management techniques can help here. Acknowledge that some of your dev effort will need to go toward reduction of technical debt. Challenge your developers to follow the same rigor you do when justifying new features. Which areas of technical debt will have the most business impact? How can assumptions be validated? How will key development metrics like number of bugs, developer productivity, etc. change? The bottom line is you need to take technical debt seriously, but elimination of all technical debt rarely makes sense. Work with your developers to find the right balance.<\/p>\n\n\n\n Do you like the feeling of taking charge in your meetings with developers? Letting them know what you expect from them? I assure you they don\u2019t like it. Remember, you are not the developer\u2019s boss. You are not the developer\u2019s customer either. There is a difference between telling the development team what needs to be built and telling them what to do. The former is a communication activity and a core part of your job. The latter is command and control management. Engineers seek clarity and appreciate strong communication from your product. However, they want autonomy to work their way. They want to work with you, not for you.<\/p>\n\n\n\n The product management function is often misunderstood, even by developers. Some see the product manager role as a glorified project administrator. Some feel it\u2019s a job that anyone without any special knowledge can do. Developers see their role as quite the opposite\u2014requiring both an inherent analytical way of thinking and lots of training and knowledge on their craft. So it\u2019s no surprise that developers often have a certain feeling of empowerment<\/a>, and in some cases, not so much respect for product managers.<\/p>\n\n\n\n The best way to counter this is to showcase your product chops. Consistently follow your product process. Share the results of your discovery process. Articulate the value proposition of the features you are building. Explain how decisions were reached and share the data driving your decisions. Field product questions from the team with confidence. Once you establish yourself and your role, developers will respect what you do and will welcome your experience and insights.<\/p>\n\n\n\n Finally, remember the end game\u2014getting customers to use your product! Both you and your developers want the satisfaction of having your collective efforts put to good use. Share the success metrics\u2014improvements in monthly active users, better conversions, etc. Even better, share the success stories, the specifics you hear from customers about how the app helped them. We are all human and respond to such feedback.<\/p>\n\n\n\n Your success hinges on the success of your whole team. Try these tips for building a stronger team, and I\u2019d love to hear if they help you.<\/p>\n","protected":false},"excerpt":{"rendered":"Appreciate the craft of software engineering<\/h2>\n\n\n\n
Help your engineers advance professionally<\/h2>\n\n\n\n
Expose them to your customers and business<\/h2>\n\n\n\n
Involve developers in your solutioning<\/h2>\n\n\n\n
Understand technical debt<\/h2>\n\n\n\n
Collaborate, don\u2019t control<\/h2>\n\n\n\n
Perform your role with confidence<\/h2>\n\n\n\n
Share success<\/h2>\n\n\n\n