How would you keep developers working on a product motivated and turning out quality work?

What is the problem

Let's take a step back on the goal we are working towards with this Google behavioral question and focus on what needs to be achieved.

We want motivation and quality output presumably throughout the year. It'll be a safe assumption if I say that motivation does contribute to quality work.

Now let's understand what are steps through development cycle which could impact these goals.

At a very high level

Product /feature ideation>Sorting of these ideas> selection of final list> validation through a framework> user validation> MVP experimentation> impact validation > finally the feature is shipped

Now what could go wrong? a lot, so lets identify the key problems 

> I don't know WHAT I'm working on #planning

> I don't know WHY I'm working on it #GoalClarity 

> I don't know WHAT my impact has been #Impact #Outcome

> I keep getting shifted from one project to another #ContextSwitching

> the feature I worked on didn't work out #Failure 

> I keep getting the same work #Boredom

> The current work doesn't excite me  #NeedtoLearn

 

From a PMing perspective : This is an end to end process. We can't solve them in isolation.

All the above problem can be solved through an agile approach combined with a thorough planning and communication rigour.

Collaborative Planning > Feature list/experiment list> planning > Execution> Experiment results > Feature roll out/ Learnings

Collaborative Planning 

This becomes an input to everything we achieve - it is ensuring we have well defined quarterly /six monthly planning process to ensure clarity on goals and timelines.

the outcome is a list of feature/product items we want to ship in order of their priority.

Feature list

Once this planning is complete it is important to bring the tech stake holders into a room and get feedback from 2 key prespectives

-> Do they agree with the roadmap - does anything need to be removed/added

-> What can be picked

-> From a pure tech perspective - What needs to be added for planning 

Example - upgrading the fresco library has no direct baring on the customer but from a tech stand point may be a task simply because it's more stable and solves some annoying but not so critical crashes?

Benefits 

> Now the tech stakeholders know the WHYs and WHAT they are working towards and what the impact is going to be 

> it brings a fresh perspective to the ideas being discussed and ensure we don't have blindspots

 

Planning

Now that we have clarity on what needs to be done we figure who does what.

We want to ensure

- Everyone has work but isn't overloaded

- We leverage existing strength

- We allow people to learn/improve on certain areas

- Everyone knows what they are going to be working on 

Benefits

> Clarity in terms what I'll be working on and when

> Time for feedback - e.g if a frontend dev wants to brush up his server side skills maybe he'll call out that he wants to contribute server side on a project

> Variety

Execution

During Execution it is important to ensure we build MVP of ideas for 2 reasons

- Derisking - Ensure we have validation before we invest

- Speed - this way we only invest on feature once we have early validation

The indirect outcome is

> you ship more winning ideas simply because due to the MVP scope you are able to experiment a lot more ideas and shipping winning feature is directly related to how many ideas you can ship /test

> Variety because you're trying out new ideas

Benefits

> you win more often

> less likely to have boredom since you're constantly innovatin

 

Experiment results

This is where we really to work on communicating

-> Wins when we win

-> Learnings when we don't win, it's important to ensure we don't repeat mistakes and reduces the probability of failure in the future 

 

Benefits 

-> motivation is sustained 

Feature roll out

CELEBRATE ALL VICTORIES - BIG AND SMALL :)

 

 

 

 

• Developer persona

  • John, the programmer

  • Behavior

    • Works in a focused fashion

    • Very detailed oriented

  • Needs and goals

    • Wants to understand the problem deeply

    • But, wants unambiguous requirements

    • Wants to feel satisfied with what he does

    • Wants to work on flexible timings

  • Motivations

    • Inspiration to work for the problem

    • Empathy for the users

    • Having fun while working

    • Gaining respect in the developer community

    • Learning new things

  • Challenges

    • Too many meetings

    • Lack of focus

    • Changing priorities

  • Ability

    • Reading

    • Experience on the job

    • Learning from ability

    • Practice

    • Education

    • Learning from others

• To turn out quality work by being motivated, there should be four things

  • Motivation

    • Even if they might not want to waste their time, I would encourage them to attend user interviews or calls

    • Provide them opportunities to share their work and learnings to the stakeholders and others

    • I will discuss the problems with them rather than give them the solutions

  • Ability

    • Pair programming

    • Schedule aside some time each Sprint for them to learn

  • Time/Focus

    • I would allow my development teams to focus on specific Sprint goals and protect them from other distractions

    • Will prioritize ruthlessly

  • Collaboration

    • Sprint goals help

    • Daily standups to communicate

  • Even after doing the above things, I will be continuously taking feedback from them during Sprint retrospective

