Blog

Management 101

A manager is expected to perform the following tasks:

1. One-on-one Meetings

   1-1s serve two purposes. First, they create human connection between you and your manager. Letting your manager into your life a bit is important. Second, it is a regular opportunity for you to speak privately with your manager.

2. Feedback and Workspace Guidance

   Good managers will let you know quickly when you screw up. The sooner you know about your bad habits, the easier they are to correct. Keep track of both good and bad feedback. Asking your manager for advice, like presentation content, design doc, etc, is a good way to show your respect.

3. Training and Career Growth

   You’re responsible for figuring out what types of training you want. It’s very important to ask your manager for specific areas to focus on in order to get promotion. Building a strong network of peers is very helpful for your career.

Developing a sense of ownership and authority of your own experiences at work is an important step in owning your career and workspace happiness. Spend time thinking about what you want although you’ll probably go through periods of career uncertainty in your life. Bring agendas to your 1-1s and try to bring solutions not problems. Consider also the manager when you are evaluating job opportunities.

Mentoring

Mentors are commonly assigned to junior members of a team and many organisations use mentors as part of their onboarding process for all new hires.

1. Mentoring an intern

   The first thing is finding a project for the intern to work on, start with small features of current project that would take you a few days to complete. Listen to his questions and answer them. When you are face to face with another person, you also have to interpret his body language and they way he’s saying those words. You will also need to clearly communicate what needs to happen and calibrate your response to provide the right adjustments. Plan to have the intern present the work he did at the end of the program.

2. Mentoring a new hire

   Your job consists of onboarding this person in the company effectively, helping out adjusting to the life in the company and building out her network of contacts. There will be many opportunities to clarify many bits of process, culture and jargon that will be completely foreign to a new joiner. Effective teams have good onboarding documents to provide to new hires. Part of the mentoring is introducing the new person around, bringing this person into some of your networks will help her to get up to speed faster.

3. Technical or career mentoring

   Many companies run formal mentoring programs where they match people up across teams, and while these programs can sometimes enhance networks, they are often an ambiguous obligation for both the mentor and the mentee.

   • Mentor: Don’t do it unless you think it will be rewarding for you and the person you’re mentoring. Don’t say yes and then fail to actually do the mentoring work.
   • Mentee: Think about what you want to get out of this relationship, and come prepared to your sessions. If you don’t have time to prepare or you don’t think preparing is necessary, ask yourself if mentoring is really something you need at all. Maybe instead you need a friend, or a therapist, or a coach.

Alpha Geek
The alpha geek is driven to be the best engineer on the team, to always have the right answer, and to be the person who solves all the hard problems. He values intelligence and technical skill above all other traits. 
The alpha geek tries to create a culture of excellence, but ends up creating a culture of fear.

Alpha geeks make absolutely terrible managers. Better off to give them a focus on technical strategies and system design.

Tips for the Manager of a Mentor: Firstly, figure out why you are setting up mentoring relationship. Secondly, recognise that this is an additional responsibility for the mentor. Finally, use this opportunity to reward and train future leaders on your team.

Hiring Interns: Don’t hire interns who are not going to graduate in the year after their internship. Hiring internship is relatively easy compared to hiring full-time graduates.

Key Takeaways for the Mentor

1. Be curious and Open-Minded

   When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Working with new people who are learning things for the first time can shed light on hidden patterns and help you make connections you may not otherwise have made.

2. Listen and speak their language

   Mentoring forces you to hone your communication skills. You must be able to listen and communicate in a way that the person can understand. Teams have to communicate effectively to get anything done.

3. Make connections

   Your career ultimately succeeds or fails on the strength of your network. Mentoring is a great way to build this network. Your career is long and the tech world can be very small, so treat the other person well.

Tech Lead

A Tech Lead is a leader, responsible for a development team, who spends at least 30 percent of their time writing code with the team. This is a senior engineering role, but it’s a mistake to tie the notion of tech lead to one that boils down to the best or most experienced engineer on the team.

The biggest trick of being a good tech lead is the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs. Tech leads will work on one major new technical skill: project management, or the work of breaking down a project.

The main roles of a tech lead are:

• Systems architect and business analyst.

  Have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. Understand business requirements and translate them into software.

• Project planner.

  Break work down into rough deliverables. Part of the challenge here is getting as much productive work done in parallel as possible. Gather input from the experts on your team. Start identifying priorities.

• Software developer and team leader.

  Continue writing code, but not too much. Start looking for opportunities to delegate work.

The value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce self-discipline to think about the project in some depths before diving in and seeing what happens.

Taking the time to explain is very important.

How to manage a Project

1. Break down the work.
2. Push through the details and unknowns.
3. Run the project and adjust the plan as you go.
4. Use the insights gained in the planning process to manage requirement changes.
5. Revisit the details as you get close to completion.

The Process Czar
The process czar believes that there is is one true process that will solve all the team’s biggest problems. Agile, Kanban, scrum, Lean, or even waterfall.
Engineers sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues with planning, focus, time management, and prioritisation.

Processes must meet the needs of the team and the work.

Be careful on relying on processes to solve problems that are a result of communication or leadership gaps on your team. It’s a waste of your time to play rule cops, and automation can often make the rules more obvious. Get more comfortable with ambiguity. 

How to Be a Great Tech Lead

• Understand the architecture
• Be a team player
• Lead technical decisions
• Communicate

Managing People

The main tasks required to manage people:

• Taking on a new report
• Holding regular 1-1s
• Giving feedback on career growth, progression toward goals, areas for improvement, and praise as warranted
• Working with reports to identify areas for learning and helping them grow in these areas via project work, external learning, or additional mentoring

Starting a New Reporting Relationship Off Right

• Build trust and rapport. Ask a series of questions that are intended to help you get to know the aspects of the person.
• Create a 30/60/90-day plan. This plan includes basic goals. The more senior the hire, the more he should participate in creating the plan.
• Encourage participation by updating the new hire documentation.
• Communicate your style and expectations.
• Get feedback from your new hire. Get as much feedback as you can about the new hire’s perspective on the team in that first 90 days.

Communicating with Your Team

• Have regular 1-1s.
• Scheduling 1-1s. The default should be weekly. Try to avoid as much as possible interrupting your reports in the middle of productive workflow hours.
• Adjusting 1-1s. Adapt the cadence of your 1-1s, junior people or people who need frequent feedback or help on difficult times will appreciate more dedicated time.

