How to Actually Hit Your Goals

And you thought setting goals was the hard part

Whenever the topic of company goals comes up, especially midway through a quarter (as I write this it is early February 2025), it goes something like: “We’ve set our goals. Now how do we OR why aren’t we hitting them?” This exasperation starts with line leaders, trickling up to executives as the quarter wears on with plenty of effort but only middling progress. So let’s discuss an approach to actually hit your goals, assuming that you’ve set them somewhat properly. If you discover you have not – too many, too vague, wrong target, wrong goal altogether, fear not. Kudos to you for trying! In the spirit of iterative improvement, you can do the hard work of undoing past mistakes (cancel goals, shuffle teams, refine targets) when the pain of the status quo exceeds the pain of change.

So, how do you actually hit your goals?

Step 0: Limit each person to working on only one goal

Right off the bat you are probably resisting this one. “People can multitask! We have to be able to do more than one thing at a time, we are an XX million dollar company! Or, we are running out of money, we have to move faster!” Yup, completely agree on your need to move faster. If you want to go fast, do as few things as possible at any one time. Work in Progress (WIP) is the master thief of time slowing you down. If you want to move quickly, allow everyone to deploy their focused attention (their most important asset) by constraining everyone to only one major goal beyond their day job. This provides a natural limit on the number of goals you can attempt at once, keeping you from temptation.

Beyond the sheer number of concurrent goals, the complexity of a given goal will require a nuanced, multidisciplinary approach to problem solving. If you ignore Sartre’s wisdom by assigning a goal to your software team alone, you can expect a software solution, whether or not you need one. Instead, you’ll often need a mix of training, software, managerial feedback and job design to get the behavior and results you desire. This mix of disciplines without proper structure can lead to very large teams, resulting in communication glut. You can use Bain’s RAPID structure, which is opinionated, yet flexible enough to piece together teams and individuals to progress work without introducing waiting delays.

You may be tempted to break the one person, one goal rule when it comes to teams with niche knowledge ($$) and/or a seemingly small contribution to a specific goal. Before you do, ask yourself if you WANT your legal team to be the bottleneck to your progress? I wouldn’t. A corollary: never let a problem persist that merely money can solve. Spend the money then go find the real, much harder-to-solve problem.

Now that you have everyone organized, you can begin the real work. Phew!

Step 1: Understand current performance

It is much easier to get where you want to go (your goals) if you know where you are (current performance). Understanding the relationship between cause and effect in the chaos of a sales process, technology development or clinical services is incredibly challenging, and should be addressed with the serious discipline it deserves. As you uncover cause and effect, you can focus your changes that will move you toward the outcomes you desire, not just in a random direction. Not all change is progress.

The easiest way to understand your current performance, known as the First Way in DevOps, is to visualize the work that you believe is relevant to the goal at hand. Resist the temptation to map out ideal work from afar. Instead you must actually go to where the work is happening and directly observe. Through your effortful direct observations, you can create a visual artifact like a process flow diagram, the ultimate purpose of which is to identify the constraint to flow. The constraint is the point in work flow at which work is piling up, with people downstream waiting for the output of that work. More on the value of the constraint in Step 2.

Unfortunately, many individuals shy away from direct observation citing HIPAA, trade secrecy, customer comfort or some other valid sounding concern that likely masks some performance anxiety. You MUST create a culture where providers of your service expect and welcome being observed, recognizing that feedback from a wise observer will immediately uncover opportunities to reduce friction in workflow at the individual and system level. Keep track of these opportunities as you will need them when it is time to generate and test solutions in Step 3.

Perhaps you have enough of an understanding of your work that you can generate a quantitative measure of performance, all the better. Whether or not you have an initial quantitative metric, you are going to want to iterate toward one, so you might as well start looking for possibilities during your observations. Pay close attention to the variance of the measure rather than just the average. In most cases of poor performance, it is a few outliers doing who knows what that drags the average down from what you expect. You can spend time with positive outliers, those doing it really, really well, to give you clues to overall system improvement, whereas your negative outliers will identify those that need direct support to find and fix errant beliefs and behaviors. Check out a case study on the reduction of work after work aka “pajama time” at Iora Health that employed these concepts. This example is focused on clinical work, but it applies to all types of work: observe the work that your sales team is doing, or your engineering team, or whoever. Make the work visible, and focus on the outliers to find the constraint and possible solutions.

Step 2: Focus on improving flow through the constraint

Let’s dive a little deeper into the Theory of Constraints, beautifully explained in The Goal. Let’s visualize any system of work as water flowing through a pipe. In every pipe, there is one “narrowest point” which sets the flow of water downstream, while causing a back up, upstream. If you’ve ever experienced traffic, airport security, a kinked hose or a million other examples, you intuitively understand the concept. It turns out that for every independent chain of activity (a service), there is also a place where the work gets “stuck.” Everyone upstream of the work is annoyed that they are backed up. Everyone downstream is so bored waiting for that they start complaining about ergonomics and paint colors. The point everyone complains about IS the constraint. Time saving pro-tip: in almost all medical settings, the constraint lives within the doctor’s portion of work flow until proven otherwise. All “improvement” not at the constraint is an illusion, either creating waste, or worse, harming overall performance.

From: https://www.smartsheet.com/all-about-theory-of-constraints

In any system, there is always a constraint. The nice part for you, goal holder, is that the constraint tells you exactly where and how to prioritize your efforts using the five focusing steps. Identifying the constraint (looking for where work is piling up) is the first step in improving it, and therefore achieving your goal.

