Prioritize Product Development Speed

<h2 data-id="title"><strong data-id="prioritize">Prioritize</strong> <span data-id="pd" style="opacity: 1">Product Development</span> <strong data-id="speed">Speed</strong></h2>

Development Speed **≠** Product Development Speed

---

<h2 data-id="title"><strong data-id="prioritize">Prioritize</strong> <span data-id="pd" style="opacity: 0.15">Product Development</span> <strong data-id="speed">Speed</strong></h2>

---

## Why this talk?
- Enterprise vs. Start Up
  - Chief Architect <i class="fa-solid fa-arrow-right text-primary"></i> Developer/Founder
  - 400+ Developers <i class="fa-solid fa-arrow-right text-primary"></i> 1 Developer
- Building SkillSensei.io
  - For leaders that want to clarify role expectations and accelerate skill mastery
  - Based on principles of behavioural science

---

## What Matters?
- Founding a Startup teaches alot
  - You learn what _really_ matters
- Solving for a Slice vs. Solving for the Pie

---

<h1>Speed!</h1>

---

<h1 class="r-fit-text">Speed!</h1>

---

<ul>
  <li class="fragment strike">Latency</li>
  <li class="fragment strike">Coding Time</li>
  <li class="fragment strike">Ticket Closing Time</li>
  <li class="fragment grow">Product Development Speed (PDS)</li>
</ul>

---

**Product Development Speed (PDS)** is the time it takes for an **idea** to provide **customer value** in production.

---

---

### Macro Perspective

<ul>
  <li>90 days to agree + <span style="opacity: 0.4">1 day to develop</span> <strong class="fragment fade">= 91 days</strong></li>
  <li class="fragment fade">1 day to create work + 30 days to start + <span style="opacity: 0.4">1 day to develop</span> <strong class="fragment fade">= 32 days</strong></li>
  <li class="fragment fade">1 day to agree + 30 days to do OKRs & QBRs + <span style="opacity: 0.4">1 day to develop</span> <strong class="fragment fade">= 32 days</strong></li>
</ul>

---

### Micro Perspective

<ul>
  <li><span style="opacity: 0.4">10 min to code</span>, but 4 days to deploy <strong class="fragment fade">= ~4 days</strong></li>
  <li class="fragment fade"><span style="opacity: 0.4">10 min to code</span>, but 3 days to release <strong class="fragment fade">= ~3 days</strong></li>
</ul>

---

Is it "done _done_"?

---

# Think E2E

_Stop fooling yourself_

---

<h2 style="margin: 30px 0 0">Why Does <strong>PDS</strong> Matter?</h2>

---

### Business Reasons

<ul>
  <li>CEO wants it <em>yesterday</em></li>
  <li class="fragment fade-in">Business is <em>competitive</em></li>
  <li class="fragment fade-in">Progress is <em>engaging</em></li>
</ul>

Notes:

- CEO doesn't care for Kubernetes or Rust, they want to out compete your competitors.
- Ever been in a speeding car where you've fallen asleep? Nope.
- I feel asleep in my first co-op's onboarding. So slow.

---

### Technical Reasons #1

- PDS is inversely related to Planning

---

---

### Technical Reasons #2

- Promotes ~best~ <strong class="text-primary">practical</strong> practices!
- _Let's play a game_ ⚽️

---

<div class="r-stack">
  <div>
  <p>In the <strong>Accelerate</strong> book, was it bigger or smaller companies that were found to have better DORA metrics?</p>

<p style="font-size: 14px">Smaller companies have less baggage, Bigger companies have more resources</p>

<div style="display: grid; grid-template-columns: 1fr 1fr">
    <p style="height: 200px; background: green; line-height: 200px; color: white" >Smaller</p>
    <p style="height: 200px; background: orange; line-height: 200px; color: white">Bigger</p>
  </div>
  </div>

---

**Which testing distribution has better ROI?**

Notes:
* https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests
* https://twitter.com/kentcdodds/status/960723172591992832

---

**Which would you pick for building App UI?**

