If the reason we hire people is to have them produce outputs, it makes sense that we understand what an output is. That's where the elves come in. Seriously.
There's a child's fairy tale about a shoemaker who cut his leather into pieces and left them on his table to finish in the morning. While he was sleeping the magic elves came in and finished up all his shoes. (I guess it was the slow season at Santa's workshop.) As soon as the shoes were finished the elves disappeared.
In the morning, the shoemaker woke up and the elves were gone, but he knew they'd been there. How did he know? He saw finished shoes where before there had been only pieces of leather piled on the table.
So, if your people were elves, and they did their job in the middle of the night, how would you know what they'd done when you came to work in the morning? If you can describe that, you've described the output you expect from someone performing the function of "shoemaker" (or whatever - you get the idea).
An output is something visible: it’s an outcome, or a deliverable, or a visible behavior; something produced after doing some work. It could be something physical, like a marketing brochure or a hamburger. It could also be a change in status – if your job is to clean a room, then a clean room is the output.
Defining an output can be a little tricky - especially with knowledge workers where there output is intangible. When someone makes a decision, I call that an output. When someone creates a new relationship with a vendor or a customer - that’s an output. You may think that that’s just the work people do, and you’d be right. But if you want to systemize your company it’s important to describe the outputs otherwise you won’t be able to improve the systems and scale the company. Think of the outputs as the reason you hire people. If you’ve ever defined the scope of work for a contractor, you’ve described the results you’re willing to pay for. That’s what I’m calling output.
SEMANTICS & DEFINITIONS
Before we get too far down this path, I want to talk about semantics. Consultants are famous for using normal words in slightly specific ways and charging people lots of money for it. I’m more interested in how you can use something that in what you call it.
For example, if you do a google search for “outputs vs outcomes” you’ll find a number of writings about the distinction. This one says an outcome is what the company needs to achieve while outputs are the actions that contribute to achieving that outcome. They say if a bakery makes a Spiderman cake for a kid’s birthday party that’s the output, but happy kids are the outcome. To me the relevant distinction is that there are some things you can control (the quality of the cake) and some you can’t (how people react to it). Your job as a business owner is to learn as much as you can about how people will react (knowing you’ll never be able to predict 100%) and use that insight to determine what your people can control and do your best to make the two line up. I don’t think the labels are critical if you understand the concepts. I may even use “output” and “outcome” interchangeably along with “results” and “deliverables”. I hope that doesn’t shock you.
This reminds me of a time in the 1980s when I was a scribe on a project for a major oil company. They were deciding which of several methodologies they should license to write software for their main frame computers. (“Methodologies” is a fancy word for method or process but consultants can charge more for it.) One of those methodologies had 5 steps — each with a distinctive, trademarked name. Another had 7 steps — but with different names, also trademarked. You get the idea. But if you looked beyond the names, it was clear that each method accomplished basically the same things. That’s because there was only one way to write good main frame software successfully back in the day.
Update: all of those methodologies used what’s now called the waterfall model to write software which is why they were so similar. It has been supplanted by a process called agile which has its own set of names and steps. Agile is different, not because of the names, but because the approach is fundamentally different. What I hope you see here is that looking at a company as a collection of outputs is fundamentally different from looking at that same company as an org chart of people, regardless of whether we call them outputs, outcomes, or results.
So, with that said, here are some different aspects of outputs.
An Output can be a Thing
The elves produced shoes, for example. A sales person’s output is signed contracts.
An Output can be Change in Status
As I mentioned, a janitor’s output is clean rooms. An inspector also changes the status of a part from unchecked to approved or rejected. That’s their output. Now that part can go into inventory (if approved) or back for rework (if rejected).
Outputs Can be Numeric
It's great if the output includes a number: 12 clean rooms per shift for a janitor, for example, or 7 pairs of shoes for an elf. Some things you want to measure by the hour, some by the shift, some by the month. Pick the right time frame for numeric output.
Outputs Can be Behavioral
Sometimes output describes a behavior rather than a physical item; for example, cooperation among team members. When that's the case, be sure to define what exact behaviors you want to see, not just what attitude you’re looking for. This often happens when a company does a values exercise to name the values they view as important. Here’s an example.
Maybe you want your people to be proactive. That’s a nice value. But how will it be visible? You may have an employee who thinks being proactive is figuring out what to do next all on their own. Someone else thinks being proactive means figuring out what to do next by telling others what they’ve accomplished and asking for feedback about how it fits with what everyone else is doing. Two different sets of behaviors might be confused by the using word “proactive” unless you describe the behaviors you expect to see.
Decisions can be Outputs
Some companies need to decide whether they should sell to customers on credit or demand cash on delivery (COD). If they give the customer credit, they need to decide how much. These are examples of decisions that are often made repeatedly. So it’s useful to assign that decision to a person, or team who can be trained and their decisions tracked and improved. Here are some other types of decision outputs.
Hiring & Firing. Often there are guidelines from HR to insure these decisions are made in compliance with laws and regulations, but the decisions still have to be made by someone.
Strategy decisions are made by the top level management of a company. These are decisions about which markets to go into and which products to carry.
Every decision needs to be made by someone, but the person may change as you promote people and your company grows. That’s why it’s useful to specify the decisions you want so you can train the people accountable to make those decisions.
Solving Problems is an Output
As someone moves up through the ranks of a company, it’s common that their promotion is due to the ability and the responsibility to solve different levels of problems. You would think solving problems is always a good thing no matter who does it. But let me give you an example where that’s not the case. Companies who do a lot of tech support often have different levels of support. Level 1 people can solve the problems that are most common and the simplest. If they can’t solve it, they’ll elevate the problem to a level 2 and so on.
Companies do this because level 3 people are more expensive and harder to recruit and train than level 2 people who are more expensive than level 1 people. If the level 3 people spent their time telling people to reboot their computer, it would be wasteful. So you don’t want everyone to solve any and all problems. You want problems solved by the right people who can do it most effectively.
That requires a process known in the medical world as triage — assessing urgency and matching the problem with the person who can best solve it. Good triage produced it’s own output. If this process of triage and elevation of problems is not done well, it can be annoying to a customer - but that’s a different output from problem solving.
Relationships can be Outputs
Relationships with potential customers or joint venture partners, are outputs that business development people are expected to produce. Relationships are also key outputs for business owners who often develop relationships with important suppliers or long standing customers. Documenting those relationships becomes important when an owner is exiting the company. Those relationships need to be transferred to someone in the company or there will be problems for the new owner.
If you’re having trouble describing the output here are four things to try.
Consider the elves. If your people did their work in the middle of the night and went home before you arrived, how would you know that they did a good job? What would you see? That’s the output you want from them.
If you had to run your company from a desert island with no internet, and could only hire contractors, not employees, how would you define the scope of work for the contracts? What would you need to see in your weekly message in the bottle to know the contractors were doing good work?
Imagine two people in the same role producing similar outputs. One does a decent job and one does a great job. What do you notice about the difference? How would you explain the difference to someone who didn’t know them?
Pick an employee. Imagine they were out on extended leave. Make a list of the things you’d have to have someone else do to fill the gap they left. That’s a list of the outputs they produce. You’ll likely find that only some of them are directly related to their role or job description. Discuss that list with the person and see what they can add to it.