[Book Recap] The Manager's Path

Re-reading this book as a reminder of best practices of manager behavior at various levels. Here is a recap.

Chapter 1. Management 101

"The secret of managing is keeping the people who hate you away from the ones who haven’t made up their minds. - Casey Stengel"

"A strong engineer may make a great mentor-manager to someone early in his career, but a terrible advocate-manager for someone who is more senior."

Chapter 2. Mentoring

Skipping

Chapter 3. Tech Lead

"A leader, responsible for a (software) development team, who spends at least 30 percent of their time writing code with the team. "

"Tech leads are in the position to act as strong technical project leaders, and to use their expertise at a larger scale so that their whole team gets better. They can make independent decisions, and they play a big role in coordinating with other nonengineering partners that their team might have."

However, tech leads will be working on one major new technical skill: project management.

...the biggest trick of being a good tech lead: the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs.

"Project management isn’t something that needs to happen in detail for every single effort, and it’s overused in some organizations. I don’t even like hiring project managers because they often act as a crutch for engineers to use instead of learning to think through their future work and ask real questions about what they’re doing and why, and their presence means that you have more waterfall-style projects instead of an agile process. Still, project management has to happen, and as tech lead, you should be doing it when it is needed, especially for deeply technical projects."

The plan itself, however accurate it turns out, is less important than spending time on the act of planning.

Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it. Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan. And at the end of it, don’t forget to celebrate!

Good Manager, Bad Manager: The Process Czar

Engineers who believe in the “right tool for the job” sometimes turn into process czars... They try to stop all work while they search for the perfect process, or constantly push new tools and processes on the team as solutions to the messier problems of human interactions.

The opposite of the process czar is not a manager who gives up on process completely, but rather someone who understands that processes must meet the needs of the team and the work.

Ironically, while “agile” is often implemented in a rigid way, the principles of the Agile Manifesto are a great summary of healthy process leadership:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As a new tech lead, be careful of relying on process to solve problems that are a result of communication or leadership gaps on your team. ... look for self-regulating processes. If you find yourself playing the role of taskmaster — criticizing people who break the rules or don’t follow the process — see if the process itself can be changed to be easier to follow. It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.

Chapter 4. Managing People

Starting a New Reporting Relationship Off Right

• Build Trust and Rapport
  • How do you like to be praised, in public or in private?
  • What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback?
  • Why did you decide to work here? What are you excited about?
  • How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of?
  • Are there any manager behaviors that you know you hate?
  • Do you have any clear career goals that I should know about so I can help you achieve them?
  • Any surprises since you’ve joined, good or bad, that I should know about?
• Create a 30/60/90-Day Plan
• Encourage Participation by Updating the New Hire Documentation
• Communicate Your Style and Expectations
  • get as much feedback as you can about the new hire’s perspective on the team in that first 90 days. ...don’t encourage people in this period to criticize the established processes or systems in a way that makes the existing team feel attacked.

Good Manager, Bad Manager: Micromanager, Delegator

The hardest thing about micromanagement is that there are times when you need to do it. Junior engineers often thrive under detailed oversight because they want that specific direction. Some projects go off the rails, and you occasionally need to override decisions made by your reports that could have big negative repercussions.

Autonomy, the ability to have control over some part of your work, is an important element of motivation. This is why micromanagers find it so difficult to retain great teams. When you strip creative and talented people of their autonomy, they lose motivation very quickly.

Practical Advice for Delegating Effectively

• Use the Team’s Goals to Understand Which Details You Should Dig Into
• Gather Information from the Systems Before Going to the People
• Adjust Your Focus Depending on the Stage of Projects
  • Early on focus on design decisions; later on progress details
• Establish Standards for Code and Systems
  • Depersonalize the process of providing feedback
• Treat the Open Sharing of Information, Good or Bad, in a Neutral to Positive Way

Creating a Culture of Continuous Feedback

