/Leadership

How To Safely Think In Systems

- Will Larson tl;dr: Will believes the most valuable leadership skill is "how to think correctly," inspired by the book Thinking In Systems. Despite many considering themselves as system thinkers, they "model casually." Will provides 3 rules for thinking in systems safely: (1) When your model and reality conflict, reality is always right. (2) Models are immutable, but reality isn’t, it's always changing. (3) Every model omits information; some omit critical information.

featured in #260


State Of Internal Tools 2021

- Kevin Garcia tl;dr: Developers spend ~40% of their time on software to help their business run. We surveyed 650 developers to find out why. Our report covers 1) which companies spend the most time, 2) what developers are building, and 3) how they are measuring success.

featured in #260


My Team Is Going In Circles, Help!

- Lara Hogan tl;dr: Assuming that outcomes are documented, clear, measurable and visible to all, lead the team through an exercise to generate a responsibilities document together. Lara illustrates this here. You're listing roles in the team and their responsibilities. If the team continues to feel stuck, coaching them using "truly curious open questions," while drafting a list of what folks need. 

featured in #260


How New Managers Fail Individual Contributors

- Camille Fournier tl;dr: (1) Doing all technical design work yourself. (2) Doing all the project management yourself. (3) Neglecting to give feedback on non-technical issues. (4) "Hoarding information" i.e. not providing business context to your team or distilling and communicating it effectively. (5) Focusing too much on your personal output and not the team's output.

featured in #259


Responsible Tech Playbook

tl;dr: "We have a duty to ensure our systems don’t degrade our society. But in the tumult of so many software projects, it can be difficult to step back and understand the implications of our work." This is a catalog of techniques that can be used to address this problem.

featured in #259


What I Learnt Becoming A Tech Lead

- Tom Gamon tl;dr: (1) Don’t write code on the critical path i.e. where you're the blocker to deploy. (2) Defending your calendar. (3) It’s not necessary to be in every conversation. (4) You don’t have to be the most experienced engineer in the team, and more.

featured in #259


The Case For Slacking Off At Work

- Jacob Singh tl;dr: Managers fear under utilizing resources so they orchestrate processes to put all engineers to work, simultaneously. In practice, this creates issues as projects invariably don't go to plan and resources cannot be reallocated easily. Jacob recommends a slacklog - "a backlog of things which can happen, but don't need to happen." These are ideas generated by the eng team, easily transferable between members, which can be added to the process to create resource flexibility.

featured in #258


Don't Assume Consensus In The Absence of Objection

- Candost Dagdeviren tl;dr: We've all been in meetings discussing a challenge with one vocal engineer, who is opinionated and likes to share ideas. It's wrong to assume that, because no one objects, consensus has been reached or that one engineer's decisions are correct. "In some cultures, people won't speak up unless someone passes them the ball and mentions their names explicitly." 

featured in #258


State Of Internal Tools 2021

- Kevin Garcia tl;dr: Developers spend ~40% of their time on software to help their business run. We surveyed 650 developers to find out why. Our report covers 1) which companies spend the most time, 2) what developers are building, and 3) how they are measuring success.

featured in #258


No Surprises: A Framework For Software Quality

- AbdulFattah Popoola tl;dr: Abdul outlines a "Maslow Hierarchy for software quality" to help you prioritize and calculate tradeoffs. The hierarchy comprises of security, usability, reliability, performance and integrity, and is explained in detail.

featured in #257