In his role as Principal Software Engineer at ITX, John Roets knows the value engineers bring to the table and describes it in the blog below. Leaning on content curated from thought leaders like Amazon’s Jesse Watson, SVPG’s Marty Cagan, and others, John offers words of caution and support to his fellow engineers and their teammates: “If you fail to see beyond technical skill as what makes developers valuable, you’ve got it wrong.”
My new favorite article is The Hard Thing About Software Development, from Jesse Watson, a software development manager at Amazon. I discovered it through James Coplien, an Agile influencer, who has labeled the article as ‘profound.’
The article itself isn’t new – it was written in 2017 – but its message is as relevant as ever.
In the article, Jesse is responding to an independent remote developer – a freelancer, gig worker – who is lamenting the fact that gigs don’t pay well.
On the surface, this seems contradictory. After all, developers are in high demand and are paid well. Right? What’s going on here?
The Value of Engineering: Experts Weigh In
In his article, Watson offers the following to help us understand this seeming contradiction:
The greatest misconception about software development is that it is a separable discipline from deep analysis of the business problem.
Programming skill in the absence of business domain knowledge is becoming increasingly worthless.
A developer’s value to their employer or customers is almost directly proportional to the depth and breadth of…the knowledge that they have internalized and synthesized in their business’s problem domain.
Pretty powerful stuff. But let’s not take just Jesse’s word for it. Let’s have a look at what other respected folks have to say.
From David Farley, in his book Modern Software Engineering:
The ease at which most people can pick up a few concepts that allows them to write a few lines of code [lulls them] into a false sense of their own capabilities. Professional programming isn’t about translating instructions [i.e., requirements] from a human language into a programming language. Machines can do that.
Professional programming is about creating solutions to problems…. (emphasis added)
The real skills – the things that really differentiate great programmers from poor programmers – are not language-specific or framework-specific. They lie elsewhere.
And from Marty Cagan, with excellent related articles here and here, as well as his podcast episode with our Product Momentum team and recently published book Empowered:
…it’s normal for an engineer to need several months to learn…the domain well enough to play the key role they need to play (emphasis added).
The concept that any engineer…can easily and instantly switch between major areas and be expected to innovate defies reality and goes way beyond wishful thinking.
A Word of Caution to Developers
The message to developers is this: If you fail to see beyond technical skill as what makes developers and teams valuable, you’ve got it wrong.
Developer and organizational attitudes, structures, and operational models continue to (mistakenly) reinforce the idea that developers are mere “order takers,” fungible assets to be moved around from domain to domain where the work is.
The message to developers and teams is this: If you fail to see beyond technical skill as what makes developers and their teams valuable, you’ve got it wrong.
Another misguided notion is that teams are “feature factories” to be run like a cost center, where value judgment of individuals and teams revolves primarily around technical knowledge and skill.
Here are some signs that you’ve got things wrong –
- Developers believe “you give me the spec, and I will code it.”
- Development teams are treated like feature teams – not like truly empowered product teams.
- Software development is project-oriented, not product-oriented.
- Development resources/teams are not kept in the same domain for long periods of time.
- Attempts to keep a “skills inventory” for development staff focus only on technical items.
- Finding the “right” candidates for hire is an exercise in looking primarily for technical matches.
The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull.
Additional insights from Jesse Watson:
The hard part isn’t the technology – the number one failure of the software industry is building the wrong product.
The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull.
Mercenaries and Missionaries
At this point let me be clear about what I am not saying: I am not saying that programming skill is not hugely important. It is. But it’s not valuable in the absence of other things. That’s the point.
Marty Cagan likes to make a distinction between “Teams of mercenaries” and “Teams of missionaries”, which makes a lot of sense to me:
Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.
How Developers Can Maximize Their Value
As a developer, in spite of your desires or beliefs, your value is not defined by your ability to be handed a list of requirements and go off on your own and write some code.
As Watson notes, “There are an ever decreasing number of software problems that are so cut and dried that they can be tossed over a wall and implemented in isolation of business expertise. This is why the price for remote programming keeps dropping to zero.”
That may also explain why our gig worker’s lamentation about pay is less contradictory than we first thought.
As you consider the value you offer, think about your work experience (as well as your experience at work), and ask yourself the following:
- Do you actively participate in requirements specification? Or are you instead a passive bystander, with no sense of responsibility for getting the requirements right?
- Do you take the time to understand the product and the problems it’s solving for users? Or are you instead mostly interested in being told what to build?
- Do you (or others) believe your need to ask clarifying questions during development is a failure of someone else to give you all the information you need? Or do you see information gathering as part of your role on the team?
The following behaviors demonstrate that you, as a developer, understand the importance of “internalization and synthesis of the business’s problem domain”:
- You ask clarifying questions about requirements and suggest product improvements.
- You point out potential impacts/risks of implementation choices.
- You ask questions about users and consider the product’s future (i.e., things that users are likely to want, or design choices).
- You actively participate in discussions about product features or product roadmap.
- You write requirements.
- You push for improvements to software design (e.g., decoupling).
- You push for organizational change (think Conway’s Law)
If you’re doing these things, well done. These are the behaviors that produce better solutions to customer problems.
Advice for Career-Minded Developers
There is an aspect of integrity at play here. Software development is (or should be) a problem solving profession. Problem solvers don’t orient around “tell me how you’d like your problem solved and I’ll implement it.” We participate in finding the right solution.
Additionally, my experience tells me that a developer’s career rarely advances on programming ability and technical knowledge alone. Those things matter, of course, but not in the absence of problem domain knowledge. Not in the absence of expertise in engineering practices. And not in the absence of a demonstrated ability and interest in problem solving, learning, and collaboration.
So, if you are a developer:
- View yourself as much more than a programmer.
- Orient yourself around the user and their problems.
- Become an expert in the product domain.
- Learn and master engineering best practices.
- Become a professional software engineer and a problem solver.
That’s what users deserve from you.
John Roets is Principal Software Engineer at ITX Corp. He and the teams he works with follow Agile development practices. John has an MS degree in Software Development and Management from Rochester Institute of Technology and a BS degree in Electrical and Computer Engineering from Clarkson University. His passion is to develop the right software the right way.
