Part 2: The People

Previous article: Part 1: First Principles

Your company is a bit like a shapeshifting amoeba. It has a border and some standard structural members, but the dimensions and edges are unique and always in motion. A lot of people tend to think of amoebas... err, companies, as having relationships with each other. They see contracts between "Company" and "Customer", logos on webpages, and elaborate glossy marcom shells. Remember though that these are just legal and creative fictions. The actual relationships exist between people and often this relationship is between only two people, one in each company. To succeed in business, this distinction must never recede to the background.

It should also go without saying, but sometimes must be said anyway, that each person is unique. You might sometimes think of people categorically by their title or role but you must interact with each person in a way that matches their unique qualities, attitudes, behaviors, and thoughts.

Internally to your company, building software products is very much like the parable of Stone Soup: Your product will not exist without each person contributing something unique to the recipe. This process is inherently a knowledge exercise and the people at your company collectively represent its very existence. Lose their knowledge through attrition and, just like someone suffering from the effects of a concussion or stroke, you will lose a very real part of yourself.

There are two dimensions I want to explore on the topic of people. First are the roles - specifically, theis domains and duties. Second, we'll talk about management - how to manage a group of people as a whole while also acknowledging and respecting their individuality.

People Roles: External

Your role as a commercial software practitioner is to do things that cause money to flow toward your company. Broadly speaking, this money exists in "the market" - a broad overgeneralization of all the people who have the problems your product solves. This market also represents all money you could have if you enjoyed 100% market share. In business lexicon, this money is called Total Addressable Market (TAM) and is one of a few very important numbers to know when calculating the potential worth of the value you generate.

While there are many personae you might need to include in your analysis, at the very least you need to consider these three roles:

Consumer: The person who directly uses (consumers) your product. For example, if you're making a spreadsheet application, this person is entering numbers or attempting to use it as an awful database (Excel joke - sorry).

Beneficiary: The person who benefits from the Consumer using your product. If you're Atlassian, for example, the Beneficiary is the management layer that hopes to benefit by their development teams using Atlassian products in terms of things like higher velocity, higher quality, etc. Often the Beneficiary controls the budget for solving a need and is often where your sales teams focus first.

Decision Maker: The person who approves the purchase of your product. Sometimes this is also the Beneficiary, but many times it's someone else entirely. In fact, it's often a role that's gatekept by a corporate function like Procurement or Finance. Whomever and however many people are in this role, you'd better satisfy them all or your product will go nowhere.

The chances of your product being a success is pretty low unless you maintain close relationships with the people in all three roles. A lot of teams are preoccupied with the Consumer ("end user") persona, but it's important to keep all three in the loop as you pursue capturing the TAM. In many companies, the Product Management ("Product") team is responsible for meeting one-on-one with the people in these roles for gathering product requirements, market testing new features (e.g., running focus groups and user conferences), and evaluating customer satisfaction.

These three roles are collectively The Customer, whose need will be turned into Requirements (typically expressed in a Market Requirements Document; MRD) and product development will carry on from there. Never forget though that your product needs to address the expectations and needs of the people, the singular humans, in all three roles - and you need to develop for all of them.

People Roles: Internal

The rest of this section focuses on the people inside the company. Before we get into the weeds, let's lay out how a commercial software product comes to be. We talked about the Customer Need above. From a commercials perspective, you should only really worry about needs that a customer will pay for. There are all sorts of interesting problems and good ideas that are, sadly, utterly worthless. Let other organizations provide solutions to these needs. You need to stay focused on revenue generation.

Company