The next step, exploit, can be better described in human services as maximizing flow through what you already have, without hiring more people/adding more stuff. Whoever lives in the constraint is losing their mind trying to keep up, feeling like they are letting everyone down and then burning out. Been there, no fun. As the constraint is usually the licensed clinician in clinical settings, first decide what you actually want your clinicians to do. This is the “top of license” concept that is all in vogue and is MUCH harder than it sounds (probably a whole post). Once you’ve clarified role expectations, then start removing friction from work flow– reduce clicks, reorganize exam rooms, use AI to write notes, ensure sufficient supplies, etc.

From there you can subordinate everything else to the constraint, which in human terms means having other team members supporting whomever is at the constraint, rather than starting their own work. If you find yourself NOT at the constraint in your organization, do NOT make yourself busy starting new work or you will only make everything worse. This is one reason for the one goal per person rule, to prevent well-intentioned bored people from starting new work, worsening flow through the system because they were bored.

Once complete, then and only then can elevate the constraint, which usually means hiring more people. At least now you are adding people to a smoothly functioning system, rather than throwing bodies at a worsening problem. Creativity before capital. Once you everything humming along smoothly, the constraint will shift on you, forcing you to find the next one. Success just leads to bigger problems!

Now that we’ve identified WHERE and WHAT KIND of improvements you ought to make, you will likely end up with a long list of possible improvements. Cue the endless prioritization conversations…

Step 3: Decide and Go

As a product leader, I will confess that I don’t like prioritization meetings for the same reason I don’t like feature roadmaps – they are kind of bullshit. More specifically, when arguing over “what fix to make next,” we have a tendency to assume that we understand cause and effect and therefore believe that our proposed solution will work in achieving the intended result. I’ve never experienced this. Or even worse, we use elaborate frameworks that attempt to quantify effort and impact, when really we are just trying to legitimize our intuition while appeasing bullies and squeaky wheels. This all stems from the errant desire to “be right the first time.” As a result, we let weeks slip by in scheduling meetings to get it right, when we could be investing hours and days doing something to actually learn about cause and effect.

To avoid this trap, pick 1 or 2 possible solutions and get going. To reinforce this seemingly haphazard approach, let’s start with the underlying math. The number of possible ways to rank a list is the factorial of the items on the list. So for a simple 10 item possible solution list, there are a staggering 3,628,000 ways to order it. Now you understand why your meetings take so long! If you want to choose 2 from 10, keeping a first and second priority, you are down to 90 possible combinations. If you are indifferent to order, there are only 45 ways to pick 2 items from 10. Still a bit of work, but achievable. So just pick 2 off your infinite list of ideas. Any 2, that your gut is telling you to pick, then get started with prototyping.

But Andrew, what about things that take a long time? Make them take less time. There is a concept from Good to Great called Bullets Before Cannons, which advises trying a small sample of something, a prototype, before committing to a full change. You’d be shocked how often I hear a request for six figures of salary time to make a statistically significant number of patient phone calls when no one has even tried to make one. Give yourself a week, pick 1 or 2 items, and try them out as quickly and cleanly as you can. Using your dedicated clinician users, try out a new workflow, or button, or simply a small tweak in furniture to see its impact. If and only if these initial tests appear fruitful should you keep going. Holding yourself to a week really limits your ability to overdesign before getting feedback. Again, you DON’T know what is going to work in advance, and the sooner you find the humility to stop pretending you do, combined with the confidence that you CAN learn if disciplined, the faster you will hit your goals.

If there are long lead time items with long waiting periods (licensure, permits, anything involving a regulator, equipment ordering, etc.) then you might as well kick off the process, being mindful of the point of no return and/or big investment. But the big things will never save you early in a problem because you don’t actually understand what is going on. Remember, creativity before capital.

Step 4: Iterate weekly

You’ve started understanding current performance, found what you think is the constraint, came up with a few ideas and tried some, all in one week. Phew, busy right? Now you have to do it again. I like one week cycles for three reasons: first, “this Friday” and “next Friday” are ambiguous enough terms so as to cause confusion. Second, week-long iterations allow people to NOT regularly work on the weekends, preserving slack and preventing burnout. Third, if you only have a week, you will not plan too much work and may actually get something done. You don’t HAVE to change what you are doing at the end of the week, but this should be a conscious decision. I’ll let you figure out what to do with stub weeks (holidays, off sites, etc.).

Every Monday (or cycle day 1) you decide on your 1 or 2 “bets” and get going. Every Friday the Rs and Ds of all the RAPIDs meet together and share 3 things:

1. Change in measured performance over the week

2. What was learned (not what was done)

3. What you plan to do differently as a result next week (same bets, next bets, etc.)

This cadence allows everyone to stay nimble, focus on learning and results over effort, and hold themselves publicly accountable without locking into a long, failed course of work. “Failed” experiments lead to learning, failed discipline leads to chaos.

On top of this weekly cadence (still with time for regular Scrum meetings as you see fit), you should loop in all the executives every 2-4 weeks and then the whole or a large subset (all RAPID members) of the company every 4-6 weeks. Again, build a predictable rhythm of your organization to keep everyone connected, informed and engaged. Keep repeating, iterating your way to success.

Seriously, that’s it. Focus a few people on a problem with a visualized flow and a measure, constrain the number of people they have to talk to (but not CAN talk to), the amount of solutions they can try at once, and don’t make them report on effort (which ends up causing them to avoid trying things to avoid looking like they “wasted” time) and have a front line team that can implement/test changes in real time and you would be SHOCKED how fast you can improve things. Plug the output into your integration process and watch as the organization begins to converge (instead of diverge) and then discover a MUCH HARDER set of problems that were obscured by your former chaos. Good luck!