The R&D team at every company is made up of a variety of personalities- developers, tech leads, team leads, you name it. The Product team is also quite a diverse group and is usually made up of creative UI/UX designers and product managers. When you throw them together, you get a meaningful relationship that creates magical features for top-notch products.

When I first joined Rookout’s product management team, I told myself that the job and working alongside developers would be as easy as breathing. As it were, I had been a developer previously before I decided to look for a career change. I found myself continuously reminding myself: “You used to be a developer, you’re a developer at heart, you know what developers want”. Sounds like a recipe for success, right?

Well, I quickly learned that having been a certain kind of developer at a certain company doesn’t mean that I know and understand all developers. Developers, much like snowflakes or McNuggets, come in different shapes and sizes. Understanding this was the easy part. The challenge, I soon came to understand, is to help your team understand it.

The relationship between developers and product managers has been challenging since the beginning of time. There is a continuous dissonance- developers want to reduce tech debt and use cool technologies, while product managers want data and “boring” features that help sell the product. Relationships are hard and take work, patience, and a whole lot of compromise – and none more so than the relationship between developers and product managers.

Managing a product for developers, made by developers, can be even more challenging. Let me take you on a quick relationship therapy session and give you my tips on how to keep the love going.

Understanding Goes Both Ways

When pitching a new feature design, the discussion and debate over it is sure to be kindled quickly. The most important thing to do when this happens is simple: listen to each other.

•  Each developer on the team has at least two opinions and is sure that this truth is absolute. As a product manager, you have to listen carefully to understand where developers are coming from.
• Product managers’ motives are not always clear to the R&D team, but it’s their job to make sure the developers understand the reasons behind these ideas. And truly, this goes both ways.

When working on a technical product, it’s important to remember that not all developers are the same. Some of them work in huge monoliths and some with microservices. Some devs are tech-savvy, living and breathing code, and some are familiar with just one language. It’s important to understand the type of developers you’re working with versus the type of developers the product is meant for.

The relationship can be damaged when product managers and developers don’t agree, or decide on a feature without any explanation for why. It’s critical to make yourself understood, no matter which side you stand on.

That being said, remember that, unfortunately, you’re not always right. Understanding each other has to be followed with an open mind, and both sides have to accept the fact that sometimes someone else is right. You’re there to succeed together, and it doesn’t matter at the end of the day whose idea specifically was chosen. It sounds a little bit like a Sesame Street episode, but what can I say? Sesame Street is always right!

‍

Communication is key

Simply saying “this is my decision” doesn’t do much for, well, most people in general.

Keeping the team engaged by introducing them to the user’s story – such as sharing quotes from meetings with them – helps them to understand the other side’s pains and needs. Presenting real conversations and telling the story with the user’s words creates a new dimension and depth to the story that can not be done in any other way.

Make sure to back your arguments with data. Show the users’ behavior and use tracking tools to display real sessions and share screen recordings from meetings with customers. Try to use numbers and facts. Ultimately- keep your team engaged. Spice it up! The more they know, the better they’ll be able to perform and work alongside you.

It goes the same for all developers in the team. Simply saying “it will take way too long to develop”, or “it’s impossible” won’t do much to help product managers understand. Even if you are 100% certain that a specific feature is wrong to develop for technical reasons, the product manager doesn’t always understand that. Oftentimes, they require a slow and detailed explanation. Relationships take patience and ultimately, it will help the team deliver faster.

Pick your battles

Developing a product is much like arguing over what to order for dinner or whose turn it is to do the dishes.
When doing so, it is important to remember: you don’t always have to win the argument. Sometimes, it’s perfectly fine and actually recommended, to take the back seat and let someone else decide which route to follow.

Let’s take a look at a classic example that occurs, no matter if you are a product manager or a developer.  A new feature is coming up and the team needs to choose the right color tone for a very small icon on your ‘About Us’ page. It’s important, right? Definitely. It is so important that the room erupts as everyone voices their opinions, and it seems like anyone has its own five opinions. Everyone is, of course, 100% sure that they are right.