Different 1-1 Styles

• The To-Do List Meeting

  One or both parties comes with a list of goals to cover in order of importance. This style is very professional and efficient, but sometimes is a bit cold. It forces reports to think beforehand what do they want to discuss.

• The Catch-Up

  Listen to anything your reports want to discuss. Let them drive the meeting. It should be as much as a creative discussion as a planning meeting. If you start focusing a lot of energy on hearing reports’ complaints and commiserating, you’re quite possible making the problem worse. There is very little value to repeatedly focusing on drama.

• The Feedback Meeting

  Quarterly is frequent enough to give the topic attention without it feeling like all you talk about is career development. Review progress toward goals, whether they are formal or personal. If you have an employee with performance issues, feedback meetings should happen more frequently.

• The Progress Report

  Mostly useful when you manage managers who are overseeing projects you don’t have time to dig into on your own. Getting progress reports from people you’re already working closely with is a waste of time.

• Getting to Know You

  Leave room to get to know the person reporting to you as a human being. Show them that you care about them as individuals. Show that you are invested in helping them now and in the future.

• Mix It Up

  Remember that when you’re not taking notes you’ll probably forget some important things. Do your 1-1 meetings in private so that you can feel free to discuss sensitive topics. For each person you manage, maintain a running shared document of notes, takeaways, and to-dos from your 1-1s.

Micromanager, Delegator
The hardest thing about micromanagement is that there are times when you need to do it. Trust and control are the main issues around micromanagement. Autonomy is an important element of motivation. Delegation is not the same thing as abdication. When you're delegating responsibility, you're still expected to be involved as much as is necessary to help the project succeed.

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
• Establish Standards for Code and Systems
• Treat the Open Sharing of Information, Good or Bad, in a Neutral to Positive Way

Creating a Culture of Continuous Feedback

There are some steps you can take to be great at giving continuous feedback.

1. Know your people
2. Observe your people
3. Provide lightweight, regular feedback
4. Bonus: Provide coaching

Performance Reviews

The 360 model is a performance review that includes feedback from, in addition to a person’s manager, his teammates, anyone who reports to him, and coworkers he regularly interacts with, as well as a self-review.

Your job as a manager is to gather all that feedback together and summarise it into a high-level view of what other people think about your direct reports.

Guidelines for writing and delivering a successful performance review

• Give yourself enough time, and start early
• Try to account for the whole year, not just the past couple of months
• Use concrete examples, and excerpts from peer reviews
• Spend plenty of time on accomplishments and strengths
• When it comes to areas for improvement, keep it focused
• Avoid big surprises
• Schedule enough time to discuss the review

Cultivating Careers

If you’re a manager, you are going to play a key role in getting people on your team promoted, you’ll need to make a case for their promotion. Learn how the game is played at your company. You need to be transparent with your team.

Start identifying promotion-worthy projects and trying to give those projects to people who are close to promotion.

If there is no growth potential on your team there’s no room for people to work at a more senior level, it may be a sign that you need to rethinking the way work is done in order to let individuals take on bigger responsibilities.

Challenging situations: Firing Underperformers
You might have to provide a performance improvement plan, a set of clearly defined objectives that a person must achieve within a fixed period of time.
One of the basic rules of management is the rule of no surprises, particularly negative ones.

You’ll always need to have a record of negative feedback to fire someone in any environment where HR is active. Give people clear improvement feedback in writing, with a timeline for improvement, and have them acknowledge it in writing as well (an email is ok).

A final warning: don’t put anyone on a plan whom you wouldn’t be happy to lose.
Coaching someone out of the company If you think your team is not the right place for somebody to grow his career. You aren’t firing him, but you are telling that he needs to move on if he wants to progress. Give the employee a chance to find a job in another part of the organisation or at another company. When he does, let him go happily.

Managing a Team

Being a good manager isn’t about having the most technical knowledge. The work of supporting people is far more important to management success.

Staying Technical

Engineering management is a technical discipline, not just a set of people skills. Technical instincts honed over years of doing the job are very important for guiding that process.

If you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle. You have to learn how to balance. If you don’t stay in the code, you risk making yourself technically obsolete too early in your career. You need to stay enough in the code to see where the bottlenecks and process problems are.

It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.

Debugging dysfunctional teams: the basics

• Not shipping.

  The trick is to learn how to balance pushing your team and holding back. Start to push for the removal of bottlenecks. When people are contending for a scarce resource, conflicts and unhappiness among team members are almost inevitable.

• People drama.

  Make it clear that a bad behaviour has to change, bring clear examples, and provide corrective feedback quickly after things happen. The best defence is a good offence, quick actions are essential.

• Unhappiness due to overwork.

  If overwork is due to (in)stability of the production system, it’s your job as the manager to slow down the product roadmap in order to focus on stability for a while. Measures of alerts, downtime, incidents, and strive to reduce them. Dedicate 20% of your time in every planning sessions to system sustainability (technical debt). For time-critical releases you should be playing cheerleader helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Offer breaks after the push and make it as fun as you can. You should avoid it next time.

• Collaboration problems.

  Regular touch-bases with the appropriate peers to work through issues. Gather actionable feedback from your team, and have productive conversations about possible improvements. Try to stay positive and supportive of their efforts in public. If your team isn’t working well together, look into creating some opportunities for them to hang out.

Managing a former peer

If you are now managing someone who was truly your peer, acknowledge the weirdness of the transition. Be honest and transparent with this person and communicate that you’re going to do your best job you can, but you’ll need his help to do it. You’re going to have to be a little bit vulnerable with him.

You may now have the ability to override his decisions, but use this power very cautiously. Resist the temptation to micromanage people. They are going to be sensitive.

You’re going to have to let go of some of your previous work.

Your goal is to show the team that you’re committed to helping them succeed.

The shield

It’s valuable for everyone to realise that they can and should focus on the things they can impact and change, and ignore the things they can’t

Helping them understand the key important goals and focusing them on those goals is important. However, it’s unrealistic to expect that you can or should shield your team from everything. Sometimes it’s appropriate to let some of the stress through the team. Help them get context into what they’re dealing with.

You are not their parent. Your team is made up of adults who need to be treated with appropriate respect.

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.

