Being a small team means that we have to wear many hats. One hour I'm looking at our acquisition funnel, and the next I'm reviewing our policies. Later in the day, I might find some time to code some features. It goes on day after day, and I can hardly predict which roles I'll have to play next.

Yet, we ship. A lot.

We managed to do that by embracing a simple truth: we're bad at focus, and we need help.

Why focus is hard

Here's what generally happens. It's the start of a quarter. You meet with your team, run some workshops and set up some goals. Everyone agrees on what the North Start is, and the team is motivated to get there. Exciting!

Then you get back to your desk. Meetings, emails, calls, bugs, tasks, new ideas, support... Distractions start to pop, and you can't eliminate those because this is work. It's what needs to happen for collaboration, and while you can reduce the noise, it's foolish to think that you can make it all go away.

So, the end of the quarter comes near, and you get that email from your manager.

"Don't forget to update your goals for the review next week."

You finally look back at that doc and realize that (1) you forgot about half of the things on the list, and (2) you're pretty far from your target.

You try your best to improve things but it's too late, and there's only so much you can do to move the needle. Your cycle is over, but you'll start again in a couple of days.

Using Continuous Delivery principles to get better outcomes

Don't worry, this is not going to be a full lesson about Continuous Delivery (CD). However, there are a couple of interesting excerpts coming from Martin Fowler's definition (emphasis mine).

The principal benefits of continuous delivery are:

• Reduced Deployment Risk: since you are deploying smaller changes, there's less to go wrong and it's easier to fix should a problem appear.
• Believable Progress: many folks track progress by tracking work done. If "done" means "developers declare it to be done" that's much less believable than if it's deployed into a production (or production-like) environment.
• User Feedback: the biggest risk to any software effort is that you end up building something that isn't useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is [...].

and

You’re doing continuous delivery when:

• Your software is deployable throughout its lifecycle
• Your team prioritizes keeping the software deployable over working on new features
• Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
• You can perform push-button deployments of any version of the software to any environment on demand

Looking at the benefits, Continuous Delivery helps us make real progress and ensures that we are working on valuable things. And to get CD done, you rely heavily on ruthless prioritization and fast feedback loops.

I did throw out a few things that were only relevant to software development, but what if we could create rapid feedback loops on business outcomes instead of feature development?

Surely it would help us make believable progress towards our North Star, and we'd be able to check that the tactical stuff we do every week contributes meaningfully to our goals.

Continuous Delivery helps teams feel confident about their outputs. We wanted to build a platform that helps organizations feel confident about their outcomes.

So we created a simple goal tracking platform with fast feedback loops at its core. We would solve our problem by automating focus and accountability.

Building Continuous Delivery for outcomes

1. Start with the loop

When you create a new project on Tability, one of the first questions is "how often do you want updates?". That's how we know when to send reminders. In our case we do:

• Weekly updates for quarterly goals.
• Monthly updates for our yearly plan.
• Quarterly updates for our Big Hairy Audacious Goal.

There are no daily reminders because we want to help with long-term outcomes, not tasks.

2. Add goals

The next step is to add goals. We just need the description, target, owner and due date. Targets are smart fields that can take different values depending on what you're tracking.

At Tability we almost always use explicit values and let the platform do the maths for us to calculate progress. There are also times where it's hard to set a metric for the goal - that can be the case for large scale initiatives where it's hard to tell if we're 30% done or 45% done. In these cases, we omit the target. We'll rely on sentiment instead (on-track, at-risk, off-track).

Once a goal is created, you can see a progress chart which shows you the expected progress over time. It makes it easy to see how well we are doing week after week. It's the equivalent of the build status in our Continuous Delivery analogy.

3. Get reminders

Tability will take over after goals are created. It will automatically send notifications to owners to remind them of the outcomes they're in charge of, and to ask them to provide an update on their progress.

In practice, it means that I can completely check out on weekends and enjoy a great time with the family. Every Monday at 8am, our bot Tabby sends me a reminder with a list of my goals for the quarter. This way I always keep our priorities in the back of my mind while I go through my tasks during the week.

That's the integration part of the process where the team checks the health of their goals early and often.

4. Share updates

We made progress updates light and easy to do.

• Progress: How fare are you today?
• Status: What's your sentiment? On-track, at-risk, off-track?
• Comment: Why do you think we're where we are? (and do we need to do something about it?)

We automate a lot with Tability but, contrary to a typical CD pipeline, updates have to be manual. That's because the value comes not from the metric, but from how we interpret it. Thinking about why we're ahead or behind our targets helps us refine our strategy and adjust our execution. If we outsource reporting to a machine, it will be great at capturing data, but it won't know how to explain the bigger picture.

And if you're still not convinced about manual reporting. Think about how often you've made good predictions. It's significantly hard to pick the right metrics and the right targets for a specific outcome. What's the best way to measure user happiness? What about satisfaction? Onboarding? You might have some ideas, but I'm sure I can find you scenarios where your choices won't work.

So we do our best to keep updates light and simple. We want to create quick loops with real feedback from the team, allowing others to chime in and offer help when necessary. Over time the progress updates create a clear view of how we've been tracking, and it's easy for us to look at the past to get context.

Goal tracking enables us to move faster with confidence

Continuous Delivery has had a significant impact on the productivity of software teams. It has helped reduce development risks, improve product/market fit by getting early feedback from users, and made organizations more agile - allowing them to adapt the scope of their work from one sprint to another, to make sure they would always provide value to their customers.

With Tability, we see similar benefits applied to outcomes. By having weekly reviews of our progress on long-term goals, we're able to focus on the things that matter the most. We're getting less distracted by side projects, bad meetings, low priority items. We can adjust our strategy after a few weeks if our current effort is not producing the right results.

But more importantly, we're able to move fast while being a remote team, because we have a clear understanding of where we want to be, and how far we are from there.

This post was first published on our blog and you can sign up for Tability today. Don't hesitate to add feedback and questions in the comments - and you can find me on Twitter at @stenpittet.