• If I have to prioritize to do three things from the above list, I would choose based on the impact it will have:

  • Focused Sprint goals (Helps in collaboration and motivation)

  • Give them the understanding of the problem through user interviews (Keeping them in touch with the users helps them understand that something that is fun for them to do may not help the user at all and also generate empathy for the users)

  • Give them hard problems to solve (Don’t ask them to change things, give them hard problems and which might take time to solve, but directly impact the business)

Developer motivation is very important to a well-functioning team. But I've been in some situations where motivation and morale was low within my developer team, and it impacted the quality of our work. I'd like to use one of those situations.

A couple of months ago, I had a situation at work where my team underwent three strategic pivots in a very short period of time. The impact to the team was bad. We had interrupted sprints and stopped and started projects abruptly. When we finally course corrected, the team was hesitant to take on any work.

My task was to get the team motivated about the work, but to also feel energized and excited by what we were trying to accomplish. In our strategic messiness we had lost sight of the customer and her goals and how we could help her.

I took a set of actions to improve morale on the team.

First, I met with every developer on the team. I truly believe that in order to do their best work people have to bring their whole selves to work. So I sat with each team member and heard them out. I acknolwedged and owned the problems we were facing and listened to them.

Second, I walked them through the changes we had as a business that led to the pivots, and shared my case for why our current strategy was better. To do this I shared our customer data, our notes from strategic conversations with our leadership team, and validation from research.

Finally, I got the team together for a kickoff. This wasn't a typical kickoff, as I invited our CEO, CPO and CTO to attend to answer any remaining questions from the team. I also invited the team to discuss and debate the strategy. Instead of prescribing solutions, we used the kickoff time to brainstorm and prioritize quick win solutions the team was excited by. We then worked together to create our roadmap.

I made sure that the roadmap consisted of feasible milestones, and made a big effort to internally celebrate each milestone. I also constantly fed back to the team customer validation and feedback so they always felt connected to the main problem but also could viscerally feel the impact they were making.

As a result, I had made the team excited and motivated by the work again. But because I had empowered them with the information they needed about our customer and problem, we were able to come up with solutions that were way better than before. Every developer on the team was an expert on the customer, so we ended up having a velocity and output that exceeded other squads and leadership gave us more complex problems to tackle. The developers on my team became subject matter experts and started working to help other developers on other team.s

First of all, I would ensure they understand how their contribution fits into the bigger picture and the impact that they are having.

Next, I will explain to them the overall goal that the product/feature aims to achieve.

Last but not the least, I will work with them to ensure that the work they are doing is contributing to their learning and pushing the boundaries of their current knowledge.

I would like to answer this question from a product manager's perspective.

Development Cycle: Planning & Ideation/ User stories and Sprints/ Feedback loops and Testing ( QA, UAT) / Feature Delivery.

1. First, I would like to get as many requirements as possible and draft them in a clear way so that there is no ambiguity when proceeding to development. That can include very small things from a simple back-end one-time data entry to big things such as wireframes. I would encourage all the developers to participate in the ideation phase and make sure that their inputs, if valid and relevant, are taken into consideration. This, way you can collaborate and bring an inclusive feeling to the team.

2. With the increasing complexity and customer demands in software products these days, change is inevitable. Change can be of two types: Trivial / Non - Trivial. Non - Trivial changes can be accommodated with minimal development work. Trivial changes require a lot of development work. That's the situation in which a product manager should put both the developer's hat and the stakeholder's hat. Explain how these changes make sense in the business context. Developers should understand that the software is of no value if left unused. Additionally, ask for some more additional sprint time so that the developers feel that the product manager is supporting them instead of reiterating the stakeholder's say. Encourage junior developers to join the stakeholder's call. A good way to start, as you can mold their thinking from a business standpoint.

3. Most importantly, send bravos/appreciation emails praising the good work. Boosts the confidence. Encourage your stakeholders to send personalized emails if possible. (Indra Nooyi, former PEPSI CEO used to send personal emails to even to the family members of best employees). Have a good team party, take some chicken/beer after every product increment (PI).

All these 3 point intuitively reflects the performance of developers and they, in turn, deliver quality work.

Developer motivation is very important to a well-functioning team. But I've been in some situations where motivation and morale was low within my developer team, and it impacted the quality of our work. I'd like to use one of those situations.