• Know your people
• Observe your people
• Provide lightweight, regular feedback.
  • Start with positive feedback. ...Positive feedback also makes your reports more likely to listen to you when you need to give them critical feedback. When they believe that their manager sees the good things they do, they’ll be more open to hearing about the areas where they might improve.
• Bonus: Provide coaching.
  • Continuous feedback works best when you pair that feedback with coaching. As situations arise, use coaching to ask people what they might have done differently. When things are going well, praise them, but also make suggestions as to what could be even better in the future. Coaching-based continuous feedback means going beyond a simple “good job” to really engage with the details and form a partnership with your direct report where the two of you are working together to help her grow.
  • Why do I list coaching as a bonus? It’s not always a core need for doing the job well,... Save your valuable coaching time for those who are receptive to it.

Real potential shows itself quickly. It shows itself as working hard to go the extra mile, offering insightful suggestions on problems, and helping the team in areas that were previously neglected. The person who has potential but isn’t yet showing equivalent performance is showing up for the team in a way that others do not, even if her work is slow-going.

Chapter 5. Managing a Team

Here is the job description that I used for the role of managing a team, which I called “engineering lead”:

• The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.
• The person who fills this role is expected to have a large impact on the success of [the organization] as a whole. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.
• The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their product group (pillar). They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team. We’ve covered the basics

Staying Technical

• As you progress in your career, even though you may stop writing code, your job will require that you guide technical decision making. Even with architects who design the systems or other senior technical staff who are in charge of the details, as the manager of a team, you have the job of holding those people accountable for their decisions, of making sure that the decisions pass the technical smell test and have been balanced against the overall context of the team and the business. Technical instincts honed over years of doing the job are very important for guiding that process.
• In fact, I mention specifically in my engineering lead job description that I expect managers at this level to implement small features and bug fixes. Why bother writing any code if all you’re doing is small stuff? The answer is that you need to stay enough in the code to see where the bottlenecks and process problems are. You might be able to see this by observing metrics, but it’s far easier to feel these problems when you’re actively engaged in writing code yourself.

Debugging Dysfunctional Teams: The Basics

• Not shipping
  • Humans, by and large, feel good when they set small goals and meet them regularly.
• People drama
  • You have to be brave and nip people drama in the bud quickly.
  • The best defense is a good offense in this case, and quick action is essential.
• Unhappiness due to overwork
  • Dedicate 20% of your time in every planning session to system sustainability work (“sustainability” instead of the more common “technical debt”).
  • In a case where overwork is due to a pressing, time-critical release, remember two things.
    • First, you should be playing cheerleader. Support the team however they need supporting, especially by helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Make it clear that they’ll have explicit break time after the push. Make it as fun as you can in the moment. Sometimes a crunch period can serve as a bonding experience for a team. But they’ll remember whether their manager was with them during the stressful period, or off somewhere else, doing her own thing.
    • Second, do everything you can to learn from this crunch period and avoid it the next time. Cut features if you can. Push back on the date if it’s truly unrealistic. Crunch periods will happen, but there is no reason they should happen frequently.
• Collaboration problems
  • Gather actionable feedback from your team, and have productive conversations about possible improvements. You can make the situation worse by undermining your peers in front of your team, so even when you are frustrated with them, try to stay positive and supportive of their efforts in public.

How to Drive Good Decisions

While the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details, you are usually accountable for the team’s progress through each of these elements. The nature of leadership is that, while you may only have the authority to guide decisions rather than dictate them, you’ll still be judged by how well those decisions turn out.

Review the Outcome of Your Decisions and Projects

• Talk about whether the hypotheses you used to motivate projects actually turned out to be true.

Run Retrospectives for the Processes and Day-to-Day

The Dos and Don’ts of Managing Conflict

Having a team that is constantly bickering and disagreeing is painful, and can be very dysfunctional. But there is such a thing as artificial harmony, and conflict-avoidant managers tend to favor harmony above functional working relationships. Creating a safe environment for disagreement to work itself out is far better than pretending that all disagreement does not exist.

