/Leadership

Parkinson's Law: It's Real, So Use It

- James Stanier tl;dr: “When you are asking people to do something, lead with a recommendation of when it should be done by. Be explicit about this, but open to negotiation. It's such a simple technique, but when you compound its usage over a year at a big company, you will be amazed at the difference it makes.” Parkinson's Law states that "work expands so as to fill the time available for its completion" and, by setting aggressive deadlines, James discusses how leaders can leverage it. 

featured in #494

5 Lessons I Learned The Hard Way From 6 Years As A Software Engineer

- Jordan Cutler tl;dr: (1) Bring solutions, not problems. Focus on showing how you are there to support the team that needs the help. (2) Clean code isn’t the end goal. Collaborating effectively with your team is more important. (3) Team outcomes are greater than individual outcomes. What you spend your time on should be directly correlated with what will bring impact for the team. (4) Adapt to your manager. Understand how to adapt to your manager’s style and goals to see the best collective outcomes. (5) Influence isn’t about wording. Focus on building relationships with a foundation of trust. 

featured in #494

Productive Compliments: Giving, Receiving, Connecting

- Kent Beck tl;dr: “At it’s best, a compliment is a warm fuzzy. Receiving or giving a compliment blesses the day. At it’s worst, a compliment is a naked power play, an assertion of dominance. Giving and receiving compliments are not natural skills. This article summarizes what I’ve learned about giving and receiving compliments so far.” Kent provides specific and actionable advice around the semantics of human connection.

featured in #493

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