Every technology team wants to have effective engineers. But what are the goals of a software engineering team? Managers might suggest it’s creating software according to requirements and user stories, increasing velocity to complete more Jira issues, or developing a user experience that replicates design mockups. One skill-set is often overlooked that prevents teams from realizing their full potential. Creating a culture of product-focused engineering is a practice that helps teams deliver better products, while improving communication between departments. Additionally, product-focused engineers are critical to creating high-impact teams that are lean and agile.

Engineers are natural problem solvers, and in most companies, the problems they are asked to solve are evaluated on two simple metrics:

• Function: Does it do what we want?
• Performance: Does it do so quickly and cheaply?

There's nothing wrong with this approach since it leads to efficient Engineering Departments focused on velocity, ones that act as a powerful tool for product managers and designers. The philosophy behind that is to let the experts concentrate on what they do best — but it also tends to silo the team and reinforce communication and expertise gaps, especially in an age where remote work, outsourcing, and contract development houses are commonplace. There’s more to building a product than strictly engineering output.

Putting Engineering and Product in Sync Product-focused engineers combine their development knowledge with higher-level product priorities to make more effective product decisions that weigh both Product and Engineering outcomes.

We’ve found that by empowering engineers to be more collaborative with product managers, designers, and other leaders, they understand their own tasks better and ultimately are more productive. Not just in the sense of code velocity but in that they are contributing to meaningful decision-making that affects both their work and the end-user.

Traditionally, the interface between engineers and Product is fragmented and infrequent, on a need-to-know basis. After all, why would you burden an engineer with Product KPIs and UX priorities? This way of approaching products is dated.

Think about it: without knowing about what users are experiencing or what interactions and metrics are important, can an Engineering Department really find the best solution to a problem? Anything being built, from buildings to devices to software, benefits from context and suffers from a lack of context.

Closer to the Code Engineers are well-positioned to identify disconnects or opportunities between design and implementation. There may be hidden states, undocumented interactions, and requirements that nobody in Product would be expected to be aware of, but with which those who coded it are intimately familiar. They know the systems in and out, and that knowledge is valuable beyond strictly implementing user stories. What would it look like if they were empowered with product knowledge?

Think of being asked to add a new payment method to a mobile app. Sure, it can be done to spec and engineering would provide a rough timeline for that. What happens if engineering estimations won’t meet the deadline required for the integration? Ideally, an engineer can evaluate alternative approaches, making a decision or recommendation by balancing engineering output and product impact.

There are questions that are very much on the product and design side, but which affect how engineering goes about its job. An engineer’s deep knowledge of the system allows them to make relevant recommendations and choices based on differing KPIs. For instance, with the payment method, there are several possible product priorities that lead to very different engineering priorities:

• Minimize sign-up friction: Focus on speed and UX simplicity
• Maximize engagement: Infer user intent and offer contextual options
• Promote partnership: Guide user to the preferred outcome

These may not be mutually incompatible, but knowing which is foremost is crucial information for engineers to keep in mind while building.

Engineering also has key knowledge itself that can affect costs and user experience, meaning Product Managers should be aware of it. For instance, what if the way users are stored means that adding a certain payment system would necessitate a lot of schema restructuring and rewriting of other integrating systems — unless you go about it a certain way that Product needs to sign-off on? Product-focused engineers are in a position to prompt that decision early on.

A product-focused engineer is aware of the concerns and priorities of product and leadership, and can make intelligent decisions down to the bare code that works in favor of those. They have a voice in how higher-level decisions are implemented and their own input is valued earlier than MVP.

Holistic views improve outcomes We've seen that this creates a better balance in organizations of all sizes, because this kind of cross-pollination between user needs, design needs, and engineering needs, is simply healthier and more productive. A holistic view of the company helps every department understand why it is they're doing what they do, and what the best way is to go about doing it.

Product-focused engineers generally come from the full-stack and front-end worlds, since they're already closer to outcomes and processes at higher levels of an organization. And while it's good for any engineer looking to be better at their job to take interest in these other signals, traits like curiosity, empathy, and active listening are equally valuable as others like memory, decisiveness, and flexibility that make a good coder.

So how do you foster a culture of product-focused engineers? It isn't simple, but we have some ideas for how to get started and implement it as a structure in your engineering organization in our next piece in this series.