• Create a data-driven team culture. Get used to give to the product or business head person data about team productivity (time that takes to complete features) or data about quality measures (number of outages, bugs found, etc).
• Flex your own product muscles. Taking the time to develop customer empathy is important because you’ll need to give your engineers context for their work.
• Looking into the future. Think two steps ahead, from a product and technology perspective. Getting a sense of where the product roadmap is going helps you guide the technical roadmap. Start asking the product team questions about the future might look like, and spend some time keeping up with technological developments that might change the way you think about the software you’re writing or the way you’re operating it.
• Review the outcome of your decisions and projects. Review assumptions after the project is done.
• Run retrospectives for the processes and day-to-day. Discuss what happened during the sprint and pick a few events, good, bad or neutral, to discuss in detail.

Conflict Avoider, Conflict Tamer
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.

The Dos and Don’ts of Managing Conflict

• Don’t rely exclusively on consensus or voting. Don’t set people up for votes that you know will fail instead of taking the responsibility as a manager of delivering bad news yourself.
• Do set up clear processes to depersonalise decisions. Start with a shared understanding of the goals, risks and the questions to answer before making a decision.
• Don’t turn a blind eye to simmering issues. Conflict avoidance manifests as an inability to address problems until they’ve gone on for way too long. It’s probably an indication that you are not paying attention.
• Do address issues without courting drama. The goal is to identify problems that are causing the team to work less effectively together and resolve them, no to become the team’s therapist.
• Don’t take it out on other teams.
• Do remember to be kind. Your goal as a manager, should not to be nice, it should be to be kind. Nice is saying “please” and “thank you”. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready.
• Don’t be afraid.
• Do get curious. Be thoughtful about your behaviour.

Challenging Situations: Team Cohesion Destroyers
One of the critical elements of creating functional teams is building teams that work well and happily together. The real goal here is psychological safety, a team whose members are willing to take risks and make mistakes in front of one another. This is why those who undermine team cohesion are so problematic.

The Brilliant Jerk
Produces individually outsized results, but is so ego-driven that she creates a mixture of fear and dislike in almost everyone around her.
It’s incredibly hard of a manager to justify getting rid of someone who produces great work.
Simply not hire one. Getting rid of brilliant jerks takes a level of management confidence that I think is uncommon. These folks will often get rid of themselves, it’s unlikely that you’ll be stupid enough to promote them.
Simply and openly refuse to tolerate bad behaviours. One of the few instances where “praise in public, criticise in private” is upended. You don’t want your culture to mimic, you need to say something in the moment to make the standard clear. If you seem emotional, it may undermine you. Your first goal is to protect your team as a whole, the second is to protect each individual on the team, and your last priority is protecting yourself.

The Noncommunicator
The person who hides information from you, from his teammates, from his product manager.
You have to nip this information-hiding habit in the bud as soon as possible. He doesn’t feel safe sharing his work in progress, and his fear often sets an example for the rest of the team.
Address the root cause of the hiding.

The Employee Who Lacks Respect
A person who simply doesn’t respect you as a manager, or who doesn’t respect her teammates. If your team member doesn’t respect you or her peers, why is she working there?

Advanced project management

Some rules of thumb to keep in mind.

• None of this is a replacement for agile project management. 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. Don’t expect to get more than 10 weeks worth of focused effort.
• Budget 20% of time for generic sustaining engineering work. Testing, debugging, cleaning up legacy code, migrating language or platform versions, and doing other work that has to happen.
• As you approach deadlines, it’s your job to say no. The only way to achieve this goals is to cut scope at the end of the project. Figure out what “must-haves” are not actually must-haves.
• Use the doubling rule for quick estimates, but push for planning to estimate longer tasks. Whenever asked for an estimate, take your guess and double it.

Joining a small team as a manager

Get someone to walk you through the systems and architecture, as well as the process for testing and releasing the software. Follow the developer onboarding process.

Work on at least a couple of features in your first 60 days. Pair with one of the engineers on a feature he’s working on, have him pair with you as you start working on a feature of your own. Get your code reviewed. Perform a release and do rotation of supporting systems.

Managing Multiple Teams

The process of understanding details about what’s happening across a couple of teams probably means one important thing: you’re not writing (much, any, production) code.

It is very difficult for a person responsible for hands-on management of multiple teams to write code. Debugging and production support are also valuable. You might be more helpful doing pair programming, or fixing minor bugs or features.

You should spend the time to gain mastery of programming before moving into management.

One of the critical parts of the job at this level: debugging team issues and keeping your teams producing quality software smoothly.

Even if you don’t program on a daily basis, it is strongly advised to code half a day per week on some creative pursuit.

Managing your time: what’s important, anyway?

It’s time to figure out how to manage your time. Setting goals for the team, helping your product team put details on the product roadmaps.

Time management is a personal thing. Managing your time comes down to one important thing: understanding the difference between importance and urgency.

	Not Urgent	Urgent
Important	Strategic, make time	Obvious work
UnImportant	Obvious avoid	Tempting distractions

Urgency is often more clearly felt than importance. Emails feel urgent, but they aren’t urgent. We also tend to substitute obvious for urgent in determining something’s value. It’s likely that you’re spending a lot of your time on things that are urgent but only slightly important, and sacrificing things that are important but not urgent. Important but not urgent is actually preparing for meetings so that you can guide them.

As a manager of multiple teams, you can win back a lot of time by pushing an efficient meeting culture down to your teams. When you stop going to all of their internal meetings, you run the risk of missing out on the clues that will help you catch problems early. Your attendance at these meetings is partially to pay attention to the dynamics and morale of your team.

Decisions and delegation

The first several months of managing multiple teams can feel like a death march, even when your hours are not excessive. The only way out of this situation is to go through it. If you don’t feel a little bit overwhelmed, you’re likely missing something.

Feeling of management from here on out is plate spinning. Your plates are the people and projects you’re overseeing, and your job is to figure out how much attention each one needs at what time.

	Frequent	Infrequent
Simple	Delegate	Do it yourself
Complex	Delegate (carefully)	Delegate for training purposes

Strong managers spend a lot of their time developing members of their teams in these areas. Your goal is to make your teams capable of operating at a high level without much input for you.

Challenging Situations: Strategies for Saying No
“Yes, and”. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap”.