• Don’t rely exclusively on consensus or voting.
• Do set up clear processes to depersonalize decisions. When you want to allow for group decision making, the group needs to have a clear set of standards that they use to evaluate decisions.
• Don’t turn a blind eye to simmering issues.
• Do address issues without courting drama.
• Don’t take it out on other teams.

Project Management Rules of Thumb

• None of this is a replacement for agile project management
  • When it comes to actually planning the details of the smaller pieces, an agile process where the team collaborates to divide and roughly estimate work is very effective at smoothing and organizing the day-to-day. As the manager, you’re not trying to disrupt or even own that part of the execution process.
  • However, you are responsible for the larger picture — the accomplishments that are measured in months instead of weeks — and this is where you have to start exerting some higher-level planning.
• You have 10 productive engineering weeks per engineer per quarter
• Budget 20% of time for generic sustaining engineering work across the board
• As you approach deadlines, it is your job to say no
  • partner with your tech lead and the product lead/business representative to figure out what “must-haves” are not actually must-haves. You will have to say no to both sides.
• Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks
• Be selective about what you bring to the team to estimate
  • it’s distracting and stressful for engineers to have a manager who’s constantly asking them for random project estimates. As the manager, you’re responsible for handling uncertainty and limiting how much of that uncertainty you expose to your team.
  • Try to get a teamwide process in place for talking about new features and customer complaints, and limit estimations that occur outside of this process.

Chapter 6. Managing Multiple Teams

... keep at least a solid half-day once a week completely free from meetings or other obligations, and try to use this time at least partially on some creative pursuit.

A big part of the challenge of time management emerges when you start to lose the sense of importance. Urgency is often more clearly felt than importance....We also tend to substitute obvious for urgent in determining something’s value.

Decisions and Delegation

• Delegate Simple and Frequent Tasks
• Handle Simple and Infrequent Tasks Yourself
• Use Complex and Infrequent Tasks as Training Opportunities for Rising Leaders
• Delegate Complex and Frequent Tasks to Develop Your Team
  • Tasks like project planning, systems design, or being the key person during an outage are the biggest opportunity you have to grow talent on your team while also making the team run better.

Delegation is a process that starts slow but turns into the essential element for career growth. If you teams can’t operate well without you around, you’ll find it hard to be promoted. Develop your talent and push decisions down to that talent so that you can find new and interesting plates to learn how to spin.

Challenging Situations: Strategies for Saying No

• "Yes, and"
  • Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership.
• Create Policies
  • Making a policy helps your team know in advance the cost of getting to “yes.”
• “Help Me Say Yes”
  • similar to policy writing, but works better for the one-off instances where there is no clear policy. Sometimes you’ll hear ideas that seem very ill-considered. “Help me say yes” means you ask questions and dig in on the elements that seem so questionable to you. Often, this line of questioning helps people come to the realization themselves that their plan isn’t a good idea, but sometimes they’ll surprise you with their line of thinking. Either way, curious interrogation of ideas can help you say no and teach at the same time.
• Appeal to Budget
• Work as a Team
  • Sometimes you will use your technical authority to say no in a way that is beneficial to the product team. Sometimes you will appeal to the finance department to help you say no to certain budget excesses. Playing good cop/bad cop can be a little bit dishonest, so use this sparingly, but it can be useful to lend your authority to a no and then be able to call in the favor when you need support for your own no in the future.
• Don’t Prevaricate
  • practice getting comfortable with the quick no (and the quick yes!) for low-risk, low-impact decisions.

Technical Elements Beyond Code

You’re going to turn your technical focus now to observing and improving the systems of work that your developers are operating within.

The popular management book First, Break All the Rules discusses several questions you can answer to help predict team productivity and satisfaction. Among them are:

• Do I know what is expected of me at work?
• Do I have the materials and equipment I need to do my work right?
• Do I have the opportunity to do what I do best every day?

For most engineers, the answer to these questions can be discerned by the speed and frequency with which they push code.

