/Leadership

Demanding And Supportive

- Ravi Gupta tl;dr: “Most people think of demanding and supportive as opposite ends of a spectrum. You can either be tough or you can be nice. But the best leaders don’t choose. They are both highly demanding and highly supportive. They push you to new heights and they also have your back.”

featured in #545


Engineering Team Meeting: Format & Topic Ideas

- Marc Gauthier tl;dr: “When I started managing the engineering department at my company, I wanted to have an interesting team meeting involving the entire team. My objective at the time was to set up a meeting that people would look forward to, going beyond simple team & company updates. It’s now been a few years since the first, and while not all presentations are a complete success, I’m pretty happy with the way it turned out.” Marc discusses the meeting format. 

featured in #545


Let Small Fires Burn

tl;dr: “Humans are bad at judging the absolute value of things. We can't estimate tasks, can't assess what's important, and we're poor predictors of impact. But we’re really good at taking two problems and saying "Yep that one's worse than the other one". You can take this insight and use it to create an ordered list of priorities. Go pair-wise through your fires, swap to put the bigger fire on top, and after n^2 iterations you'll have a stack ranked list of fires from biggest to smallest.”

featured in #545


When To Write Strategy, And How Much?

- Will Larson tl;dr: Will covers: (1) When to write strategy, in particular the pain points (like cross-team friction) and opportunities (like senior hires) that are good moments to start writing. (2) How much strategy your org can tolerate, avoiding the traps of writing so much that it’s ignored or so little that there’s not much impact. (3) Using strategy altitude – how permissive a given strategy is and where it’s implemented – to manage the overhead that strategies creates. (4) Mechanisms to debug whether you’re doing too much or too little strategy work. 

featured in #544


One On One Meeting Format Ideas

- Marc Gauthier tl;dr: “As a manager, doing one on one meetings with your direct reports is your most important tool. I’ve talked a bit before about opening lines, but I figured it could be interesting to dig into how I handle this every week with my teams. I think it’s important to have a clear format shared to direct reports. This frames the conversation and helps the manager fullfil the objective, while giving some insights to the direct report regarding what this is all about.”

featured in #544


Enthusiasm: Managing Our Most Precious Resource

- Kent Beck tl;dr: “The enthusiasm-enhancing way to allocate people to tasks is to let the people allocate themselves. They have context, in the form of accountability and purpose and approximate proportions, but to preserve enthusiasm they must make their own decision. And a fired up engineer is five times (for some value of five) as valuable as that same engineer just putting in hours.”

featured in #543


The 3 Motivational Forces Of Developers

- Ben Northrop tl;dr: “After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. It undergirds all of his decisions and interactions. It predicts what kind of code he'll write, what technologies he'll prefer, and even how he'll succeed on a given assignment. And it's often quite easy to peg for any given developer after just a few days of working with him or her.” 

featured in #543


How to Write Great Tech Specs

- Nicola Ballotta tl;dr: Nicola covers: (1) What a tech specs document is, why it's important, and why it can sometimes be challenging to create one. (2) How to create outstanding tech specs. (3) A Notion system for creating tech specs. (4) Tips from both his own experience as well as the communities.

featured in #542


The 3 Motivational Forces Of Developers

- Ben Northrop tl;dr: “After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. It undergirds all of his decisions and interactions. It predicts what kind of code he'll write, what technologies he'll prefer, and even how he'll succeed on a given assignment. And it's often quite easy to peg for any given developer after just a few days of working with him or her.” 

featured in #542


Ask For Advice, Not Permission

- Andrew Bosworth tl;dr: From the CTO at Meta: “One of the most common anti-patterns I see that can create conflict in an otherwise collaborative environment is people asking for permission instead of advice. This is such an insidious practice that it not only sounds reasonable, it actually sounds like the right thing to do: “Hey, I was thinking about doing X, would you be on board with that?”" Andrew argues that the problem with asking for permission is that you’re implicitly asking someone else to take some responsibility for your decision. Asking for advice creates advocates for your idea but doesn't saddle them with responsibility.

featured in #541