A couple of months ago, I had a situation at work where my team underwent three strategic pivots in a very short period of time. The impact to the team was bad. We had interrupted sprints and stopped and started projects abruptly. When we finally course corrected, the team was hesitant to take on any work.

My task was to get the team motivated about the work, but to also feel energized and excited by what we were trying to accomplish. In our strategic messiness we had lost sight of the customer and her goals and how we could help her.

I took a set of actions to improve morale on the team.

First, I met with every developer on the team. I truly believe that in order to do their best work people have to bring their whole selves to work. So I sat with each team member and heard them out. I acknolwedged and owned the problems we were facing and listened to them.

Second, I walked them through the changes we had as a business that led to the pivots, and shared my case for why our current strategy was better. To do this I shared our customer data, our notes from strategic conversations with our leadership team, and validation from research.

Finally, I got the team together for a kickoff. This wasn't a typical kickoff, as I invited our CEO, CPO and CTO to attend to answer any remaining questions from the team. I also invited the team to discuss and debate the strategy. Instead of prescribing solutions, we used the kickoff time to brainstorm and prioritize quick win solutions the team was excited by. We then worked together to create our roadmap.

I made sure that the roadmap consisted of feasible milestones, and made a big effort to internally celebrate each milestone. I also constantly fed back to the team customer validation and feedback so they always felt connected to the main problem but also could viscerally feel the impact they were making.

As a result, I had made the team excited and motivated by the work again. But because I had empowered them with the information they needed about our customer and problem, we were able to come up with solutions that were way better than before. Every developer on the team was an expert on the customer, so we ended up having a velocity and output that exceeded other squads and leadership gave us more complex problems to tackle. The developers on my team became subject matter experts and started working to help other developers on other teams.

My short answer would be, as interviews only have about 2 min or less to answer any questions, lengthy answers do not help.

 

First and foremost is the early collaboration with the dev team to help them understand the WHAT and WHY of the problem. Who are the users and how will it impact them. Let them then come up with the HOW part of it

Now that everyone is clear on the WHY part. COLLABORATE with the dev team to brainstorm on how can we acheive it and prepare a high level architecture. This will bring in ownership in terms of what we are building, what is in scope and what is out of scope

Upon finalising the high level solutioning, clearly define the IMPACT metrics for the product feature and set the accountability for each of the metrics

Let the dev team work independently on the WHEN part of the product release and understand from them the rationale of the proposed timelines and collaborate with them to check can we do better

During the execution phase, help them unblock by providing clarity on open questions without the need for them to keep waiting while aslo ensuring that there is no scope creep happeninguntil and unless it can't be avoided. This brings in TRUST while working with the dev team.

Work closely with the dev team during the testing phase and act as part of the testing team to ensure there is no blame game as part of the bug triage sessions later, thereby ensuring no last minute surprises

Post the product release, ensure to clearly communciate the metrics movement in terms of product effectiveness.

FInally, it is very important to provide VISIBILITY of the dev team infront of the leadeship team. So, whenever there are status updates or townhalls, appreciate the dev team in public forums to RECOGNISE their efforts in bringing the product live.

First and foremost is the early collaboration with the dev team to help them understand the WHAT and WHY of the problem. Who are the users and how will it impact them. Let them then come up with the HOW part of it

Now that everyone is clear on the WHY part. COLLABORATE with the dev team to brainstorm on how can we acheive it and prepare a high level architecture. This will bring in ownership in terms of what we are building, what is in scope and what is out of scope

Upon finalising the high level solutioning, clearly define the IMPACT metrics for the product feature and set the accountability for each of the metrics

Let the dev team work independently on the WHEN part of the product release and understand from them the rationale of the proposed timelines and collaborate with them to check can we do better

During the execution phase, help them unblock by providing clarity on open questions without the need for them to keep waiting while aslo ensuring that there is no scope creep happeninguntil and unless it can't be avoided. This brings in TRUST while working with the dev team.

Work closely with the dev team during the testing phase and act as part of the testing team to ensure there is no blame game as part of the bug triage sessions later, thereby ensuring no last minute surprises

Post the product release, ensure to clearly communciate the metrics movement in terms of product effectiveness.

FInally, it is very important to provide VISIBILITY of the dev team infront of the leadeship team. So, whenever there are status updates or townhalls, appreciate the dev team in public forums to RECOGNISE their efforts in bringing the product live.