• If the work they need to do is clear, they know what code to write.
• If the tools, tickets, automation, and process are available and easy to use, they are able to get the code written.
• And if they’re not distracted by excessive meetings or drowning in support and incident management, they’ll get a chance to write code every day.

Good Manager, Bad Manager: Us Versus Them, Team Player

As a manager, be careful about focusing on your teams to the exclusion of the wider group. Even when you have been hired to fix a team, remember that the company has gotten this far because of some fundamental strengths. Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it. The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.

Durable teams are built on a shared purpose that comes from the company itself, and they align themselves with the company’s values... this purpose-based binding makes teams:

• Resilient to loss of individuals.
• Driven to find better ways to achieve their purpose.
• First-team focused.
  • Leaders who are strong team players understand that the people who report to them are not their first team. Instead, their first team is their peers across the company.
• Open to changes that serve their purpose.

The Virtues of Laziness and Impatience

“laziness, impatience, and hubris” are virtues of engineers

As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice modeling, right now: figuring out what’s important, and going home.

I can’t stand watching people waste their energy approaching problems with brute force and spending time rather than thought. And yet, any culture where you are encouraged to work excessive hours all the time is almost certainly doing just that. What is the value in automation if you don’t use it to make your job easier? We engineers automate so that we can focus on the fun stuff — and the fun stuff is the work that uses most of your brain, and it’s not usually something you can do for hours and hours, day after day.

So be impatient to figure out the nut of what’s important. As a leader, any time you see something being done that feels inefficient, question it: Why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value faster? Can we strip down this project into something simpler and get it done more quickly?

“faster” is not about “the same number of hours but fewer total days.” “Faster” is about “the same value to the company in less total time.”

Laziness and impatience. We focus so we can go home, and we encourage going home because it forces us to constantly focus. This is how great teams scale.

Chapter 7. Managing Managers

Here, you need to follow up on all the little things until you figure out what you don’t need to follow up on. Is recruiting happening? Are your managers coaching their teams? Has everyone written up their goals for the quarter? Have you reviewed them? What is the status of that project that should be finishing up? That production incident that happened the other day — did the postmortem happen? Did you read the report?

• How to get information from your skip-level reports
• What it means to hold your managers accountable
• Managing first-time and experienced managers
• Hiring new managers
• Figuring out the root of organizational dysfunction
• Cultivating your teams’ technical strategy

Skip-Level Meetings

if you want to build a strong management team, understanding the people who report to those managers and maintaining a relationship with them is hard to avoid.

Some suggested prompts to provide the person you are holding the skip-level 1-1 with include:

• What do you like best/worst about the project you are working on?
• Who on your team has been doing really well recently?
• Do you have any feedback about your manager — what’s going well, what isn’t?
• What changes do you think we could make to the product?
• Are there any opportunities you think we might be missing?
• How do you think the organization is doing overall?
• Anything we could be doing better/more/less?
• Are there any areas of the business strategy you don’t understand?
• What’s keeping you from doing your best work right now? How happy (or not) are you working at the company?
• What could we do to make working at the company more fun?

In the group setting, these questions can be used to draw out information:

• What can I, your manager’s manager, provide for you or your team? Anything I should be helping with?
• Is this team working poorly with any other teams, from your perspective?
• Are there any questions about the larger organization that I can answer?

The purpose of this skip-level process, beyond maintaining trust and engagement, is to help you detect places in which you’re being “managed up” well, to the detriment of the team under that manager.

At this level, you’re constantly making tradeoffs between investing in expensive engagements, such as 1-1s, that can provide deep value but cost you in time and energy, or casual engagements that are more efficient in terms of your time but provide less detailed information.

Hiring Managers

First, make sure that the person has the skills you need. Second, make sure that she’s a culture match for your organization.

The biggest difference between a management interview and an engineering interview is that managers can, theoretically, bullshit you more easily.

Separate your fear of what happens after you hire the manager from what you’re trying to evaluate when interviewing her. You can evaluate her and get worthwhile information from the management interview. So how do you do that? Look at the skills you expect from a manager, and ask her about them.

