Bottleneck #03: Product v Engineering
- Rick Kick Kennedy Collins tl;dr: "These two mindsets put two parts of your organization at odds. The easy path is to skip the difficult conversations and operate within silos, coming together infrequently to deliver a release. We believe that aligning these two disparate organizations into cohesive team units removes organizational friction and improves time to value," as discussed in this post.featured in #362
Maximizing Developer Effectiveness
- Abi Noda tl;dr: (1) Developer effectiveness is heavily influenced by work environments. e.g. clarity around what to work on, access to quality documentation, tooling. (2) To create more effective working environments, focus on quick key feedback loops. (3) Leadership creates a culture where developers are empowered to make incremental improvements to the developer experience. e.g. open forum to listen to IC’s, dedicated programs for big problems.featured in #361
featured in #360
featured in #360
“Should I Create a Performance Improvement Plan For My Direct Report?"
- Lara Hogan tl;dr: Lara introduces the PIP decision framework: (1) Ask yourself if you believe the person will be able to meet expectations within 30 days and consistently thereafter?” (2) If yes, ask what haven't you stated clearly yet to this person about what to expect in this role?” (3) State the gap between their work and what’s expected in their role as clearly as possible to see if the new clarity changes things. (4) Ask what's in their way of meeting these expectations?featured in #359
Join 2,000+ Engineering Leaders At Interact | A Free, Community-Driven Virtual Conference
tl;dr: If you’re an engineering leader (or are planning to be), join Interact on Oct. 25th. Speakers from Shopify, Slack & Stripe will explore engineering challenges, grow networks & help you become an elite leader. It’s virtual. It's free. It's awesome.featured in #359
Mike Acton’s Expectations Of Professional Software Engineers
- Adam Johnson tl;dr: "Games industry veteran rattles off a sample of 50 things he expects of developers he works with:" (1) Can articulate precisely the problem trying to be solved. (2) Someone else can articulate the problem trying to be solved. (3) Can articulate why the problem is important to solve. (4) Can articulate how much my problem is worth solving. (5) Have a Plan B in case the solution to my current problem doesn’t work. And More.featured in #358
Fewer, Happier Incident Heroes
- Will Larson tl;dr: "A few long-tenured engineers, who happen to have the explicit access credentials to all key systems and implicit permission to use them, help respond to almost all incidents. These folks become increasingly load bearing, as few others acquire the knowledge, and access credentials, to respond when they’re not available. Fast forward to the future, and one of these key responders leaves the companies, which creates more load on the remaining responders." Will discusses how to solve this.featured in #358
What Makes A Great Manager Of Software Engineers?
- Abi Noda tl;dr: "The researchers developed a framework that synthesizes their findings into the 15 attributes that make up a great engineering manager. The attributes fall into the three high-level functions of cultivating, motivating, and mediating a team of developers. There’s nothing particularly surprising in this framework, but it provides a comprehensive model that can be used for self-assessment or evaluation."featured in #357
Software Engineering Practices
- Simon Willison tl;dr: Simon outlines 7 recommended “software engineering practices” for development teams, including: (1) Documentation in the same repo as the code. (2) Mechanisms for creating test data. (3) Rock solid database migrations. (4) Templates for new projects and components. (5) Automated code formatting. And more.featured in #356