How to increase your Team's Motivation
Use a Product Mindset to boost motivation and clarity for the future.
Hey there 👋🏼
As Engineering Leaders, one thing we deal with is the motivation of our teams.
Several vectors affect motivation: money, the work itself, the number of interruptions, interactions, etc.
A few issues ago, I mentioned how important it is for a team to have a clear mission and vision.
The vision of a team focuses on the future. The mission focuses on what the team wants to achieve in the present and is aligned with the vision.
If you want to dive deeper into this, follow the link above.
Something that affects the team's motivation is the connection they have with their scope. External forces like Product or other Engineering or Security teams often drive this scope. Sometimes you'll also find teams just in reaction mode and always fighting fires.
Let me start this newsletter by asking you to stop, assess what your team is working on and evaluate their connection with what they're building.
Many teams working purely to keep a stack alive quickly lose motivation. Usually, their work revolves around:
Security patches
Mandatory upgrades
Bug fixes
Up/Downscale
Cost centric opportunities
Eventual major upgrades
etc.
All of this is often done on top of legacy software.
Our job as Engineering Leaders is to turn this lack of vision around.
Someone told me the other day to look at each of my areas as startups.
That resonated a lot with me. Cogs started working immediately.
I started thinking about what we're building and maintaining and asked myself why other developers would use our stack. How would they rate our service? Why would they come back for more features? What if I was a customer? Would I be back?
Nowadays, we hear much about the productisation of a team's stack and a product-driven mindset. That a team's work should revolve around a product. After a lot of thought, they're right. We should look at what we provide as a product, service, or a platform.
Even if we own a single microservice, we can look at it from a product perspective:
How will our customers interact with it?
How will they test against it?
What changes should they expect?
Is there versioning?
Is there a feature release calendar?
Do we have a public roadmap?
Are we taking insights and feedback from our customers?
Do we even know who our customers are?
Today I have a challenge for you.
Open a blank document and write your team's mission and vision.
Write who your customers and stakeholders are and who is driving features and further developments of the team.
Create a box for every product you own. If you have multiple, do you have a suite of connected products, or are they assorted and disconnected?
For each product, discover why it exists. What's its purpose? What's the vision for the future?
Write again about who your customers are and who is driving features. But this time, focus on each one of your products. Reflect on the difference between what you have now and before.
Now, look at your roadmap. What story are you telling your customers about the products they use? Is it thriving in new features? Or is it stalled, and they should look for a replacement?
Please work with your team on this; you'll find it amazing to have a team connected with a product.
A lot of times, you need to find out clear lines defining your products and their long-term vision.
This exercise helps you review what you have on your plate, understand why it exists and what the next steps should be.
Congratulations if you discover that the future doesn't exist and that you should decommission a specific stack. You now have a clear vision of what you should do next:
Is there an alternative already in place? Usually yes. If not, time to find out the best one and plan its implementation.
Do you have a list of everyone using the product that will be decommissioned?
Create a detailed plan for the decommission and migration to the new solution.
Agree on the minimum time the customers need to migrate to the new solution.
Send a communication alerting that your product will be shut down on date X and explain the migration procedures.
A couple of weeks before the decommission, send a comm as a reminder. And do the same on the week of the shutdown.
Feel the joy of shutting down the service.
Celebrate this achievement with your team. Take advantage of this step!
So often, you have demotivated teams maintaining legacy software, adding costs to the company without a real reason.
We're in the best time of the year for you to see everything your team has under their scope clearly.
Take your team with you on this journey.
They need to stop being seen as code operators that move tasks left to right in JIRA boards and become part of the products their help maintain and build.
Make them a crucial part of the product; otherwise, it might not be today or tomorrow, but soon you'll lose them to another challenge.
Alright, that's it from me this week. I hope you have a fantastic weekend and that this issue helps you reassess everything your team has under their belt and motivates you to see it with a product and customer mindset.
The best time for change is always now.
If you're not finding value in this newsletter, please consider unsubscribing. There are no hard feelings, and I appreciate your part in my journey. Perhaps in the future, we'll meet again!
If you are enjoying the newsletter, the best compliment you can make is to share it with one person.
Thank you for being part of my journey!
Have an incredible week! 💪🏼
Parada 👊🏼 A Leader's Mindset