The 9 Principles Of The Perfect Startup Engineering Stack
- Zach Zaro tl;dr: Zach Zaro, CEO and cofounder of Coherence, outlines the 9 principles of the perfect startup engineering stack. “A well-chosen set of developer tools can be the key to moving quickly. The ideal stack should be easy to set up, affordable, and integrate services that your team already knows and trusts.”featured in #402
Directly Responsible Individuals
tl;dr: GitLab assigns a "Directly Responsible Individual" (DRI) to every project who is ultimately accountable for its success or failure. This article discusses how DRIs operate and their characteristics: (1) Detail-orientated without losing a strong strategic perspective. (2) Calm under the pressure of implementation and deadlines. (3) Strong listener with great skill at asking questions. And more.featured in #402
Numbers To Know For Managing (Software Teams)
tl;dr: “Based on philosophy, experience, and analysis; we hope they’ll be of some use.” The authors cover topics such as: (1) Minimum number of direct reports anyone should ever have. (2) Minimum number of candidates you should interview before making a decision. (3) Number of days before a new hire should have merged a pull request, (4) Number of days before a small support issue becomes a large support issue. And more.featured in #401
featured in #401
featured in #400
Cloud-Native Privileged Access Management
tl;dr: DevOps practices have revolutionized how apps and infrastructure are managed, but access hasn't kept up. Shared secrets like passwords and keys – the #1 source of data breaches – are the norm. Teleport replaces shared secrets like passwords, keys, tokens, and even browser cookies with true identity, removing risk while letting engineers go fast.featured in #400
Architects, Anti-Patterns, and Organizational Fuckery
- Charity Majors tl;dr: Charity’s core principle is that “only the people responsible for building software systems get to make decisions about how those systems get built.” Effectively, the presence of an architect can make decisions “someone else’s problem,” resulting in weaker engineers and poorer systems. Charity highlights how architects can often be misused by organizations and best practices of how to use them in your organization effectively.featured in #399
Beyond Spreadsheets: Driving Developer Productivity Improvements Using Goals, Signals, And Metrics
- Rebecca Murphey tl;dr: So many developer productivity journeys start with a spreadsheet. But since such approaches rarely end well, we wrote this article to help you replace metrics-driven opportunity discovery with the goals, signals, and metrics framework.featured in #399
Simple Explanations For Complex Phenomena
- Paulo André tl;dr: Paulo discusses the conflict between our desires - as engineers - to “crave certainty, order, and structure” and the constantly changing scope of our work. “If you’ve done it before, requirements are known. If someone else has done it before, requirements are knowable. If it’s never been done before by anyone, requirements will change.” and most of our work falls in this last space. Paulo believes this requires a “momentous shift in mindset” with how we approach our work with “less predicting & planning, more probing, sensing & responding.”featured in #398
Getting More From Your Team Health Checks
- Justin Kotzé Fiona Siseman tl;dr: Leaders at Spotify run health checks as a source of data to support - and not judge - teams. Checks usually follow the following pattern: (1) Ask predefined questions in the areas of tech health, team health, and product health. (2) Run debrief workshops where members of a squad discuss their results and decide on a set of actions. (3) Aggregate results into a multi-team-level visualisation, so that patterns and trends can be observed and addressed. This article discusses how they’re run.featured in #398