Create policies. Making a policy helps your team know in advance the cost of getting to “yes”.

“Help me say yes”. Means you ask questions and dig on the elements that seem so questionable to you. This line of questioning helps people come to the realisation themselves that their plan isn’t a good idea.

Appeal to budget. Lay out the current workload in plain terms, and show how there is little room to manoeuvre. “Not right now”.
Work as a team. There will be times when you and your peers will need to act together to say no.
Don’t prevaricate. When you know that you need to say no, it’s better to say it quickly that to delay and drag out the process. You’ll be wrong sometimes, so when you discover that you were too quick to say no, apologise for making that mistake.

Technical elements beyond code

Assuming that the job at this level becomes essentially nontechnical is a mistake. You now need to develop an eye for technical health signals for the overall team.

Measuring the health of your development team

Interrogate every process to determine the value it should provide, and always ask yourself if it can be automated further.

• Frequent releases.

  Frequency of code change is one of the leading indicators of a healthy engineering team. Part of moving fast requires breaking work down into small chunks. You have to be the advocate and push for technical process improvements that can lead to increased engineer productivity, even if you’re not implementing them all yourself.

• Frequency of code check-ins.

  The importance of breaking stuff into chunks. Engineers who don’t write tests often have a harder time breaking down their work, and learning how to test-driven development can help them better at this skill.

• Frequency of incidents.

  Determining the level of software quality you need for the product you’re building and adjusting that measure over time is a technical challenge for you, the manager, to help address. Developers support code or systems they write. Incident management, when it becomes merely reacting to incidents rather than working to reduce them, can turn into a task that diminishes your team’s ability to do what they do best.

Us Versus Them, Team Player
It can be hard for new managers to create a shared team identity. They unite the team by empathising how this identity is special as compared to other teams. Taking this too far, this identity is used to make the team feel superior to the rest of the company, and the team is more interested in its superiority than the company’s goals. This attitude make the team vulnerable of many dysfunctions.
Fragile to the loss of the leader. When you hire a manager who builds a clique, that clique is likely to dissolve and leave the company if the manager leaves the company.

Resistant to outside ideas. Miss opportunities to learn and grow.

Empire building. Leaders who favour and us-versus-them style tend to be empire builders, seeking opportunities to grow their teams and their mandates without concern for what is best for the overall organisation.

Inflexibility. Struggle against changes that comes from outside the group.

Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture. The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.
By creating a strong and enduring alignment between the team, its individuals, and the overall company, purpose-based binding makes teams.
Resilient loss of individuals.

Driven to find better ways to achieve their purpose.

First-team focused. Consider the needs of the company as a whole before focusing on the needs of their team.

Open to changes that serve their purpose.

Getting clarity about the purpose of your team and your company can take time. In startups especially.

The virtues of laziness and impatience

Impatience paired with laziness is wonderful when you direct it at processes and decisions: figuring out what’s important, and going home.

Be impatient to figure out the nut of what’s important. Laziness as “faster”, about “the same value to the company in less total time”. Forcing yourself to disengage is essential for your mental health.

Managing Managers

Managing managers adds a whole new level of complexity. It’s easy to miss out on the details because you no longer engage regularly with all of the individual developers on each team. You’ll need to practice honing your instincts.

The fallacy of the open-door policy (You can come to me whenever you want to discuss problems)

One thing managers have to keep in mind is that a part of their job is to ferret out problems proactively. The open-door policy is nice in theory, but it takes extremely brave engineer to willingly take the risk of going to her boss to tell him about problems. When you manage managers, you ultimately evaluate them on the performance of their teams. Part of the job is simply to make sure that your 1-1s have room for real conversations.

Skip-level Meetings

A skip-level meeting it’s a meeting with people who report to people who report to you. Their purpose is to help you get perspectives on the health and focus of your teams. It’s a short 1-1 meeting, held perhaps once a quarter, between the head of an organisation and each person in that organisation.

If you have a larger organisation, there are other ways to get skip-level time. Like holding lunches with whole teams a couple of times a quarter for each team. However, people act differently in group scenarios. It is a good opportunity to get a sense for where the team believed their focus needed to be. Skip-level lunches provide familiarity, which in turn generates more willingness for people to come to you.

At this level, you’re constantly making tradeoffs between investing in expensive engagements, such as 1-1s, or casual engagements that are more efficient but provide less detailed information.

Manager Accountability

There is one universal goal for these relationship: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team. Sometimes managers make your life easier by hiding problems and telling you what you want to hear, until months later you see things failing apart and wonder where you went wrong. You have to hold managers accountable. The manager ultimately needs to take responsibility for pulling the team out of problematic situations (unstable product roadmap, errand tech lead, full-time firefighting mode). The manager is accountable for the health and productivity of the team. When the product organisation is constantly changing goals, the manager should identify that the changes are causing problems on the team, and work with product to explain the problem and refocus on what’s important. If the team can’t do anything but fight fires, the manager should put together a plan for tackling causes of the fires, and if necessary bring requests for hiring more people or adding more people to the team so that they can get the situation under control. You’ll need to help your managers, sometimes they won’t have the energy to push back against product and they’ll need your support.

The People Pleaser
The people pleaser has deep aversion to ever directly making people he cares about unhappy. If you’re in the group that he cares, he’ll always say yes. People pleasers often burn themselves out. The therapist people pleaser can inspire huge loyalty, but unfortunately this can mean he amplifies drama and negativity, and disappoints his team by making promises that he cannot possibly keep. There is the external pleaser, the one that wants to make her boss and her external team partners happy, and is terrified of revealing problems on her team.

If it happens you end up managing somebody in this situation, you can work on help the person feel safer saying no and externalising more decisions so he doesn’t take failure personally. Providing strong partners who can take on the task of determining the work roadmap. Creating better processes for getting work scheduled, having a structure that specifies the requirements for getting promotions or accessing other opportunities, the people pleaser can rightly point to the process as something outside of her control. One of the best things you can do is show the person that he’s exhibiting the behaviour, and highlight the downsides.

Managing New Managers

First-time managers need a lot of coaching, it will be an up-front cost that pays long-term dividends for your organisation. No book or training can replace you spending some time asking your new manager how her 1-1s are going.

