How much do you know about how your team works?
On average managers either did not know or could not remember 60% of the work their teams do. In one extreme instance, a manager in our study could describe only 4% of their team’s work.
Autonomy does not always help team performance: teams allowed to choose both the composition of their groups and the ideas they work on perform substantially worse than those who are only allowed to choose either teammates or ideas (but not both).
On making decisions
Here’s a simple list of questions: What are the five big decisions on your desk right now? Would others in your position have a different list? How much of your day is spent learning what you need to know to make those decisions? And can you make them all by Tuesday? (Seth Godin)
Roger Martin thinks it’s time to accept that pay for performance doesn’t work: research, a discussion, and two examples of how to do it differently.
A consultant asked the managers they work with: “What qualities did your best managers have?”
Here’s a summary of the responses:
- Empathetic. Supportive. A real person. Has a good sense of work/life balance
- Clearly defines goals and strategy. Understands the team’s needs and wants. Advocates for team and team members
- Invested in team members’ professional growth. Cares about you personally & shows you respect
- Good teacher & coach. Challenges people by giving them feedback and also being open to receiving feedback
- Keeps communication lines open. Leads with consistency & transparency
- Isn’t judgmental. More likely to ask “what can we learn from this?” You can fail and know you’re not going to be punished
- Can sense when you’re struggling or down. Asks “how are you doing? How can I help?”
- Deals with everyone a little differently. Understands what gets different people excited about their work
After 21 months of covid asking “How are you?” might be just a little too existential. Try these instead:
Netflix started the OOPS project to encourage engineering teams to self-report when they encounter an operational surprise. This writeup contains a narrative description of the events that led to surprise, and identifies contributors, mitigators, risks, and challenges in handling.
It’s a process of accountability and learning that certainly applies beyond software engineering.
Here is the structure of one engineer’s write-up
based on the OOPS template that has evolved over time inside of Netflix, with contributions from current and former members of the CORE team.
My personal outline looks like this (the bold sections are the ones that I include in every writeup)
- Title
- Executive summary
- Background
- Narrative description
- Prologue
- The trigger
- Impact
- Epilogue
- Contributors/enablers
- Mitigators
- Risks
- Challenges in handling
This month last year, the most popular entry of the issue was
For a little self-reflection: How do you know if your career is your calling?
To read other issues of the newsletter, go here.
Subscribe right here ↓