<div class="r-stack">
  <div style="display: grid; grid-template-columns: 1fr 1fr">
    <ul>
      <li> TanStack Table </li>
      <li> Tailwind </li>
      <li> Headless UI </li>
      <li> <span style="color: green">Price: $0</span> </li>
    </ul>
    <ul>
      <li> MUI (X)</li>
      <li> <span style="color: red">Price: $0-15/month/dev </span> </li>
    </ul>
  </div>

---

## Why is **PDS** Hard?

---

## Two Key Reasons⋆

1. Unknown Unknowns
2. Culture Mismatch

---

### #1 - Unknown Unknowns

- Solving customer problems requires _full stack_ understanding
- Yet most people know:
  - Only a _slice_ of their stack
  - May not even have _mastery_ of that slice
- Thus, **Problems are solved sub-optimally**

---

---

<div style="display: flex;">
  <div style="flex: 1; align-self: center">
    <h4>Artificial Boundaries</h4>
    <ul>
      <li class="fragment" data-fragment-index="1">"I'm a front-end developer"</li>
      <li class="fragment" data-fragment-index="2">"I'm a back-end developer"</li>
      <li class="fragment" data-fragment-index="3">"I'm a data engineer"</li>
      <li class="fragment" data-fragment-index="4">"I'm DevOps" 🧐</li>
    </ul>
  </div>
  <div class="r-stack">
    <img src="./assets/front-end.png" style="height: 600px;" class="fragment" data-fragment-index="1">
    <img src="./assets/backend.png" style="height: 600px;" class="fragment" data-fragment-index="2">
    <img src="./assets/data-engineer.png" style="height: 600px;" class="fragment" data-fragment-index="3">
    <img src="./assets/devops.png" style="height: 600px;" class="fragment" data-fragment-index="4">
  </div>
</div>

---

#### Bad Recipe

<ul class="addition">
  <li>Limited perspective</li>
  <li>"Google uses X" tool picking</li>
  <li>"New must mean better" mindset</li>
  <li>"As an X developer, other X developers do..."</li>
  <li>...</li>
</ul>

---

---

---

### Example - PostgresSQL

- Fairly common database nowadays
- Yet, most people treat it as only dumb data storage

---

- 🦸 Developer with **Unknown Unknowns**
- 🧑‍💻 Developer with **Known Unknowns**
- 🧓 Developer with **Known Knowns**

---

### "I want search capability!"

- 🦸 We need ElasticSearch to do search
- 🧑‍💻 PSQL can do a lot nowadays, let's look into it
- 🧓 Use PostgresSQL's full-text search

---

```sql [1-4|6-9]
-- Create a `tsvector` column with GIN index
ALTER TABLE products ADD COLUMN details_ts tsvector
    GENERATED ALWAYS AS (to_tsvector('english', details)) STORED;
CREATE INDEX product_details_ts_idx ON products USING GIN (details_ts);

-- Query it with special @@ operator
SELECT *
FROM products
WHERE details_ts @@ to_tsquery('english', 'toy');
```

---

### "I want a faster experience!"

- 🦸 We need to cache with Redis and move from Ruby to Go/Rust/Java/C#
- 🧑‍💻 We have NVMe and different PSQL table types, can we do something here?
- 🧓 Lets try `UNLOGGED` tables and `synchronous_commit = false`

---

```sql [1-6|8-13|15-16]
-- Create a table that does not write to WAL
CREATE UNLOGGED TABLE cache (
    key text PRIMARY KEY,
    value jsonb,
    inserted_at timestamp DEFAULT NOW()
);

-- Expire rows after a particular time
CREATE INDEX cache_inserted_at_idx ON cache (inserted_at);
CREATE OR REPLACE FUNCTION expire_rows (retention_period INTERVAL) AS
$$
  DELETE FROM cache WHERE inserted_at < NOW() - retention_period;
$$ LANGUAGE sql;

-- Create a schedule to run the procedure every hour
SELECT cron.schedule('0 * * * *', $$CALL expire_rows('1 hour');$$);
```

---

### Unknown Unknowns

- At least **_know_** your unknowns
- Then prioritize _knowing_ **relevant** unknowns
- And then **_master_** your knowns

