/Leadership

Retool Developer Day

tl;dr: Join our product and engineering leaders for a first look at what's new with Retool. We'll be diving deep into new GPT-powered features, Python support, and a brand-new way to rapidly deploy databases.

featured in #401


Being Right Doesn’t Matter

- Roy Rapoport tl;dr: Roy discusses a critical difference in being right about something as a leader and being effective in persuading others that you’re right. “I finally figured out that if you’re wrong and you don’t persuade people, that’s fine — heck, that’s probably best since you’re wrong. But if you’re right? You have a duty to be effective in persuading others that you’re right. There’s no partial credit for “I was right, but nobody listened to me.””

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


Three-Bucket Framework For Engineering Metrics

- Abi Noda tl;dr: “CEOs don’t know or care about the technicalities of engineering measurement; what they really want is a way to have confidence that you’re accountable for the millions of dollars they are spending on engineering.” Abi argues that you should be concerned about 3 types of metrics as an engineering leader: (1) Business impact: Current or planned projects, and project roadmap. (2) System performance: Reliability, speed and user experience. (3) Developer effectiveness.

featured in #397


Using Cultural Survey Data

- Will Larson tl;dr: Will focusses on reading and acting upon survey data from the perspective of an engineering leader. In this post he works through: (1) Reading survey results. (2) Taking action on survey data. (3) Whether to modify survey questions. (4) When to start and how frequently to run.

featured in #397


Recognition And Rewards At Work

- Lara Hogan tl;dr: “What we recognize is what we reward,” and we often reinforce behaviors accidentally e.g. when ask a team to demo an upcoming release, add a Slack emoji high-five response to a comment, we are recognizing something we like about someones behavior and signaling to those around us that we want to see more of that behavior. Lara provides us with an exercise to establish how we are recognizing and rewarding our teams and reports.

featured in #396