A short story about workarounds and empowerment
How engineering teams can be protagonists in solving critical business problems with no code at all.
Hi all! It’s Mateus here with the November issue of
. Hopefully, things are going well over there with you all, now that we’re close to the holiday season. 🎄In this month’s issue, we’re going to talk about a real situation I experienced and was reminded of when talking with the guys from Typo in the “Beyond The Code” podcast. If you want to check this conversation out, here’s the link. I had a really nice time talking to them.
This painting is called The Card Players, by Paul Cézanne.
The situation
Thursday, end of the day. A PM slacked me about a high-value commercial opportunity that could come to one of our products. The only thing pending for the company to go ahead with it was our department's approval meaning we would have to unblock it fast.
The task
When performing a gap analysis, it looked like our product wasn’t built for what was being proposed - but we had a feeling that we could get there. On the first brainstorming sessions with only me and the product team, we were finding a way out but with the downside of some unfancy technical debt. And it would require some effort from our engineering team. Small, but an effort still.
The issue here is that the team is already at capacity with other commitments for the next month and my first and immediate reaction was that the team could not be more overloaded. After all, that’s what prioritization is here for, right? We pick one thing and drop the other.
The action
But something still felt off with this approach. The prioritization answer just seemed to me like a mediocre answer, the easiest answer. In the heat of the moment, however, it was the only one coming to my mind after thinking of a couple of solutions with the product team. And before committing to any of them, we decided to have a refinement session with the engineering team to see their take on the available options.
Here we explained the context very briefly to them and showcased the solutions we were thinking about previously. Discussion started, and trade-offs everywhere and a lot of divergence on the proposed hows and their consequences. It looked like we were going nowhere.
Then I thought about this word: the how. We were giving bias and blockers to the conversation by already bringing pre-thought solutions - that might not even be solutions at all. What if we had taken a product discovery approach and, with it, navigated the problem space with the team instead? We could’ve done better as the managers of the team: we could’ve provided the team with a bit of the why and the what and asked them for the how instead of telling it. And so we did it by resetting the conversation.
The result
After getting enough context and framing the problem, one of our engineers quickly came up with a statement of how our current architecture might support without engineering effort at all. It was just a matter of abstracting the product vision and reframing it: we already had everything in place from a functional and non-functional perspective.
We documented this decision internally, gave the green light to the business and the initiative ended up being delivered without extra effort, no prioritization exercises, and earlier than expected. Just by providing the necessary context for the problem and trusting that the team would come up with the best solution for it.
Takeaways
I personally took some lessons from this situation. Here are some of the main ones:
There are better ways to say no. Before a big, rounded no and pulling myself out of the conversation, try to offer alternatives. See what else can be done whilst respecting the constraints currently in place.
Understand the problem before discussing solutions. Focus on the why first, then on the what, and only after that on the how.
Empowerment is underrated. Build great teams and trust them to do the job. Provide them with the necessary context for the problem resolution instead of top-down solutions. Let them navigate the problem space as well in order to drive the solution space efficiently.
Product and engineering work better in collab. This example is product-driven, but Laura Tacho makes a great point here when it’s the other way around.
Build is overrated, leverage is underrated. The current architecture and feature set can be a powerful accelerator if looked at with another lens. Almost always, the best code is no code.
And you, what else would you’ve learned from the situation? I’d love to hear it in the comments. That’s a wrap-up for November, folks. See you next month for the last issue of 2023. 🎅🏻