How to Communicate with Engineers
Why communication with your engineering team is critical
‘We need to spend time refactoring the code for the next few weeks’, says the engineer.
‘Burn in hell’, says the product manager.
Why communication with your engineering team is critical
If you want to be a really bad product manager the best way to do it is to have a really bad relationship with your engineering team. Nothing guarantees bad products more than a bad relationship between a PM and engineers.
Working with an unmotivated team of engineers who resent what they’re building, hate the product manager and are consistently watching the clock until they can head home to watch Game of Thrones is a really unpleasant experience.
Communication is a critical part of creating a strong and productive relationship with your engineering team.
The rules for communicating with your engineers
1. Remove barriers
The division between ‘product’ and ‘engineering’ is counterproductive. Instead, see yourselves as 1 team. You are not a special product snowflake who dishes out work to the engineers and tells them what to do. You are not ‘above’ the engineers – or anyone else in the team – because you can put together a business model canvas and a few graphs in Powerpoint. You are all the product team.
You are all building a product to delight your users and achieve your business goals. The users of your product won’t have any notion of your product being built by a team of engineers and a product manager in an agile fashion with kanban boards and Slack channels. They will experience it as a single entity and you must all see yourselves as 1 team.
Sit together on the same bank of desks if possible.
If your engineers start talking about ‘product’ as though it’s a separate entity or part of the company, kindly remind everyone on the team that you’re all building the product. Lines of code are not just lines of code; there are real human beings interacting with the product on the other side of the screen.
If you’re a PM in a remote set up, visit your team on a regular basis. Make sure you stick to your daily stand ups and use video in your video calls so that your team can see you and your face every day. Your face is important – so use it. Put your face in your avatar on Trello, on Slack, on Jira and any other tools you use. And make sure that the rest of the team does the same. Remote teams will not work without faces.
There’s no doubt that it is tougher to build a sense of oneness with a remote team but it is possible to remove at least some of the barriers by regular daily interactions.
Use language which reflects this notion of your single entity. Use ‘we’, ‘us’ ‘our goals’, ‘our achievements’ and ‘the product team’ to describe yourselves and what you are looking to achieve. Give yourself a team name and use that. Don’t support the notion that somehow the product team is separate from the tech teams. Use language that supports the idea that you are 1 team, building a product together.
Lead
As a product manager, it’s vital that you can demonstrate leadership within your team and indeed your organisation. But what does leadership even mean?
Leadership is often a bit of a buzzword which has many different definitions. There is no 1 definitive way to characterise strong leadership so I won’t bother to define it in one single sentence.
For me personally, product leadership is demonstrated through attitudes, behaviours and personal principles:
- Take extreme ownership– the concept of Extreme Ownership is taken from a book by a US Navy guy who wrote a book with the same name. Here’s his take on how to be an extreme leader.
The Dichotomy of Leadership A good leader must be: confident but not cocky; courageous but not foolhardy; competitive but a gracious loser; attentive to details but not obsessed by them; strong but have endurance; a leader and follower; humble not passive; aggressive not overbearing; quiet not silent; calm but not robotic, logical but not devoid of emotions; close with the troops but not so close that one becomes more important than another or more important than the good of the team; not so close that they forget who is in charge. able to execute Extreme Ownership, while exercising Decentralized Command. A good leader has nothing to prove, but everything to prove.
- Have self discipline – if you say you’re going to do something, do it (an engineer never forgets). This could be as simple as sending around the notes after a retro or grooming the backlog before the next planning session. Your team will notice if you don’t follow through on the things you’ve promised to do. And they’ll question your authority and integrity as a result. If you have no intention of doing something, don’t say you’ll do it.
- Speak up on behalf of the team – Praise the team. Talk about your successes. Defend the team when stakeholders complain that they never get what they want. Sitting in sheepish silence when others are trashing your work is weak. Sure, listen to criticism, but if you think it’s unfounded, challenge it. Stand up for yourself – and your team.
- Listen – such a cliche but it’s incredible the amount of time we spend waiting to speak rather than listening. If your team are speaking to you about tech debt, the complexity of a feature or a concern about the product strategy, listen to what they’ve got to say and respond with an engaged answer which addresses their concerns. However, if a discussion is descending into a black hole of unimportant drivel and debate as can sometimes happen when you’re speaking in a group, cut the conversation short and bring the team’s attention back to the matter at hand.
- Make decisions – Often as product managers, we are forced to make decisions with little data to help us. Naturally, we want as much data as possible to ensure we’re not barking up the wrong tree. But the truth is, sometimes even with a huge amount of data to back up a specific decision, you won’t know whether your idea is going to be successful until you take the plunge and do it. Indecisiveness is a killer in product management. Do what you can to mitigate risks but have the guts to make decisions. Indecision means you’re preventing yourself from knowing more than you do today.
- Be unpredictable – one of the most powerful ways to demonstrate leadership is to be unpredictable. Predictable behaviour makes others feel too comfortable in your presence and can sometimes give others a feeling of control over you. Specific unpredictable behaviours can jolt others into paying more attention to you and force them to look up to you as a leader. For example, if you’re always praising the team in your retros, in your next retro, focus only on the negatives. Or, if you don’t usually speak up in standups, make a point of talking about a specific story or about something which is going on in the wider context of the business. If you’re a happy, jolly person a simple tactic is to not smile at all for a few hours. Engage with your team as normal but simply don’t laugh at any jokes or crack any yourself. Go and sit on a different bank of desks and make yourself unavailable for an entire day. These sudden, unpredictable, alarming shifts in behaviour disarm people and make you appear as a stronger leader. Don’t do it too often, else you’ll appear to have a personality disorder, but a sprinkling of unpredictable behaviour every now and again will help you create a strong sense of leadership.
Create BS free zone
Engineers have many talents. Aside from their mind boggling skills for problem solving and writing lines of beautiful code to power your products, all engineers are born with an innate, superhuman capability of sniffing out bullshit.
Putting together a deck with some fancy numbers and using phrases like ‘empower’, ‘leverage’ and ‘solutionize’ may win you brownie points in the boardroom but you’re dealing with a different kettle of fish when you’re speaking to your engineers.
They will call you out on the slightest whiff of BS so if you’re thinking of using buzzwords to motivate or get buy in from your team, forget it.
Instead, speak in plain, simple, honest terms. Explain what you’re trying to achieve and why. Be as brutally honest as you possibly can and leave the cliches for meetings with your sales and marketing team instead.
Ask your team to call you out every time you use a BS phrase. Eventually you’ll learn to remove them from your vocabulary when you’re speaking to the team.
Motivate
A friend of mine once described engineers as cats and I think the cat analogy is probably the most accurate of all the offensive terms I’ve used to describe engineers throughout this piece.
But describing someone as a cat isn’t offensive.
Cats are smart.
If you want a dog to do something you tell it what to do. Cats won’t. They won’t ‘sit’ or ‘fetch’ like dogs. No no. They are too smart for that.
If you want a cat to do something, you’ve got to give it some strong, tangible incentives. You have to make it explicitly clear how the cat will benefit from doing something. You have to motivate the cat to do something.
Laying catnip is crucial to getting developers on board. As a product manager, motivating your team means laying down the catnip and explaining the wider context to ensure your team want to do the work that’s required.
Motivating teams is difficult. How do you do it?
Here’s a few ways I’ve found to be particularly useful.
1. Explicitly link the everyday work back to the overall vision and goals
Getting bogged down in a particularly challenging bug fix or a feature can be demotivating. A demotivated engineer who is peeved off about working on a particularly unexciting piece of work can have a knock on effect on the rest of the team. 1 demotivated engineer will tell 3 others and their mood will be negatively impacted too. Before you know it, the whole team are unhappy because of 1 story that doesn’t seem clear or a bug fix that seems irrelevant. To avoid this, make sure you make it explicitly clear why a particular bug fix or story is relevant to the bigger picture.
For example, if you’ve prioritised a bug fix, explain why it’s so important to fix it. Explain the impact that this bug is having on the business today; the amount of revenue that is being lost, the number of customers that are unhappy because of it, the amount of additional work your customer service is having to do. Fixing the bug means extra revenue, a rise in NPS and happier customers.
If a particular story or bug fix doesn’t really align with your overall vision, ask yourself why you’ve prioritised it. If it doesn’t align with your goals, your team shouldn’t be working on it.
2. Facilitate interaction with real human users
One of the most powerful ways of motivating your team is to ensure that they know that there are real, human beings using your product. So often, product teams get bogged down in their own internal processes, tools and squabbles and forget that the only reason any of the team exists is to add value to the person who is using the product.
For engineers in particular, this can be difficult. Whilst product folks are often interacting with other parts of the business which provide context and insights about the business, if you don’t involve your engineers in those meetings, understanding users of your product can be difficult for engineers.
Here’s some ideas on how to combat this:
- Meet real users – get your engineers in front of people who are actually using your product. Everyone in the product team needs to understand that there are real users using your product. This is often easier said than done and even as product managers we often don’t interact with product users as often as we should. If you work in a team of product managers, work together to get visits in the diary planned for visiting real users in person. Or organise a hang out session with a handful of your users. Incentivise your users with some vouchers or something.
- Set up a human panel
- Invite engineers to usability tests – if your UX team runs regular sessions with users of your product, invite your engineers along. The insights they get from seeing users stumble over specific parts of the product will be invaluable. Of course, you can’t invite the whole team to all UX sessions so record the sessions and share insights and recordings with the rest of the team afterwards.
– A human panel is a panel of users who use your product. These should be real life users of your product who report back their thoughts on the product every few months (perhaps once a quarter). These humans are real and your engineers should know about the panel. Give them real names and identities and refer to them in your planning and sizing sessions ‘e.g. is this really useful for Dave? Will Margaret really care about whether we use the latest javascript framework?’. Rotate the human panel every now and again to keep it up to date.
Expose the team
When we build a close relationship with our engineers we can sometimes feel like they need to be shielded from the rest of the business.
This makes sense to some extent since we want to avoid awkward clashes between your star developer and the Head of Marketing who has no clue about technology. If stakeholders know they can go directly to engineers they’ll be sending them a wish list of things to do in no time. This happens a lot.
But, there’s a strong argument to be made to break these barriers down. Quite often, it’s the strange combination of 2 seemingly unrelated departments that can lead to creative solutions to difficult problems.
Allowing your engineering team to be more exposed to other elements of the business can make product people feel insecure; if the developers can go straight to the stakeholders then where do I fit into the picture? This fear leads us to drive a wedge between engineering and the rest of the business.
Don’t be afraid to let the team get a little exposure to what is going on in the business. Include engineers on email threads with stakeholders discussing business problems but ensure that it is the product backlog which determines the work to be done – and not the opinions or requests of individual stakeholders.
Set up a cross functional stand up once a fortnight where a few representatives from the wider business can chip in and explain what they’re working on and how it aligns to the overall business goals.
Encourage the engineers to spend some time with your customer service teams so that they can see real problems that users have every day.
Removing yourself from the equation and encouraging the engineers to speak directly to stakeholders every now and again can bring fresh insights into existing problems or creative perspectives about future plans.
Spread the love
Engineers love to get praised (as do we all!). It’s really, really important to make sure your team feel loved and supported. Give genuine praise for features that have been developed and explain what problems this solves for the business.
Often, engineers will assume that the complexity of a task is linked to its impact. For example, a small change can be seen to be unimportant because it didn’t require a lot of work, but sometimes tiny changes can have an unexpectedly large impact on the business. Make it clear that every piece of work is having an impact, even the smaller ones.
Be sure to distribute your love evenly throughout the team. Even if you do have a ‘star’ developer, as many teams do, be sure not to focus all your attention on 1 or 2 members of the team and try to treat everyone equally.
Share information regularly
- Your NPS has increased from 35 to 40 thanks to the new live chat feature
- Your NPS has decreased from 40 to 35 following last week’s bugs
- Your customer service team have received a note from a customer to say how much they love the new features that have been rolled out
- Revenue is up 15% since last year and the product is at the core of this increase in revenue
Share these little tidbits of information with your team as regularly as you can. Sometimes, stakeholders will send you an email to thank you for the work you’ve done. The entire team should be looped in on these kinds of communications to ensure that they also reap the benefits and the praise when it comes. It’s highly motivating for the team.
Get personal, but not too personal
When you first start working with an engineering team, they’ll usually be wary of you. You are the outsider, the ‘business person’, the ‘manager’. They will assume you have ulterior motives you until you prove otherwise.
Building a strong, deep relationship with every member of your team is critical to your product’s success. Don’t treat engineers as code machines. They’re not. Instead, treat them as human beings and engage with them on a personal level so that you build a genuine connection.
Ask your team where they live, what they’re up to on the weekend, what they’re watching on Netflix and crack a few jokes in your planning sessions and retros to lighten the mood. Some will want to be left alone at all times so leave them alone. Others will want to develop a relationship.
Whilst creating a jovial, open, dynamic atmosphere at work is wonderful, be wary of trying to be everyone’s best friend. If you cross the line and become just another colleague it will be more difficult to assert yourself in times where you need it. Try and find a balance between developing close relationships based on mutual respect and maintaining a degree of authority over the direction of the product and the decisions you take.
Be assertive
We’ve all heard the term assertive but what does being assertive really mean?
There are 4 types of behaviour in the workplace:
- Aggressive – loud, annoying, obnoxious people who shout and demand to get what they want. You walk on eggshells around these people because they are deeply unpleasant to be around. You often wish they would get a new job or drop dead but they rarely do. Worryingly, I’ve noticed that it is often the case that the loudest people do sometimes get what they want. But the collateral damage they do along the way can prove fatal – depending on the environment of the company itself. If the company is full of aggressive arseholes they’ll no doubt fit in rather nicely.
- Passive aggressive – you smile all day, laugh at people’s jokes and say yes to everything. Inside you’re raging and unhappy with being forced to do work you feel you shouldn’t be doing or that you’ve been taken advantage of, but you lack the necessary will or the skills to stand up for yourself and something about it for fear of upsetting others. Instead, you might say ‘Oh no, it’s fine – I can do that’ and then scuttle back to your desk and purposely make a pig’s ear of it to prove that they were wrong to ask you to do it after all. You might send around a note laced with seemingly jolly phrases but underneath it all lingers an undercurrent of resentment. Passive aggressiveness is a particularly difficult type of behaviour to deal with and is not recommended in product management. If you lack the ability to say no to something or someone in product management, you are doomed.
- Assertive – you’re neither too aggressive or passive; you’re a delicate balance of the two. You assert yourself, you clearly articulate your position and your opinion without resorting to aggressive tactics. You can say yes and no. You’re not afraid of what other people think about you to the point where it debilitates you and your decision making. Sure, you want to be liked, like most of the population, but your desire to be liked doesn’t paralyse you into making popular decisions for fear of being disliked.
- Passive – you genuinely don’t care about anything. And you’ll probably be made redundant in the next round of layoffs.
When you’re speaking to your engineering teams, you must adopt an assertive position. Any of the other ways to communicate can be severely damaging – both to your reputation and your team. I’d argue that passive aggression is the worst of these behaviours; worse than aggression since you’re obfuscating your true beliefs, worse than passivity because you do care, you just can’t find the strength to articulate yourself properly. Passive aggression makes teamwork and leadership incredibly difficult.
If your planning session is getting out of control because the team are spending 25 minutes debating whether a story should be 3 points or 5 points, assert yourself by making it clear that there’s been too much discussion and move on to the next story.
If a member of the team is being unnecessarily negative about a project, assert yourself and tell them that their negative attitude is unhelpful and is contaminating the rest of the team and that they should bring this up in the retro.
If a story is taking 10 times longer than it was sized, be assertive and ask why this is the case. There’s usually a genuine reason which you’ll know about but if you feel you’re being taken advantage of, don’t be afraid to speak up and question timelines and why things are taking longer than you had originally anticipated.
You may feel like your engineering team will hate you if you’re too assertive. However, I’ve found the exact opposite to be true; developers will often prefer to be told straight up about something (positive or negative) than have to wade through an artificial facade of emotion to find out what your true intentions or beliefs are.
Explain why
Nothing is more demotivating than a list of things to do without any context or reasons why they should be done.
As product managers, we are essentially creating a to do list for the business and the product team. Without actually line managing any of the engineers, no one is compelled to do anything you say. The best way to motivate people to want to do what’s on the list is to explain the why behind the list.
- Why should this bug be fixed?
- Why have you prioritised this feature over another?
- Why is there such a strict deadline for this particular set of features?
- Why are we now doing something which we said we wouldn’t 2 sprints ago?
- Why is Facebook login not relevant to our audience?
Would you do anything on a to do list that someone else wrote for you without explaining why you should do it? Of course you wouldn’t.
The first step is for you to be clear, as a product manager, why you’ve prioritised a piece of work in the first place. You should know why you’re building your product in a specific way, why a bug is now relevant to fix or why you can now take a 2 week sprint to do some cleaning up.
Your planning session is the best place to clearly articulate the why behind the what. At the start of your planning session spend 5 minutes or so to explain to the team what’s going on in the wider context of the business and what that means for the next sprint.
Then, where appropriate, as you discuss each story, explain briefly why this has been prioritised. If you’re struggling to find reasons why the team should tackle this story, then ask yourself why it’s been prioritised in the first place.
Podcast
Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.
Product launches, news and analysis delivered to your inbox. Weekly.
