OopsImAManagerMVP.qmd

---
title: "Oops I am a Manager <br> MVP<br>"
subtitle: "Minimal Viable Process<br><br>"
author: Andrew Holz 
date: August 13, 2024
title-slide-attributes: 
  data-background-color: black
  data-background-image: "/images/OopsManagerBackground.png"
resources:
  - /images/OopsLineupBackground.png
  - /images/Oops-MVP-ProcessBackground.jpg
  - /images/OopsManagerBackground.png
  - /images/Oops-MVP-POPBackground.jpg
format:
  revealjs: 
    width: "1600"
    height: "900"
    theme: [default, custom.scss]
---

## Who am I {background-image="/images/OopsLineupBackground.png"}

### (and why "Oops" ?)
<br>

:::::: {.columns}

::: {.column width="10%"}

:::

::: {.column width="80%"}

:::: fragment
#### Many early leadership opportunities are **battlefield promotions** and **emerge** rather than being planned
`<br>`{=html}
::::

:::: fragment
#### Very few organizations have good (any?) leadership development
`<br>`{=html}
::::

:::: fragment
#### Lots of leadership training is dry and takes itself too seriously
::::

:::

::::::

::: notes
HOW I GOT HERE

HERE? CURRENT TITLE **"HEAD OF ENGINEERING OPEN SOURCE"** supporting Shiny,Quarto and mlverse teams

- Spin out from BELL LABS 25 YEARS AGO ONE JOB OUT OF MY **CS/PYSCH degree**
- BEEN LEADING TECHNICAL TEAMS EVER SINCE
  - **Starups to midsize to leading 80 people at a Fortune 500 company**
  - Love helping people on **the Leadership Journey more than anything**

MANY LEADERSHIP OPPORTUNITIES ARE ACCIDENTAL OR BACKED INTO

OPPORTUNITY EMERGE

THIS TALK IS A LITTLE HELP FOR PEOPLE THAT **MIGHT BE ON THE OOPS**

NOT SO SECRET MISSION IS TO ENCOURAGE EXPLORATION of TECHNICAL MANAMANGENT FOR THOSE WITH _ANY_ **GENUINE INTEREST IN BEING A FORCE MULTIPIER FOR OTHERS** 
-- the less pointy haired bosses the better!

MOST **LEADERSHIP TRAINING IS DRY, TAKES ITSELF SERIOUSLY and LACK SPECIFIC ACTIONS** TO TRY AND PRACTICE -- 
:::

## MINIMAL VIABLE *PROCESS*?!? {background-image="/images/Oops-MVP-ProcessBackground.jpg"}
<br>

:::::: {.columns}
::: {.column width="20%"}
:::
::: {.column width="70%"}
:::: fragment
### Process
How shit gets done.
::::
:::: fragment
### Viable
 Someone is paying the bills, they expect meaningful progress.
::::
::: fragment
### Minimal 
Heavy processes don't promote progress they paralyze it.
::::

:::
::::::



::: notes
PROCESS:
  **Structured Approach** to accomplishing work.  
  -- turning needs into results
  Implications of **repeatable**
  Highlighting “process” explicitly points to the repeatable nature of work and the potential to learn and **Continually Improve** how things get done.
VIABLE:
  **Effective** - 
  **Sustainable**
MINIMAL:
  **Simple.**  (as you can get away with)
  **Remove complexity that doesnt add value!**
  **Leave Space.** (as you can get away with) People want to do good work.  
  **Excessive process robs people of autonomy!**
    (people want autonomy and mastery) - success comes from motivated people in flow
:::

## DISTILLING THE PROCESS

<br> <br>

:::::: {.columns}
::: {.column width="10%"}
:::
::: {.column width="25%"}
:::: {.fragment .center-fragment}
![Oops MVP Orders](images/Oops-MVP-Orders.png){width=400 height=400}
GATHER


(and order)
::::
:::
::: {.column width="25%"}
:::: {.fragment .center-fragment}
![Oops MVP DS](images/Oops-MVP-DS.png){width=400 height=400}
DO SHIT
::::
:::