---

### PSQL Capabilities
* Caching - `UNLOGGED` tables
* JSON storage - `jsonb` data type
* JSON APIs - `jsonb_agg` serialization
* Message Queuing - `SKIP LOCKED` querying
* Vector Searching - `pgvector` extension
* Spatial Searching - `postgis` extension
* Analytics - AWS's Zero-ETL or `pg_analytics`
* Pub/Sub - `NOTIFY/LISTEN` capability

---

Notes:
* https://www.amazingcto.com/postgres-for-everything/

---

### Advisory Experience
* Often a _single line_ can change your PDS
  * Adding a missing index
  * Removing a legacy package in `package.json`
  * Enabling tracing

---

<p class="r-fit-text key-point-title"><strong>Master</strong> your <strong>existing tools</strong>, <br/> before picking up new ones!</p>

---

### **PDS** is a Compass 🧭

- Focuses you on skills gaps
- Focuses you on full-stack understanding
- Delineates when you should persist vs. rethink

---

<p class="r-fit-text key-point-title">Maintain a <strong>Beginner Mindset</strong></p>

---

### Simple Ways to Learn

- Subscribe to **weekly newsletters** (e.g. Cooperpress)
- **Periodically code** outside your day-to-day area
- Practice building a **product E2E**
- Ask a trusted senior for a **learning roadmap**

Notes:
* Previous session Madeline mentioned how "Mentoring was being key to take ownership and make it easy"
* But how do you make _mentorship_ easy? How can you track someone's progress?
* How can one team give another team a set of skills to learn to become independent?

---

---

---

### #2 - Culture Mismatch

- Is there an incentive to go fast?

---

### Seriously...

- Compensation is not tied to PDS
  - You get same salary regardless
- Focus is on _looking_ productive, not PDS
  - Visibility & RTO > _customer problems solved_
- "Typical" managements tasks are not tied to PDS
  - Stand-ups, Retros, 1:1s, etc.

---

### Compare the Two

- Martial Arts schools
  - One focuses on positivity, good social connections, and breaking a sweat
  - One focuses on winning tournaments, and trains for competition
- Which school has better fighters?

---

### Compare the Two

- Software organization
  - One organization focuses on "being Agile", "being Lean", "being DevOps"
  - One organization focuses on "solving customer problems quickly"
- Which organization (probably) has better PDS?

---

### Tomorrow at Work

- Why are you having a stand-up, when your board can tell you the answer?
- How much of your retrospective is focused on PDS?
  - And how many of them did you do, and to what result?
- Why are your PRs/MRs taking so long to merge in?
- How come you can't do branch deployments?
- How come most people on the team don't understand the data storage?

---

## **PDS** is a North Star ⭐️

---

### Meaningful Questions

- Not "Svelte, Vue, vs. React"
  - Rather "can we build UI quickly"?
- Not "We need to schedule a meeting with Ops"
  - Rather "why can't I do this myself?"
- Not "We need Scrum, Kanban, or XP"
  - Rather "...what can we do today to go faster?"

---

## Personal Reflection

- Things I'll never say again
  - "The requirements should have been clearer"
  - "Of course we should have used X"
  - "I don't know X, I'm a Y developer/manager"
  - "We should use X, Google uses it"

---

## Personal Learnings

- Updated heuristics
  - New features - Months <i class="fa-solid fa-arrow-right text-primary"></i> Days
  - Capacity required - 1 Team <i class="fa-solid fa-arrow-right text-primary"></i> 1 Person
  - Infrastructure changes - Days <i class="fa-solid fa-arrow-right text-primary"></i> Minutes

---

## Next Steps
* Be curious 
  * Do you know all the steps involved in your company's PDS?
* Be bold
  * Regularly question the rituals you have. Do they help PDS?
* Be proactive
  * Network and come to know your unknowns.

---

<h1 class="r-fit-text">Master your <strong>Craft!</strong></h1>

---

## Questions?

* **Contact:** <a>payam.moghaddam@skillsensei.io</a>
* **What I do:** 
  * Advise local software companies 
  * Build SkillSensei to accelerate skill development