But experienced engineers often have a good sense of what customers want, and businesses can leverage that knowledge in the early stages of product development (such as conceptualization and design), and not just writing and maintaining code.

So how do you get a department whose goal is shipping code to step back and look at the bigger picture? In this article, we’ve gathered some tips from engineering team leaders, including four who participated in a recent LeadDev webinar about getting organizations to reorient toward a more user-focused approach:

• Najla Elmachtoub, Senior Engineering Manager at Etsy (moderator)
• Rajat Dwivedi, Director of Engineering at Plivo
• Thomas Lobinger, Senior Software Development Manager at AWS
• Kainar Kamalov, Head of Product at Pipe

Values and principles

User focus begins before a line of code is written. It starts with company values. At Plivo, the very first of our company values is customer obsession. We strive to:

• Start with the customer always
• Understand what problem the customer is solving
• Understand how they use our products
• Ensure we do whatever it takes to keep them happy
• Do what’s right for the customer

Other organizations have similar values and principles. At Amazon, Thomas from AWS says, the culture is about driving autonomous decisions and moving quickly to do the right things for customers. He says that Amazon has 16 leadership principles, which guide groups in different ways, so there is no 'truth,' no 'best.' The principles act as a framework for discussion, through which they arrive at a good solution for their users.

Both Plivo and Amazon can point to their values and principles, and it’s important for any organization to have them written down. Kainar from Pipe notes that in a startup, the engineering culture is established by the early engineers. As the team scales, the culture can change unless you put your values and principles into words and refer to them regularly.

The role of software engineering

One of the principles should address the role of the engineering department and its members. Is it to pump out code, or is it to solve problems for users? Both goals might involve the same tasks, but they might deliver different results.

And of course, different engineering team members have different strengths and weaknesses. 'Entry-level engineers are more focused on acquiring tech muscles than on customer insight,' Plivo’s Rajat points out, 'which is fine.' As they climb the ladder of experience, they’re more able to incorporate user insights into solutions.

Managers’ experience makes a difference too. As a manager, Thomas says, you have to 'understand the expectations, but focus on the things you bring in addition.' If you have a product background and are an engineering leader, 'you have a superpower' – a set of skills, a context, and an acquired language that enhances your ability to lead an engineering team. It’s easier for managers with such diverse backgrounds to communicate with a wider range of people on the team.

Finally, consider the organization of the team. 'If the project and engineering teams work in silos with an assumption that they know their jobs better than others,' Thomas says, they may be less willing to collaborate.

The importance of communication

That point segues nicely into the importance of communication. 'Product and solutions are moving targets. They evolve as we progress,' Rajat says, so the product and engineering teams must stay in close communication. One way Plivo does that, he says, is by organizing teams in pods by product, which makes them smaller, like a startup, and makes it easier for them to have the necessary frequent communication.

Kainar noted that in startups, everyone on the team tends to work on multiple different tasks. The most technical people often focus on the most challenging technical problems. But the whole team can be involved early on in talking to customers, doing research, and critiquing wireframes before product implementation.

Thomas agrees that it’s easier to communicate when you have a small, startup-sized team. In a larger organization, he says, you need to understand your organization’s ecosystem. You have to talk to people to learn the history of the situation you find yourself in and understand what you’re solving.

Management has a key role, Kainar says. 'It’s important to be good communicators. As leaders, we have all the context, and it’s important to communicate why certain problems need to be solved. Once everyone is on the same page, it’s easier to come to the same conclusions about what are the right things to solve, and why.'

Lack of communication limits engineers’ ability to focus on users. In a communication vacuum developers can get accustomed to this, and rather than offering valuable input they may just build what they’re asked to without contributing insights that might better address the problems at hand.

Hearing the voice of the customer

One technique user-focused software engineering teams use is having developers try to use the software they’re building to do the tasks end-users need to accomplish. Thomas says, 'If the product you’re building can be used by the people building it, I try to pull engineers into customer conversations. We also have hack days when engineers pretend to be the customer. They will be quickly very annoyed at how the software works', which gives them the impetus to change it.

Kainar cited a policy at one company in which every new hire has to use the product and write up what’s wrong and right with it. The idea, he says, is 'to form a relationship with and empathy for the customer.'

Processes

One way to maintain user focus is to bake it into the processes the team uses. Processes are powerful tools for facilitating regular workflows.

Kainar says processes can 'get everyone in the engineering team to be involved in the customer journey.' A user-focused process might start with defining a problem statement, then gathering user stories, and involving engineers early on. Eventually, product managers and designers get involved. 'It’s all about good communication,' he reiterated.

At Plivo, Rajat says, the product and engineering teams are synergistic: 'the product team are the heart of the business and the engineers are the brain.' Each team comprises a product manager, engineering manager, developers, and QAs. They talk regularly about product vision, market scenarios, and customer insights and behavior.

Motivation

Communication also enhances team motivation. Rajat highlighted the importance of an engineering team knowing what they’re building and why, and who the user is. Some projects aren’t for customers – they might be for internal teams. Engineers are more engaged when they know what problem they’re solving, versus taking a requirement and coding it. That gives a sense of collective ownership and purpose.

Reaping the benefits

All these factors make for a better software development environment. With a user-focused team, engineers are more likely to deliver what the user wants, which leads to higher velocity development thanks to fewer redesign iterations – which also helps lower costs.

Engineers in user-focused organizations intuitively understand how to meet users’ needs. Product managers can focus on innovation instead of micromanaging fine details – which decreases friction between the PM and engineering teams.

Developers are happier when they know they’re delivering software that meets customers’ needs. That sense of satisfaction enhances employee retention and makes it easier to recruit more engineers.

The benefits reach other teams as well. Customer service teams are likely to get fewer calls. Customer success teams see increased NPS scores and customer satisfaction. Finance and management see the user base growing as customers tell colleagues in other organizations.

In a user-focused engineering team, developers understand that what drives the business is what drives their goals. Having a strong set of user-focused values and principles and regular communication results in better software for both businesses and their customers.