Engineering Performance Playbook; Product lessons from N26 CPO; Microsoft's Copilot Study; Balancing TDD between design and testing

Issue #52 Bytes

🌱 Dive into Learning-Rich Sundays with groCTO ⤵️

📘 Engineering Performance Playbook

After working with 150+ engineering leaders, I've identified the 5 biggest mistakes they repeatedly make that prevent them from delivering predictable, measurable results. I've distilled these learnings into five daily emails that not only highlight those mistakes but also provide the hacks to avoid them.

It just takes 5 minutes daily to learn these frameworks, which we are applying at Typo to make engineering teams more impactful.

---

Article of the Week ⭐

“Strategy is a little bit overrated for product. For most product managers, your strategy should be, "How fast can I go from hypothesis to data?" —Mayur Kamat

Unconventional product lessons from Binance, N26, Google

Mayur Kamat appeared on Lenny’s Podcast to share his experience in building high-performing product engineering teams. The conversation was information-dense, captivating and inspiring to anyone pursuing to level and leverage their abilities as a leader. Naturally, we’ve extracted the core ideas from the episode to help you find information relevant to you in your role as CTO, CPO or a leader in product engineering.

1. Product Strategy Is a Byproduct, Not a Precondition

Mayur challenges a popular belief that great PMs should focus on long-term strategy early in their careers. In practice, he’s found that the highest-performing teams aren’t preoccupied with vision decks. The most effective strategy emerges through rapid iteration, experimentation, and tight feedback loops.

Teams at N26 and Agoda ship fast, measure the outcome, and double down on what works. That culture requires infrastructure and experimentation tools, tight cohort analysis, and clear metrics. But once that scaffolding is in place, you replace opinion-based product thinking with data-proven momentum.

In fast-paced environments like Binance strategy was the compounding result of dozens of daily course corrections.

2. Google Hangouts Was Doomed by Misaligned DNA

Mayur’s most visible failure was as PM on Google Hangouts. Despite unlimited resources, world-class engineers, and Larry Page personally supporting the project, it flopped. Why? Because the product DNA of Google’s Founders simply didn’t align with what made a great messaging app.

He reflects that some companies are fundamentally mismatched with certain product types: Google with social, Microsoft with mobile, Facebook with enterprise. When a company’s success is built on a specific set of values and operating models, it’s incredibly hard to succeed in domains that require the opposite.

3. The Operating Cadence at Binance Was Ruthless

At Binance, Mayur operated in a radically different system: no middle management, 55 direct reports to the CEO, and every leadership problem triaged at a nightly 11PM global meeting. If something was critical, a product owner was assigned that night, given full resources, and expected to report daily until the issue was resolved.

That level of execution meant projects like international KYC compliance or fraud prevention moved in days rather than months. Teams didn’t wait for consensus. They didn’t ask for resourcing. They had ownership, urgency, and visibility.

This system only worked because of several key cultural traits:

• Hyper-alignment on mission

• Extreme compensation leverage

• Bias for detail

This wasn’t sustainable in all contexts, but Mayur now brings parts of this cadence: like focused daily syncs on high-stakes projects into more regulated environments like N26. The lesson: speed isn’t just a value, it’s an operating system.

4. Optimize for Compounding, Not Compensation

One of Mayur’s most practical philosophies: early career comp doesn’t matter. Your learning velocity, network density, and exposure to scale matter 10x more. If you spend the first 10 years of your career optimizing for cash, you’re trading long-term upside for short-term comfort.

He encourages PMs to pick roles where:

• They are operating close to their strengths

• The company is growing fast enough to expose them to new problems monthly

• There is joy in the daily work, not just the eventual title

The biggest leverage? Joining category-defining companies early. Ones that force you to solve never-before-seen problems, like N26 with mobile banking in Europe or Agoda scaling travel during volatility. These environments create dense alumni networks, shared war stories, and rare skills. That’s career rocket fuel.

---

Other highlights 👇

Findings from Microsoft’s 3-week study on Copilot use

Microsoft ran a randomized trial with 200+ developers to study Copilot’s impact on code output, mindset, habits, perception and more. The study uncovered five high-leverage findings for engineering leaders rolling out GenAI tools. As always, Abi Noda didn’t take long with his meta analysis for those of you too busy running companies to be reading white papers.

🧠 Key Findings (Condensed)

1. Initial skepticism was high.
Most developers hadn’t used Copilot before. Common blockers: lack of time, doubt it would help, or no perceived need. Only 20% trusted AI-generated code.

2. Perception shifted quickly.
After three weeks of use, developers felt Copilot was more useful, enjoyable, and inevitable. Belief in its future role increased significantly.

3. Output metrics stayed flat.
No statistically significant change in coding time, PRs, or lines written—likely due to short duration. Microsoft notes real gains show up after ~11 weeks.

4. Self-reported productivity improved.
Developers said Copilot saved time on boilerplate, kept them focused in the IDE, and made it easier to write docs and tests.

5. Validation is the new bottleneck.
Main challenge: Copilot-generated code often looks right, but isn’t. This increases the burden of review and critical thinking.

---

The balancing power of TDD: finding the sweet spot between design and testing

Like it or not: TDD is a staple in modern software engineering discussion whether practiced, cherished or loathed. Unless you’ve been living under a rock you’ve probably heard about it at length.

Is test-driven development anti-design? Stanford’s John Ousterhout thinks so. Kent Beck, TDD’s creator, strongly disagrees. Most teams sit somewhere in the messy middle.

In this entertaining takedown of false binaries, Zac Beckman reframes software development as research, not construction. TDD isn’t about writing tests first, it’s about validating assumptions fast, especially in complex or novel systems.

• Design vs. Test is a false dichotomy: Great teams prototype risky ideas in tight feedback loops without losing design intent.

• TDD ≠ dogma: Writing a test for every line of code kills flow. Writing no tests at all kills quality. The magic is in balance.

• Software is science, not civil engineering: We’re exploring, not executing. TDD is our experiment loop.

• Validate early, avoid architecture regrets: A client’s “clean” microservice design masked a legacy bottleneck, discovered too late. Iterative (and incremental) validation would’ve caught it early.

• Design with tests, not after them: Good TDD reveals flaws early and keeps architecture honest.

---

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week(end), Ciao 👋

---

Credits 🙏

Curators - Diligently curated by our community members Denis & Kovid

Featured Authors - Mayur Kamat (w/ Lenny’s), Abi Noda,

Zac Beckman

Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.

---

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.