The first role after the Customer is the Company. This role senses a market need (at this point, monetary worth may not be known, but we'll get to that in a moment) and is largely filled by the Sales and Marketing organizations. It may also include executive leadership (CxOs) as they interact with the market, Service arms as they observe customer problems, and sometimes the Board of Directors. Regardless, this role is responsible for sensing a need and documenting a market requirement that satisfies it. This might be expressed as a corporate initiative or take some other form, but for simplicity, we'll assume the internal requirement is documented in a Market Requirements Document (MRD).

Product Team

The Product Team or, more precisely the Product Development Team, will take a Requirement from the Company and create a Solution to be sold. I break this team into two main parts: Product Management and Product Engineering. Your company might call them different things and these two roles may not report to the same executive, but these roles are tightly married in any successful commercial software company, so I join them here.

Product Management, sometimes just called Product, evaluates a requirement and defines a Solution that responds to it. Product will pass this along to the Product Engineering (Engineering) team when it meets criteria for timeliness, profitability, fitness, etc. At that time, it will be added somewhere into the development roadmap. Just as the Company produces the MRD, the Product team releases these details as a Product Requirement Document (PRD).

Product Engineering takes the PRD and creates a technical specification (architecture, technical components, etc.) and develops a solution that satisfies all the Market and Product requirements. I'll discuss the Product Engineering team in more detail in the next section.

Sales Team

It's probably obvious, but the Sales Team is responsible for selling the solution. The job of the Sales Team will be relatively easy if everyone upstream did a good job of making a marketable and salable solution. This is possible assuming that 1) the Customer accurately recognized a need and determined how much they are willing to pay to solve it, 2) your Company accurately sensed this need, 3) Product correctly evaluated the requirements, and 4) Engineering developed a worthy solution. I'm not going to get into how to manage a sales team, but suffice it to say, their job is rarely this easy.

Production Team

Once a sale is made, the solution needs to get into the hands of the Customer. This job is fulfilled by the Production Team. In a multitenanted SaaS product, this might be as simple as enabling a new account. In a more traditional hardware + software business, the product literally needs to be produced, shipped, installed, and configured before the customer can use it. In addition to considering all three external roles above, it's also very important to consider the expense of your Production Team vs. the deal sizes you win. Some products don't scale well at all because no one thought ahead about dealing with success and the whole operation dies soon thereafter under insurmountable production and deployment costs.

Customer

Now we're back to the Customer and the cycle repeats. It's unlikely you solved all the customer's needs with a single solution. In fact, commercial software companies are usually incentivized to not solve everything with a single product since this would mean there's no chance of repeat business with the same customer.

The business model for your company should match the paying model for your TAM - maybe it's selling subscriptions with incremental enhancements, maybe it's helping them grow their own business and taking a cut of that growth, or maybe you really do just want to be "one and done." Assuming the customer has more needs (and you're willing to solve them) though, the cycle repeats.

Leading (Internal) People

As an engineering leader, one of my primary duties is doing exactly that - lead the engineers. This is made exponentially easier if there's a simple mission directive everyone can understand and apply to their daily work. I've worked at small "garage" startups and I've worked for large megacorporations. Successful businesses typically have a simple (hopefully one sentence) mission that everyone at the company can understand and execute. For example, when I was at Cisco Systems, the number one mission for a while was "Be #1 or #2 in every market we sell to." What this provided to the entire organization of 50,000+ people was a statement from the very top that if you were working on a product that had no chance of making Cisco the #1 or #2 company in that market, you should figure out how to get there or exit the market. I call these mission statements razors because they allow every employee to make a very simple, binary decision about any given project or task. Hopefully you can define the mission for your people at any given time with a simple one sentence razor.

One measure of effective leadership is how consistently each of your people are pulling in the correct direction. Are they unified or are they scattered? It might be challenging to come up with such a simple rule, but it pays off handsomely. In a Servant Leadership model, it's crucial. Without it, the Individual Contributors (IC) who have been given autonomy will authoritatively do their jobs while unknowingly lacking a common goal and pulling in the wrong direction. You want every action they make to be correct and efficient, so give them a rule to live by.

The next step is translating this mission for each of the individual teams through the Manager level. Perhaps you're delivering a SaaS product that stores data in a data lake, processes this data, responds to user queries, and presents the results in a web application. In this case, let's say you have a team for each of these components: data storage, data processing, querying, and presentation. As the leader, you need to make sure each team is pursuing the mission with alacrity, efficiency, and accuracy.

Next, let's say your current mission is: "Improve product responsiveness by 35% in 90 days." Work with each manager to translate this for their team. Remember, if a project or task is not helping your team meet this mission, they should not be doing it (at the very least, they should be asking the manager to explain why they're doing it). So for the data storage team, perhaps the manager translates this to "Reduce data retrieval times by 50%." And for the presentation team, perhaps it becomes "Improve data transfer and display times by 40%." You want each team thinking of how to get you to the overall 35% responsiveness improvement in ways that are relevant to their domain.

At the same time, you will need to establish metrics, measurements, and goals for each product component that provide visibility into the product's and team's overall performance. Measure data retrieval times, query execution times, display times, etc. and establish an overall "product responsiveness" metric that can be captured. Baseline these and set incremental targets to match the cadence of your release cycle.

Lastly, bake these into individual goals. Ask each employee to come up with at least one goal for how they will support their team's version of the group's mission. They can work with their engineering lead or manager to make sure it's S.M.A.R.T. (or your whatever your preferred mnemonic is). The manager should then follow up during 1:1s with how the employee is progressing toward that goal to ensure it remains relevant and achievable. At the end of the performance interval, the IC will receive direct feedback on how well they helped move the group in the correct direction.

Use this approach to synchronize product, executive, manager, and IC goals and to support quantitative evaluations. With everyone sharing the goal, knowing how to contribute to overall progress, and rolling results into the next cycle's plan, you will see steady progress toward accomplishing your mission. It takes some savvy discipline, but it will give you hard facts to demonstrate continuous improvement.

Orchestrating the Engineering Team

We'll wrap up this article by talking about how to orchestrate the inner Product Development cycle. Product features arrive from the Company to Product, move from Product to Engineering, and then are emitted as value to Sales and then Delivery. This external cycle is shown as strictly linear and implies a pipeline that's probably too basic for your actual needs, but I'm trying to keep it simple.

Internally, there's higher resolution cycle that supports continuous value flow toward the customer and hopefully continuous revenue back to your company. These steps, detailed below, are Specify, Schedule, Develop, Test, and Release (and repeat). A Customer Need might be rather large and take a long time to solve. However, breaking this down into logical chunks of value, typically along architectural and/or feature set boundaries, will allow your team to continuously deliver valuable increments to your customers.

Specify

As described above, Product transforms the Company's MRD into a PRD. Market requirements might be something like "Must support multiple user accounts and roles per customer providing access to information and actions matching their subscription level." Product would then turn this into more technical details like "Must support federated single sign-on with at least Microsoft Entra ID" along with a list of roles and a description of what each of those roles can do, etc. Note that this Specify step is different than an architectural specification that happens in the Develop stage.

Schedule

For any marketable feature ("value"), there is a best time to introduce it. It's important that the roadmap be properly paced to support actual development velocity and also to land features when they're needed, no sooner and no later. In most cases, roadmaps track larger deliverables with coarser time resolutions, so the timing might be to a given quarter. This loose granularity is important because it allows Engineering to interleave deliverables and engineering resources efficiently so that team utilization remains at the desired level (typically 80% or so). If the roadmap is specifying things to the month, week, or date, chances are low that your overall efficiency will be good because "all-hands emergencies" are happening regularly.

Develop & Test

When the time is right (according to the Schedule), the Product Engineering team starts creating the market deliverable. This creation happens in two main ways: Develop the software and Test the software. It works best when these two things happen as close to simultaneously as possible. The further they are separated, the larger the testable increments will be. This results in more failed checkpoint demos, more bugs, and more missed delivery commitments.

Developing has two phases: Specification and Implementation. The Test (QA) function needs to be tightly interleaved with both. During Specification activities, QA will gain valuable insight into how the solution is intended to work and be able to create a test strategy that matches the implementation. If you develop in a vacuum and then test only when you think you're completely done, you're definitely not going to be. This approach will frustrate everyone (including developers) and will almost always result in a lower velocity than integrating dev & test into the same process.

Specification, including software architecture, should be led by senior technical staff of all the relevant disciplines. For the Presentation team described above, this will be the API, UI framework, UX design, and associated QA senior staff. These folks will break the PRD into discrete engineering chunks (e.g., elaborated into Epics and Stories, to use a few common terms) for implementation.

Implementation is the next step and is executed by the assigned development team. In an epic/story breakdown, epics are assigned to a single team and team members work on the various stories. The exact workflow process will depend on your product, but the goal is to ensure your pipeline is as continuous as possible, even if you're developing a monolithic release deliverable, so that all the resources in the team remain productive. By using a kanban approach to development, you'll probably be able to more easily see where your bottlenecks are. Bottlenecks are waste, so identify and remove your bottlenecks as quickly as possible.

Also, automate as much as possible. Automation is a huge force multiplier when used effectively. Save your humans for things humans are good at and let computers do things computers are good at. Trying to make either do the wrong thing will lead to massive frustration. If possible, have a fully simulated and automated environment for the engineering team to work with on their own systems so they can test the code as soon as it's written, not days or weeks later in a formal integration environment.

Release

Once the need's requirements have been satisfied and the solution is ready for distribution, Product Engineering will issue the release. There should be an appropriate level of ceremony for the release (perhaps led by a Release Manager) to ensure all the stakeholders are satisfied and all the steps were followed. A Release Readiness Review checklist is a great way to make sure everyone agrees that the software is ready for production.

The Customer will (eventually) get the solution, but at this point in the cycle, the Product Team will already be working on the next increment. This activity overlaps the development and release cycle, so everyone can get started on their next increment right away.

Summary

Building and maintaining the correct relationships between your company and the market you sell to are critical to your success. Remember that these relationships are actually between humans in each organization, not the companies they work for. Focusing on the wrong outsiders will definitely lead to developing products and features that no one will buy. "Value" has become an intrinsic word to effective commercial product development, but don't end up building worthless value.

Guide your team with a simple and consistent mission that everyone can use every day for tasks large and small. This will keep everyone pulling in the same direction and greatly accelerate your product development cycle. At the same time, it will keep the entire team on target, eliminating the tangents that can consume vast amounts of resources and yield little or nothing of value. By the way, this also results in happier employees that don't leave your group.

Finally, have a Software Development Lifecycle and production pipeline that makes heavy use of automation to keep value continuously streaming toward your customer. With the right relationships and conversations happening at the beginning, proper management in the middle, and a low-friction production pipeline at the end, your customers will be delighted with your product time after time.

Next, in Part 3: The Product, I'll talk about identifying value, prioritizing it, and getting it out the door.

Recommended Reading

The Goal by Eliyahu Goldratt (Amazon) [The original storybook for Theory of Constraints.]

The Lean Startup by Eric Ries (Amazon) [Measure, Improve, Profit (or Pivot).]

The Phoenix Project by Gene Kim et al. (Amazon) [An adaptation of The Goal for software and IT people.]

The Service Startup by Tenny Pinheiro (Amazon) [My introduction to Design Thinking.]

Turn the Ship Around by L. David Marquet (Amazon) [An excellent example of inverted leadership easily adapted to software engineering organizations.]

Wiring the Winning Organization by Gene Kim and Steve J. Spear (Amazon) [Probably the single best book I've ever read on technology management.]

Justin Wolf wrote his first line of code when he was about five years old. Since then, he's written hundreds of thousands of lines of code for consumer products in assembly language (Intel and Motorola), C, C++, C#, and other languages. In the mid 1990s, he began learning about computer networking while at Cisco Systems and spent a decade working on enterprise and residential networking products. He worked for about eight years at national laboratory on cybersecurity projects and then at a lab spin-out leading product development of a visual analytics platform fusing machine learning with human-in-the-loop analysis. Most recently, he led a large engineering team building massively distributed systems for battery energy storage systems (nearly 100,000 networked devices for the largest deployments). He lives in Southwest Washington state with his family (and pets) and enjoys sailing in the Pacific Northwest inland sea as often as possible.