Hey everyone! Glad to be writing about this subject. I love that Product-Led companies help us be impact strategy. This idea also came from conversations with other engineers in QuintoAndar and the struggles they were having with boundaries. So to extend that possibility to anyone I created an ongoing form for questions and ideas. Hit me up and send it to your friends and colleagues, the more the merrier: https://bit.ly/dear-luciano 🤗

I started my career in a tiny startup that eventually became a tiny software house. There we each did everything. Sold projects, talked to customers, defined scope of what we had to do and how that related to what we needed to build, planned sprints, wrote the software… you get the gist. This is, in a way, terribly inefficient. Still, it hammered something in my head: When we’re building products, every single type of decision–be it business, design, engineering–affects the product strategy, and product strategy affects what we’ll actually build. A corollary to that is: we’re all responsible for Product Strategy.

Fast-forward a few years, and I joined QuintoAndar, where we have more clearly defined roles. Here a team usually has people with complementary skill-sets trying to solve problems and evolve our products. We have Designers, Product Managers, Software Engineers, Data Scientists, etc., all within the same team. This is intended to make the team more autonomous and allow them to collaborate as an early-stage startup. This was great to me because I could finally focus a lot of my time on my specialty: building software. This focus was a blessing. It made the team more efficient, more effective and made us grow faster in what we do.

Building Software is a craft. It takes time, focus, and creativity. We frequently do it in a flow state, and we Engineers are usually passionate about honing that craft. So it’s only natural that when we focus on it, we’re drawn deep into our world and forget what’s around us. It’s almost addictive being that focused. So much so we can forget the truth that we just talked about: we’re all responsible for Product Strategy. If we tunnel focus on building things, we can create Silos.

Sure we can present our work to one another. Create flashy visualizations and share learnings. Communication is key, after all. But, if we each just take our work and put it in the hands of the next person, we’re effectively working as a small waterfall. When we put ourselves in these siloes, accountability goes downhill.

This is usually the cause when we see Engineers complaining that Product Managers don’t give them enough time to build solid architecture, to trim out technical debt. When Product Managers start to see the team as slow or “too Junior.” When the Designers start to feel that they don’t have agency. Silos kill accountability.

Before we go into what the role of engineers actually is, let us start from a shared understanding:

We’re only leveraging all the power of a small autonomous team if we work collaboratively and everyone is directly involved in all steps. This doesn’t mean going back to how I built things in my tiny software house. We still have specialists and still rely on each other’s strengths. What it does mean is that we take ownership. We don’t let anyone in the team set us to fail.

When we ask this question, the most common answer revolves around Technical Debt. Which is certainly something important, but there’s a lot more to that. Collaboration is at the center of our role here. The programmer hidden in a cave receiving assignments and shipping them is thankfully a dead concept. Our role is:

Discuss, Participate and understand thoroughly the outcomes we’re going for. We need to be in the room and disagree until we can commit. Do not half-ass or say “I told you so” later. It’s also our fault if the team goes on to pursue an outcome we don’t trust in a way we don’t think is the right one. It’s way easier to sit out and avoid hard conversations. Confirmation Bias is a thing, and people will try to defend their points of view. But that’s only more reason why we should bring opposing views and challenge what’s being discussed. But what if I’m not included in the discussions? Well, have you asked to be included? If you have been asking and still are not, look for somewhere else to work.

Do not commit to deadlines we cannot meet. Understand when we can make a high-integrity commitment and when we cannot. Help the team draft experiments and prototypes that give us more knowledge and buy us time to make the most critical decisions when we have more information. This could be included with the last point, but I’m singling it out because it’s one of the most common ways we err.

Communicate clearly during execution and adjust strategy. While we’re building, we make several decisions that affect quality, documentation, and timeliness. This is even more reason for us to understand the strategy fully. While these decisions are clear to us, they’re not clear to the rest of the team members. We need to make sure to communicate emphatically whenever things change. For example, the team might not be on board with us shipping a product that is not accessible. Knowing that we can’t build it to be accessible in the current timeline allows us to either change the schedule or reduce the scope. But only if we communicate that before it’s too late.

Feed data and insights back to the team on how big issues and opportunities really are. Rewriting an application is way easier when we’ve shown people that it’ll make us unlock a lot of value or capacity for the team. This means understanding Software Quality, measuring it, and communicating about it, so the team understands the impact as much as we do. We’ll also pick up things along the way while we’re delivering projects or studying that the rest of the team doesn’t know is even a possibility. We need to bring them to light.

That’s a lot of “extra” responsibilities. But to own our careers and escape the build trap, we need to do this. The best part about doing this is that work becomes way more collaborative and satisfying. We build trust in the team. If you’re an engineer, I hope this helps you take more ownership. If you’re not, I hope this convinces you to include engineers in your Strategy. If I save one wasted quarter with useless features or products with this text, it’s done its work. Let me know if that was the case for you. 🤙🏾

If you have any feedbacks &/or ideas for the next issues please send it to me and I’ll make sure to read and act on it.

If you liked this content, share it with others who might like it too, and thanks a lot for reading it :)