MICHAEL WINTERS

Start Small

You’re new. People want you to deliver results. “Move the needle.” You know how to do that really well, and you’re eager. What’s your first step?

Hint: the first step is not to move the needle. Nor is it to determine that you will move the needle by means X and Y, or to commit to moving it by N% in the next Z quarters.

The first step is to establish trust. Because without trust nothing good can happen.

Trust is the accumulation of experiences where people’s expectations were satisfied: outcomes == expectations. Note that this is algebra. Both sides of the “what happened” vs. “what I expected to happen” equation must be in balance.

Start by building the equals sign. In other words, establish the process by which expectations can be both declared and met:

  1. Identify desired outcomes. (“The needle moved => that way.”)
  2. Identify work that you think will achieve the desired outcomes.
  3. Select a SMALL amount of that work - like, absurdly small. The smallest possible quantum with a demonstrable result. The timeline on which you will deliver would ideally also be SMALL.
  4. Align! Your stakeholders must not only understand your perspective on these first steps but agree with them.

The hard part: Nobody wants to see the needle move slightly. That’s not why we hired you. This makes step 4 the hardest, because your stakeholders will absolutely disagree with step 3. Why are we talking about crumbs when we’re trying to move mountains? This is a waste of time.

Except that it isn’t. You are building the muscle by starting small. Just like a software project should not expect a “big bang” deploy to go well, people should not expect “big bang” project selection and delivery to go well.

Continuing:

  1. Deliver the work.
  2. Perform the algebra with your partners. Did you deliver what was agreed upon? Did that deliver the desired (but SMALL) outcomes?

With skill and luck, and by selecting an appropriately SMALL amount of work, the answer to both of those questions should be “yes” out of the mouths of your stakeholders. Even if they scoff a bit at the size of the deliverable.

Getting a “yes” is what matters here, because “yes” is what builds trust. It indicates to everyone involved that this collection of humans knows how to agree on things and then go do them. It’s a subtle emotion. Agree, do. Agree, do. This is the “inner loop” of success. You can always optimize it further, but you cannot function as a collective without it.

NOW you can start to think about the needle. You can increase the amount of work you will deliver in the next cycle and the next by a similar SMALL increment, until everyone is both confident in what will and won’t be done and agrees that the team is operating effectively.

This is the same underlying philosophy behind Agile. The goal there (which is never spoken about!) was to build trust and confidence between the customer who is paying for software development and the provider thereof. We often forget this in corporate environments, when we start seeing each other as collaborators and managers. But treating managers and stakeholders as customers can go a long way towards building an effective relationship.