How I work with engineers
As a senior product manager, I have been fortunate to work with a multitude of talented engineers over the years. There have been many ups and downs during those interactions. And I have realized one critical lesson: the relationship between the product manager and the engineering team is paramount to the success of a product. While this may seem obvious, the degree to which this relationship is fostered and maintained can make or break the outcome of a project. In this article, I will tap into my own experience and share with you how I manage my relationship with various counterparts of the engineering team. I will discuss the challenges that I have faced and how I overcame them, and what worked for me.
Context
But before I share what works for me, I would like to provide you with the context - about the product, myself, and the high-level traits of the engineers I work with.
Assume that the product is old and mature. Like any enterprise software, it has been implemented with heavy customizations across different clients, industries, and regions of the world.
I graduated as a mechanical engineer. Thus all my technical learnings have been on the job. I am a curious person who follows the 'Stay Hungry, Stay Foolish' motto. And fortunately, I learn quickly. Whenever I am stuck with some engineering problem, I go to the internet to learn and find solutions.
While the engineers I work with, are pretty young. 2-3 years of work experience. They like to experiment with the 'cool' stories while doing the bare minimum on the topics that they deem uninteresting. Our tech stack is a bit dated, which again dampens the enthusiasm of the engineers. Engineering managers are quite experienced and understand the complexities of working in a large organization. They keep an eye on the performance of the engineers and rely on PMs to prioritize the work on the sprint. Once the priority is decided, POD leads to take care of day-to-day work and technical issues/bugs during development. Architects are quite senior and have been working in the org for more than a decade now. They are my main source of knowledge when it comes to 'why' a particular feature was developed in the past and whether the same context stands its ground even today.
How do I handle myself?
All of the below is to improve the 'TRUST' I would like to have between engineer and me.
Know the basics of the trade: I actively seek out opportunities to learn technical knowledge on the job. I ask a lot of questions from my engineers in day-to-day conversations. I google the jargon if I didn't understand it properly. Additionally, I take time to read technical documentation, attend team meetings and code reviews, and even experiment with the product itself. Over time, it helps me to speak the engineer's language, communicate effectively and make informed decisions.
Be curious and truthful about what I don't know: I am naturally curious in the development process.?I try to understand the process so that I know how things work. Later on, I might be able to optimize the same as well. Being a PM, I am in touch with PMs of other teams as well. I will ask them about a current problem that my engineer is struggling with, and check if this has been solved by them or not. If it has been, then I facilitate the learning between teams. I also encourage my engineers to ask their friends in case they are stuck.
Be demanding: Given the usual time constraints, there have been scenarios when an engineer would say many jargons in order to take a shortcut around a problem. But that's one of my jobs to read between the lines and understand the REAL motivation of the engineer. In most cases, I would demand that engineer would adhere to the best practices, and solve the problem in the right way. Because if they don't do it now, this small shortcut will lead to technical debt in the future.
Take a stand when required: During challenging times, such as delays in deliverables, or a bug-ridden code, I first firefight the issue at hand. And then?try to empathize and understand the root cause. I stand by the engineers if I feel the reasons were genuinely out of the control of the engineering team. This helps me instill a sense of support and collaboration to persevere obstacles. O have noticed that this helps engineers go the extra mile for me during demanding times.
Protect them from unnecessary meetings: Needless to say, I would usually not expose the engineers to meetings. Instead, I understand the technical issues at hand and convert them into functional/business language when required. Obviously, vice versa is also applicable.
领英推荐
Resolve the inherent tension between QA and Dev: I am usually present in the Dev to QA handover. This helps me understand if the development was done with all the points written in PRD and if no nuances were missed. I also help QA understand the context and the probable areas of impact that he/she should be testing
How do I work with Engineers?
Give them 'Why' and encourage them to ideate: I always involve Architects during the initial ideation phase. I have noticed that engineers are quite logical in their thought processes. Many times, they come up with a different perspective that I haven't been able to notice. I explain to Architects
I would also admit that they ask the hard questions during the discussions, that act as guardrails for me and keeps me on track
Be approachable for ideation: Whenever a user story is assigned to an engineer or a team, I take special time to explain my thought process in detail. Even why a button is called 'XYZ'. And I let them know all the perspectives I have thought through. And at the end, I let them know that if there is any idea for improving the solution, they should connect with me. And make sure that they are heard and given attention whenever they approach me with issues or suggestions. This makes sure that they know that their ideas are valued. And honestly, I have received some good ideas from them during the development, which were incorporated into the stories
Proper sizing of stories: This discussion happens with the architects during the preparation of technical specifications. Proper sizing of the story ensures that we take up only as much as we can chew during the sprint. This forces me to do ruthless prioritization so that last-minute surprises can be avoided and proper expectations are set with stakeholders. This also helps my POD lead to plan the development in a better practical and definitive way.
Written and verbal communication: I have been writing long and detailed PRDs to lay out each and every details that are possible on the feature. But lately, I have noticed that engineers do not go through details every time. As a result, I have started including the 'TLDR' concept, and diving the PRDs into logical sub-topics. In this way, I make sure that developers are able to find the right amount of details at their convenience. Additionally, I keep asking for some minor details about the story throughout the development, so that they don't miss them.
Provide final mockups: I have also found that I should work as much as possible to provide a finalized version of my mockups to developers. Finalized version means that there would be no changes in the design. If you think from a developer's perspective, having fully approved designs means they can avoid the frustration of endlessly accommodating numerous design changes. This not only saves valuable time and resources but also fosters a culture of trust and collaboration between the product management and engineering departments.
I would be happy to know your thoughts or suggestions on how can I improve further.
Images from vecteezy.com