Leadership Levels

Hiring

Hiring is an essential topic for CTOs and leaders alike. Marco and Raphael dive deep into the topic and share tips and tricks of great hiring pipelines, the importance of career ladders for the process and metrics of a healthy pipeline. Book reference: Daniel Pink - Drive: The Surprising Truth About What Motivates Us. https://www.danpink.com/books/drive/Concept: Amazon Bar Raiser program https://www.aboutamazon.com/news/workplace/amazon-bar-raiser

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)]