A while ago, at a Product Tank meeting here in HK, someone asked the question…
‘How can I encourage my developers to do the work?’
I, naturally forgot about this for some time until a developer friend of mine came over to Hong Kong, and told me he was doing a talk to answer this very question. He asked for my input to this… I spoke to my squad… and here’s our answer!
Recruit based on mindset first, technical skills second
Why: The simple reason is that mindset is near impossible to change, but technical skills are always enhancing. In fairness, we need a balance here to maintain the velocity and to provide guidance to further the technical understanding. But mindset cannot always, and nearly always won’t change.
What do I mean by mindset: Their ability to rationalise, their ability to explain the technically complex to the technologically inept, their honesty, and their area’s for further development. Their perception of what great products mean to them, and how they further their knowledge. Questions which look to get to the bottom of these, should inform you of their mindset. Where development is more than just their day job, their understanding that great product extends beyond the team, and that they are always keen to learn more!
How: If you’re a hiring manager — get going!
If not, I’d have a word with the hiring manager, with the talent acquisition folk and design some questions to help to understand their background, and highlight the benefits of this potential shift in hiring!
It’s always helpful if you are able to speak in their language also. And here I don’t mean in cantonese. But it helps if you can understand the tech speak to a basic level of comprehension. If you feel that this area is an area you need to improve, go on a course!
2. Set a vision — a vision that everyone is behind
Why? Having a universally shared vision is so important. It makes sure that everyone on the ship is doing their bit to make the ship go, go in the right direction, and make no icebergs are hit! This should, in itself, make sure that all discussions are based around whether or not a piece of work will support us in reaching this vision.
How? These visions, and strategies, and roadmaps shouldn’t be set in isolation. They should support the business vision, and involve the squad and the SME’s around the business to agree on and decide upon in a workshop.
3. Goals — make sure these are aligned
Why? Similarly to the vision, goals are what provides us with the fuel to do a job, and do this job well. (Meeting these is what often a decider of bonus potential!). The purpose of a product team is to make products that customers use.
How? Speak to the manager first, to understand the goals of the development squad. It’s crucial to ensure that at least one goal has a commercial aspect to this, and that this goal is aligned to your own. Perhaps set up a workshop, maybe with the commercial squad, to support the decision around what the goals could be.
4. Everything is possible — with compromise
Why? (nearly!) everything is possible, tech wise. You just maybe have to compromise, or weigh up the pro’s and con’s.
How? Speak to your squad about the ‘size’ of the different solutions to a problem. this is an important factor in supporting the decision of the best route forwards.
5. Don’t get involved with deciding on tech —
Why? It’s not you job and others’ know this better!
How? Though it is possible to decide on what you want this tech to do. Such as to AB test, to be performant, to be modular. Make these clear, leave it up the the developers to decide on what they feel comfortable with and what support there is in the market etc. Be prepared to compromise here also (see number 4.)
6. Speak to developers like the humans that they are!
Why? Needs no explanation : These people are your friends. Without them, you would produce nothing of worth!
7. Share the analysis. And the praise. And the reward.
Why? Being the product manager, often means you are going to meetings, receiving emails, and being the go to person people pass praise on to! And this praise should be passed on to, forwarded on to, and mentioned to the developers. It can be easy to forget, but the developers don’t usually hear this kind of praise. And this praise can be motivating. And, added bonus(!) may make your velocity go up.
The above details just our own experiences, where we work currently. And everyone is a different and at a different stage! 1 thing which I’d really like to try is to expose the developers to the discovery phase — so that they understand more about the users attitudes and needs!
I really hope the above helps you to communicate with and share your experiences with your developers!
What do you do to work effectively with your developers? What works best? Is there anything I missed?