ROWE: creating a results-focused work environment

There's a trope in the world of work where organizations brag about how they measure results vs. hours worked (also known as ROWE).

The logic is straightforward: unlike the jobs of yesteryear, a knowledge worker can perform high-leverage activities and make significant progress that is not directly bound to hours as the input.

I agree with this and think it makes sense at a high-level.

There have been times in my career where I've made significant progress on a thorny issue while taking a break and walking. If knowledge work involves thinking, your brain can be running many threads at seemingly random times of the day.

As we've been growing the team at Friday, I want to create a place where we can do our best work and not worry about the exact number of hours worked. It's virtually impossible as a distributed team to count hours anyways. I'd very much like to create a results-focused environment, but it's not clear how to actually do this.

A few weeks ago, I decided to start reaching out to people to try to unpack what a results-focused workplace actually means and how it works and I was met by radio silence.

After this experience, I decided to dive a bit deeper.

My gut reaction is that a "results-focused workplace" is a buzzword that's thrown around with little consideration. Quite frankly, it seems like a feel-good term that lacks substance.

We've been experimenting with a few approaches here at Friday and I'd like to make progress here. In the rest of this post, I'll outline how I think about a results-focused environment and maybe spark some discussion around it.

Hours is clear, "results" is not

The first point I'd like to make is that a forty-hour week is a clear and trackable metric, while measuring results is ambiguous. For the last 30+ years my dad has worked in manufacturing and when I was growing up, he'd be home at the same time every single day.

There was very little ambiguity around this mode of work.

Now think about "results." What does that mean and how can we track it? What does it mean? Is my definition of results your definition of results? Probably not.

The first thing we need to acknowledge is that we are trading a clear metric for one that is non-obvious. Therefore, we need to establish some sense of common ground. More on this later.

Any metric can be gamed

The second point I'd like to make is that virtually any metric can be gamed. If you use lines of code as your metric, someone will find a way to contribute without actually contributing. If you use story points in Jira, someone will sandbag. The list goes on and on. This is true with hours as an input as well.

A potential alternative to this approach is to create metrics that counterbalance each other (Andy Grove mentioned this in High Output Management). This may work, but it also creates complexity that may create unintended side effects as well.

To be clear, I like metrics and use them all the time, but I'm not convinced that relying extensively on data makes a ton of sense, especially for roles like a software engineer, product manager, etc.

Clarity is needed

In order to move towards a results-focused work environment, we need to create clarity around the expected output of an individual or team.

More importantly, there needs to be some level of agreement between stakeholders around work expectations for a given time period (most likely a week or sprint). How do we create clarity? I think there's a few inputs, which I will break down into two sections:

Foundational components (High-level)

The first and obvious step is that there needs to be some level of clarity around where you are going, and how each person fits in. Using a sports analogy, you need to know what success looks like (scoring goals) and each person's position on the field (forward, midfield, defender).

If you don't have clarity of purpose and roles, it's reasonable to expect that this will carry over into the next section, which is the day-to-day work.

Tactical components (the work itself)

Now, let's zoom in on the work itself and and see if we can create clarity. From my observation, if you want to create a results focused environment, you need to do a few things:

• It should be led by the individual (opt-in)
• There should be discussion to remove ambiguity, develop common ground, and tweak if needed (establishing a benchmark to work from)
• It must be written down (to create clarity and reduce potential miscommunication)
• It must be referenced later (accountability, feedback loop)

1.) It should be employee initiated

If you are a team leader and are constantly telling your team exactly what to do, this may not create high levels of motivation in the long-term. Ideally, you want the people on your team to opt-in and determine for themselves what they aim to accomplish in the given week or sprint. 

If the person hasn't opted into what they aim to accomplish, you may be pushing a ball up a hill in the next steps.

2.) There should be a step with a feedback loop to establish common ground

Next, there needs to be discussion and common ground needs to be created around the expected output. This may be done collectively as a group or between the employee and the team leader. This will typically take the form of a meeting as you need a fast feedback loop to align around what are most likely ambiguous tasks.

The goal of this step is to create common ground amongst stakeholders in regards to the expected output.

I made a graph below to illustrate the negotiation that needs to happen in this step. Perhaps you need to adjust your expected ouput or the inverse may be necessary.

If you are a team leader and think someone is off track or isn't working on the right things, you can have a conversation here and reset expectations or in a 1-1 meeting.

3.) The expected output should be codified in writing

Codifying the discussion is an underrated step that can help prevent future problems. The reality is that people forget things easily and remember past conversations differently. Our brains can only process so much information in real-time.

If you don't write down the expected output, you are setting yourself up for future conversations where it feels like people are on a completely different page. You need to move the information from short-term memory to a hard-drive.

4.) The expected output should be referenced later

Finally, the codified discussion is meaningless if it's not referenced later. The feedback loop is necessary as it will take time to get this right.

You should be able to answer the following questions:

• Did we accomplish what we said we would? Why or why not?
• How should we adjust our expectations moving forward?

Growing up, I played soccer all the time. After every game, I'd reflect on my performance. The coach would do the same with the entire team. I think a similar principle applies at work. Did we have a great week? Did we do our best work in the past sprint? These regular checkpoints are critical.

Specific examples

Now, I'd like to share tactical ways we go about doing this internally at Friday. You may notice that we don't do scrum. It's more informal with a bit less structure and no story points.

I'm not going to pretend like this process is perfect. I suspect we will iterate on our communication process as we go.

Example #1: Sharing weekly priorities on Monday

Every Monday around 11am, I ask the team - "what do you plan on accomplishing this week?" in an asynchronous communication workflow. As you can imagine, this is done with our tool (more examples).

Typically, we will have some discussion around the priorities and goals for the week in a meeting, so this is less about figuring out what we are working on and more about documenting what we've already discussed (establishing common ground).

This establishes the benchmark. As the team leader, I have thoughts around what we need to accomplish, but I try to actively solicit feedback first.

Then, we write this down and share it with everyone on the team, so it can serve as a reference point for later discussion and to ensure that we continue to make progress. Here's an example of what Ryan shared for his weekly priorities.

As you can see, this doesn't need to be complex. This artifact serves as a reference point for the next section.

Example #2: End of week recap on Friday

Every Friday, we do a weekly recap as well. This serves as a retrospective on the work, but also how people felt about the work and what they accomplished. This is not shared publicly with the rest of the group - it goes directly to me and serves as a helpful foundation for 1-1 conversations.

One advantage of this approach is that people are more honest behind a screen and you can use this rich insight to kickstart great conversations without the awkwardness that typically transpires in a retro.

People will share more useful insights behind a screen, but the information becomes even more useful when you can avoid group dynamics & filtering that happens in a public setting.

Next steps

One weakness I have is that I'm not great at planning more than 1-2 weeks.

I tend to be overly optimistic about what can be accomplished in a given period of time. Right now, I feel very comfortable estimating a week's worth of work and what the end result might be, but it's a bit more vague if I were to plan out what we might accomplish in a month or two. This is an area that I hope to dig into more in the future and build process to help.

How do you do this? Also, how do you measure results vs. hours with your team or company? Feel free to shoot me a note on Twitter.