Mistakes Iā€™ve Made As An EngineeringĀ Manager

- Sarah Drasner tl;dr: (1) Thinking people give feedback the way they want to receive it. (2) Trying to do everything yourself as a manager is the best way to help. (3) Communicating something one time is enough. (4) You have to have everything together all the time.

featured in #225

Should Engineering Managers Be Technical

- Charity Majors tl;dr: "If you want to coach a team, you gotta know the game." Charity wouldn't recommend becoming an EM without 5-7 years engineering experience. You don't have to be the best engineer to be a great manager. The key is to have both social and technical skills.

featured in #225

Software Engineering Culture Metrics

- David Xiang tl;dr: David breaks down how to look at engineering culture via questions, characteristics and values, giving examples of each, and 3 interesting metrics - (1) Adoption of frameworks & tools, (2) effectiveness of retrospectives & (3) effectiveness of RFCs.

featured in #225

Tools For Effective Delegation In Engineering Management

- Jason Wong tl;dr: (1) Know what to delegate (2) Identify desired outcomes and restraints and give full business context (3) Remove yourself from the project, but find the right cadence for updates and label your feelings when asked for feedback.

featured in #224

Mobile Platform Teams

- Gergely Orosz tl;dr: "The idea of setting up a mobile platform team will probably come around to you if your area has around 20 or more mobile engineers working on one or more apps." Gergely talks through how to approach this and challenges ahead.

featured in #224

How To Be A Sponsor When You're A Developer

- Lara Hogan tl;dr: You don't have to be a manager to sponsor someone. Lara provides a framework of real-life, non-managerial examples facing within the org and outward, and when speaking to your sponsee and to others.

featured in #223

Fulfilling The Promise Of CI/CD

- Charity Majors tl;dr: "The time elapsed between writing and shipping is the room temp petri dish where pathological symptoms breed." Focus relentlessly on the length of time between when a line of code is written and deployed to production. Fixate on shrinking this interval as it forces us to do the right things - write small diffs, review code quickly, etc.

featured in #222

Make Boring Plans

- Camille Fournier tl;dr: "Novel technology deserves boring plans." Exciting visions come with unpredictability. Strategy that executes this vision can be stressful if it starts and ends with the vision alone. "Contrast this to the team that turns that vision into boring plans" e.g. start with a small proof of concept so you can learn the process.

featured in #222

How To Stop Endless Discussions

- Candost Dagdeviren tl;dr: Candost uses the Request For Comments to stop such discussions. Proposals are written in the NABC format (need, approach, benefits, competitors) comments are given within a timeframe. This steers away from seeking consensus, is valuable for the author's own thought process & creates solutions based on facts.

featured in #222

Maximizing Developer Effectiveness

- Tim Cochran tl;dr: The primary reason for low effectiveness is working environment. "There are too many new processes, too many new tools and new technologies" increasing complexity and friction. Tim contrasts a day in the life of both a high and low effective environment, and recommends optimizing key feedback loops.

featured in #221