When people start quitting because their manager hasn’t give them a career path or isn’t inspiring them, it’s the ultimately your responsibility. Use skip-level meeting to help out detect areas where you need to support your new manager fully. A new manager who is working all the time is probably failing to hand off her old responsibilities to other people on her team. Make it clear that you expect the new manager to hand off some of her old work, and help her identify opportunities to do so.

Managers who neglect the job are bad, but managers that take to the job with gusto because they believe it’s the key to realising authority are worse. A skip-level meeting will reveal their frustration that they have no ability to make decisions themselves. If your new manager is skipping your 1-1s or evading questions about what the team is working on, you may have a control freak on your hands.

The manager you’re training should be ultimately making your job easier. Clearly set the expectations up front that you’ll hold her accountable for the team, and help her build the skills to achieve this. If they truly don’t have the willingness to learn and the aptitude to become solid managers, they’re a big problem. Making the wrong person a manager is a mistake, but keeping her in that position once you’ve realise she’s wrong for it is a critical error.

Managing experienced managers

Management tends to be a very culture-specific task in a company, if you either work as a manager or hire a manager for a company that’s not a good culture fit, you’ll have problems.

First challenge is making sure this person fits in with the culture of your team. Often we overvalue expertise in product areas and allow it to blind us to cultural and process fit with our companies and teams.

You need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge.

Collaborate on areas of difference, allow him to teach you things, and take an active role in the process.

Hiring Managers

Make sure that the person has the skills you need, then make sure that she’s a culture match for your organisation. You can verify the latter 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 role-play difficult situations, like dealing with an employee who is underperforming, or delivering a negative performance review. Ask about her management philosophy. If she doesn’t have one at all, that might be a red flag. What’s the role for a manager? How does she stay hands-on, how does she delegate? Speaking skills are useful for certain types of leadership but not all. Give her an abbreviated version of your standard technical interview.

To check for cultural fit, you need first to understand the values of the company around you. If you value servant-leadership and you hire a manager who wants to dictate exact marching orders to the team, there will be a bad fit. Similarly, if you value collaboration and hire a manager who thinks that the loudest voice in any conversation should win, you will also have problems. Managers shape their teams to their culture. If you hire a manager who doesn’t fit culturally with the team she’s managing, the manager will fail and you’ll have to fire her, or most of the team will quit and then you may still have to fire her. Most new hires act in self-interest until they get to know their colleagues, and then they move into group interest.

Critical elements to hiring a new managers: the reference check. Ask the references to describe the ways the person succeeds as well as the ways she fails. Ask them if they would work with or for this person again.

Debugging dysfunctional organisations

The best engineering managers are often great debuggers. They are relentless in their pursuit of the “why”.

• Have a hypothesis. You need a reasonable hypothesis that explains how the system got into the failed state.
• Check the data. Look at the team chats and emails, look at the tickets, look at the repository code reviews and check-ins. What do you see? Look at their calendars.
• Observe the team. Sit in their meetings. Boring meeting are a sign. They may be a sign of inefficient planning on the part of the organisers. Good meetings have heavy discussion element, where opinions and ideas are drawn out of the team. Be aware, the act of observing changes the outcome, or rather, causes an outcome to happen. Your presence might provoke hiding the problem you’re trying to find.
• Ask questions. Ask the team what their goals are. If they don’t understand the goals of their work, their leaders aren’t doing a good job engaging the team in the purpose of the work.
• Check the team dynamics. Very professional groups tend to have a degree of personal connection between the members. A bunch of people who never talk to each other and are always working on independent projects are not really working as a team.
• Jump into help. It’s OK to jump in and help debug team issues as you see them, particularly when the manager in question is struggling. It can be an opportunity to teach the manager and help him grow.
• Be curious. We get better at debugging by doing it often. We become better leaders by pushing ourselves and our management teams to really get into the bottom of the organisational issues.

Setting expectations and delivering on schedule

You must always be aggressive about sharing estimates and updates to estimates, even when people don’t ask. You must be aggressive about getting estimates.

Estimates are often useful even if they aren’t perfectly accurate because they help escalate complexity to the rest of the team. Not every project necessarily has requirements that change frequently, and it’s possible to do up-front work to drastically reduce the unknowns that make software estimation difficult. Business want to plan and get ideas of cost for effort. Teaching your teams how to hone their instincts about complexity and opportunity is worthy goal.

Don’t be afraid to cut scope toward the end of the project in order to make important deadlines.

Challenging Situations: Roadmap uncertainty
There are a few strategies about building a roadmap:
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 e some of the results, even if you don’t necessarily complete the grand vision. Everything must be repeatedly re-examined with an eye toward what’s the most valuable right now.

Don’t overpromise a future of technical projects. This kind of thinking will get hopes up and then disappoint.

Dedicate 20% of your team’s schedule to “sustaining engineering”. Refactoring, bugs, improving engineering processes, doing minor cleanups, and providing support.

Understand how important engineering projects really are.

Treat big technical projects the same way as product initiatives. Gather data to support yourself, and talk about what will be possible when the work is done. 

Teams may even be disbanded or moved around in ways you don’t understand or agree with. Push for engineering involvement in the early planning for the new work so that people can get excited about the projects they are moving on to. 

Staying Technically Relevant

• Oversee technical investment. You’re accountable for making sure the team is placing its technical best in the right places. You can see where the ares of greatest need or opportunity lie.
• Ask informed questions. Having accountability doesn’t mean that you personally do the research to find potential investments. You guide these investments by asking questions. You need to know enough about the work to sniff our misguided efforts and evaluate proposed investments.
• Analyse and explain engineering and business tradeoffs. Understanding the business and customer goals, you offer guidance as to which technical projects can achieve those goals within reasonable time frames.
• Make specific requests. You still need to have enough understanding of the technology in your organisation to make specific requests without distracting the senior engineers with questions. Managers who don’t stay technical enough relay these questions on the team, and then relay the team’s response back up to management. This is not value-add role.
• Use your experience as a gut check. Rely on your instincts to guide where you spend your time and attention. So, how should you invest your time to stay technically relevant?
  • Read code. Looking over code reviews and pull requests can give you insight into changes that are happening.
  • Pick an unknown area, and ask an engineer to explain it to you. Have him pair with you on a small change.
  • Attend postmortems. In times of failure you can most clearly see where problems have built up.
  • Keep up with industry trends in software development process. Make time to learn about how other teams deliver software.
  • Foster a network of technical people outside your company.
  • Never stop learning.

