The Importance of Product Minded Engineers on an Internal Developer Platform

What differentiates DevLab is that it enables our developers to enter flow for clockwork projects. The majority of work required on this platform is removing the many barriers that disrupt, interrupt, and break us out of our flow state. I cannot notice when an engineers’ flow state breaks because we work asynchronously and remotely due to COVID-19.

I rely on a talented team to provide feedback on their experience using the platform. This input enables the project to course-correct toward flow. Members of my team act like the “Product-Minded Engineers” Gergely Orosz describes.

Feature Development for Flow

With any new internal developer platform, there are endless opportunities and features to add. Our north star is flow. We must identify what is breaking our developers out of their flow and fix that first. As the product manager, I do not work in the product day-to-day. I trust my team to inform me if something is breaking their flow. I hypothesize that our customers will not access their flow if the platform engineers cannot either. Is it as simple as tracking engineers’ flow states? I can only speculate and describe that ideal. With any new internal developer platform, there are endless opportunities and features to add. Our north star is flow. We must identify what is breaking our developers out of their flow and fix that first. As the product manager, I do not work in the product day-to-day. I trust my team to inform me if something is breaking their flow. I hypothesize that our customers will not access their flow if the platform engineers cannot either. Is it as simple as tracking engineers’ flow states? Is it as simple as tracking engineers’ flow states? I can only speculate and describe that ideal.

How does the ideal team act?

At the end of the previous week, the product manager and product-minded engineers agreed to a common goal and created stories for a feature slice. The team is not tasked solely with coding. They take control to create design documents, diagrams, call meetings, and whatever is necessary to hit our goal. They own the problem and are welcome to ask for our customers’ time as they like. If the iteration bogs down the team can stop the line and suggest an improvement to the process. We might change the priority of the work in progress or stop work until enough discussion occurs. The next iteration is on the horizon. The engineers’ check-in with the product manager to create new stories. We chirp back and forth on the details, designs, and complexity of each of the stories. Each week we ship that feature slice and observe its impact on our customers.

Conclusion

I love the idea of working on a team where everyone owns the problem and holds each other accountable. Wouldn’t you want to work with passionate people driving you and your growth forward? I will be honest I am not sure what the formula is to shape those around you to become product-minded engineers. Growing product-mindedness might start with writing down clear expectations of engineers on teams. Or it begins with sweating the small stuff. If I learn, I will share it in an update.

Do you work with product-minded engineers? Are you striving to grow your team into product-minded engineering roles? Are you skeptical about product-minded engineers?