Well, you can sit there and argue for hours, fight, and make sure that your specific idea will be the one chosen. Or, you can decide that there are more important things than winning the fight, and simply move on. Choosing to avoid this battle will actually help create a better relationship and help to gain each other’s trust.

And on that note, as with any relationship, it’s critical to earn your team’s trust and to earn yours. It’s not only easier but necessary, to pick your battles and fight for what’s really important. So leave certain decisions to your partners. This way, when something is really important, it will be quick and easy to get your way. It is a give and take relationship, so make sure you know what are the truly important decisions that are worth fighting for. Anything else should be discussed and decided together as a team.

Make decisions together, as a team

Being a team player is not just something to write on your resume. It’s key to working together to create great products.

It might sound like a bad cliche, but it’s a true one: It’s not a race, it’s a marathon. You will continue to release features, fix bugs, and design together for a long time. When the decision is made by only one person, even if it’s the best thing to do if the whole team is not up for it the marathon will be harder to complete.

It’s important to remember that whether you are a developer or a product manager, you are a part of a team. Therefore, the team should be synced, aligned, and all should trust the final decision. Moving forward with the next steps and decisions will be easier if your partners are working arm in arm with you.

Sometimes, someone else knows better

Product managers have to know their users best. They need to be able to be familiar with their pain points and struggles and ultimately understand best what they need.

In every product, some decisions are made purely on a tech basis. As a product manager for a technical product, it’s essential to be familiar with the technology, to know how developers work, what they do every day, and the meaning of using different languages, frameworks, and terms.

Sometimes, the fact of the matter is that you’re not the most technical person – or most learned person – in the room. This even more so when you are managing a product and your persona is a developer.

When the team decides to support a new language or add a new feature about a trendy, technical topic, it’s ok – and even recommended – to approach the dev team and say “your knowledge is way deeper than mine, can you explain it to me?”. It’s good to do your own research, but it’s also good to go and ask someone who knows better.

Much like if you had to cook an omelet with Gordon Ramsay around, you would definitely ask for advice, even if you are familiar with how to properly cook eggs. Same with developers- even if you know the language or the tech, it’s worth asking for deeper insights where you can.

And devs, we all know that product managers can oftentimes ask too many questions and usually at the worst timing. Sometimes, the questions don’t make the most sense. And yet, it’s important to take the time and help the product manager on the team to make sure every last detail is understood when it comes to new features. Don’t be the Gordon Ramsay of your team. Help the product managers understand how to make the tastiest omelets!

‍

Finally

Well, for better or for worse, product managers and developers are in this relationship together. There’s no point in fighting over who’s right or who’s stronger. The journey is done together, hand in hand, and as long as the team is going in the right direction, it really doesn’t matter.

Working together will not only create a positive workspace but lead to better relationships and improve your coffee break experience, which we all know is what truly matters 😉 But really, it will also lead to a significant improvement in both developer and product workflows. By establishing good and strong relationships within your team, you’ll be able to increase velocity. This means that you’ll be able to deliver faster and fix bugs quicker, and thus help to guide your company in the right direction.

Let’s be honest. At the end of the day, it’s all about speed and quality. And by keeping the love not only alive but thriving, between devs and product, you’ll make sure that your company is experiencing faster quality feature delivery than ever before- and you’ll guarantee a perfect journey together to a better product. Trust me, as someone who’s been there, it’ll be worth it.

A mere few months ago the majority of the world was forced to change drastically, including the move into a ‘fully remote’ mode of office work. As reality was bearing down upon us, tech managers and CEOs everywhere were huddled together trying to figure out how to not only make it work, but work well. They had to figure out the best plan of action- ensuring their employees were up for the task and that they had everything required to work from home for a seemingly indefinite amount of time. Alas, this is a difficult task as each employee is different and each of their needs varies from the other.

The changes to becoming ‘fully remote’ that companies are still currently dealing with have affected each employee differently, especially in terms of their individual velocity. And of course, as is the way of the world, a dev’s individual velocity ultimately affects the team’s velocity. When looking at individual employees and their impact on the team’s velocity, there is one type of employee that stands out in particular: the pivotal employee.

