Unlocking Peak Performance: Why You're Not Getting the Results You Deserve

Why are you not performing as much as you’d like?

Output and Outcome are two quite confusing words to me. In fact, I find myself constantly using them interchangeably while moderating the daily stand-up meetings for the backend team. Output means the amount of something produced by a person, machine or industry. Outcome, however, means the way a thing turns out; a consequence. To put it into my context, I measure Output by how many features (or tickets) an engineer has produced at a given timeframe (amount produced), and the Outcome becomes the measure of completing the feature that actually meets the clients deliverables (how it turned out). Essentially, to perform, Outcome outweighs Output.

Having worked in the industry for a while, I have always wanted to learn about what would make me more effective, thus improving my performance at work. One of the things that makes this difficult is the fact that there is no straightforward way to measure the productivity of a software engineer. Personally, the measurement of output and outcome gets more complicated depending on whether we base effectiveness on output or outcome.

I have always been biased towards focusing on output instead of outcome. If an engineer delivers a lot of functionalities, whether we measure it in lines of code or functional points - those functionalities do not matter if it does not help the client/user improve their activity.

Difference between being Busy and being Productive?

Being busy is like multitasking, rather than prioritising results. Being productive is working smart by prioritising the most important tasks. To gain productivity, I hyper-focus on a single task, and then move on to another; Think of it as single-threaded programming, whereas being busy is attempting to multitask, except without optimal results from being spread too thin. Productivity is fuelled by purpose and productivity is what will yield an outcome.

What counts as results and what’s a good day for you?

On a daily basis, I perform different tasks and certainly not all of them produce results. I only consider something as a result if after taking up a task I am able to find a solution, implement it, test it and roll it out. This gives me satisfaction, and I therefore deem it as result. Most engineers assume finding a solution to a task is the result, however, there are plenty of solutions for any given problem and it would come down to whether that solution actually produces the best outcome.

Every morning, before I open up a terminal or editor, I scribble a list of things I wish to accomplish before the end of the day. If I am able to nail everything on my to-do list before leaving, I consider it a good day. It always hits differently knowing that my slate for the day is clean and for a few hours, I become the happiest man in Gambia.

Problems that hinder output?

There are multiple issues that developers come across while working on a task, and different issues have varying impacts on the speed or outcome of a result. Mostly, constant change of requirements of an application can affect outcome. In a recent Stack Overflow survey, 33% of respondents consider building an application with unspecified requirements as their biggest challenge in attaining optimal results.

Quality assurance is one of the few things that hinder results. Admittedly, I sometimes temporarily ignore errors, warnings and dirty code I have written because I have a deadline to meet. In an Agile framework, this is sometimes necessary (as long as you remember to revert and fix at a later time). I even find myself switching flows towards another problem to fix something different in a desperate effort to save time.

Recently, I read an article on devbridge.com and came across the term Result Driven Development (RDD). The idea is similar to Test Driven Development (TDD). With TDD, you start by defining the result you want, create means to measure those results through metrics and evaluate whether you’ve achieved your goal. With RDD, results drive the design of the product and they determine whether the product is valuable. I believe this is one approach that an engineer can use to achieve results.

Conclusion

Output and Outcome are quite related, output merely being the actions or activities done to achieve a result and outcome being the actual value of the result. As an individual or team, results should always be the focus. Just calling something a “result”, of course does not make it the right thing to focus on, and it certainly counts as a skill to pick the right results to observe. One handy notion I have adopted from Seiden, who says that an outcome should be a change in behavior of a user, employee, or customer that drives a good thing for the organization. He makes a distinction between “outcomes”, which are behavioral changes that are easier to observe, and “impacts” which are broader effects upon the organization.

Lastly, remember that output is simply a means to an end. If you as an individual have achieved all stated outputs, but you have not achieved the desired outcome/results, then you probably need to revise the outputs. Measuring the achievement of your output alone, without measuring outcome, can produce the “watermelon effect”, which means having all features you implemented working and green for deployment, but after being used, does not produce the desired outcome for your clients.