The Big Leagues

Your first job is to be a leader. The company looks to you for guidance on what to do, where to go, how to act, how to think, and what to value. You help set the tone for interactions. You’re capable of making hard decisions without perfect information and willing to face the consequences of those decisions. You know how to plan for the months and years ahead. You understand organisational structure and how it impacts the work of teams. You can play politics in a productive way, in order to move the organisation and the business forward. You work well with your peers outside of engineering. You understand how to disagree with a decision and commit to deliver on it. You know how to hold individuals and organisations accountable for their output.

The book High Output Management, breaks down management tasks into four categories:

• Information gathering or information sharing: synthesising large quantities of information quickly, sharing information with 3rd parties in a way they would understand.
• Nudging: Reminding people of their commitments by asking questions instead of giving orders.
• Decision making: Taking conflicting perspectives and incomplete information and setting direction.
• Role modelling: Showing people what the values of the company are. Showing up for your own commitments. Setting the best example for the team even when you don’t feel like it.

My job wasn’t to be the smartest person in the room. It wasn’t to be “right”, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way.

What’s a VP of Engineering?

VP role has one obvious difference from the CTO role. The VP is usually at the top of the management career for engineers.

This role means that the person has a solid handle on processes and details. This person is capable of dropping into the details and making things happen at a low level. The VP is usually the one pushing the execution of ideas, while the CTO focuses on larger strategy and the position of technology within the company.

She aligns the development roadmap to the hiring plan, planning out how teams need to evolve.

The job for an VP of Engineering is both a big one and a detail-oriented one. This position must be able to gain people’s trust and show wisdom in management and leadership. Most engineers are reluctant to trust people without technical credibility.

The VP of Engineering have some stake in organisational strategy, she sets goals to achieve business deliverables, closely aligned with the product team. She should have a strong business and product instinct and a track record of getting teams to deliver big projects, including the ability to negotiate deliverables.

They want their teams to be happy, but it’s important to tie that happiness to a sense of accomplishment. They cultivate a healthy and collaborative culture.

What’s a CTO

A CTO is not an engineering role. CTO is not at the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers. It’s not a role most people who love coding, architecture, and deep technical design would enjoy doing. It follows that the tCTO is not necessarily the best engineer in the company.

The CTO should be a strategic technical executive the company needs in its current stage of evolution.

A CTO must care about and understand the business and she should be able to shape business strategy through the lens of technology. She is an executive first, a technologist second. The CTO may identify areas where technology can be used to create new or bigger lines of business.

Strong CTOs also have significant management responsibility and influence. The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

CTOs that don’t have management oversight over teams, technology becomes an execution arm and they cannot have much strategic influence. You can’t give up the responsibility of management without giving up the power that comes with it.

If you give up management, you’re giving up the most important power you ever had over the business strategy, and you effectively have nothing but your organisational goodwill and your own two hands.

Being a CTO it’s a business strategy job first and foremost. It’s also a management job. If you don’t care about the business your company is running, then the CTO is not the job for you.

Changing priorities

Priority changes from senior management can sometimes happen without warning. When leaders see an opportunity or feel that the priorities of the organisation need to change, they often expect the change to happen immediately. This rarely happens. You must first go though the list of things in flight and kill or postpone work in order to make room for new priorities. You need to do that, if it’s truly urgent. Not focusing on the right priority it’s a sign that you and the CEO have a misaligned understanding of reality, and you need to get on the same page.

The more senior the management and leadership position you take in the company, the more the job becomes making sure the organisation moves in the direction it needs to move in, and that includes changing direction when needed. You do this by clearly communicating the direction to your teams and making sure they understand it and are taking the necessary steps to change course. Most people need to hear something at least three times before it really sinks in. The larger the organisation, the harder it’ll be to change priorities quickly. Keep the CEO informed about what’s happening and why. Do your best to show that you understand his priorities and tell him about the concrete steps you’re taking to meet those priorities.

Setting the strategy

Strategy as a critical element, setting strategy looks like

• Do a lot of research. The technology we had currently built, the pain points. Where the expected growth will come from the future. What are the scaling challenges right now, and where they might be in the future. What are the current productivity bottlenecks.
• Combine your research and your ideas. Draw out the systems in place at your company, slice and dice the systems and teams across various common attributes. Get insights on the way data flows and changes, and possible axes for evolution.
• Draft a strategy. Actionable ideas to improve operational efficiency, expand features and grow the business. Consider the structure of the business, the needs of the customer and possible future evolutions. Develop a technology strategy that supports these factors into the future.
• Consider your board’s communication style.
  • In an underdeveloped strategic plan, the system and architectural details offer very few forward-thinking ideas beyond the next 6 to 12 months. It’s not uncommon for company boards to read through the slide deck before a meeting, so that the meetings can be focused more on the details on presentations.
  • A good technology strategy means good technology architecture, team structure, underpinnings of the business and the directions in which it was header. Potential futures of the business. Anticipates and enables future growth.

Challenging Bad Situations: Delivering Bad News
You’ll need to excel at communicating sensitive information to large groups
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. Your team deserves to hear the message coming from your mouth directly. The second-worst way to deliver a message is with all them in a room at once.

Do talk to individuals as much as possible. Try your best to talk to people individually about the news.

Don’t force yourself to deliver a message you can’t stand behind. You might need to have someone else help you deliver it.

Do be honest about the likely outcomes. Being forthright with people will help them trust you and tolerate unhappy news well.

Do think about how you would like to be told.

I Have A Nontechnical Boss
Reporting to a nontechnical manager can be a total culture clash.
Don’t hide information behind jargon, and be careful with details

Expect that you will need to run your 1-1s with your new boss, so come prepared with a list of topics.

Try to bring solutions, not problems to be solved. Don’t shy away from delivering bad news.

Ask for advice. Nothing shows respect like asking for someone’s advice.

Don’t be afraid to repeat yourself.

Be supportive. Show that you are there to support.

Actively look for coaching and skill development in other places. Get a coach, ask for training, and create a peer group outside of the company.

Senior Peers in Other Functions

