The Holistic Engineer
Software products are born of many different types of organizations, and even within similar organizations roles might have different names. Here's a generic example with some names on the roles. New products and features start with product managers. Their role is to talk to customers and sales, educate themselves on the market, and determine the right product or enhancement. The handoff to engineering takes the form of a product requirements document (PRD) -- it might sound like jargon, but the term is more or less universal. Software engineers execute against that PRD; QA engineers design tests that assert conformance to the PRD while developers steer the product from point A to point B as described by product management. Documentation writers and learning services take the PRD and the software to generate collateral that teaches customers how to use it. Product marketing makes the PowerPoints; sales presents them to customers.
And that's where babies come from.
It's not a perfect process, but it's birthed many successful products. The shortcoming is that it can bury engineers under filters. Instead of learning about actual customer problems, engineers hear some processed form of what the customer said. Instead of raw critique of a new feature, engineers hear a softened and truncated form. The more technical the product and the market, the more those filters impede innovation and hamper the trajectory of the product.
The holistic engineer augments the jobs of those specialists, participating in each phase of product development. They join in those early conversations with customers, and share the responsibility of market comprehension. They partner to construct the requirements and design that those engineers will then implement. Along the way, engineers of course validate decisions with sales and customers -- this is Agile writ large -- but engineers also participate in the outbound documentation, training, and marketing activities.
From start to finish, the process is designed to fuel innovation by arming creative engineers with data and understanding. Customers often tell you what they want; they rarely tell you what they need. The more technical or disruptive the product, the more value an engineer has in those conversations, extracting the essence of the problem from the noise of preconceptions. The relationships with customer and the full context around their problems keeps engineers grounded as the inevitable gaps emerge in the product specification. Holistic engineers also help to educate the rest of the company and the rest of the world about new products and features. The process of explaining technology advises the way engineers design and build products. When we're having a hard time explaining a feature or presenting a product, we need to revise our design. We've all heard engineering accused of building a product that was too complicated for the market, or engineers complain that a product failed because it was poorly marketed; both are symptoms of poor coordinating. Giving engineers holistic responsibility guards against this problem -- if the product is failing the onus is on them to solve it.
Most important though are the feelings of ownership and agency associated with the whole-body approach. The holistic engineer is explicitly tasked with making a product succeed. That's not to say that he or she goes it alone -- specialists in all functions have major roles -- rather the engineer is empowered to move the product through all stages; the other side of that coin is that there's no opportunity to shrug off a responsibility as belonging to someone else.
In this model, everyone in every role at the company has the opportunity to engage in product management. Indeed, there's still value in explicit product management. Channels of communication need to be easy and open for people with ideas to connect to people who will distill them into implementation. And it's not enough to just create the right environment; hiring processes need to identify broad thinkers, and mentorship needs to nurture and reward holistic execution. Not every engineer can -- or wants to -- take on those additional responsibilities, but the best thrive with market and technology awareness, unencumbered by filters. They want responsibility and authority to make their ideas succeed.
The idea of the holistic engineer isn't theoretical, it's the model we stumbled into in the Solaris Kernel Group, and later implemented deliberately at Fishworks. There, a small team took on wide ranging responsibilities to build a product that's now doing $400m/year for Oracle. At Delphix we're again inculcating and hiring for holistic thinking. At all three I've seen engineers develop new products and features that address customer needs that would have otherwise never emerged from customers' initial requests. It's not easy to find the right kind of engineers, but if a company can empower the right engineers in the right ways -- and they can live up to the responsibility -- the payoff is a better product, built more efficiently.
- ← Previous
ZFS fundamentals: transaction groups - Next →
On Systems Software