One of these days while scrolling on Twitter, I saw an anecdote - but at the same time a fact - which I liked:
“When management tells you to build a specific thing
Junior engineer: I can figure that out!
Mid-level engineer: that’ll take me about x amount of time
Senior engineer: what’s the end goal of this project? “
Another reply on the same thread:
Staff engineer: but no seriously, who asked you to do this, and what are we hoping to get out of it, and if we don’t do it, do you think they’ll just forget they asked?
This triggered me since I could totally relate to this journey of becoming a more mature software engineer, and to some other thoughts I’m currently having, I’ll explain to you.
Some years ago, when I was working as a software engineer in a big tech company, and my leader left, I had the chance to learn more about technical leadership on the go. From one day to the other, I needed to set the technical direction for engineers of the team and contractors. I always had the option to not accept that challenge and go back to my individual contributor track, but something inside of me was telling me to jump in the soup and make the best out of that opportunity. It was a good idea.
One of my main motivations to keep growing and learning more about technical leadership and engineering management was doing precisely the opposite of some bad managers and leads I had in the past. I bought several books, courses, tried things in practice, and so on. I felt super comfortable leading teams, people were happy, productive, delivering features, and I had fruitful relationships with my direct reports. However, there was one thing I felt that was not still quite right. I did not have the feeling we were investing our time building the most impactful thing we could.
Some can say this is the responsibility of a Product Owner or a Product Manager, but I tend to not play this game of excuses that leverage segregation of duties, I think we can - and should - all help each other. What if you work with some less experienced Product Managers? What if your PO feels overwhelmed with the amount of work, without really putting deep thoughts on the product? I believe it’s our role, as more experienced leaders in tech, to also give some direction regarding product decisions and goals. But how?
We can stop the conversation here and say prioritization with stakeholders, users, etc. is the path. They know what is the most important thing to build, right? Not really. They have a minimal understanding of the complexity of the product you are making, they don’t know about your strategies and how to connect your current efforts to short, medium, and long term goals. They just have a limited perspective of a set of problems and pains, and what are some possible solutions for them.
I love this quote from Gojko Adzic, seasoned tech-consultant, and creator of the Impact Mapping practice:
“The measure of success, for many teams out there, is rolling out software features to production. This is when they declare victory. Teams measure and manage things like time, velocity, story points, effort. Those things are inputs and outputs, but not really relevant from a customer or business perspective.”
This statement makes me feel uncomfortable because I agree with it, and I usually use those metrics, and yes, I declared victory when something was released. However, for more times than I wanted to, teams that I worked with released something, and its impact was not that significant. It is working, it is beautiful. The code is excellent and bug-free, but one question remained: was this the most valuable thing we could build with our time?
How can we shift this engineering mindset about building the thing right instead of building the right thing? The good news is that some folks already thought about this challenge. Nothing I’m writing here is super new or rocket science, but my career focus was always on how to build software and teams, not the what and why of products.
“When we develop a product, of course, we want to build the “right” product. The right product is a product that does something much like the idea we originally had, except that instead of what we originally thought, it has what customers actually want, need, respond to, desire, and love. No one - at least no one I have ever met - knows upfront what people will love. We get a successful product out there by getting something out there as soon as possible. Then we listen to the market, which tells us mostly what they don’t like, and maybe a few words about what they do like. Then we change the product or - as Lean Startup would have it - we pivot” - Ron Jeffries.
As I mentioned in another article, I like to reduce ideas to their essential parts, and if you ask me what the most fundamental idea about building the right thing is, I would say: the feedback loop. There is no particular framework, workshop, book, or other prescription that can ensure that the product you are building is useful, and customers love. A good part of your efforts should be invested in experimenting, prototyping, releasing things fast, collecting feedback from users, and iterating. The rest is a distraction.
There are some practices out there that can help you on this journey of finding the right thing to build, such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. However, from my limited and engineering biased perspective, having an amazingly fast feedback loop with the customers is the most effective way to ensure you invest your time on the right points.
I’m just starting some serious study about product management. Let’s see if I’ll change my mind in a few weeks.