Lesson 1: Providing the basics

When we were told at Rookout that we were to begin WFH (work from home), our first reaction was to make sure that our productivity wouldn’t take a hit. Our goal was to make sure that our team’s velocity wouldn’t slow down.

Every company has had to prepare itself somehow. Some companies have previously practiced WFH methods, while other companies had to start from scratch. Throughout the process, we noticed that companies who previously didn’t allow or practice WFH for their employees had the hardest time acclimating – to the point that they were starting from the most basic step of having to buy laptops for their employees. Yet, these companies weren’t the only ones scrambling to figure it out. Even companies that had allowed their employees to WFH a day or two per week had to adapt and help their employees- such as helping them to create a home office by buying them office chairs, keyboards, or mouses (for example, companies such as Shopify and Google did just this).

Regardless of where your starting position was at the beginning of these turbulent times (unless you’re a company like Gitlab or ArsTechnica), you probably handled it iteratively, much like Maslow’s Hierarchy of Needs, in what I have personally dubbed as ‘Maslow’s Hierarchy of WFH’:

On the lowest rung is your employees’ Physiological Needs. You must make sure that they have all their physiological office needs met, even while not in the office. These are aspects such as having a working laptop, fast internet that won’t kick them off Zoom calls, and coffee that will keep them alert enough to work properly.

The next rung on the pyramid is your team’s Safety Needs, such as having the correct VPN.

Right after, their Social Belonging needs to be taken care of. This can be done in a variety of ways, such as with online happy hour zoom calls or zoom coffee breaks, for instance.

Then their Self-Esteem needs have to be met. This can be done by ensuring each team member gets the proper recognition for their work, even if you’re not physically around to make sure they get it.

Finally, you reach Self-Actualization- like writing this blog post on working from home.
As you move up Maslow’s pyramid, you keep assessing how good your team’s velocity is. Throughout each level, you look around and think of how you and your team coped with this sudden and major change to becoming ‘fully remote’?

Lesson 2: Managing to manage remotely

As VP of R&D at Rookout, managing my dev team during these distributed times was definitely a challenge. Everybody was working from home and scattered throughout different cities. As everyone was getting settled into the new fully remote routine, we underwent our own journey through Maslow’s Hierarchy of WFH.

Managing remotely is difficult, especially if you’re not used to it. When your job is to write code, it is mainly just you and your laptop. Sometimes, however, it is necessary to sync with your teammates and ask them questions, as well as of course syncing with your manager to understand what your tasks and goals are.

When you are managing your team, you need to make sure that no one falls by the wayside. At Rookout we believe in minimum status meetings and minimum time wasters. However, when you’re not in the office, there’s no more being able to casually ask your dev, “how’s it going with your project?” while chit-chatting in the coffee corner, or being able to walk around to your team members and make yourself available for queries.

Some of your team will proactively pull on your coat by Slacking you or ask for a Zoom session. However, a more significant part of the team will be those devs that you’ll need to Slack, call, poke, beep, fax, or really do almost anything to make them talk to you (even if they desperately need your help). Basically, this means that while you’re dealing with changing to a work from home workflow, you’ll also have to learn how to fit your managing style differently to every employee.

Lesson 3: Coping with the highs and the lows

The most frequently asked question that managers get asked by their own managers and colleagues in the last few months is “How is your team doing?” and not “How is that magic micro-service doing?” or “Where did you get that Zoom background?”. They’re simply trying to find out how your team is coping with their new distributed routine (or, to be exact, how you’re coping with managing them).

About 10 years ago, I was talking to a friend who had just had his first baby. I asked him how things were going with the new baby and he replied with the best answer I have ever heard.
“Having a kid changes your peaks. In the past I had highs and lows- sometimes I was happy and sometimes sad. With a kid, though, everything is to the extreme – your lows are feeling like the world is crashing down and your highs are like you’ve conquered the world.” For the past three years – since my daughter was born – I relate to this answer every day.

