This week we discussed sections 5.3 through the end of the chapter.
Section 5.3 — Make your peers your first team
- The ingredients necessary for a team are awareness of each other’s work, evolution from character to person, refereeing defection, avoiding zero-sum culture, and making it explicit. For anyone that’s seen Geoff’s playbook talk where he speaks to values, strengths, and beliefs, they’ll know these ingredients are 100% Geoff.
- At Lirio the managers are getting together to learn from one another and share ideas about how to measure performance. Jamie mentioned he worked with a team where the managers pushed for more peer coaching and spending less time talking to direct reports.
- Dennis works on a team where his leader consistently makes work visible to others so they can prevent missteps.
- Geoff liked the statement “Spending time together learning about each other, often at a team offsite, will slowly transform strangers into people.” This is very powerful; you work with other human beings, not roles.
- Jamie likes the concept of “socializing” new ideas to make them less threatening to others and to get buy-in.
- There needs to be a manager or highly respected team member to hold people accountable for good behavior.
- The idea “Long term, I believe that your career will be largely defined by getting lucky and the rate at which you learn.” reminded Geoff about his fate-driven career management post.
- Jamie’s best experience was building a team of amazing people that ship awesome stuff. You learn faster when you’re interested.
Section 5.4 — Consider the team you have for senior positions
- Geoff hadn’t heard of the “Rooney Rule.” It’s from Dan Rooney of the Pittsburgh Steelers about an NFL policy requiring league teams to interview ethnic minority candidates for high-level positions (much like affirmative action, but for interviewing). Houston wondered why this was mentioned. Maybe this is about building a diverse team because you’ll get better ideas; getting away from the status quo.
- You don’t truly know what people experience have to bring to the table. How can you compare a dev with a Github account to a single mother who does development for a paycheck?
- Not everyone has the opportunities to learn the skills you need for a given job. Hire people that are willing to learn. Give people chances.
- When Geoff first started his current job, he drafted a 90-day plan about transitioning into the role. The book said it’s important to get feedback on how the plan is working, which unfortunately Geoff never received. Many of us haven’t had success with 90-day plans.
- On the concept of having a vision/strategy document about “where the team will be in two to three years,” Geoff said, “Years???? I’ll be lucky if I know where the team will be in two to three months depending on how much change I can bring about. Plus, teams grow and shrink.”
- At a previous job Jamie had a vision for deployments to be non-events by putting systems and processes in place to automate as much as possible. Strategies are important for long-term views. Senior people need to have some direction they want to see come about.
- Put initiatives, visions, and strategies in a backlog so you can prioritize them and define how much time to spend on what.
Section 5.5 — Company culture and managing freedoms
- Definitions: positive freedom is the freedom to do things (vote, read, smoke), negative freedom is the freedom from things (having your movements tracked, taking a literacy exam before voting).
- What’s an example of how a company would leverage these freedoms to steer toward a goal? For example, freedom to wear what you want at work. What things do you really value? If you have unlimited PTO you have the positive freedom to take as much time off as you want and you have the negative freedom from working too much. Every action has positive and negative consequences.
- Paradox of positive liberty: having power but not wanting it. Jamie said this plays out for him through decision fatigue in development. We do want some choice, though.
- Tom DeMarco suggested to keep doing things the way you’re doing them, but always change exactly one thing for each project. Geoff thought this was interesting, but asked why you would change something unless you’re running an experiment or deliberately trying something new to learn about it. Jamie said this is more about not settling for the status quo. Another example is trying to avoid using if-else statements in favor of other techniques and tools; you end up learning something you wouldn’t otherwise have encountered.
Section 5.6 — Kill your heroes, stop doing it harder
- “Unless your problem is that people aren’t trying hard, the ‘work harder’ mantra only breeds hero programmer whose heroic ways make it difficult for non-heroes to contribute meaningfully.” Well stated! Asking people to work harder is lazy management. Solve the problem you actually have (e.g., too many dependencies, invisible work, tech debt, not enough people, knowledge gaps).
- “…either kill the environment that breeds hero programmers, or kill the hero programmer by burnout.”
- On rehabilitating heroes: “They might hate you for a while, and they probably should, because you created them with your ham-fisted attempt to fix your current problem.” Geoff wondered how many people actually look at themselves in the mirror like this.
- “Without policy, your tool is stepping back and allowing the brokenness to collapse under its own weight.” Geoff said that some people/systems need to fail to truly learn. Without being smug about it, would it be useful to have a journal entry that says, “I think this will turn out badly because X, Y, Z is happening” and then share that with others post mortem?
- You don’t want too much stock to manage, but enough to buffer when things get held up.
- Dennis recommended being heroes as a team, not as one person.
- If you cover for people continually, you’re just an enabler for unhealthy behavior.
- Retrospectives and post mortems are important so you can learn from inevitable mistakes.