/Management

The Five Principles Of Modern Developer Tools

- Chris Bell Sam Seely tl;dr: Engineering teams are increasingly outsourcing non-core, yet critical parts of their stack to third-party vendors. This post delves into the challenges and emerging solutions of using third-party services in your stack. It discusses five key principles of modern developer tools: code-based resource management, source control management, rich type definitions, CI/CD integration and managing tools as part of your deployment lifecycle.

featured in #466

Standing On The Shoulders Of Giants: Colm On Constant Work

- Werner Vogels tl;dr: This is why many of our most reliable systems use very simple, very dumb, very reliable constant work patterns. Just like coffee urns. These patterns have three key features. (1) They don’t scale up or slow down with load or stress. (2) They don’t have modes, which means they do the same operations in all conditions. (3) If they have any variation, it’s to do less work in times of stress so they can perform better when you need them most. There’s that anti-fragility again.

featured in #466

Your Small Imprecise Ask Is A Big Waste Of Their Time

tl;dr: "Imprecise asks from managers and leaders cause a disproportionate amount of turmoil and wheel-spinning. To combat this, leaders should be very precise with the amount of time investment they’re asking for when they ask for things. A little bit of awkward precision up front can save major headaches down the line." The author shares examples to illustrate such asks. 

featured in #465

Effective Engineering Teams

- Addy Osmani tl;dr: The Google research team concluded that the following were pillars of team effectiveness. Addy discusses each in depth: (1) Psychological Safety: "On our team, making a mistake is seen as an opportunity to learn rather than a blunder to be penalized." (2) Dependability: "I can count on my teammates to deliver on their promises and commitments." (3) Structure and Clarity: "We have a clear and effective roadmap for decision-making within our team." (4) Meaning: "The work I contribute to the team holds personal significance for me." (5) Impact: "I can clearly see how our team's efforts make a difference to the broader goals of the organization."

featured in #465

Benchmarking

- Will Larson tl;dr: It’s easy to lean too heavily on benchmarks by believing that they answer questions: they don’t really do that. Benchmarks only ask questions, they never answer them. It’s up to whoever is using the benchmarks to extract the questions and do your own work to answer them. If you look at “R&D costs as a percentage of revenue” across companies, you’ll notice that some are four or five times higher than others. Are the high spenders early in making a calculated bet into releasing a new service, or are they just inefficient? Either, or both, could be true, and that’s the sort of interesting question-answer pair to work through when using benchmarks to evaluate.

featured in #465

It's All Just Leadership After All

- James Stanier tl;dr: "The pertinent question is whether you should manage senior managers and senior ICs differently. After all, they have different roles and responsibilities, and so it would be natural to assume the way that you manage a Staff Engineer would be different than the way that you manage an Engineering Manager. Right? Nope, that assumption would also be wrong. Sorry. You don't need special approaches for managing both roles. In fact, you can apply the same strategy to both, and not only does this simplify your approach, it actually encourages the best behaviors from both roles." James discusses his approach. 

featured in #464

The Human Side Of Software Engineering Teams

- Abi Noda tl;dr: Developers were asked to rate a set of challenges to determine which factors had the highest impact. The two most impactful challenges identified were insufficient analysis at the beginning of a task and lack of leadership. Other impactful challenges included missing documentation, demotivation, and information not being made known to the team. Abi discusses how to address these. 

featured in #463

Tests Are Bad For Developers

- Stephan Schmidt tl;dr: Stephan argues that while tests are crucial for software development, they are perceived negatively by developers because they highlight mistakes without immediate benefits. He suggests that tests become a burden when under business pressure, as they can lead to blame for missed deadlines. Stephan advocates for tests as non-negotiable and part of professional engineering, urging QA to support developers in creating effective tests.

featured in #463

Organize Your Week As An Engineering Manager

- Nicola Ballotta tl;dr: "What should my week look like, and what exactly should I be doing?" This question is particularly pertinent for those who have transitioned from a developer role, where their schedule was often tightly structured and well-defined. In this essay, I aim not only to provide answers to these questions but also to guide you through the process of creating a weekly calendar that reflects the typical responsibilities of an EM."

featured in #462

Hire Better Managers: 35 Interview Questions For Assessing A Candidate

tl;dr: (1) What are 1-2 questions you always ask your team members in one-on-one meetings, and why? (2) If I asked someone on your team about your leadership style, what would they say? (3) Tell me about a time when you delved into significant detail and got your hands dirty. (4) What ritual or practice have you found to be most effective for helping your team connect and collaborate? (5) Why did you leave IC work?

featured in #462