From Code to Customer: How Engineering Managers Can Master the Love Factor

One of the biggest mistakes I ever made as an Engineering Manager was to think that my domain was purely technical; that Product was the sole voice of the customer. This is a disempowering point of view and does nothing to foster Customer Love for the team. It made me set my scope narrowly into the tactical technical problems, or even the strategic architectural ones, missing entirely the far larger (and more interesting!) world of business strategy. 

As a recap, the best summation I ever got for the responsibilities of an Engineering Manager were: 

1. Happy Team 
2. Customer Love 
3. Don’t ship Stupid 

In Part 1 of this series, we covered the first and the most important of these, Happy Team. Today I want to tackle that mistake of mine, and talk about the second priority: Customer Love. 

Customer Love: Is the customer really always right? 

In my 28 years in the industry, I’ve heard a lot of lip service paid to the Customer is Always Right dictum, both within and outside tech. It’s a good principle, though not always true. (One only has to see complaint letters sent to tour agencies, e.g. “I went on the holiday in Spain but couldn’t understand anyone because they all spoke Spanish!”, to realize this.) 

In the tech world, however, I’ve rarely seen an emphasis on customers truly be the driving force behind product decisions. 

Why? Well, let’s talk about a few reasons. 

Deadlines, deadlines, deadlines 

It’s a well-known truth that any software development effort is subject to three main variables: Features, Quality, Deadline. All three cannot be set at once, or, at least, not without completely burning out the team if the project in question runs longer than a week or two.  

In the traditional Waterfall model, leadership typically sets Features and Deadline as the main invariants, leaving quality to suffer. In fact, I still remember the bug triage meetings I attended in the early 2000s, where we’d walk into the room chanting “Punt, punt, ship.” The product in question had a bug tail in the hundreds, and if we really took on every bug we would’ve slipped the deadline by months. Hence, punt, punt, ship.  

Agile flipped this model on its head, allowing teams to use either Features and Quality (we’ll ship when we’re ready), or Quality and Deadline (the MVP model). This was a marked improvement, but even there, the draw of getting the product to the market faster was huge. And once the industry started getting rid of manual testers in favor of automation, and then reassigning SDETs to SDE roles, the corresponding drop in found bugs made shipping earlier that much easier. (For PMs, the SDET->SDE merge was a godsend: “You’re telling me that before I had a team of 4 devs and 4 testers, and now I have 8 devs? Awesome! I can get twice the number of features into the product!”) 

Who suffered? Why, the customer, of course. Product quality dropped. (Anyone remember Windows Vista?) Even compilers, once a paragon of reliability, started misbehaving. The number of poorly-conceived features skyrocketed.  

 Customer Love this is not, friends.  

Customers? Who the hell are those? 

One of the most memorable customer encounters I’ve had occurred when I had to fly to Boston on a day’s notice to meet with a VP whose company had deployed our product at a yearly subscription. A couple of months into the deployment, he had sent our customer support team an angry email, ending with “I wouldn’t buy this shit if it was free.” 

They’d been having problems. Granted the product was problematic (a staggering amount of technical debt the product team wasn’t given the time to tackle), but we on the team believed it still provided value and wanted to get to the bottom of the customer’s issues. 

So the senior PM and I went on site. We talked to the VP, and to the members of his organization. We listened to their concerns and talked about ways to tackle them. 

And you know? By the end of our day visit, the customer’s temper had cooled by orders of magnitude.  

The other super-memorable experience for me was as a solo developer of a Windows Phone app called CycloMeter. The most memorable part of this was the support emails. I’d set up a channel via UserVoice where customers could contact me directly. I replied to every one of those emails. I worked with them to resolve their issues, and in cases where I could not, I created channels in the app to either refund their money or give them free addons. 

The app enjoyed a 4.8 on the App Store and was the top cycling app on Windows Phone several years running. 

Now, let me ask you this. If you’re a member of a product team, when was the last time you talked to one of your customers face to face? Has that ever happened? I know that large companies put significant obstacles to any attempt by the product team to interact directly with their customers. Developers are frequently forbidden from answering forum posts, or if they’re allowed, they or their responses are vetted by the marketing team. Site visits? Forget about it! A couple teams I was on had a Frontline program where SDEs could shadow customer support, but, at most, they’d engage once every half a year. 

How can we profess Customer Love if we don’t know who the customer is? If we’ve never talked to them, heard their painpoints, their wishes for our product? How can we profess Customer Love if we outsource Customer Love to PM, Marketing and Sales? 

Customer Love? We need a different approach! 

So what does Customer Love mean for you, the Engineering Manager or the SDE? Well, first, it means doing your level best to understand your customer’s needs and to ensure your team has a solid view of how the customer is using your product and what they need to do with it.  

Getting this view can come in many different forms depending on the shape of your product: 

1. Direct engagement via site visits 
2. Shadowing Customer Support 
3. Answering or at least reviewing forum/social media questions 
4. Regular syncs between your team members and Sales and Marketing to understand the customer needs in your product niche 

All of this is input data you, as an Engineering Manager need, to tackle the Features/Quality/Deadline triangle.  

But even more than that, there’s nothing more satisfying than having a direct interaction with people using what you and your team build, even if that interaction starts out negatively. The opportunity to help your customer directly is hugely empowering, and it is no less hugely empowering for your engineers!  

Call to Action 

Not only should you as an EM look for such opportunities, but you should also encourage your engineers to do the same. Get them to reach out to your Marketing/BizDev/Sales/Customer Support counterparts. Give them time to dive above the day-to-day grind of the code and think about the business. Don’t make the same mistakes I did – never put your customer rep people into the position of being the only source of your customer interactions and knowledge. As a manager (and even a dev) you need to own the whole story, end to end.  

Doing so will enable better decisions on the ground, whether they be technical or prioritization, and this will translate into a more successful product that your customers will love.