Stakeholder management series: Tips for working with software engineers
In the last stakeholder management series, I discussed working with marketers. Today, let’s take a look at working with software engineers. As Marty Cagan wrote, “There’s probably no more important relationship for a successful product manager than the one with your engineers.”
What is software engineering?
[Software engineering] involves creating high-quality, reliable programs in a systematic, controlled, and efficient manner using formal methods for specification, evaluation, analysis and design, implementation, testing and maintenance.
[Association for Computer Machinery]
Software engineering is a discipline that adopts engineering approaches, such as established methodologies, processes, tools, […] in the development of large-scale software seeking to result in high productivity, low cost, controllable quality, and measurable development schedule.
[D. Patel and Y. Wang 2003]
Each definition is a mouthful, but there’s logic. Often, software engineering is equated to coding, a common misnomer. This misnomer is aggravated by the colloquial and interchangeable words used when discussing software engineers: developers, programmers, or coders. But if we break down the definition of software engineering, we’ll see it involves:
specifications (i.e., gathering and defining why and what we want to build)
evaluation & analysis (i.e., assess if it’s feasible)
design (i.e., define tactically how to achieve what we want to build)
implementation (i.e., the coding/programming, plus all the work to get it workable in the real world)
testing & maintenance (i.e., did we mention we have to figure out how to maintain this software and ensure consistency/repeatability)
measurable development schedule (i.e., do all the above within time/people/budget constraints)
These activities also don’t have to be sequential in modern software engineering. For example, one engineer is coding one feature, while another is designing a different feature.
3 Types of Software Engineers You Will Encounter and Their Responsibilities
Product Software Engineer (PSE) -> Responsible for working with PMs to define the software solution / product using common technologies and computer science or engineering principles.
Specialized Software Engineer (SSE)-> Responsible for using their deep expertise in one specific technology area (e.g., security, data, infrastructure/SRE, developer operations/tools(DevOps), machine learning).
Software Engineering Manager (SEM) -> Responsible for managing other software engineers: hiring, coaching, mentoring, firings, promoting, and compensation.
Don’t assume engineering’s job title == responsibility
We naturally look at job titles and assume responsibility. For example, a person with the title “Software Engineering Manager” has the responsibility of managing other software engineers. But that individual may also have the responsibilities of a Product Software Engineer and has in-depth knowledge in a specific, technical area. A different organization may give that person the title of Director of Engineer, Head of Engineering, or Technical Lead.
It’s also common to split software engineering responsibilities across different job titles and individuals. At larger organizations, there are usually two career tracks for software engineers: Individual Contributor and People Management. Thus, the Software Engineering Manager responsibility may be separated from the Specialized Software Engineer responsibilities.
What PMs should take away from this is, don’t equate job title to job responsibility. The 3 types of software engineers I presented earlier are about responsibilities. But job titles vary considerably across companies. To help, I’ve associated some possible job titles with each combination below:
First, when it’s a single software engineering responsibility (possible job title on the right).
Product Software Engineer -> Software Engineer (level 1, 2, 3, 4), Front-end Engineer, Full-stack Engineer, iOS Engineer
Specialized Software Engineer -> Machine Learning Engineer, NLP Engineer, Software Developer in Test, Mobile Engineer, Site Reliability Engineer, Research Engineer
Software Engineering Manager -> Technical Lead, Engineering Manager, Technical Manager, Software Engineering Manager
Second, when there’s a combination of responsibilities.
PSE + SSE + SEM -> Head of Engineering, Director of Engineering, Technical Lead, Software Engineering Manager.
Tough role because this individual has responsibility in three areas.
Occurs at smaller organizations, sometimes by necessity
PSE + SEM -> Head of Engineering, Director of Engineering, Technical Lead, Software Engineering Manager.
See how the job titles are the same as before but the responsibilities are different?
Not every person with Director of Engineering title has to have in-depth technology expertise in a technology sub-field. They can equally succeed by bringing on Specialized Software Engineers as needed.
Individuals here apply their general technology skills and people management skills more than their technology specialty.
PSE + SSE: -> Director of Engineer, Principle Engineer, Senior Software Engineer, Engineering Fellow, Research Engineer, Technical Engineering Manager.
A technology practitioner who knows how to apply in-depth, specialized expertise and knowledge to solving/creating products.
Individual contributor, not formally responsible for managing other engineers
SEM + SSE -> Director of Engineer - SRE, Director of Engineer - ML, Director of Engineering - [specialty name], Head of DevOps, Head of Security Engineering
Manages other software engineers in a specific function or specialized area
May be less directly involved in helping PMs define the product direction or solving general product problems, depending on specialty and it’s technology relationship to the product
Ensure smooth operations of technology in support of other engineer teams.
Context for Tips Below
Tips are based on the responsibility of the software engineer you’re working with, not by a software engineer’s job title.
It’s common for PMs to work with software engineers who hold all three responsibilities. Thus, you’ll have to use all the tips when working and not think about them in a siloed fashion. Be aware of what activities the individual software engineer is doing will help you know which tip matters when.
These are the foundations. As my friend George wrote, “Inexperienced [Software Engineers] and PMs often begin working together as opposing forces and it takes them years to realize that without forging trust and a true partnership neither side wins, and particularly the org takes the biggest loss.”
Tips When Working with Product Software Engineer
Candid and open conversations. Your problems are your Product Software Engineer’s problems and vice versa. Thus, you have to start out with being as candid and blunt in all conversations, not just areas you think that are technical.
Have frequent chats. This can help reduce misunderstandings and expose implicit assumptions.
Admit when you need help. For example, if you don’t understand something technical, ask your Product Software Engineer to teach you. Similarly, if you’re stuck on a product problem, bounce off your issue by clearly laying out the problem and how you’re thinking of resolving the situation. [Note: You are still accountable for solving the problem so don’t be lazy and do the thinking first.]
Solicit input and advice on non-technical issues. For example, I have discussions with my Product Software Engineer on monetization and product organization structure. These conversations help clarify my thinking and hear a different perspective.
Understand the differences and overlaps in responsibility. If you review the responsibilities between Product Manager and Product Software Engineer, you’ll uncover some overlaps (e.g., figuring out what to build, defining the development schedule, handling project management), but also clear differences (e.g., designing the technical architecture, picking the technology stack, coding). While the differences and overlaps will differ between each pair of Product Manager and Product Software Engineer, here are some commonalities.
Product Managers are responsible for validating value and business risk. If we can build whatever we imagine, will customers choose to use it and will the product make money / be sustainable? That’s the fundamental question PMs have to figure out and solve.
Software Engineers are responsible for figuring out the feasibility and maintainability risk. Can we build and maintain what we imagined, given the time/people/resource constraints? That’s the fundamental question Software Engineers have to figure out and solve.
Know when you’re acting as a “consult” versus “responsible for making the decision”. The strongest conflicts arise when you have differing opinions, but also believe each is responsible for making the final decision. If you’ve a good understanding of each other’s roles and responsibilities and have candid, open conversations, resolving your differences will be easier. Examples of conflicts I’ve seen:
PMs with strong tech backgrounds (i.e., former software engineer): Don’t think this is the technology that should be used? Don’t agree with the performance standards the software engineering team is targeting.
PMs with strong design backgrounds (i.e., former UI designer): Concerned the project won’t be completed on schedule? Concerned with the quality of code.
Share your opinion, but know you are simply adding information for the Product Software Engineer. Reciprocate when the shoe is on the other foot when a Product Software Engineer has concerns.
3 roles in 1 person problem. If you work at a startup with fewer software engineers, it’s likely your Product Software Engineer is also a Software Engineering Manager and an Individual Software Engineer (i.e., writes code). This is a challenging combination of responsibilities. Thus, you can help her or him in a few different ways:
Share the burden on people management by being open to conversations and solutions. Any performance or career issues with an individual software engineer will divert attention, so finding ways to solve these non-product issues
Advise the person not to focus on writing code for the sake of coding, but focus on Product Software Engineering activities: designing the overall product solution, managing the development process, and guiding individual software engineers. This doesn’t mean she or he can’t ever code, but that is not their primary responsibility. One way is to have the individual layout the coding framework, but for other software engineers to execute. Another way is to have the Product Software Engineer focus on coding a core feature or function as a way to “show, not tell” other software engineers.
Tips When Working with Software Engineering Managers
What’s best for the individual software engineer may not be what’s best for the product or product team. Software Engineering Managers are focused on developing and growing their direct reports. But what’s best for the individual may not be what’s best for the product or product-team. This isn’t to say, you shouldn’t try to find shared outcomes. But as a PM, you also need to have conversations when this conflict arises and champion the product or product-team over the individual.
Write quarterly feedback on individual software engineers using +1/-1. Most Software Engineering Managers will seek your feedback on their direct reports. So, once a quarter, block down 45 minutes and jot down some +1/-1 feedback you have of individual software engineers you work with. This way, you’ll have a couple of examples you can always pull from when asked, especially helpful during performance review cycles.
Try resolving issues with individual software engineers first. Have an issue? Have you spoken with the individual? Only escalate if you can’t resolve or need advice on how to resolve after you’ve tried first.
Talk to the Software Engineering Manager to understand their mentorship and career growth approach. As managers, the conversations they are having with their direct reports are often about career progression. As a PM, you aren’t likely aware of these details, but they impact the motivation and reasoning for a individual software engineer. Spending time to understand how Software Engineering Managers are mentoring and coaching their direct reports will help you understand the motivations. Better still, talk to your individual software engineer to understand what they hope to do in their career.
Tips When Working with Specialized Software Engineer
Treat each software engineer as an individual. While there are many stereotypes for software engineers, no two individuals are like. Some love to travel and some don’t. Some like video games and others don’t. Some play musical instruments and others don’t. Spending time to get to know the individual and their goals.
Recognize people’s life stage maybe different from yours. As a PM, are you in your 20s and single? Are you in a stable relationship? Are you married but without kids? Are you married with young children? As your life changes, so does your priority. The same is true for others and individual software engineers. Understanding a person’s life stage helps you understand where there might be differences and think about how to work around them.
No single software engineer is an expert at everything technical. Just as PMs may gravitate towards different specialties, so do software engineers. Talk to each software engineer to understand his or her strengthens and weaknesses, what they gravitate towards, and how they work. Some specialized software engineers are more removed from the product and how the company makes money, thus you may have to spend more time providing basic context than you would with product software engineers.
A closing comment about faith and trust
Building a good working relationship with someone takes time because, fundamentally, I believe a good relationship means you have trust. Trust in each other’s judgements and actions. You can’t do that without time interacting with each other. Your reputation (e.g., recommendations from others), brand (e.g., companies, schools, or people you associate with) and recognition (e.g., awards won, previous successes) can boost your trust signal, reducing the time it takes to build a good relationship. However, that’s harder to do with software engineers because you’re usually working on building something new, that’s unproven. Those other signals may not be enough. I’ve had heated disagreements about business risks, product direction, and don’t always have enough data to logically convince my software engineering partner. In those situations, I sometimes gambled by using my responsibility/authority card as the Product Manager. But that’s a big gamble. If the outcome is successful, I’ll have earned that trust and built a good relationship. If it fails, I’m preparing my resignation or firing. I believe PMs have to think sometimes in this manner.
People who helped contribute to this article:
George Theka, Senior Software Engineering Manager @ NYTimes
Roy Yu, Software Engineer at Facebook
Source:
Comparative Software Engineering: Review and Perspectives – Guest Editors’ Introduction
How Is A Product Engineer Different From A Full-Stack Engineer?
Inspired: How to create tech products customers love by Marty Cagan