::: {.column width="25%"}
:::: {.fragment .center-fragment}
![Oops MVP Work](images/Oops-MVP-Work.png){width=400 height=400}
DELIVER


(profit?!?)


::::
:::
::::::

::: notes

**RIGHT ABSTRACTION** for our process both so we can talk when we all have different ones -
SKETCHING YOURS in a BIT MORE DETAIL CAN BE USEFUL

**FINDING FRICTION (and WASTE)**

**HANDOFFS and PASSING THE BATON**

**ONE TWO THREE**

Fundamentally the **UNDERPANTS GNOMES** had it right.

Agile and Agile

:::

## DISTILLING THE PROCESS - PLANNING
<br>

:::::: {.columns}

::: {.column width="5%"}

:::

::: {.column width="25%"}

:::: {.fragment .center-fragment}

![Oops MVP Orders](images/Oops-MVP-Orders.png){width=400 height=400}
GATHER 

(and order)
::::

:::

::: {.column width="55%"}

:::: fragment 
<br>

### Intentionally consider **all stakeholders** and the level of input they can/should provide
<br>
::::

:::: fragment
### Specify as much as detail as the team needs and **no more** 
<br>
::::

:::

::: {.column width="15%"}

:::: {.fragment .center-fragment}
`<br>`{=html}
{{< qrcode https://tidyfirst.substack.com/p/responsible-slack >}} 
::::

`<br><br><br><br>`{=html}

:::: {.fragment .center-fragment}
`<br>`{=html}
![](images/Oops-MVP-Story.png){width=250 height=250}
::::


:::

::::::

::: notes

**FRICTION!!!**
**LOOK FOR SEAMS AND HANDOFFS - BATON TO PASS can be dropped.**

**FIRST BATON is TEEING UP THE WORK**
   How is it determined what goes into the queue?  Does the team have a role in shaping it? (not worried if the role is a product manager or leader or shared)
**ALL THE STAKEHOLDERS**
management, product manager, users, passive viewers, other teams
**METRICS CAN BE A FORM OF STAKEHOLDER**
Are the decision makers close enough to the process?  Do they have what they need to make good decicisions?  
Is it possible to be more goal based to allow the team to figure out the how?
Product Manager vs Team Lead vs Two levels up -

CAN BE DISCONNECTED CAUSING DISATISFACTION in HIGHER UPS
**High Level Goals - A Mission.**
**Specific Work** to Accomplish that 

Often when things go awry or things are taking too long the focus is on "more spec" "more process" -
BEWARE PROCESSES accumulate -

**SMALLER BATCHES** have a backlog but also have a place for "someday" you dont feel guilty about.  Good ideas come up again and again. 
How long an interval is one of the easiest things to experiment with.  2,3,4,5,6 weeks can all work and will change planning and amount of discretion, and time spent on all the work around a batch.

**STORYTIME**
**SHINY TEAM - GUILT DRIVEN DEVELOPMENT**
Speccing the work is where Shiny struggling.  No traditional product person, dev team set agenda.  
They were serving themselves and needed missions not specs.  QA was insisting on specs. Write the story up front.  It was wasteful and frustrating.  Productivity and joy went up as speccing and tracking.
Sometimes for complex work involving other groups specs get done more often not.
:::

## DISTILLING THE PROCESS - DOING 
`<br>`{=html}

:::::: {.columns}

::: {.column width="5%"}

:::

::: {.column width="25%"}

:::: {.fragment .center-fragment}
![Oops MVP DS](images/Oops-MVP-DS.png){width=400 height=400}
DO SHIT
::::

:::

::: {.column width="45%"}

:::: fragment 
`<br>`{=html}

### Make sure you leave as much **space** as possible - for the **who**, **what** and **how**
`<br>`{=html}
::::

:::: fragment
### Carefully consider meeting purpose and freqency, as well as who needs to be there
`<br>`{=html}
::::

:::

::: {.column width="15%"}

:::: {.fragment .center-fragment}
`<br>`{=html}
{{< qrcode https://tidyfirst.substack.com/p/responsible-slack >}} 
::::

`<br><br><br><br>`{=html}

:::: {.fragment .center-fragment}
`<br>`{=html}
![](images/Oops-MVP-Story.png){width=250 height=250}
::::

:::

:::::::

::: notes
**SIGNS OF FRICTION**

 **Burnout, no redunancy, feeling unappreciated** 
 **Dont same work same person**.  
 Fairness if there is more and less exciting work.  Dont always let those willing to do the drudgery
 Are you burning certain people out with the same sort of work over and over?
 Are you "assigning" work at a higher level (team lead?) when the team can figure it out?
 **AUTONOMY** 
Enabling people to work how they want (as long as its not at the cost of others)  

**INPUT TOO LATE** IN THE PROCESS
**MEETING DREAD** feeling pointless
  keep falling into that work no matter how much they say they dont mind.
  Dailes?  Weeklies? Demos? Pairing? Review

    https://tidyfirst.substack.com/p/responsible-slack 
    The more deadline driven your org - the more slack is absolutely required. 

STORYTIME:
Doing dailies - too many folks, updates I dont care about.\
Wait my turn. Too much or too little detail. Broke into **subteams the met less often** told them to meet a couple of times a week as needed Moved on to a new experiment - 
**Context Partners** Meet at least weekly on the critical features with your content partner.

:::

## DISTILLING THE PROCESS - DELIVERING

`<br><br>`{=html} 

:::::: {.columns}

::: {.column width="5%"}

:::

::: {.column width="25%"}

:::: {.fragment .center-fragment}
![Oops MVP Work](images/Oops-MVP-Work.png){width=400 height=400}
DELIVER
::::

:::

::: {.column width="60%"}
:::: fragment 
### Beyond **shipping** other aspects of delivering are often neglected!  
`<br>`{=html} 
::::

:::: fragment 
### Make sure the **team is getting credit for wins** (or do **your** best to own mistakes)
`<br>`{=html} 
::::

:::: fragment
### As a leader you can **make solo process improvements** in delivery
`<br>`{=html}
::::

:::

::::::

::: notes
SIGNS OF FRICTION
- General unhappiness **"team isnt delivering enough"** "team delivering the wrong things" 
- Lack of awareness about **what has been accomplished**
- **Team feeling down on itself**... like its spining its wheels... going nowhere...
- Confusion about **"ARE WE DOING THE RIGHT THINGS?!?"**

**Literally deliver well -- that build, sending that report, update that dashboard, fix that pipeline**

**People (stakeholders) need to KNOW**

Fact is teams like winning - **TRUMPETING ABOUT SUCCESSES creates MORE SUCCESS** 

WHAT IS REPORTED AS SUCCESS WILL HAPPEN MORE!
**HONEST REPORTS GAIN CREDIBILITY, EVEN (ironically) FAILURES!**

- Always need to look at the seems and handing off is important
- an often overlooked - claiming wins - **where as a leader you can have a particular impact** but important to bring others in.  avoid it being entirely solo for too long if you can.
:::

## EXPERIMENT! EXPERIMENT! EXPERIMENT!

`<br><br>`{=html}

:::::: {.columns}

::: {.column width="5%"}

:::

::: {.column width="75%"}

:::: fragment
### Accept there is no ***RIGHT*** Process
Only a "right now process" which must change to improve
::::

:::: fragment
### Observe and Reflect (together)
Uncover the friction and waste 
::::

:::: fragment
### Formulate Experiments 
Make changes to your process (lean towards less but frequent) 
::::

:::

::::::

:::::: {.columns}

::: {.column width=25%}

![](images/Oops-MVP-Experiment.png){width=300}

:::

::: {.column width="75%"}

<br><br>

:::: {.fragment .right-fragment} 
### ***REPEAT...***
::::

:::: {.fragment .right-fragment} 
### ***REPEAT...***
::::

:::: {.fragment .right-fragment} 
### ***REPEAT...***
::::

:::

::::::

::: notes
So we have an abstract mapping of our process and have thought about "hot spots" where is there friction, what bits stick in you or your teams gut

But some of the biggest problems seem really hard to fix especially **"while the plane is flying"**

Time to ACT.  Act through experiments.  **Small incremental experiments.**
**Bring "the team" along** in solving those and don't let the org chart dictate who is on the team to  drive experiments. 
**processes get stale and even if they are right** - experiments can help confirm that
and help you re-energize to feel good about how its all running!

**Continuous improvement of process.**
Agile but for process, not work product.
small "a" agile, not big "A" proscriptive Agile.
Remember we are going for the **minimum viable process- give people room to be awesome.**
Simply taking away a meeting, or a checkin, or a kanban board stage can be a good experiment.

END THOUGHT: **The best process is a moving target...** so we need to train ourselves to look for friction and where its not working and figure out how to improve...

:::

## RETRO TO (explicitly) BUILD EXPERIMENTS

<br><br>

:::: {.fragment}
***You DO DO RETROSPECTIVES once in a while right?!?***  
<br> 
::::

:::::: {.columns}

::: {.column width="5%"}

:::

::: {.column width="25%"}

:::: {.fragment .center-fragment}
WHICH PART OF OUR PROCESS KILLS YOUR SOUL THE MOST?
::::

:::

::: {.column width="25%"}

:::: {.fragment .center-fragment}
WHAT (POSSIBLY DUMB-ASS) WAY MIGHT MAKE IT SLIGHTLY LESS CRAPPY?
::::

:::

::: {.column width="25%"}
:::: {.fragment .center-fragment}
WHICH "WAY" COULD WE EXPERIMENT WITH AND ADDRESSES THE WORST BIT?
::::
:::

::: {.column width="20%"}
:::: {.fragment .center-fragment}
![](images/QRCodeRetros.png){width=200 height=200}
::::
:::

::::::

:::: {.fragment .right-fragment}
`<br><br>`{=html}

Give one at a time a few cycles and **keep or pitch** and **try another one**.
::::

::: notes
**POINTED QUESTIONS** 
**REINFORCE ITS ABOUT THE TEAM and THEIR JOY**

**HAPPY CONFIDENT teams do more and better work**

GET SOME EXPERIMENTS **If the **team helps shape the experiment they are more likely to succeed** and buy in.

**Limit EXPERIMENTS IN PROGRESS** - just like other work. 1 or 2.
smallest feasible changes that might have an impact

Multiple senior members of the Shiny team have **Kanban allergies** but if your team doesnt...
:::

## A TOUCH MORE EXPERIMENT PROCESS {background-image="/images/Oops-MVP-POPBackground.jpg"}
### ... if you find it really necessary

`<br>`{=html}

:::::: {.columns}

::: {.column width="15%"}

:::

::: {.column width="60%"}

:::: fragment 
### POP (of the popcorn method) 
::::

:::: fragment
<tactic> - Problems and observations 
::::

:::: fragment
<tactic> - Options <br>
::::

:::: fragment 
<tactic> - Possible experiments <br> 
::::

:::

::: {.column width="20%"}
:::: {.fragment .center-fragment}
![](images/QRCodePopcorn.png){width=200 height=200}
::::

:::

::::::

:::::: {.columns}

::: {.column width="35%" column-padding=50px}

:::: fragment

<br>

The popcorn kanban board can help, especially if you ***identify experiments***, 
but have trouble following through!  

(CORN: Commit, Ongoing, Review, Next)

::::

:::

::::::

::: notes
What I have described so far is the "POP" of the "POPCORN" process improvement method by **Claudio Perrone**
CORN is **(COMMITS, ONGOING, REVIEW, NEXT)**
https://djdegrood.wordpress.com/2017/12/21/improving-with-the-popcorn-flow-by-claudio-peronne/

:::

## BATTLING EXCUSEY PANTS BUT, BUT, BUTS...
<br>

:::::: {.columns}

::: {.column width="85%"}

::: {.fragment .question-fragment} 
OUR BIGGEST PROBLEMS ARE NOT _IN_ OUR GROUP -- ITS "THEM"
:::
::: {.fragment .answer-fragment}  
COLLABORATION TIME - include them in the POP!
:::

::: {.fragment .question-fragment} 
WE DONT HAVE TIME FOR THIS -- WE ARE OVERLOADED
:::
::: {.fragment .answer-fragment}  
if you stick to a process that isnt really working it will only get worse.
:::

::: {.fragment .question-fragment} 
ITS JUST NOT GOING TO MAKE A DIFFERENCE -- WE HAVE TRIED
:::
::: {.fragment .answer-fragment}  
failing is part of the process, learn.  bad ideas? too ambitious? lack of follow through? learn and improve.
:::

::: {.fragment .question-fragment} 
MANAGEMENT WONT LET US - THEY MAKE US...
:::
::: {.fragment .answer-fragment} 
dont disempower you and your team, you are just being "agile" 

and you asked permission?!?
:::

:::

::: {.column width="15%"}

`<br><br><br>`{=html}

{{< qrcode https://www.leanessays.com/2022/06/when-demand-exceeds-capacity.html >}} 

`<br><br><br><br><br>`{=html}

{{< qrcode https://staysaasy.com/management/2024/08/06/standardize.html >}} 

:::

::::::
. . .



::: notes
Retros "small a" agile not "big A" agile Retros can get stale. If you have them frequently and you follow the same old "Start" "Stop" "Continue" or "Mad "Sad" "Glad" I ask you to have one and put a finer point on it! GET SOME 

EXPERIMENTS If the team helps shape the experiment they are more likely to really give it a shot

**as a leader you need to model it and believe it**

Our stakeholders keep moving the goalposts!

:::

## Agile up your process - not just your product
`<br>`{=html}

:::::: {.columns}
::: {.column width="10%"}
:::
::: {.column width="75%"}

### ***Individuals and interactions*** 
::: {.answer-fragment}  
**over processes and tools.**
:::

### ***Working software*** 
::: {.answer-fragment}  
**over comprehensive documentation.**
:::

### ***Customer collaboration*** 
::: {.answer-fragment}  
**over contract negotiation.**
:::

### ***Responding to change*** 
::: {.answer-fragment}  
**over following a plan.**
:::

{{< qrcode https://agilemanifesto.org/display/000000049.html >}}

:::
::::::


## Said another way... {.poem}

<br>

:::::: {.columns}

::: {.column width="75%"}

In a lively hub where ideas fly and dart,

The team mapped their processes, each playing their part.

“Keep it all light, let’s empower and grow,

Yet ensure that our output has value to show!”

<br>

They tweaked and they tested and with agility played,

Finding new ways their efforts could sway.

From shadows of old, they emerged step by step. 

Their process now streamlined, efficient and light.

:::

::: {.column width="25%"}

![](images/Oops-MVP-JoyousLightTeam.png)

:::

:::::: 


::: notes
IF YOU LOVE DR SEUSS 1/2 as MUCH AS I HOPEFULLY THIS WILL BRING IT ALL HOME

IF NOT I BEG YOUR FORGIVENESS FOR MY INDULGNENCE
:::



## Thanks!


:::::: {.columns}

::: {.column width="75%"}

If you are on this journey and want some support PLEASE REACH OUT andrew.holz\@posit.co linkedin/andrewholz

You can find this talk on github: 

https://github.com/icarusz/OopsImAManager-MVP/

:::

::: {.column width="25%"}

{{< qrcode https://github.com/icarusz/OopsImAManager-MVP/tree/main >}} 

:::

::::::

<br>

Some of my favorite technical leadership books I love and keeping coming back to:

:::::: {.columns}

::: {.column width="25%"}
![](images/ResilientManagement.jpg){width=150}

Resilient Management

Lara Hogan
:::

::: {.column width="25%"}
![](images/ElegantPuzzle.jpg){width=150}

An Elegant Puzzle
Wil Larson
:::

::: {.column width="25%"}

![](images/ManagersPath.jpg){width=150}

The Managers Path
Camille Fournier
:::

::: {.column width="25%"}

![](images/HighImpact.jpg){width=200}

<br>

High-Impact Tools for Teams

Alex Osterwalder
:::

::::::