/Organizational Design

Work Is Work

tl;dr: Org design is fetishized by corporate America always looking for some hack. There isn't one. Organizations are imperfect and, at very best, scale linearly. Despite that, there are tips on how to design a scaling organization here.

featured in #169


The 5 Whys Of Organizational Design

- Kellan Elliot-McCrea tl;dr: When considering org design, a useful exercise is to walk down each level of the org by asking the 5 whys, this helps you understand where the pressures lie. The author runs through this and the common discoveries he's made when asking these questions.

featured in #140


The Five Types Of Communication Problems That Destroy Company Morale

- Cate Huston tl;dr: All company problems are communication problems of some type. These are broken into the following buckets (1) Lack of depth (2) Conflicting context (3) Missing empathy (4) Communication that triggers anxiety (5) Assuming unearned trust.

featured in #138


How To Evolve An Engineering Organization

- Will Larson tl;dr: The following are explained in detail (1) measure what you hope to improve (2) size the org against peers, goals and performance (3) structure into smaller teams (4) project growth (5) rest in between changes to master the current structure.

featured in #135


As Your Team Gets Bigger, Your Leadership Style Has to Adapt

- Julie Zhuo tl;dr: As teams grow quickly, leadership style changes in the following ways - move from direct to indirect management, reports treat you differently, more context switching, re-prioritization of challenges & focus of people-centric skills. The article outlines ways to manage these changes as they happen.

featured in #134


Software Roles and Titles

- Eric Elliot tl;dr: The first half runs-through typical roles in engineering orgs from Engineering Fellow, CEO, CTO down to Intern, and how they tend to fit in both small and large orgs. The second half discusses how the cogs fit together to create the machine and typical dysfunctions.

featured in #133


How Is Software Developed At Amazon?

- Todd Hoff tl;dr: Fireside chat with Ken Exner, GM at AWS Dev Tools. The article summarizes it more extensively than I will. Key ideas are: Create more autonomy and higher velocity by moving away from monolithic architecture towards microservices and two pizza teams 🍕🍕 Automate everything Culture of ownership and accountability. Two pizza teams own everything relevant to their product. They acts like startups, managers oversee startups Are the short summaries (tl;dr sections) helpful? Please vote here

featured in #131