Development Team Report Card, Part 3: Product Design

Here in this final part of the Development Team Report Card series, I’m going to help you evaluate how effective your development team is in building software that delivers value. I’ve labeled this idea “product design” because the design of a software system will either accelerate the delivery of value, or hinder it. A team that excels at product design maintains synchronization with the business needs and shepherds the technical intricacies to serve those needs. However, as a manager, it can be difficult to get an accurate view of the product’s design and how well it aligns with your business’s goals. Here are some indicators that you can look for to gauge the effectiveness of your team’s application of product design:

  • Grade: F
    The planning and delivery of new features is tedious and unpredictable. Bugs and sluggish software performance take a significant share of the team’s time. The remaining time is full of wasteful back-and-forth because new features tend to be poor solutions to poorly-understood problems. Long-term strategy is plagued by technical concerns, requiring an unnecessary and wasteful emphasis on those technical concerns in the big picture. The developers take an adversarial stance to strategic changes, claiming, “the system wasn’t designed to do that.” Many conversations with your developers about adding new features tend to be of the form, “Well, we can’t do that, because <impenetrable technical gibberish>.” You wouldn’t dare put an end-user and a software developer in the same room, because the developer’s bitter contempt for the user is so palpable.
  • Grade: D
    The development team recognizes the mismatch between the strategic vision and the state of the software, and has some very frightening recommendations to correct that misalignment. “This code is crap! We need to throw it in the trash and rewrite it.” Naturally, the person(s) responsible for the code being “crap” are either not in the room at the time, or no longer with the company. Absent from the team’s recommendations are a clear understanding of the tactical steps required to execute on the strategic vision: your team still doesn’t quite understand how the software makes money. Therefore, larger, more intricate features are hard to build. Despite this, your can see that your developers are more interested in building what’s needed than preserving what’s already there.
  • Grade: C
    Although references to a big rewrite are still heard whispered in the wind, it isn’t a rallying cry for your software developers. Developing larger, more in-depth features isn’t impossible; however, the implementations of those features are full of workarounds and half-measures. The inner workings of the software still remain misaligned with the problem domain it’s intended to solve: your software developers are required to mentally translate business-level requirements into the language of the system (you can tell because they will translate for one another out loud sometimes). Simpler, more self-contained features are starting to develop a professionally-crafted sheen, as though (*gasp*) the developers who built it have a clear understanding of the users’ needs.
  • Grade: B
    Despite a few exceptional areas of the software, the software is becoming a well-crafted solution to its problem space. At least half of your developers “get it” immediately upon reading a usability complaint, and they see those complaints as valuable. Your development team actively discourages user contempt. Unfortunately, some technical concerns still require attention at the strategic level, and you may still have some quality issues. However, a positive feedback loop is beginning to develop, because the development team has cultivated enough domain knowledge to have meaningful input into the planning of new features.
  • Grade: A
    Your development team is a machine that transforms product vision into product reality. Additionally, the team also has meaningful contributions to the strategic plans of the software. They’re not technical concerns, as they are for F-rated organizations; instead, your developers are actively identifying risks, gaps, and opportunities that you didn’t see. The communication that you have with your developers is largely non-technical, because you don’t need to know or care: they’ve got that part well under control. If ever you need visibility into the technical details, your team can easily identify why each decision reflects the needs of the business.

This doesn’t have to be utopian, if you’re willing to foster an environment with a few key ingredients.

Many poorly-aligned organizations simply suffer from anemic vision. An ancient document warns of what plagues many organizations:

Where there is no vision, the people perish[.]
— Proverbs 29:18a (KJV)

I’ve written before about the importance of an effective product manager, and it bears repeating: software development will flounder without a dedicated person to guide the software’s vision. Even the most talented software developers will be hindered by the absence of that vision. A talented product manager will be invaluable in helping to shepherd your development team’s collective consciousness into a more fruitful relationship with your big-picture strategy. You ignore the value of product management at your own great peril.

Next, I would recommend that you take a close look at the language you use to communicate your product’s vision. You should consider the vocabulary of your vision paramount, and here’s why: this empowers your software developers to weave that language into the very code itself. The nouns, verbs, and other vocabulary of that high-level strategy is referred to as domain, and an emphasis on precise articulation of that domain is quite powerful:

If programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features.

— Eric Evans, Domain-Driven Design

This emphasis not just on what to do, but why to do it empowers your team to solve the business’s problems rather than just carry out orders. Many software projects are shackled by the “noise” of features that are built without a clear understanding of the underlying domain, requiring software developers to mentally translate between the language of the domain and the language of the system. That translation is necessary when the domain is vague or ambiguous, because the computer demands precise instruction. When enough precision exists in how you communicate domain, that translation becomes unnecessary. Without that wasteful translation, serendipity thrives, and new features become easier and easier to build.

The broken collaboration in the team with a grade of ‘F’ above exists because the team’s perspective is out of alignment with that of the business. The development team’s goals are in conflict with those of the business. When this misalignment occurs, the dialogue around strategy is labored, disjoint, and unproductive. With a properly-aligned team, there is a productive partnership between those who author the vision and those who carry it out.

By creating this alignment, you delegate the responsibility of dealing with quality problems and technical details to your team. Make it clear that quality problems and technical details don’t belong in discussions at the strategic level. If they’re surfacing at that high of a level, that’s an indicator of a problem that you need your developers to solve. Of course, allow for some give-and-take. If you’re trying to recover from problems of the past, your developers may need extra time and resources to deliver on that strategic vision. However that gets balanced, the long-term vision is that the team should manage those technical concerns and demonstrate mastery of them. Set the expectation on your team: “I expect you to be the experts: you should have mastery of the technical details.”

Software developers will, in general, align themselves with the code. They are the Lorax of your software: they speak for the code. Your job, as a manager, is to encourage both the developers and the business around them to align that code — and, by extension, the developers themselves — to your business’s goals. Measuring your organization’s skills in product design is measuring that alignment. The product’s design, if done right, will create fertile soil where changes to your software grow effortlessly.