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.

– 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

– 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. 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.

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.