Senior leaders must actively practice first-team focus. They should dedicate first and foremost to the business and its success, and secondly to the success of their departments. Having few to no peers on your first team who are fellow engineers can feel very isolating.

You let them own their ideas, and they let you own yours. If you disagree, try to stay out of it, always choose to discuss with kindness. The place for disagreement is either one-on-ones or in your leadership team meetings. Expect to defend your own technical decisions and roadmap in this settings. You have to put aside the idea that they’re acting in irrational and self-interested ways when they disagree with you or do things you don’t like.

Establishing this fundamental trust is really difficult. A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.

Your peers who are not analytically driven are not stupid. Throwing out jargon to people make us look stupid to them. Disagreements that happen in the context of leadership team don’t exist to the wider team. Once a decision is made, we commit to that decision.

The Echo

You’ll be watched more closely than you’ve ever been watched in your life. Your first team is compromised of your peers at the leadership/executive level, and your reporting structure has now become your second team. Socialising heavily with your team outside working hours is a thing of the past.

If you don’t detach, you’re likely to be accused of playing favourites. In fact, you probably will play favourites if you maintain very strong social ties with people who report up to you on the team. You need to detach because you need to learn how to lead effectively, with a throwaway comment, you can cause people to change their whole focus. Your reports are going to have a hard time distinguishing between their buddy and their boss.

Your mere presence will change the tone and structure of meetings you attend. As you choose which behaviours to model in front of the team, they will learn those behaviours and copy them.

You’re going to be part of hard decisions. It won’t be appropriate to discuss these decisions with other people at the company. It is tempting to rant to those you consider friends and your reporting team, but this is a bad idea. As their leader, you can easily undermine their confidence by sharing worries that they can’t do anything to mitigate.

Care more about people as individuals. Take time to get to know as many people as you can as humans. It cab be easy to start to dehumanise people and treat them like cogs. People can tell when their leader stop caring about the individuals. Nurture that kind of connection reinforce that you do care.

Ruling with Fear, Guiding with Trust

• Practice relatedness. Getting to know your team as people or let them know you as a person. If you want a team that feels comfortable taking risks and making mistakes, one of the core requirements is a sense of belonging and safety. This means you need to take little time to small talk.
• Apologise. When you screw up, apologise. You’re showing the team that apologising doesn’t make you weaker, it makes the whole team stronger.
• Get curious. When you disagree with something, stop to ask why. Attacking something we disagree with makes that harder. Learn how to turn that disagreement into honest questioning.
• 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?

True North

The role played by a senior leader of a functional area (CTO, CFO, etc.), sets the baseline of what excellence looks like in this function (“True North”).

A way of exploring the True North in technology is by looking through the lenses of risk analysis. Things like:

• Having a single point of failure.
• Having known bugs and issues.
• Being unable to tolerate high load.
• Losing data.
• Putting out code that is undertested.
• Having slow performance.

True North helps us understand that all these issues must be carefully considered. Just because these rules have exceptions doesn’t mean we forget that they exist. True North is the guiding instinct that we as leaders have developed over time. You must spend enough time in your career to hone these instincts in order to be comfortable making fast judgment calls. At this level your coaching and mentoring are likely to come from people outside of your company. Do you know other senior managers at companies in your area? Do you admire any technology senior managers? What is it about them that you admire? Are you behaving like a role model for your team?

Bootstrapping Culture

As part of your role of senior engineering leader, part of your job is to set the culture of your function. Neglecting the team culture is a sure-fire way to make your job harder.

In startup culture, the ideas of “structure” and “process” are seen as pointless at best and harmful at worst. Startups believe that structure is the reason large companies move slowly.

Instead of talking about structure, is better to talk about learning. Instead of talking about process, it’s better to talk about transparency. We don’t setup systems because structure and process have inherent value. We do it because we ant to learn from our successes and our mistakes, and to share those successes and encode the lessons so we learn from failures in a transparent way.

Consider not only what you care about, but also how you can scale that knowledge and effort effectively.

The important thing for leaders to be willing to do in those early days is to pic a strategy and run with it. You don’t need to find the perfect solution; you need to find something that will get your through to the next milestone.

Sometimes companies decide to limit the decisions themselves, as in organisation that forgoes titles. Deciding not to decide right now is a popular option for new companies, because it really doesn’t matter at the scale of a few people.

Pretending to lack structure tends to create hidden power structures. In The Tyranny of Structurelessness Jo Freeman describes a set of circumstances in which the unstructured group can work:

• It is task oriented. It is the task that basically structures the group.
• It is relatively small and homogeneous. Homogeneity is necessary to insure that participants have a “common language” for interaction.
• There is high degree of communication. Information must be passed on to everyone.
• There is a low degree of skill specialisation. Everything must be able to be done by more than one person. People become interchangeable parts.

When work is done to satisfy an immediate task, in a unified code base worked on by a team of interchangeables, the result is not usually a larger thoughtful structure, but a tweak here, a hack there. We usually end up refactoring the code to make it scalable, this involves identifying and explicitly drawing out structure in order to make code base easier to read and work in.

That is the value of structure. Structure is how we scale, diversify, and take on more complex long-term tasks. In the same way that strong technical system designers are capable of identifying and shaping underlying system structures, strong leaders are capable of identifying and shaping underlying team structures and dynamics, and doing so in a way that supports the long-term goals.

The earliest startup is like a driving car. As you grow, you graduate to a commercial flight. So you need to consider your movements more carefully. Finally you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you are capable of going very far and taking tons of people along the ride.

Assessing Your Role

• People. Leaders who want a high degree of control over their organisation tend to need more structure in place to make sure their wishes are enacted.
• Age. The longer a company is around, the more habits become entrenched. The longer the company has been around, the more likely it is to continue to survive.
• Size of existing infrastructure. If you have few established business rules and little code or physical infrastructure, there is less need for structure. The more existing business rules and infrastructure you have, the more you’ll need clarity on how to handle them.
• Risk tolerance. Your structures and process should reflect this.

When failures occur, examine all aspects of reality that are contributing to those failures. The patterns you see are opportunities to evolve your structure, either by creating more or different structure or removing it. Using failure to guide evolution lets you apply structure at the right level. Success is often a poor teacher. If you want to learn from success, make sure you can identify the actually improvement you’re seeking.