• 1-1s
  • Any manager you hire should role-play a few 1-1s as part of the interview process. One of the best ways to do this is by asking the people who would report to the new manager to interview her by asking her to help with problems they have right now, or have had in the recent past.
  • You can take it a step further and actually role-play other types of difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review.
• Importantly, a manager must also be able to debug teams.
  • Ask the manager to describe a time when she ran a project that was behind schedule, and what she did in that scenario. Or ask her to role-play with an employee who is thinking about quitting. Ask the manager to describe how she’s coached employees who were struggling, and helped great employees grow to new levels.
• Ask her about her management philosophy.
  • If she doesn’t have one at all, that might be a red flag. While a new manager may not be able to answer this question well, an experienced manager who has no clear philosophy is a cause for concern. What does she think the job of a manager is? How does she stay hands-on, and how does she delegate?
• Depending on the seniority, you might have a candidate come in and give a presentation to a group of people.
  • The point of this is not specifically to judge the contents of the presentation, but to see how she is at commanding a room, answering questions posed by a group, structuring her thoughts, and getting up in front of an audience.
• What about technical skills?
  • You want to make sure that you get enough of a sense of a candidate’s technical skills that she’ll be able to establish credibility to the team she’ll be managing.
  • In the case of someone who will need to write some code, give her an abbreviated version of your standard technical interview.
  • For a noncoding manager, ask technical questions that you believe she should be able to address given her experience. Design and architecture questions based on the types of systems she’s built or managed are a good approach. Make sure she can discuss the tradeoffs that were made and why.
  • You might also have her mediate a technical debate between engineers who disagree on the solution to a problem. A good technical manager will know what kinds of questions to ask that tease out the core issues and guide the group to a solid consensus.

one of the critical elements to hiring in new managers: the reference check. Do thorough reference checks for anyone you’re planning to bring on board, even if you’ve worked with that person before. Ask the references to describe the ways that the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again. Ask them what they love about the person, and what drives them crazy. If you’re not doing reference checks when you hire management, you’re doing your team a massive disservice. Reference checks, even ones chosen carefully by the candidate, often reveal a lot about what you can expect to get when hiring her. Don’t leave out this crucial step.

Debugging Dysfunctional Organizations

the best engineering managers are often great debuggers.

Setting Expectations and Delivering on Schedule

Sadly, we are often asked this question in times when things are not taking any longer than the estimate. We are often asked this question when our leadership, for whatever reason, either didn’t like the original estimate or didn’t ask for it at all, and now they’re upset, despite nothing going wrong.

Therefore, you must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks.

This means you must be aggressive about getting estimates, and as we all know, software estimation is a very difficult process. Negotiating the process that your team uses to estimate, on what timescale, for what projects, may be part of your job at this level.

Showing some empathy for the person providing pressure and being willing to help out in other ways can go a long way to shifting focus from blame to action.

Strategies for Handling Roadmap Uncertainty

• Be realistic about the likelihood of changing plans given the size and stage of the company you work for.
• Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision.
• Don’t overpromise a future of technical projects.
• Dedicate 20% of your team’s schedule to “sustaining engineering.”
• Understand how important various engineering projects really are.
  • How big is that project?
  • How important is it?
  • Can you articulate the value of that project to anyone who asks?
  • What would successful completion of the project mean for the team?

Staying Technically Relevant

Your technical responsibility:

1. Oversee Technical Investment
2. Ask Informed Questions
   1. You need to know enough about the work to sniff out misguided efforts and evaluate proposed investments.
3. Analyze and Explain Engineering and Business Tradeoffs
4. Make Specific Requests
   1. As a director-level manager, you still need to have enough understanding of the technology in your organization to make specific requests without distracting the senior engineers with questions. By knowing enough about the progress of your teams, the projects, and bottlenecks, you can filter out technically infeasible ideas and map new initiatives onto ongoing projects. These specific requests should be used to keep the teams productive and balance technical risks with organizational goals.
   2. Managers who don’t stay technical enough sometimes find themselves in the bad habit of acting as a go-between for senior management and their teams. Instead of filtering requests, they relay them to the team and then relay the team’s response back up to management. This is not a value-add role.
