chore(piqued): a note on selling change

Your efforts to right the ship needs to be sold to a number of stakeholders.
Each group of stakeholders want to know how they will benefit from your efforts.
Managers are often the biggest decision makers but are typically
the simplest to persuade as well. With management and other non-engineerng IC
stakeholders, the first thing we need to do is to stop using the phrase tech
debt. This phrase is not prioritized with these stakeholders.
Let's first take look through the eyes of management:

1. What do managers care about?
    * They care about getting their teams tasks done

2. What does your manager's manager care about?
    * About all their teams getting their tasks done

3. What does the manager's manager's manager's manager care about?
    * Making their mark... and that requires everyone finishing their tasks

<img style="display: block; margin: auto;" src="piqued/interest_piqued.gif" alt="my interest is piqued">

The common thread when talking to management is that they are mostly bean
counters wanting to make their bosses happy 👻. I'm mostly joking,
but I imagine its not far off for a lot of you. For the rest of you all
that have competent leadership, make it easy for your management to
sell your efforts up the chain of command!

When we're talking to these stakeholders, we need to phrase our endeavor in
terms of improved velocity, improved quality, reduced defects, and an
overall win for every effort going forward. It doesn't have to be hard
and fast numbers to support this.

Take a small example of a task your team has to complete. Write down
what's required to get it done following the status quo/legacy software.

Here are some items to capture:

* What's the amount of work involved?
   * Take a guess, t-shirt size it
* Take note of how much rework/non-value added work is required to get this done
   * Non-value work are often necessary, but mountains of it are eveidence of a systemic problem
* Write down how much risk is inherent to the part of the system impacted by the task
* How easy is it to test?
   * If its difficult or impossible to test we're increasing our risk of defect dramatically
   * If you have data, even if its anectodotal, speak to that
* Do we have a safe means to rollback in the event of an issue?
   * What's the likelihood of encountering that situation?
* Take note of the concern from the team regarding the work
   * Is there a general feeling we're dealing with a house of cards?
* Acknolwedge the on call experience
   * Has it been getting better/worse/stayed the same?

Taking a few moments to answer the above helps you build a coalition around
your new design endeavors to your non-engineering stakeholders. Notice we
never mentioned anything about CPUs/jenkins/kubernetes/etc. We kept it at
the language of management.

Take a moment to explore what this task will look like when you have the
redesign in place. Do not include the time it takes to bootstrap
that new design. We'll get to that *cost* in a bit. Capture the same items
from the list above, only this time do so as if you have your legacy
replacement in place. I recommend making one addition to the list above.
I recommend you add a line item for things that you can now do that
were once _impossible_. The more meaningful that item is to your stakeholder
the better they'll receive the whole of your argument for change.

Quick note about the *cost* of the legacy replacement. If you start by
talking about the cost of the legacy replacement, you're going to be facing an
uphill battle. Management will miss the forest for the trees. Your
management's head will immediately go through the thought exercise of trying
to explain something they don't fully understand to their boss. Not only is
it a design they likely won't fully understand, they'll also have no idea
what true *value* they'll get out of the design. Instead postpone that
discussion until **after** you've provided the *value* of the work.

Now all you have left to do is add everything up and summarize it by stakeholders.
Stakeholders include but are not limited to the following:

<details><summary>Management</summary>

Note how much your velocity could improve across the board. Also,
make note of the ability to test and assure quality earlier in the code's
lifecycle. Ideally, you're able to create a strong integration test footprint.
This raises the bar of quality you're delivering to your stakeholders. If
you take it a step farther and include end to end tests and continuous
deployment tests.... you're in an **insanely strong** position.

<details><summary>On Continuous Deployment Tests</summary>

After I had learned to design and test well I still found issues in
deployment. We aren't deploying in a vaccuum. If you're deploying in
the cloud, you have some sort of cloud infrastructure that has to be
available/setup to do what you need to do. Regardless of where or how
you deploy, you have some environmental dependencies. Any of those can
create an issue when they do not line up with expecations. There's a
lot more to the problem than what we see in a continuous integration (CI)
pipeline.

If you do not have continuous deployment tests, try creating a CLI/scripts
that codifies your deployment tests. These can be issued after a deployment
reducing the risk of defects. Since the tests are codified into a CLI/scripts,
your whole team has a simple way to repeat the process. Once again, we're creating
standardized work. This can take you quite far. When you have the means to deploy
tests that run in your deployment environments, you can take what's in that
CLI/script and reuse it in the tests you setup. A giant standardized win!

</details>

These test feedback loops improve your ability to understand the system.
Increasing the bus factor beyond one is a huge win. That is a (often
undisclosed) risk associated with any team. If a team has high attrition
rate and its largely due to the dysfunction created by the miserable
developer experience and the flawed shortcuts they often produce... you
can help move the needle here by improving the entire team's experience
working within the system. Retention rates are often tied to management
compensation, so if you can make an impact here, you're directly improving
your management's position. The manager has skin in the game to make sure you
can succeed.

When you're talking to management, its about the broader picture. Its
about improving how team as a whole can react to the needs of the business.
Improving your team's feedback loop's in the dev cycle, improves the
bottom line. The more successful the engineers become, the more successful
the manager becomes. Attrition drops, comraderie increases, and you're
seeing a greater impact on the company's performance! Its a win-win situation.
Make sure you sell it as such!

</details>

<details><summary>Engineers</summary>

This is typically an easy sell. If you are feeling the pain, then
undoubedbly others on the team are feeling it as well. When you're
providing a rope to climb out of this mess, they tend to listen. Not
all engineers will entertain the thought of something new. Realistically,
you're going to face engineers wearing at least one of the three hats
mentioned in the [introduction](#1-introduction-top). The folks who have
acclimated, are the biggest resistance you'll face. These often include
managers :sigh:. Often times they understand the tribal knowledge and
believe the struggle they went through to get to this point, are what
everyone should go through. You'll know survival bias when you see it.
The thing to remember with those who have acclimated, is that they
may have some knowledge that could help you improve the bottom line, but
they withold it knowningly or unknowingly. Providing them a space to air
their grievances with a potential new shiny design and the existing
design will prove fruitful more often than not. It'll also help build
trust with those who have concerns about any *changes*. Providing
a tiny prototype to show off the wares your selling, goes a **long**
way with engineers. If they can taste the sweetness of this new
design, they will back it and they will fight for it.

</details>

<details><summary>Yourself</summary>

The first thing you have to remind yourself.... start small! Don't
try and boil the ocean. Build up incrementally wherever possible. This
makes it so much easier to vet assumptions, provide progress to your
other stakeholders, and reaffirm your commitment to the new design. Those
small milestones are motivating. When you identify a bad assumption, its
much easier to rethink your inks when its a small change. As the old adage
goes:

> The only thing youre guaranteed with a big bang design, is a big bang

After you've established the first few updates, you'll hit the ground
running. Remember, its a work in *progress*. You'll be working on progress
for a while if you want to completely sunset the legacy code. If you
don't mind having multiple versions at a time, you can use the 80/20 rule
and pick out the small subset of behavior from the legacy design and replace
it. Once those are in place, and you and the team reap the benefits,
it'll be hard to stop the team from finishing the rest in my experience 🙃.

</details>