How Apple Is Organized For Innovation
tl;dr: Apple has a functional organizational design - teams are structured around features i.e. cameras, not product categories i.e. iPhones. Three management traits are key: (1) Deep field expertise. (2) Immersion in details. (3) Willingness to collaboratively debate.
featured in #216
The 5 Whys Of Organizational Design
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
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
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
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
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?
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 🍕🍕
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