/Management

How To Plan?

- Kellan Elliot-McCrea tl;dr: Rules of thumb for making planning suck less: (1) Do fewer things. (2) Bottom up processes don't work. (3) Planning is the wrong time to introduce anything new. (4) You must provide frameworks and constraints. (5) Project planning has an inflection point. (6) Don't wait to kill bad ideas. (7) Minimize dependencies. And more.

featured in #362


What is Reverse ETL? The Definitive Guide

- Tejas Manohar tl;dr: Learn everything there is to know about Reverse ETL, how it fits into the modern data stack, and how you can start activating your warehouse data today.

featured in #362


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


10 Advanced CSV Import Features You (Probably) Won’t Launch Yourself

- Christina Gilbert tl;dr: CSV importers are deceptively simple – a parsing library in front of a database seems like it should take 1 sprint to build. We surveyed engineers on multiple teams and found that these 10 features caused the most scope increases and missed launches.

featured in #361


Bucketing Your Time

- James Stanier tl;dr: James advices ICs and Managers to bucket their time: (1) Map out how you’re spending your time into daily, weekly, monthly and quarterly buckets. (2) Identify which of the tasks are repeated and which are one-offs. (3) Are all of your one-offs strategically important or are they busywork? (4) Is there anything that you can delegate to others or automate? (5) Is there anything that you can remove completely? 

featured in #360


11 Monitoring Requirements For Enterprise DevOps Teams

tl;dr: Isaac Johnson, a Principal Software Engineer and DevOps Architect with experience at multiple Fortune 500 companies, reveals the key capabilities he looks for when evaluating monitoring platforms for enterprise DevOps teams. He offers a candid look at common monitoring pain points and shows how to overcome them.

featured in #360


Being An Introverted Leader

- Matheus Tait tl;dr: Lessons from Matheus: (1) Being an introvert is not a problem to be solved. (2) Capitalize on your strengths and being an introvert. (3) Recharge moments - "insert moments for a quick walk, a meditation, water, or a book. Sometimes a lunch alone with just my book works well for me." And more. 

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


Real-World Engineering Challenges #6: Migrations

- Gergely Orosz tl;dr: Gergely covers examples of companies that have carried out large scale migrations, including: (1) Box: a zero downtime data migration using a 6-step plan. (2) Pinterest: data migration using double writes. (3) LinkedIn: navigating the migration chaos when 100+ engineers were needed to write code and 600+ use cases need to be moved. And more. 

featured in #359