/Leadership

First Decide How To Decide: “One Weird Trick” For Easier Decisions

- Jacob Kaplan-Moss tl;dr: "The heart of this process – the move that I think makes it work so well – is that it includes an explicit step to first decide how to decide. That is: when a decision appears that it’ll be controversial or difficult to make, instead of immediately starting to discuss the matter at hand, the stakeholders first come to an agreement about how they’ll eventually decide. In fact, this happens twice: first at the macro scale when the organization agrees to adopt this process overall, and then in the micro scale, for each individual decision." Jacob discusses an example. 

featured in #471

New Engineering Managers Have A High Failure Rate — This Figma Leader Is On A Mission To Fix It

- Marcel Weekes tl;dr: Marcel discusses the context and solutions to three common problems he sees when engineers transition from IC to management roles: (1) The best-suited folks aren’t the ones elevated to management. (2) New managers fall into a spiral that never pulls them out of IC work. (3) Managing former peers can be just plain awkward.

featured in #471

Leading Successful Product Teams

- Ariel Salminen tl;dr: “We’ve been operating in a remote first culture so these rules apply in that context.” The first 5 rules are as follows: (1) Avoid meetings as much as possible. Instead of having them, communicate asynchronous to each other via tools such as Linear, GitHub, Figma, Slack, and similar. (2) Provide at least three days of focus time per week for designers and developers in the team. (3) Trust your team to make decisions, they’re the experts. (4) Default to openness. The team should be sharing what they’re doing whenever they can. (5) Define just the right amount of process. Too much process and it will slow down your team and their performance, while not enough will create inconsistency.

featured in #470

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 while asking for advice creates advocates for your idea but doesn't saddle them with responsibility.

featured in #469

6 Tiny Wording Tweaks To Level Up Your Communication As A Software Engineer

- Jordan Cutler tl;dr: (1) Use “Would you be open to” instead of “Can you” when you want to seem less commanding but still lead to a “yes.” (2) Add “because” to your reasoning or request to strengthen it. (3) Use “can we” instead of “can you” to be more collaborative, particularly in code reviews. (4) Use “What do you think” to assert a suggestion but still leave it open for discussion. (5) Use “It seems like” when the conversation is at a stalemate and you want to call it out directly. Many times this breaks the stalemate. (6) Change the order of your “but” to negate the part you actually want to negate.

featured in #469

Navigators

- Will Larson tl;dr: Will had to solve a common problem — how to make technical decision within a large organization of over 400 engineers. He established Navigators, individuals accountable for these decisions in their area of expertise who report directly to the CTO. (1) Each major area of the business has one Navigator, who is an active contributor to the software written. (2) There is exactly one Navigator for a given area; Navigators do not overlap. (3) Each Navigator is accountable for the technical decisions made in their area. This includes interpreting organizational strategy and applying it to their context. Will elaborates on the roll here. 

featured in #468

OKRs In Software Engineering

- Abi Noda tl;dr: OKR maturity was found to be positively correlated with the following: (1) Having a unified mission as a team. This is intuitive: a unified mission brings alignment, and this alignment may drive people to set better OKRs as it is clear what they’re working toward. (2) Overall happiness at the company. This aligns with the finding from previous research that progressing towards a meaningful goal is a top motivator for employees. (3) Working remotely. “We hypothesize this is because teams who do not have regular face time and in person meetings with leadership need to be more clear on what they are doing, how it relates to the org, and have better ability to share back their progress.”

featured in #468

Scaling Standards And Community In Your Organization

- Nick Penston tl;dr: Nick discusses (1) How to scale adoption of engineering best practices and organizational standards. (2) How to enable sustainable communities around common interests. (3) The power of a culture founded in continuous learning and innovation. "A key tenant to this model is to decentralize the ownership of standards and best practices to small groups focused on specific focus areas of a problem space. Your engineers and technical staff drive this process which facilitates the sharing of skills, knowledge, and measures of success."

featured in #468

How To Build Trust

- Jacob Kaplan-Moss tl;dr: "These are all going to be fairly high-level, just skimming the surface – I could probably write a full post for each point, but will keep them brief to avoid making this article into a book." Jacob elaborates on the following: (1) Act consistently. (2) Communicate clearly and transparently. (3) Be reliable. (4) Set and respect boundaries. (5) Use role power sparingly. (6) Give feedback. (7) Give credit, take blame. (8) Delegate effectively. (9) Sponsor and coach. (10) Respect confidentiality but be clear about limits. (11) Ask for permission to give feedback, suggestions. 

featured in #467

How To Boss Without Being Bossy

- Jeff Wofford tl;dr: "Leaders command people. That’s kind of what a leader is: someone with the authority to direct the actions of others. But people don’t often appreciate being commanded. When you step into leadership you face this challenge: how do you direct the members of your team without offending them? How do you become a good boss, but not be “bossy”?" Jeff maps clarity and harshness to show how various phrases compare. 

featured in #467