/Management

Is This Strategy Any Good?

- Will Larson tl;dr: Will discusses: (1) The various ways that are frequently suggested for evaluating strategies, such as input-only evaluation, output-only evaluation, and so on. (2) A rubric for evaluating strategies, and why a useful rubric has to recognize that strategies have to be evaluated in phases rather than as a unified construct. (3) Why ending a strategy is often a sign of a good strategist, and sometimes the natural reaction to a new phase in a strategy, rather than a judgment on prior phases. And more. 

featured in #603


LLMs: An Operator's View

- James Stanier tl;dr: James discusses “what leadership should do from the perspective of the productivity of teams and organizations, and consequently how we should think about spending our budgets to make that happen. There are plenty of hot takes out there on AI. This is not intended to be one of them.”

featured in #603


You Make Your Evals, Then Your Evals Make You.

- Tongfei Chen Yury Zemlyanskiy tl;dr: The post introduces AugmentQA, a benchmark for evaluating code retrieval systems using real-world software development scenarios rather than synthetic problems. AugmentQA uses codebases, developer questions, and keyword-based evaluation outperforming open-source models that excel on synthetic benchmarks but struggle with realistic tasks.

featured in #603


Synchronous Work, Asynchronous Work

- Ted Neward tl;dr: Over the last two years, we've seen a dramatic policy debate playing out on the feeds of LinkedIn: "WFH vs RTO". Nearly everyone has an opinion, and many of them are held strongly. Some are held based on data, some on personal preference, and many are based on personal experience. Nearly all of them, however, focus on the wrong part of the debate: it's not really about "WFH vs RTO", but about "async vs sync".

featured in #603


Leading Effective Engineering Teams In The Age Of GenAI

- Paul Gross tl;dr: “Using AI in software development is not about writing more code faster; it's about building better software. It’s up to you as a leader to define what “better” means and help your team navigate how to achieve it. Treat AI as a junior team member that needs guidance. Train folks to not over-rely on AI; this can lead to skill erosion. Emphasize "trust but verify" as your mantra for AI-generated code. Leaders should upskill themselves and their teams to navigate this moment.”

featured in #602


The QA Wolf Advantage: Vertical Integration For Superior QA

- Jon Perl tl;dr: Traditional outsourced QA relies on inefficient, costly tech stacks that fall short of QA engineers' needs. QA Wolf took a smarter approach. They built proprietary technology that aligns with customers’ needs, enabling their QA engineers to deliver 80%+ automated test coverage for their clients in just 4 months. In this free webinar, CEO Jon Perl reveals how QA Wolf is redefining QA automation.

featured in #602


Some Mistakes I Made As A New Manager

- Ben Kuhn tl;dr: “I had an unusually hard time becoming a manager: I went back and forth three times before it stuck, mostly because I made lots of mistakes each time. Since then, as I had to grow my team and grow other folks into managing part of it, I’ve seen a lot of other people have varying degrees of a rough time as well—often in similar ways. Here’s a small, lovingly hand-curated selection of my prodigious oeuvre of mistakes, and strategies that helped me mitigate them.”

featured in #602


Categories Of Leadership On Technical Teams

- Ben Kuhn tl;dr: “Recently I’ve been having a lot of conversations about how to structure and staff teams. One framework I’ve referenced repeatedly is to break down team leadership into a few different categories of responsibility.” Ben shares what these are and why he finds it useful. 

featured in #602


Categories Of Leadership On Technical Teams

- Ben Kuhn tl;dr: “Recently I’ve been having a lot of conversations about how to structure and staff teams. One framework I’ve referenced repeatedly is to break down team leadership into a few different categories of responsibility.” Ben shares what these are and why he finds it useful. 

featured in #601


Operational Mechanisms For Strategy

- Will Larson tl;dr: “I refer to the art of making policies work as “operations” or “strategy operations.” The good news is that effectively operating a policy is two-thirds avoiding common practices that simply don’t work. The other one-third takes some practice, but can be practiced in any engineering role: there’s no need to wait until you’re an executive to start building mastery. This chapter will dig into those mechanisms.”

featured in #601