Inputs, Outputs, Outcomes
At this very moment a Manager somewhere is wondering if they have an accurate and honest model to measure performance of their team members and projects. These questions often sound like one of these:
Is this one team member not doing anything or does their performance report look bad because they have a really challenging problem? Are they just unlucky with lots of quality issues and scope creep? What’s the best way for me to help?
Is this one team member looking good because all they do is small tasks, or did they find a way to make big tasks into lots of small ones? Should I give them more challenging work?
Am I just playing a numbers game with reports to make it look like we are successful?
We have a career performance framework, but it isn’t helping me identify if someone is really productive or not, I can just diagnose the skills they might have or activities they are involved in which we assume are useful.
How do I communicate progress and team performance to my business counterparts when we’re stuck on enablement work that doesn’t directly change any metrics?
Are we working hard, and if so, are we doing anything useful?
There's a very simple and easy to remember mental framework that will let you diagnose those situations and pick a path forward clearly. I call it “Inputs > Outputs > Outcomes”, and all you need to do is clearly assess the state of each of these.
In simplest terms, “Inputs” are just raw human effort, you can work all day and never complete a task, but you still provide a huge amount of inputs. Outputs are an indication of work that is done. An output is often that moment when you checked an item off your todo list. Outcomes are only ways that you were able to make a concrete impact on business driven metrics, something connected to the reason that you and your entire team got budget approval to exist in the first place.
A lot of people get stuck debating measures along these three areas because some are meaningful, some are easy to get data on, some are flawed, and some have a lot of conditions and context around them. Often people seek for a “solves everything” metric with a heavy bias towards one that has some data records attached to it. Sometimes people like to waste time steering conversations towards the vagueness of human language and argue that someone can interpret an outcome as an input (for example, some nonsense statement like “this team exists to have people work on tickets” and they measure hours of work invested). These are cases where even the behaviours of these two people are not focused on outcomes, they either want outputs (in the former case, they just want something to measure so they can check it off their list), or input driven (they don’t care if selecting metrics is done, they just want to add something). Neither of those behaviours drove outcomes, and I can use this model to identify where their disconnect was and work on solving it with them.
Right now I manage Software Engineers, and one of the most common questions new employees have is “Am I doing well?”, especially in situations where they might not be completing work as quickly as they thought they should. Sometimes they don’t even ask, but I can tell it is a concern of theirs because they preemptively try to defend their situation by giving me context about the problems they have. This is a form of a request for performance feedback and support which should not be overlooked, and you can quickly ask them to describe their activities, what they completed, and how they are making an impact to get an idea of where the problems are.
In general you can informally observe and probably have a good gut-feeling for where your own engineers are in this framework:
Some Engineers are known for their ability to take on an objective, do any research or discussions needed, and then operate in ways that produce great outcomes, bringing something of value to the business in a short timeframe. It might not be clear if they are doing a lot of work, but you do know their work is on-target.
Other Engineers are “Ticket Crushers” who create visibility in terms of the amount of work they are doing: tickets fly from left to right on the board, and they have multiple deployments per day. You might not know if all their work is useful, but you know they seem to get a lot done.
A number of engineers have times where they seem very busy but it isn’t clear if they are on-track to getting done or when they will get done, it might not even be clear if they are working. You might not even know if their work will be worthwhile if it ever gets delivered.
When you discuss productivity with someone you can diagnose their situation by starting a discussion about outcomes. Ask them about what numbers they are impacting, what the results of their work will be, and if they have or have not already made an impact. This lets you identify if they understand the work’s purpose and also if they are delivering.
Afterwards, and especially if you detect they have problems with delivering outcomes you can direct the conversation towards their outputs. It is unfortunately common that engineers are busy releasing software but unaware of how it is connected, this leads to a lot of change or work in areas that are not in the target-area. They may be over-producing quality in areas that do not need it, they might be cutting corners in places they should not, they might simply be stuck or slow in converting their input effort into output task completion. This could be for any number of reasons but you can explore ways to solve skill gaps, process issues, external blockers, or even direct mentoring on how to get the work done. Do they work on a lot of unrelated topics at the same time?
If you have a lack of outcomes you should still check how their Inputs are doing. Are they not able to contribute to a topic due to being spread too thin? Are they lacking motivation? Did they not understand the importance of working on it, or are they uncomfortable with doing the work? Are they just not showing up for work?
In general I tell myself that inputs produce outputs which produce outcomes, and if something at an earlier stage is broken everything downstream will not see results. I do think this is not the full reality however, as some level of interplay exists. You may have someone with poor inputs because they do not understand the outcomes, or you may have someone with great quality of outcomes but the volume of outcomes is low due to low ability to complete work. In general the rule works, and if you have an awareness that they are not fully isolated like stages in a vehicle assembly line, you will be able to use this tool effectively.
The thing that makes this concept work is that it forces your conversations to add detail about how work gets done, instead of inspecting a person for different skills or characteristics, it also is not applying pressure blindly to try and get results (for example, asking for estimates or burndown charts), or blindly offering encouragement as a way to motivate (“Well, I trust you can do it!”). This gives you a way to find the right places to get involved with minimal guesswork, and makes it really clear what you need to do to help. In fact, you can form a plan together and explain the problems and get mutual agreement on where the focus for improvement is needed.
I’ve found I can use this to improve performance of individual contributors on my teams, improve the collective performance of a team, and get projects back on track.
I found I can also use the details I gained from these simple “Input, Output, Outcomes” conversations to help me communicate to the rest of the company about where a project is, what problems they have, and how they can track progress and effort at different stages. If you can’t ship outcomes you need to be able to explain the outputs and explain how they will contribute, and show that outputs are happening. If you have no outputs you need to be able to show the inputs and explain what outputs those will create. In my experience, once you and your teams consistently deliver good outcomes, most people outside of your team will stop asking about your outputs or inputs, but if you fail to keep up healthy outcomes they will start to ask about it (and sometimes it can happen when there is management change, and someone new with no context wants to understand your baseline performance numbers gets involved, or your outcomes are called into question in a political setting).
You may discover that to enable your team to actually focus on Outcomes they must first receive training, agree to be accountable for outcomes, get buy-in from external teams, and many other challenges. This is part of the job of a manager and a leader who wants a team to become outcome focused.
The Success Theater measures of team performance are too easy to get tricked into. Tracking the hours someone is typing is a measure of raw input but it tells you nothing particularly useful beyond how much they typed. If they are not typing, does it mean they are not participating in other forms of input (meetings, thinking, reading)? Does a high task completion mean a team is successful, or just that the team uses a task tracking system in a specific way? Does it mean that the outputs are actually useful, and are they actual outputs or just numbers reported in a ticket system? Success Theater is attractive because it is so easy to access the data, but this data is relatively meaningless and distances you from the details about how you can manage and improve the performance of your team. Often, the data given to you by an elaborate query can be extracted with a simple conversation focused on “Inputs, Outputs, Outcomes” and a meaningful diagnosis with the details of what to do can be found faster than untrustworthy data.
Performance is about work getting done, so focus your conversations into the details of these three stages and you will be able to diagnose, anticipate, and communicate performance issues with minimal effort and no overly complicated frameworks. It can be as simple as “Inputs, Outputs, Outcomes”. Don’t be afraid of the details, structure them.
