/Process

Performance & Compensation (For Eng Execs)

- Will Larson tl;dr: Will discusses: (1) The conflicting goals between those designing, operating, and participating in performance and compensation processes. (2) How to run performance processes, including calibrations, and their challenges. (3) How to participate in a compensation process effectively. (4) How often you should run performance and compensation cycles. (5) Why your goal should be an effective process rather than a perfect one.

featured in #446

Why Fast?

- Matt Rickard tl;dr: “Why do ambitious things sometimes come together so fast?” Matt argues the following: (1) Right time, right place: “Sometimes, groundwork from many disparate threads comes together, making the previously impossible possible.“ (2) A sense of urgency is one of the best motivators. (3) Constraints foster creativity. (4) Fast favors prototypes. A focusing mechanism for pruning unnecessary details.

featured in #446

Push And Pull

- Kellan Elliot-McCrea tl;dr: Kellan discusses a model for understanding engineering processes that focuses on two elements: "Push" and "Pull." "Push" refers to the rules, templates, and expectations set by a team for a process. "Pull" is the inherent value or need that the process fulfills, making it worthwhile and valuable for team members to engage in it. The author notes that many processes fail due to a lack of "Pull," as seen in the example of weekly status updates that fade out because "It didn’t feel like anyone was reading it."

featured in #445

The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches)

tl;dr: "Half of all PRs are idle for at least 50% of their lifespan." The article identifies four root problems in PR management: (1) No formal process for getting PRs assigned. (2) No standardization or best-practice guidance for PR size. (3) Teams treat all PRs with equal importance despite different risk levels. (4) Lack of visibility into PR context or how long it will take to review until opened. To address these issues, the article suggests two potential solutions: pair programming and continuous merge.

featured in #445

Akin's Laws Of Spacecraft Design

- Matt Rickard tl;dr: The article presents 45 laws by David Akin, Professor of Aerospace Engineering, including: (1) Engineering is done with numbers. Analysis without numbers is only an opinion. (2). To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong. (3). Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. (4). Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. (5). Three points determine a curve.

featured in #443

How Games Typically Get Built

- Gergely Orosz tl;dr: Insights into the world of game development, contrasting it with traditional software development. Game development involves programmers, designers, artists, animators, writers, and sound designers. Games typically undergo a prototype stage, followed by full production, where multiple teams work in parallel, often leading to integration challenges. The game development life cycle consists of three main phases: pre-production, production, and release. Gergely emphasizes that while game development borrows practices from software development, such as TDD and agile methodologies, it requires adaptations to fit the unique challenges of the medium.

featured in #442

Building Software The Swarmia Way

- Hugo Kiiski tl;dr: We all know that there’s no single right way to build software. But because we love learning about how other high-performing software organizations approach team composition, rituals, technology choices, and more, we figured why not return the favor and open up our own workflow.

featured in #439

Bottlenecks vs Bandpass

- Andrew Bosworth tl;dr: To avoid bottlenecks in product development, horizontal teams should establish clear guidelines and standards, allowing vertical teams to work efficiently. This frees up time for horizontal experts to focus on complex issues and enables faster progress in the future.

featured in #429

Pull The Andon Cord

- Taylor Pearson tl;dr: The Andon Cord was a rope that hung in Toyota factories that instantly could stop all work on the assembly line, which workers were encouraged to pull when they saw an issue. Once pulled, a manager came down to look the issue but the worker who pulled the rope was the one that came up with the solution. This process had 2 benefits: (1) It made workers feel trusted and part of the company’s output. (2) It dramatically increased quality as workers had a lot of tacit knowledge that managers didn’t.

featured in #401

Automating Safe, Hands-Off Deployments

- Clare Liguori tl;dr: “In this article, we walk through the steps a code change goes through in a pipeline at Amazon on its way to production. A typical continuous delivery pipeline has four major phases - source, build, test, and production. We’ll dive into the details of what happens in each of these pipeline phases for a typical AWS service, and provide you with an example of how a typical AWS service team might set up one of their pipelines.”

featured in #401