5. Use Your Experience as a Gut Check

Given your level of technical responsibility, how should you invest your time in order to stay technically relevant?

• Read the code
• Pick an unknown area and ask an engineer to explain to you
• Attend postmortems
  • When outages happen, make it a priority to attend the post-outage debriefs. These meetings are often full of details about the process of writing and deploying software that you miss when you aren’t coding every day.
• Keep up with industry trends in software development processes.
• Foster a network of technical people outside of your company.
• Never stop learning.
  • Find articles and blog posts about technology and read them. Watch talks. Pick something you’re really curious about and dig in a little bit deeper, even if it isn’t relevant to your team or company. Don’t be afraid to ask questions of your team and look for opportunities to learn from them. Learning is a skill that you can practice to keep your mind sharp.

Chapter 8. The Big Leagues

In his book High Output Management Andy Grove breaks down management tasks into four general categories:

• Information gathering or information sharing
  • Sitting in meetings, reading and writing emails, talking to people one on one, gathering perspectives. The strong senior leader is capable of synthesizing large quantities of information quickly, identifying critical elements of that information, and sharing the information with the appropriate third parties in a way they will be able to understand.
• Nudging
  • Reminding people of their commitments by asking questions instead of giving orders. It’s hard for a leader of a large team to forcefully guide that team in any direction, so instead rely on nudging members of the team to keep the overall organization on track.
• Decision making
  • Taking conflicting perspectives and incomplete information and setting a direction, knowing that the consequences of a poor decision will impact both you and possibly the whole team. If making decisions were easy, there would be much less need for managers and leaders. However, as anyone who has spent a lot of time managing can tell you, making decisions is one of the most draining and stressful parts of the job.
• Role modeling
  • Showing people what the values of the company are. Showing up for your commitments. Setting the best example for the team even when you don’t feel like it.

Whether you’re a CTO, a VP, a general manager, or a head of engineering, your days are shaped by those four tasks.

"It took me a long time to realize that my job wasn’t to be the smartest person in the room. It wasn’t to be “right.” Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way." - James Turnbull

Challenging Situations: Delivering Bad News

• Don’t blast an impersonal message to a large group.
  • The worst way to communicate bad news is via impersonal mediums like email and chat, especially mediums with commenting abilities.
  • the second-worst way to deliver this message, especially to a large group that you know won’t be happy, is with them all in a room at once.
• Do talk to individuals as much as possible.
• Don’t force yourself to deliver a message you can’t stand behind.
  • f you absolutely can’t deliver the news in a way that won’t betray your strong disagreement, you might need to have someone else help you deliver it. Perhaps you ask another executive to step in, or maybe someone from HR. Depending on the size of your team, you can deliver the information to a trusted lieutenant and have that person help to share it. As someone in senior leadership, you have to learn how to maturely handle decisions you don’t agree with, but that doesn’t mean you have to go it alone.
• Do be honest about the likely outcomes.
• Do think about how you would like to be told.

Senior Peers in Other Functions

So, beyond establishing basic respect for your peers’ ownership of their turf and respect for their abilities as functional experts, you also have to put aside the idea that they’re acting in irrational or self-interested ways when they disagree with you or do things you don’t like.

Throwing out jargon to people who aren’t familiar with it — and who don’t even need to be familiar with it — makes us look stupid to them.

The final element of this first-team trust and respect is the cone of silence. Disagreements that happen in the context of the leadership team don’t exist to the wider team. Once a decision is made, we commit to that decision and put on a united front in front of our engineering teams and anyone else in the company.

At this level especially, you must decide whether you want to fall in line or quit. The middle ground, openly disagreeing with your peers, does nothing but make the situation worse for everyone.

The Echo

