/Leadership

Guide To Leading Meetings For Software Engineers

- Jordan Cutler tl;dr: (1) Before the meeting: Figure out the outcome you want to achieve by the end of the meeting. Invite people based on that outcome. Send a message or tag in the channel about the meeting invite and the purpose. Add a meeting description so everyone knows what it’s about. Start the meeting description with, “The goal of this meeting is…” (2) During the meeting: Start the meeting off by reiterating the expected outcome and goal. Respectfully keep the meeting on track pointing to the goal. Make sure everyone feels heard throughout the discussion. (3) After the meeting: Document all important points. Post a summary of the points and action items along with dates and responsible individuals.

featured in #492

Listen Or Speak

- Mike Fisher tl;dr: Mike, former CTO at Etsy, discusses how he navigates leadership styles - the under-importance of listening, the over-emphasis on speaking, and examples of how effective leaders leverage both. “While I still prefer a leadership style of listening before speaking, other than in emergency situations, the convergence of speaking and listening are complementary forces in leadership. The dynamic balance between the two crafts a leader who not only inspires but also empowers. Such leaders create environments where dialogue thrives, ideas flourish, and consensus is reached without compromising the vision or the drive needed for action.” 

featured in #491

The Management Team

- Joel Spolsky tl;dr: “Stop thinking of the management team at the top of the organization. Start thinking of the software developers, the designers, the product managers, and the front line sales people as the top of the organization... The “management team” isn’t the “decision making” team. It’s a support function. You may want to call them administration instead of management, which will keep them from getting too big for their britches.” Managers are administrators who aren’t supposed to make hard decisions but enable others to do so. 

featured in #490

Empty Questions

- Ed Batista Jennifer Ouyang Altman tl;dr: “All too often our questions aren't truly open and honest inquiries. They may be loaded questions, freighted with biased assumptions. They may be leading... or simply be statements in disguise. The problem with these questions is that they're never as clever or well-hidden as we think they are. They feel hokey and theatrical.” Jennifer prompts us to ask empty questions, which release preconceived notions of what the answer is, not forcing an agenda or trying too hard. Empty questions come from a place of empowering, expanding and elevating. Examples are provided. 

featured in #490

Mastering Programming

- Kent Beck tl;dr: “From years of watching master programmers, I have observed certain common patterns in their workflows. From years of coaching skilled journeyman programmers, I have observed the absence of those patterns. I have seen what a difference introducing the patterns can make. Here are ways effective programmers get the most out of their precious 3e9 seconds on the planet. The theme here is scaling your brain.” 

featured in #488

The Snow Melts At The Periphery

- James Stanier tl;dr: The initial signs of trouble in an organization are not at the center where engineering or management are situated, but at the edges. This is because people at the edges are the most exposed to the outside world i.e. where bad reviews are posted, where customers ask for help, and where social media complaints about unacceptable bugs are posted. As you become more senior in an organization, it is easy to become isolated from the outside world. James explains how to tackle this. 

featured in #486

Microsoft's New Future Of Work Report

- Abi Noda tl;dr: The report focusses on LLMs e.g. GitHub Copilot and its impact on software development, suggesting it has the potential to improve productivity and reduce cognitive load. However, its benefits are distributed unevenly across users and it introduces new challenges. Key takeaways: (1) Benefits of LLMs in software engineering depend on the specific task e.g. easier to start a project with an LLM but difficult to change generated code. (2) Issues arise with writing prompts and overreliance e.g. burdensome to inspect code, accepting incorrect code. (3) LLMs help the least experienced the most. (4) Adoption is influenced by how well AI tools fit within workflows. (5) Analyzing and integrating information become more important than generating code. 

featured in #486

Useful Tradeoffs Are Multi-Dimensional

- Will Larson tl;dr: Tradeoff decisions often result in disappointment e.g. you can’t deploy software quickly and test it thoroughly, you have to sacrifice usability due to safety features. Will believes the key is to introduce a new dimension to the decision making process. His approach: (1) Believe and socialize that there is a new dimension to discover. (2) Get specific on stakeholder requirements. (3) Seeing dimensions is the same as seeing layers of context. Expand your contextual awareness or pull in a team with knowledge. (4) Test new dimensions for usefulness quickly. Don’t go too deep. (5) Ask those who’ve solved similar tradeoffs. (6) Only add a dimension if it provides significantly better outcomes. 

featured in #485

Trifectas Go All The Way Up

- James Stanier tl;dr: Trifectas are a group of three people from different disciplines i.e. engineering, product and UX, who work together to achieve a goal. They are often smaller teams lower down the org. James advocates and explains how and why trifectas should exist throughout the org - in senior leadership and middle management too. They ensure that the leadership team is aligned with the long-term strategy of the organization, allows for clear accountability, creates positive tension between disciplines and enables issues to be resolved quickly.

featured in #484

How To Fix Broken Teams

tl;dr: “If you get to a place where you see a team like this, take a deep breath - things are going to be tough for a while.” The author shares the following steps: “The new manager needs to: (1) Fix process and run them well. (2) Manage out cynical culture carriers. (3) Get in the weeds and learn the system. (4) Hire at least some new teammates. (5) Make sure the mission is good. 

featured in #483