When every new hire slows down the team down for months because there is no onboarding process, that is a failure due to lack of structure. When people regularly leave the company because they have no path to advancement or career growth, that is a failure due to lack of structure. The third time you have a production outage because someone logged directly into the database and accidentally dropped a critical table, that is a failure due to lack of structure. Better to talk about learning and transparency rather than using the word structure.

Creating Your Culture

Culture is how the things get done, without people having to think about it.

Consciously guiding the culture of your team is part of a leader’s job.

Culture is the generally unspoken shared rules of a community. Culture doesn’t mean that every single person holds exactly the same values, but it tends to guide a general overlap.

In complex environments where the needs of the group must override the needs of the individual, cultural values are the glue that enables us to work as a team.

Applying Core Values

Define your culture. If you have a set of company values, map those values onto your team.

Reinforce culture by rewarding people for exhibiting its values in positive ways. The stories that we tell as a community bond us together.

One of the most important uses of performance reviews is to evaluate the alignment between team members’ values and the company’s values.

Learn to spot people who have value conflicts with the company or team. Using the core values to coach people in areas where they are misaligned can help you articulate what otherwise may feel like just ambiguous friction.

Finally, use this as part of your interview process. Look out explicitly for places where the interviewee seems to match or collide with these values. Cultural fit is not about hiring friends. Cultural fit as determined by friendship tests is almost certain to be discriminatory in some way.

Write the values down if they aren’t already written, and try to be explicit. Use this explicit list to evaluate candidates, praise team members, and inform your performance review process.

Creating Cultural Policy

Getting started on these documents from scratch is hard. Fortunately there are fewer and fewer documents that you need to start from scratch to create, as more people are sharing publicly their policies and processes. Be mindful however, what works for one company, will not always translate well to another company, even if the companies have a lot of things in common.

Writing A Career Ladder

• Solicit participation from your team. Enlist the support for senior managers and engineers on the team to provide feedback and details.
• Look for examples. Examples of ladders from friends at other companies to help provide some ideas for the details.
• Be detailed. You want something that is inspirational and descriptive but that matches your company.
• Use both long-form descriptions and summaries.
• Consider how the ladder relates to salary.
• Provide many early opportunities for advancement. You may want to be able to promote someone every year for the first two to three years of her career. Create several levels that encompass the role of software engineer.
• Use narrow salary bands for early-career stages. Lots of levels and narrow salary bands mean that you can promote people quickly.
• Use wide salary bands when and where you have fewer levels. You want those salary bands to overlap. Software engineer band may go $50-100K, and a senior software engineer band might go $80-150K. This is meant to retain talent who are performing well at their current levels. This also also allows you to hire people who are on the fence into the lower level with the expectation that they will be promoted quickly.
• Consider your breakpoint levels. Lack of advancement means that the person has not achieved the maturity of independence needed to remain at the company. For many companies, it’s somewhere around senior engineer. Someone who’s made it this far is a solid team member. You may even want to use it as a the point at which your ladder levels get harder to achieve.
• Recognise achievement. Celebrate and share keystone promotions.
• Split management and technical tracks. You do not want people to feel that the only path to advancement is by managing people, because not everyone is suited to that role.
• Consider making people management skills a mid-career requirement. Consider making leadership experience (tech lead) a requirement for promotion to senior individual contribution levels.
• Years of experience. Distinguish the keystone levels by an expectation of maturity increase, and these tend to correspond with years of experience.
• Don’t be afraid to evolve over time. A ladder is a living document that will need to evolve as your company grows.

Cross-Functional Teams

Cross-functional product development is putting everyone who is needed to make a project successful together in one group.

We are acknowledging that the most important communication is that which leads to effective product development and iteration. It will probably produce systems that have some inefficiencies compared to companies that have a more engineering-centered team structure. You’ll have to decide where you’re willing to take some system design hits in order to most effectively create products.

Structuring Cross-Functional Teams

Engineers are managed by engineering managers that report to the CTO. Product managers report to the head of product. The determination of who was working on what is done largely by the team itself.

Someone in engineering needs to oversee critical core systems, and you probably need a few specialists. These functions can be kept in a small infrastructure organisation that is not generally assigned to product development. Engineers assigned to product teams still need some time to account for engineering-specific tasks like on-call, interviewing, and technical debt (advise to reserve 20% of the time for these tasks).

The infrastructure team supports both fundamental systems as well as large frameworks and technologies that will be used by many teams across the company.

In technology-focused structures, the focus is on being the best engineer. In product-focused structures, the engineers who have the best product sense will start to emerge as the leaders of the team.

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.

Developing Engineering Process

Without any process, your teams will struggle to scale. With the wrong process, they will be slowed down.

Think of process as risk management.

This has two important implications. The first is that you should not put a complicated process on any activity where you want people to move quickly or that the risks themselves are obvious to the whole team.

The second implication is that you need to be on the lookout for places where there is hidden risk, and draw those hidden risks out into the open. Processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socialising change or risk to the team as a whole.

Practical Advice: Depersonalise Decision Making

CODE REVIEW

You want the process to be straightforward and efficient:

• Be clear about code review expectations. Code review is largely a socialisation exercise, so that multiple team members have seen and are aware of the changed code.
• Use a linter for style issues.
• Keep an eye on the review backlog. Limit how many outstanding review requests a person can have assigned to him.

THE OUTAGE POSTMORTEM

• Resist the urge to point fingers and blame.
• Look at the circumstances around the incident and understand the context of the events. Understand and identify the factors that contributed to this incident.
• Be realistic about which takeaways are important and which are worth dropping. Pick the one or two that are truly high-risk and highly likely to cause future problems, and acknowledge the ones that you are going to let go for now.

ARCHITECTURE REVIEW

The goal of architecture review is to help socialise big changes to the appropriate group, and to make the risks for those changes clear.

• How many people on the team are comfortable using this new system/writing this new language?
• Do you have production standards in place for this new thing?
• What is the process for rolling this out and training people to use it?
• Are there new operational considerations for using this?

Some guidelines:

• Be specific about the kinds of changes that need architecture review. Usually these include new languages, new frameworks, new storage systems, and new developer tooling.
• The value of architecture review is in preparing for the review. It forces people to think about why they want to make these changes. It make people aware of the risks that they may not have considered.
• Choose the review board wisely. The scope of the deciding group is best kept to the people who will be closely impacted by the decision.