You’re no longer one of the team. Your first team is comprised of your peers at the leadership/executive level, and your reporting structure has now become your second team. If you shift your mindset successfully, you will probably start to detach socially a little bit from the overall organization.

Correcting a Culture of Fear

• Practice relatedness.
  • One marker of the culture of fear is a tendency to treat people impersonally.
• Apologize.
  • When you screw up, apologize. Practice apologizing honestly and briefly.
• Get curious.
  • When you disagree with something, stop to ask why.
• Learn how to hold people accountable without making them bad.
  • How do you measure success? Does the team have the capabilities needed to succeed? Are you providing feedback along the way?

Chapter 9. Bootstrapping Culture

Instead of talking about structure, I talk about learning. Instead of talking about process, I talk about transparency. We don’t set up systems because structure and process have inherent value. We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. This learning and sharing is how organizations become more stable and more scalable over time.

Pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and the challenges of trying to scale that communication.

That, in short, is the value of structure. Structure is how we scale, diversify, and take on more complex long-term tasks. We do it to our software, we do it to our teams, and we do it to our processes.

Structure grows as the company grows and ages. In fact, there’s even a law that accounts for this, from John Gall’s book Systemantics:

• A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Ironically, while luck plays a role in both failure and success, we often attribute failure to bad luck and success to our own actions.

Cross-Functional Teams

Conway’s Law is often cited in discussions of this kind of structure. It states: “Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”

When we put cross-functional teams together, we are acknowledging that the most important communication — the communication that we need to favor above all else — is that which leads to effective product development and iteration.

What is truly important to the success of your company or your organization? If the most important thing is evolving a product that is a function of many different business areas coming together, you probably want leaders who have that business sense. On the other hand, in the areas where the technology must be rock-solid or exceptionally innovative and cutting-edge, you probably want teams that have more of an engineering focus and that are led by people who can design complex systems. You don’t have to go entirely one way or the other, but recognize that one of these will lead the company as a whole, and — especially if your role is in senior management — focus your skill set on the one that the company itself most values and hire in for the other.

Developing Engineering Processes

Think of process as risk management.

One way to think about engineering processes is that they serve as a proxy for how hard or rare it needs to be for something to happen. A complicated process should exist only for activities that you expect to be rare, or activities where the risks are not obvious to people.

There’s a saying in politics that “a good political idea is one that works well in half-baked form,” and the same goes for engineering processes. The processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socializing change or risk to the team as a whole.

Chapter 10. Conclusion

The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others. The more time you spend understanding yourself, the way you react, the things that inspire you, and the things that drive you crazy, the better off you will be.

Great managers are masters of working through conflict. Getting good at working through conflict means getting good at taking your ego out of the conversation.

One other trick I use to get away from my ego is curiosity. I also have a daily habit of writing a page or two of free-flow thoughts every morning, to clear my mind and prepare for the day. I always end with the mantra “Get curious.”

So I leave you with that thought. Look for the other side of the story. Think about the other perspectives at play. Investigate your emotional reactions, and observe when those reactions make it hard to see clearly what’s going on around you, what needs to be said. Apply that curiosity to people. Apply it to process. Apply it to technology, and strategy, and business. Ask questions, and be willing to have your notions proven wrong.

Stay curious, and good luck on your path!

Books recommended in this book

• First, Break All the Rules: What the World's Greatest Managers Do Differently
• Arbinger Institute, Leadership and Self-Deception: Getting Out of the Box (San Francisco: Berrett-Koehler, 2000).
• Brené Brown, Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead (New York: Gotham Books, 2012).
• Peter F. Drucker, The Effective Executive (New York: HarperBusiness Essentials, 2002).
• Marshall Goldsmith and Mark Reiter, What Got You Here Won’t Get You There: How Successful People Become Even More Successful (New York: Hyperion, 2007).
• Andrew S. Grove, High Output Management (New York: Vintage Books, 1983). L.
• David Marquet, Turn the Ship Around! A True Story of Turning Followers into Leaders (New York: Portfolio, 2012).