5 Tactical tips for product managers working with software engineers.
Have you thought about how best to work with software engineers you interact on a daily basis? What are their challenges and frustrations? How do they like working with product managers? What can you do to make their working lives better, and thus yours?
To answer such questions, let’s first try to understand what roles software engineers perform. WARNING: The information presented below is a framework, not an exhaustive or definitive definition of the role of software engineer, which varies across companies.
What’s the role of a software engineer?
A software engineer’s role focuses upon applying technology to solve problems by:
architecting systems and/or interactions among systems
implementing or developing software (aka programming, writing code)
managing software engineers (aka technical people management)
defining and managing software engineering development processes
In summary, software engineers are focused on ideating, designing, programming, and maintaining computer software systems. This definition doesn’t exclude them from other roles, such as driving sales or managing financial budgets. However, by defining the primary role of a software engineer this way, I’m able to draw boundaries that help us contextualize how product managers can best work with software engineers in their primary role.
5 Tactical tips for working with software engineer
Act as a product manager, not as a software engineer.
This is an obvious statement, yet I see product managers falling into this trap repeatedly because engaged PMs gravitate towards solving problems.
For example you might:
dictate how to architect a system because you’ve previously build a similar product
start writing code because you were a software engineer or took a developer boot-camp to get a change out faster
act as informal people manager for the software engineering team because you have people management experience or software engineers don’t want to do people management work
write technical documentation because you’re good at written communication
modify the software development process because you want to shorten the development time
While all the above are commendable and in certain cases, necessary actions that can be justified after the fact, you’re still acting in the role of a software engineer and not as a product manager. Even assuming your intentions are good and the results are positive, such actions are likely short-term band-aids because long-term, it’ll cause the following consequences.
You’re product work will suffer (e.g., understanding the marketing/industry, talking to users or potential customers, communicating, defining clear metrics, writing good product requirements or user stories) or you’ll burn out from overwork.
Roles and responsibilities between product manager and software engineer will blur, confusing everyone and making it difficult to manage accountability
You’ll make some software engineers angry because you’re telling folks how to do their jobs, depriving other software engineers from stepping up into their role, and actively encouraging others to disengage or free-ride.
Thus, remember. Act as a product manager, not as a software engineer.
——————————————————————————————————————
Make and own business/product decisions.
One of the toughest part of a product manager’s role is making decisions made under uncertainty (i.e., unclear or incomplete information) with time and/or resource constraints.
Examples:
Which features should I prioritize first for my users/customers?
Should I delay the software release with the known defects?
Do I continue to put time and resources to iterate on this problem or pivot to the next one?
Such decisions often have large consequences, sometimes negative. Regardless of the difficulty, a product manager must make decisions, even if that decision is to wait for more information to make another decision. Product managers that do not or cannot make decisions will cause software engineers to:
lose confidence in the product manager’s capabilities, and thus the product
take over from product manager’s role, thus diminishing the software engineer’s capacity to perform as a software engineer
seek someone else to be the decision maker, diminishing the product manager’s role
pause and stop software engineering work
churn and flounder by performing wasteful or unproductive software engineering work
attempt to manage all possibilities, ultimately resulting in burn out
Thus, it’s important that product managers make and own business/product decisions.
——————————————————————————————————————
Talk to your software engineer about their roles and expectations.
While you might be talking to software engineers all the time, have you asked him or her how they define their role and responsibilities? As I warned before, there’s no singular definition of a software engineer’s role. Even if there was, no software engineer can do everything or everything perfectly. But by talking with your software engineer, you should be able to compare how they define their role and responsibilities to your expectation of their role and responsibilities.
How to talk to your software engineer about their roles and expectations
Write down top 5 activities you think are the software engineer’s responsibility. You can use these 4 categorical areas as guidance:
architecting systems and/or interactions among systems
implementing or developing software (aka programming, writing code)
managing software engineers (aka technical people management)
defining and managing software engineering development processes
Add top 5 activities you don’t think are the software engineer’s responsibility, but you see the person consistently doing this now.
Ask the software engineer that you’d like to talk, to better understand his or her areas of responsibility. If you’re uncertain how to initiate this conversation, preference the conversation as an experiment, that you’re trying to find ways to improve yourself on how you can be a better product manager when working with software engineers.
Ask him or her about their role and responsibilities. Example questions:
What part of your role do you excel at the most? The least?
What part of your role do you enjoy or struggle?
What do you want to do more of, or less of?
What are the roles and responsibilities you expect of product managers in general, of me in particular?
What are areas I can help you in your role?
Synthesize and compare your conversation with what you previously wrote.
How to analyze the information will have to be a separate topic, but by just comparing what you heard to your assessment, you’ll have a starting point to understand if your expectation of the software engineer is the same or different as his own expectation. And if you’re a micromanager your work with software engineers, it’ll be the beginning of a journey to set clear role expectations, goals, and expected outcomes.
So, talk to your software engineers.
——————————————————————————————————————
Listen and incorporate meaningful feedback.
If you’re doing #1, #2, and #3, now it’s time to give you the next, harder tip: Listen and incorporate meaningful feedback.
If you’ve started conversations with software engineers and identified the way forward is to better define role and responsibilities expectations and differences, it’s now time to start listening and incorporating their feedback. To work better with someone, it’s a two way street.
How to Listen?
Ask questions. What, When, Who, and How are the best type of questions. Try not to start with Why questions because this is a type of question that often results in defensiveness and forced justification.
Take notes. This doesn’t mean you should take dictation, but write down important points, either during or right after the conversation.
Be curious. Admit when you didn’t know about something you just heard and then, dive deeper with the person.
Show you care. This person took the role of a software engineer for a reason. Maybe it was financial. Maybe it was because of the urge to build. Maybe it was an area they naturally excelled.. Maybe because they liked the people they met. Maybe because their parents were software engineers. Learn about it.
From these conversations, you’ll get to know the specific person better and then, be able to understand if you should incorporate any of the information they provide back to you, to adjust your #1, #2, and #3. That’s why I use the term this tip: Listen and incorporate meaningful feedback.
——————————————————————————————————————
Facilitate communication across teams and roles efficiently
Product managers aren’t software engineers. We aren’t designers. We aren’t sales or finance. We’re not HR or recruiting or even customer service. And even if we sometimes act as pinch hitter in some of these roles to get our products out, one consistent activity we must do is facilitate communication across teams and roles efficiently.
I’m emphasizing efficiently because I’ve seen product managers struggle with managing communication across numerous, different stakeholders. Even in the small stage companies or product teams of less than 5 people, a product manager must communicate with multiple different roles, sometimes both internally and externally. Managing the communication effort itself consumes so much of the product manager’s time and energy, the product manager doesn’t have any time to define the product requirements or success metrics that software engineers need.
The impact on software engineers us typical pause, stop, or rework and/or long working hours because product requirements were poorly made or undefined
How to more effectively facilitate communication across teams and roles?
Reduce ad-hoc communication by creating a written forum for commonly asked questions that’s maintained and update along with consistent, short meetings for discussions
On the written forum
Force everyone to use the same tool. Whether it’s Google Drive/Google Doc, Confluence, Trello, Notion, Basecamp, Excel, Word, Consistency is better than 3-4 different tools. If there’s a conflict on picking a tool/forum, choose the tool used already by the majority of individuals.
Keep it updated, but don’t go overboard. Write information that’s frequently asked, but not one-off.
If the information feels outdated, delete it. Small amounts, but accuracy information is better than large amounts of most accurate and some inaccurate information.
Make it a habit to direct people to the written forum, even if the answer is missing.
On the meeting
Consistent timing is critical for building a cadence and behavior
Shorter meetings (30 minutes) is better than longer (1hr) because you’ll have multiple individuals with different roles who may only seek a small piece of information/update. If you didn’t get through all the discussions in 30 minutes, consider increasing the meeting frequency or hold specific meetings on a topic for discussion
Document decisions and action items from meetings and publish it in written forum. Action items should be assigned to an individual by name.
Facilitate the completion the agenda/update prior to the meeting by setup automate email or Slack reminders the 1 - 2 days before the meeting
After reviewing previously agreed upon action items, have everyone silently read the agenda for 2 - 3 minutes. Then, proceed round robin whereby each person can ask questions of others in the meeting.