Tech Leadership Deep Dives

Security

Managing security is hard because a lack of security only becomes apparent to the business when a breach happens, and the business loses real money. In this episode, Marco and Raphael share secrets for managing security successfully as a leader in tech. From managing and defending security topics on the board level to making security a first-class citizen and running pen tests at scale. A few links to tools that we mentioned (no book references this time): - OWASP Top 10 https://owasp.org/Top10/2025/0x00_2025-Introduction/ - CVE (Common Vulnerabilities and Exposures) https://www.cve.org/ - Snyk https://snyk.io/product/open-source-security-management/ - Github Dependabot https://docs.github.com/en/code-security/concepts/supply-chain-security/about-supply-chain-security - Burp-Suite https://portswigger.net/burp

Organizational Design in Tech Departments

From a small team with frontend backend, to a growing organization with fullstack teams, staff engineers and end to end responsibility. Shaping your tech department the right way - at the right time - is crucial for business success. Let's explore! # References ## Books ### Accelerate: The Science of Lean Software and DevOps - **Authors:** Nicole Forsgren, Jez Humble, and Gene Kim - **Website:** [IT Revolution — Accelerate](https://itrevolution.com/product/accelerate/ [https://itrevolution.com/product/accelerate/]) ## Concepts ### DORA Metrics (Lead Time, Deployment Frequency, Change Failure Rate, Mean Time to Restore) - **Originators:** Nicole Forsgren, Jez Humble, Gene Kim and the DORA (DevOps Research and Assessment) team — now part of Google Cloud - **Website:** [dora.dev](https://dora.dev/ [https://dora.dev/]) ### Architecture Decision Records (ADRs) - **Website:** [Architectural decision - Wikipedia)](https://en.wikipedia.org/wiki/Architectural_decision [https://en.wikipedia.org/wiki/Architectural_decision]) ### Technical Debt Quadrant (Deliberate/Inadvertent × Prudent/Reckless) - **Originator:** Martin Fowler (2009) - **Website:** [Martin Fowler — Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html [https://martinfowler.com/bliki/TechnicalDebtQuadrant.html])

Tech Debt

In this episode of the Tech Leadership Deep Dive, your hosts -Marco and Raphael - dig into what “tech debt” really looks like in the real world, why it quietly builds up, and how it can eventually slow (or even sink) a company if it’s not actively managed. A few highlights that stood out: ➡️ Tech debt shows up as “we’re suddenly slow”: shipping goes from multiple deploys/day → weekly → monthly, QA cycles get painful, and every change feels risky. ➡️ It impacts hiring: strong engineers don’t get excited about joining teams stuck on outdated frameworks and brittle systems. ➡️ It increases security risk: old dependencies and unpatched runtimes expand your attack surface - often until something breaks publicly. ➡️ Upgrades become projects: the longer you delay maintenance (framework versions, libraries, architecture decisions), the more expensive and disruptive it becomes later .➡️ Good management makes it visible: using DORA/Accelerate-style metrics (lead time, deploy frequency, etc.), tracking shortcuts via architecture decision records, and labeling work in Jira helps quantify where time goes (new product vs. “keeping the lights on”). ➡️ The key is communication: tech leaders need to translate “tech debt” into business language (risk, speed, cost, capability), not just engineering jargon-and negotiate tradeoffs explicitly when shortcuts are necessary. The core message: some tech debt is inevitable, but unmanaged tech debt compounds-like interest-and eventually limits speed, safety, and talent. # References ## Books ### Accelerate: The Science of Lean Software and DevOps - **Authors:** Nicole Forsgren, Jez Humble, and Gene Kim - **Website:** [IT Revolution — Accelerate](https://itrevolution.com/product/accelerate/ [https://itrevolution.com/product/accelerate/]) ## Concepts ### DORA Metrics (Lead Time, Deployment Frequency, Change Failure Rate, Mean Time to Restore) - **Originators:** Nicole Forsgren, Jez Humble, Gene Kim and the DORA (DevOps Research and Assessment) team — now part of Google Cloud - **Website:** [dora.dev](https://dora.dev/ [https://dora.dev/]) ### Architecture Decision Records (ADRs) - **Website:** [Architectural decision - Wikipedia)](https://en.wikipedia.org/wiki/Architectural_decision [https://en.wikipedia.org/wiki/Architectural_decision]) ### Technical Debt Quadrant (Deliberate/Inadvertent × Prudent/Reckless) - **Originator:** Martin Fowler (2009) - **Website:** [Martin Fowler — Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html [https://martinfowler.com/bliki/TechnicalDebtQuadrant.html])

Leadership Levels

In this first episode, we unpack “Leadership Levels” in software engineering: ➡️ How responsibilities shift from IC → Team Lead/EM → Director/Head → VP/CTO ➡️ Why “leaders who still code too much” can become bottlenecks (even with the best intentions) ➡️ How to set clear expectations with career frameworks (and why that changes everything) ➡️ Promotions without the Peter Principle: acting roles, de-risking, and coaching people into success ➡️ Why strong IC career paths matter just as much as management tracks If you’re building or scaling an engineering org - or you’re a new (or seasoned) leader - this one’s for you. # References ## Books ### The Leadership Pipeline: How to Build the Leadership-Powered Company - **Authors:** Ram Charan, Stephen Drotter, James Noel - **Website:** [Leadership Pipeline Institute](https://leadershippipelineinstitute.com/) [https://leadershippipelineinstitute.com/)] ### Inspired: How to Create Tech Products Customers Love - **Author:** Marty Cagan - **Website:** [SVPG — Inspired](https://www.svpg.com/books/inspired-how-to-create-tech-products-customers-love-2nd-edition/) [https://www.svpg.com/books/inspired-how-to-create-tech-products-customers-love-2nd-edition/)] ### The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't - **Author:** Robert I. Sutton - **Website:** [Bob Sutton — The No Asshole Rule](https://bobsutton.net/book/no-asshole-rule/ [https://bobsutton.net/book/no-asshole-rule/]) ### How Google Works - **Authors:** Eric Schmidt and Jonathan Rosenberg (with Alan Eagle) - **Link:** [How Google Works — Wikipedia](https://en.wikipedia.org/wiki/How_Google_Works [https://en.wikipedia.org/wiki/How_Google_Works]) ### The Peter Principle: Why Things Always Go Wrong - **Authors:** Laurence J. Peter and Raymond Hull - **Link:** [The Peter Principle — Wikipedia](https://en.wikipedia.org/wiki/Peter_principle [https://en.wikipedia.org/wiki/Peter_principle]) ## Concepts ### Conway's Law - **Originator:** Melvin E. Conway (1967/1968 paper "How Do Committees Invent?") - **Website:** [Mel Conway — Conway's Law](https://www.melconway.com/Home/Conways_Law.html) [https://www.melconway.com/Home/Conways_Law.html)] ### Dunning-Kruger Effect - **Originators:** David Dunning and Justin Kruger (1999 paper "Unskilled and Unaware of It") - **Link:** [Dunning–Kruger effect — Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)] ### Imposter (Impostor) Phenomenon / Syndrome - **Originators:** Pauline R. Clance and Suzanne A. Imes (1978 paper "The Impostor Phenomenon in High Achieving Women") - **Website:** [Dr. Pauline Rose Clance — Impostor Phenomenon](https://paulineroseclance.com/impostor_phenomenon.html) [https://paulineroseclance.com/impostor_phenomenon.html)]