If I could sum up the best programmers I’ve worked with in a sentence, it would be:

They know what to build and they know how build it

The later is almost trivial to achieve compared to the former, but without both, you won’t be doing your best work.

I’ve only recently come to understand how equally important both building “software right” and building the “right software” are. As a young engineer, working as a consultant, at the bottom of an org-chart, I was given things to build so I built them. “Knowing how to build” was all it seemed I needed to know. Fortunately, getting good at knowing how to build software is straightforward (if time consuming). It just takes experience and practice, and there are myriad tools, techniques, and other resources to help.

Knowing what to build, however, is pretty difficult. Solving problems is often easier than knowing which ones need solving.

What problem are we solving?

Knowing what software to build requires specialized knowledge beyond software development. Generically, you have to understand what problem exists that needs solving. You then have to evaluate all the ways in which that problem could be solved (with or without software). And then you have to weigh those solutions against a variety of constraints: time, money, chance of success, cost of failure, etc.

Unlike building software, the processing of deciding what to build is not that generalizable. You have to have specific knowledge of the domain in question as well as access to data about the organization you’re working for. My (limited) understanding of the utility industry while working at Opower in no way prepared me for working at Stitch Fix, where I must understand retail, logistics, and…women’s fashion.

Enter the product manager

The way most teams deal with balancing what to build against how to build it is to separate duties. On one side, you have developers who are great at building software. On the other are product managers/analysts/whatevers that understand the domain as well as the specific business. The two teams are intended to work together: product managers identify the right problems to solve, and developers write software to solve them.

This is a nice idea, but it has practical problems. The product manager is rarely technical enough to understand software at a detailed level. Even when they are (for example, a former developer who moved into product management), they have no real skin in the game to actually develop the solution. Whatever decisions they make, it’s the developers that are subject to them.

The developers, lacking an understanding of the business, won’t propose solutions that prioritize solving the underlying problem, but instead prioritize their own team or work. Depending on the developers, you might get solutions that:

• are easy to build and maintain, but don’t really solve the problem.
• are more interesting to work on than an optimal solution.
• use new technology, putting the solution at risk, AKA “Résumé-Driven-Development”

I’ve done all of these things myself, and seen talented programmers to the same.
Without a firm understanding of the purpose of the software, can anyone blame them?

When developers complain about being treated as replaceable parts, this is precisely why that treatment happens. Developers proposing solutions without a solid understanding of the problem being solved are not acting like partners; they are acting like ticket-takers. It’s demoralizing to be a ticket-taker, and you aren’t going to do your best work this way.

Instead of acting like machines that ingest software and produce source code, developers need to act like partners.

Partners

With a product person lacking necessary technical skills and responsibility to properly balance technical solutions, and a development team lacking an understanding of the problem being solved, someone has to meet in the middle.

Although acquiring technical proficiency is straightforward, it’s incredibly time-consuming. There’s no reasonable way a product manager can gain a deep enough knowledge of programming to help. But, understanding the problems being solved, why they are important, and how to know when they’ve been solved is much simpler. This is what the developers should be doing.

Which brings me back to the best developers I’ve worked with. Although technically skilled, they weren’t necessarily programming wizards. What made them effective was that they took the time to understand the problem being solved. They took the time to understand what measurable impact a solution might have, and why it was important. They learned about the specifics of the business where they worked.

They were doing their best work. They were engaged with what they were doing. They delivered results and could point out how what they did had a positive impact on the organization.

When the developers understand why they are doing what they’re doing and have a way to know that what they did achieved its goals, everyone benefits. The organization gets more optimal solutions, and the development team is much happier. Instead of acting like (and being treated like) ticket-takers, the developers are treated as partners. And partners are trusted.

Instead of pressured to deliver something quickly, a trusted team can have honest conversations about delivery schedules. A trusted team doesn’t have to justify their every technical decision to someone that can’t understand it. A trusted team doesn’t spend a lot of time getting “permission” to work a particular way. A trusted team spends most of its time building great software that solves real problems and has a measurable impact. Who wouldn’t want to work on that team?

This is a massive payoff for spending time understanding the team’s place in an organization. Gaining said understanding, however, can be tricky.

Understanding

To get an understanding of the problems your team exists to solve, you need to connect what your team does directly to the goals of the organization. Ideally, you can point to the features you build, and show how they affect the data used by the company’s decision-makers.

This may be impossible at your current job. It is likely difficult. If your company culture can withstand it, start asking questions. Get curious about what you’re doing and why. Talk to the people involved about how they work and how they make decisions. If your company culture makes this difficult, or you don’t find any answers, start polishing your résumé. You are not positioned to do your best work.

If you can’t (or don’t want to) hone this skill where you’re at, my recommendation is to find a product company that sells its product directly to the product’s users. The business model of such a company is very easy to understand. Everything such a company does can be traced to reducing cost or increasing/protecting revenue. All you need to learn is the specifics of the company’s line of business.

I’m not saying that you can’t do your best work at an enterprise software company, a non-profit, or as a consultant. I’m just saying that if you want to start getting good at knowing what software to build, you want to start off simple, and a business model based on direct sales tends to be pretty simple.

Whatever you do, start asking yourself (and others), why you are building what you are building. What problem does it solve? What other solutions were evaluated? Be curious, and you’ll start doing your best work.