Engineering teams need to be 'INSPIRED'
How engineering teams can support a product team transformation to be INSPIRED and EMPOWERED!
I’m a fan of Marty Cagan’s books and product principles from ‘Inspired’. This book was transformational to our Product and Engineering teams (big thank you to Jason Mongue for inviting me to join the Clover Group’s bookclub).
I’m one lucky Engineering leader. I work with amazing Engineers and Product Managers who have embraced this model. We have a culture of curiosity so it was no surprise that when we started talking about ‘Inspired’ and some of the principles from the book we found it aligned with how we like to work. While we prefer this model we didn’t have a great framework to reference and discuss the issues we had that moved us away from being an empowered team.
If you didn’t read the book, I highly recommend it. I won’t do it justice here but I hope to continue to write some short bites on how we transformed our product and engineering teams. While the book was written for Product Managers, I believe it is essential for Engineering to learn these principles. It’s so much fun to solve problems, to talk to customers, to pursue solutions that deliver outsized value. Delivering a million features is “easy”, delivering an elegant, cohesive and lovable product is extremely hard.
Here’s a quick reference to the 2 models from the book: feature teams vs empowered teams:
Feature/delivery teams deliver output of prioritized features. The value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.
In an empowered product team, the product manager is explicitly responsible for ensuring value and viability. The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.
Marty Cagan went into some more details in this episode and for me, having lived through a number of companies with various shapes and sizes for Product and Engineering teams, I can relate to his points and some of his frustrations (Product management theater, overhired roles, feelings of being a victim of your company’s way of working and what you can do about it).
I agree with Marty, if you believe you are stuck on a feature team, there is something you can do about it. And since I mainly write to Engineering leaders, I will +1 this message and tell you that you too, Engineer and Engineering Manager, can have a big impact in moving your team toward an empowered model. I will focus more on some of the transformative principles and how it helped our team become more Empowered (also a great book to read).
So let’s get to one of my favorites from the book.
Fall in love with the problem, not the solution -Marty Cagan
Whether or not your PM is handed a feature request to build or they are empowered and able to focus on value and viability, here’s what you and your engineers can do:
Ask what problem we need to solve. Before you jump into a solution, implementation and feasibility, oh and debating estimation, make sure you and your team understand the problem deeply. Do you see the pain? Do you understand the world of the user who is facing this problem and why they are trying to solve for it. If you don’t, spend time getting to these questions. You need to gain a clear understanding of the problem to deliver the best solution.
This quote from Antoine de Saint-Exupéry resonates with me and relates well to this topic
“If you want to build a ship, don’t drum up the team to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”
Spend time helping your team fall in love with the problem, they will yearn to solve it and deliver amazing outcomes.
Talk to your customers, all the time. Make sure you and your Engineers get on customer calls. When the PM comes in with that request from a customer, make sure you include the engineers on a call with them. This is part of the product discovery stage and Teresa Torres’ book Continuous Discovery Habits is an excellent companion to teach you some of these skills.
Increase your user empathy. Get into your user’s world and understand it as best as you can. You’ll be surprised how much fun the job gets when you are given a problem to solve vs a bunch of features to build. Having empathy for your user can guide you to improve your product experience. Even small incremental iterations can lead to significant quality improvements but you will not know how to best prioritize without some level of user understanding.
Your organizational design could impact your team’s ability to make this work well. Are there layers of teams who talk to customers and you keep the engineers in a protected bubble in the spirit of helping them stay focused on writing code and delivering features? Please stop this practice. This is another reason why it is hard to get out of the feature team model.
To engineers who do not want to talk to customers: you are limiting your growth potential. I know it’s stressful and sometimes scary to get on calls with customers but trust me on this, the more you do it, the easier it gets. As a senior engineer, you want to grow this skill and get a deeper understanding of your user’s problems. Demand to talk to customers (I highly doubt anyone will stop you), to get on support calls, to learn how the business works and operates. It will help you deliver value well beyond the feature requests and bug fixes. You will be able to learn how to drive for outcomes not just to move a task or story on a board.
Finally, to the engineering leaders, you can help transform and support the transformation of our product teams. They are our partners and the way we work together will have a tremendous impact on the results both teams are able to deliver for the business.