Nowadays, when people ask me “How’s your team doing?” I tell them that becoming a ‘fully remote’ company really tests your team in an extreme way. All the peaks change. You know that team member that you have difficulty keeping track of in normal times? Well, good luck doing that when he is WFH and has such bad Wifi to the point that you can’t even see him on video. But hey, at least you’re not interrupting him and he’ll get some work done…right? And what about the team member that needed your help all the time and wasn’t able to move forward without it? Well, let’s be honest. He’ll probably just live his best life watching Netflix until he manages to catch you in between your other Zoom sessions.

Lesson 4: Finding your team’s equilibrium

So, real talk, how is my team doing? Did the team’s velocity change? Well, as Thanos says, “Everything is balanced as it should be”. In an almost karmically balanced way that none of us could have foreseen, some of my team have reduced their velocity, while other team members’ velocity has skyrocketed. However, the most interesting phenomenon that arose from this scenario is the pivotal devs.

You know that one dev that knows everything? I don’t mean that they are the expert in everything, but rather that they know something about everything. This is the dev who knows all about the data flow in your system, why that piece of crap legacy code wasn’t deleted yet, about that feature that nobody uses, how to use the CLI to everything and, if needed, they will even configure your Emacs and VIM (although they don’t use them).

This is the dev that everybody turns to when they have a question. They are the Google personified of your company. Even if it will take your team 10 minutes to find an answer, they will prefer to ask this dev instead. They are the oracle, the chosen one. They are your pivot. Really, you’ll sometimes even see a line forming near their desk.

How much work, though, can the pivot truly accomplish in the office? How is their velocity? Well, frankly, it’s terrible. Everybody asks them questions all the time, making it so that they switch contexts like crazy. But what happens when everyone is out of the office? The pivot is at home and it isn’t as easy to disturb them as it used to be.

Pivots flourish in these distributed times. They now have full focus and don’t need to switch contexts non-stop. Unfortunately, this increase in productivity means that the others might start to stumble blindly in search for answers or in search of the pivot. All of a sudden you’ll see a drop in the velocity of everybody else because the answers are simply more difficult to find when the pivot isn’t around to give them to you.

Lesson 5: It’s time for independence

The velocity drop around the pivot happened because some of the team members got too used to not being independent. Having the pivot around and available reduced the need to find the answers for themselves. Now is the time to start developing that much-needed independence.

In order to reduce the impact on velocity, you must first make the pivot more available to your team and set your expectations with them. But, you must make sure that the pivot’s answers aren’t “fish”, but are rather “fishing rods”. His answers should be links to documentation, links to tutorials, or explanations as to how he acquired his data. Now is the time to teach your team how to fish. Don’t feed them. Let them feed themselves. Otherwise, when the next time the pivot isn’t available they will starve. See the following (very scientific and accurate, I’ll have you know) graph I doodled with the amazing Excalidraw:

But how do you teach your devs to fish? Apart from trying to have your pivot show them where to get all the answers, of course. Well, it all boils down to ensuring that they have the right tools that help them properly understand their code. One of the major contributors to your team’s reliance upon the pivot dev is their lack of understanding of the code and the software that they’re working on. By giving them the ability to deep dive into the code and get the data they need to figure out what is happening in it, you’ll ensure a rise in their independence. So don’t worry, you and your pivot can sit back and relax at home in your pajamas, without having to worry that your devs aren’t able to work properly.

Lesson 6: Reap the fruits

Making everybody independent will increase your team’s productivity and velocity. After becoming ‘fully remote’ I doubt you will ever go back to what it used to be. There are multiple indications in the industry that the way we work will change in the future. After you’ve seen what your pivotal people can achieve when your team is more independent, you will keep making sure that they have the right conditions, as well as the right tools, to flourish. And after you’ve seen what your team can achieve when they are focused on being independent, you will never allow any dependence to develop again. Either way, whether your company returns to business as usual or changes its day-to-day, you’ll come back stronger than ever.

‍