The Manager’s Path – My Reading Notes

These are my notes from the book: The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

These notes don’t cover everything in the book, only the parts that seemed relevant to me, but they can be a reference for someone who also read the book and wanted to remember key points quickly.

1. Management 101

What to expect from a manager

Think of a good manager you had. Which qualities did they have.

Bening neglect until you ask for help is a decent option when you consider alternatives like manager who ignores you, doesn’t give feedback just to tell you don’t meet expectations. Or who micromanages every step. Or who yells at you.

But there are better alternatives too. There could be someone who cares about your growth.

One-on-one meetings

Two main purposes:

• building human connection
  • letting the manager a bit into your life makes it easier to understand the context when something bad happens in your private life
• regular opportunity to speak privately
  • it shouldn’t be status meeting
  • it should be regular so that reports can rely on it.
  • the reports can and should control the agenda

Feedback and workplace guidance

The only thing worse than getting behavioral feedback is not getting it at all, or getting it only during your performance review.

The sooner you know about your bad habits, the easier they are to correct.
This also goes for getting praise. A great manager will notice some of the little things you do daily and recognize you for them.

Keep track of this feedback, good and bad, and use when you write your self review.

Praising in public is considered best practice because it reinforces good behavior.

There other types of feedback e.g. about presentation, design doc. Asking manager for opinion makes them feel good and helpful.

Manager also helps to clarify your role at the company.

If you don’t ask your manager about promotion don’t expect to just give you one magically.

It’s great when managers can identify and assign stretch projects that will help you grow and learn new things.

Good managers will also help you understand there value of the work you do when it’s not fun and glamorous.

As you become more senior, expect the feedback to be more high level e.g. about the team or strategy.

Training and career growth

A manager should help you find resources for career growth e.g. conferences or classes to attend, helping you get a book you need, pointing you to the expert.

Managers also contribute to your career via promotions and compensation. They can help you preprare.

Realize that stretching yourself is about more than just learning new technologies: great CTOs have strong communication skills, project management skills, and product sense.

How to be managed

Spend time thinking about what you want

You’ll probably go through periods of career uncertainty. It’s pretty universal truth that once you get the job you wanted, the enjoyment eventually fades and you find yourself looking for something else.
You think you want to be a manager, only to discover that the job is hard and not rewarding in the ways you expected

Use your manager to discover what’s possible where you are, but look to understand yourself in order to figure out where you want to go next.

You are responsible for yourself

Knowing yourself is a step one. Step two is going after what you want.

Bring agendas to your 1-1s when you have things you need to talk about. When you want to work on projects, ask. Advocate for yourself. When your manager isn’t helpful, look for other places to get help.

You will not get everything you ask for, and asking is not usually a fun or comfortable experience.

Give your manager a break

The job of the manager is to do the best thing for the company and the team. It is not to do whatever it takes to make you happy all the time.

Your relationship with your manager is like any other close interpersonal relationships. The only person you can change is yourself.

You should absolutely provide feedback to your manager, but understand that they may not want to listen or change.

As you become more senior, your manager expects you to bring solutions, not problems. Try not to make every 1-1 about how you need something, how something is wrong.

Asking for advice is always a good way to show respect and trust.

Choose your managers wisely

Managers can have huge impact on your career. It can be another thing to look at before accepting the offer.

Strong managers know how to play the game at their company, how to get promoted, they can get you feedback and attention from import people, they can have strong networks which can get you a job after you stop working for them.

Assesing your own experience

• have you had a good manager? What did they do that you found valuable?
• how often do you meet 1-1 with your manager? Do you bring your own topics? If it’s a status meeting can you do it differently?
• do you feel you can tell your manager when you have a major life event? Do you feel that your manager knows something about you personally?
• has your manager delivered good feedback to you? Bad feedback? Any feedback at all?
• has your manager helped you set any work-related goals for this year?

2. Mentoring

The importance of mentoring to junior team members

It could be a junior who still remembers the onboarding process or a senior who gives technical guidance too.

Being a mentor

Mentoring an intern

Often it’s a first opportunity to practice being responsible for others while being safe to learn (you won’t be fired because you were a bad mentor).

Even if you don’t hire the intern they will tell their friends about the place the worked at.

It’s important to have a specific project for the intern. Sit down with them and break it down.

Listen carefully
Listening is the first and most basic skill of managing people. It’s a precursor to empathy.
Monitor yourself while listening: are you spending all the time thinking what to say next, thinking about your own work, ignoring the words?

Body language also matters.

Be prepared to say anything complex a few times in different words. If you feel you don’t understand something, repeat the question in different words and let them correct you.

Interns may be afraid to ask questions. It’s good trying to get them out from them.

Clearly communicate
If the intern ask too much it gives you an opportunity to work on another management skill: communicating what needs to happen.

Calibrate your response
You may need to adjust to the mentee’s response. They may meet your expectations or the opposite. They may be super fast but low quality or super slow and overly perfect.

Mentoring a summer intern

• prepare for his arrival
  • a desk, access, etc
• have a project
  • specific but not urgent.
  • something that the team cares about, but not critical so that it’s ok if the intern does it
  • multiply time by 2x. If the internship takes 10 weeks, plan something that a new hire would do in 5
• let them show what they did
  • it makes it clear that you expect them to finish the work
  • it makes them feel like the work they did mattered

Mentoring a new hire

Your goal is to help the person to adjust to life in company, build your and their network, telling about processes e.g. how does work get done, and what the rules: spoken or unspoken.

Technical or career mentoring

Set the goals and expectations.
You don’t have to say yes to mentoring if you don’t feel you can’t do it.

Good manager, bad manager: The alpha geek

Alpha geek is the smartest engineer in the team who knows everything, participates in every good decision, bad doesn’t in bad ones (“I told you it would fail”). They claim they build culture based on intelligence, but in fact it’s built on fear. They think everyone should know they know, and point out the ignorance if you don’t.

They are dangerous to be promoted to managers. Mentoring can help them get out of this view. But if they are unwilling to change then it can be dangerous too.

Tips for the manager of a mentor.

What you measure, you improve. Figure out what you’re hoping to achieve by creating the relationship, why you are setting it up in the first place.

It could be getting up to speed and be productive. If the company is setting up the mentoring programs outside of new hires and interns, try to make sure that there is some guidance and structure to the program before you push people into it.

Recognize that this is an additional responsibility for the mentor. It’s often viewed as low-status emotional labor (skill that addresses the emotional needs of people and teams. It’s hard to quantitatively measure so it’s often dismissed as less important). Mentor should be treated as a first-class citizen with other responsibilities the person might have. Plan for it and provide the mentor time to do the job right.

Mentoring provides returns in form of better employee networks, faster onboarding, and higher internship conversion.

Unless the purpose of the mentoring is driven by diversity, give people the best mentor for their situation.

Use this opportunity to reward and train future leaders on your team.

Hiring interns to grow your hiring pool:

• don’t hire interns who are not going to graduate in the year after their internship
• hiring interns is relatively easy compared to hiring full-time graduates

Key takeaways for the mentor

• be curious and open-minded
  • you have the opportunity to see the world through fresh eyes, what about your organization is not so obvious to a new person, or things you thought you understood but cannot explain clarly
  • it’s hard to see patterns when the only data points you have a are your own experiences
• listen and speak their language
• make connection

Assesing your own experiences

• does your company have an internship program? If so, can you volunteer to mentor an intern
• How does your company think about onboarding? Do you assign mentors to new hires? If not, can you propose to your manager that you try doing this, and volunteer to mentor someone?
• Have you ever had a great mentor? What did that person do that made you think he or she was great? How did the mentor help you learn – what did he or she teach you?
• Have you ever had a mentoring relationship that didn’t work out? Why didn’t it work out? What lessons about that experience can you apply to avoid similar failures going forward?

3. Tech lead

It may not be a point on a ladder but a set of responsibilities of the senior engineer. It doesn’t have to be the most experienced engineer.

You continue writing code, but with the added responsibility of representing the group to management, vetting plans for feature delivery, and dealing with a lot of the details of the project management process.
You focus on the whole team’s productivity and strive to increase the impact of the team’s work product.

You have to learn how to influence without authority. You can sell the idea by focusing on the different impact this would have on individual team members.

All great tech leads know this one weird trick

The biggest challenge of a tech lead is stepping away from writing code. You need to learn the act of balancing and scheduling. Sometimes you’re on the maker’s schedule, sometimes on the manager’s schedule. The worst scheduling mistake is allowing yourself to get pulled randomly into meetings.

Part of your leadership is helping the other stakeholders respect the team’s focus and set up meeting calendars that are not overwhelming for individua contributors.

Being a tech lead 101

The tech lead serves multiple roles:

• System architect and business analyst
  • you identify the systems that need to change and the critical features that need to be built
  • you need to have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software
  • you also need to understand business requirements and translate them into software
• Project planner
  • you break down work into deliverables
  • you need input from experts on your team
  • you want to start identifying priorities
• Software developer and team leader
  • you should focus on delegating and avoid going down the rabbit hole

When you become a leader you realize that with recognition comes burden.

Managing projects

Even in agile some degree of project management is needed. Especially for projects that involve words like infrastructure, platform or system.

The act of planning and thinking of things possible to predict and dependencies is more important than the plan itself.

It is good idea to explain basic concepts and ideas to other people. Not everyone is able to read the code.

Managing a project

• Break down the work
  • you don’t have to do it by yourself.
  • whatever works for you. Spreadsheet, Gannt chart.
  • what can be done in parlalell, what need to be done in sequence
• Push through the details and the unknowns
  • the trick is to not stop when you feel stuck. You will always feel you don’t know something
• Run the project and adjust the plan as you go
  • having the milestones help you understand where you are
• Use the insights gained in the planning process to manage requirements changes
  • you learn a lot about additional unknowns from breaking the project down
• Revisit the details as you get close to completion
  • cut the work that falls below the “good enough” line.
  • make a launch plan, make a rollback plan.

As a manager you shouldn’t push people into management. There’s nothing wrong with staying deep in technology.
At some point, to progress in your career, you’ll probably need to do the lead job even if you’re interested in individual contributor path.
If you feel like there’s plenty to learn and you want to work individually on this project, don’t take the lead. If the project wouldn’t challenge you technically you can consider the lead role and learn new skills.

Decision point: Stay on the technical track or become a manager

The chapter describes differences between imagined and real work of engineer and a manager.

Good manager, bad manager: The process czar

The process czar believes that there is one true process that will solve all the team’s problems.
They can be valuable team members because they make sure no task is forgotten and that everything is wrapped up.
They tend to blame problems on a failure to follow the process, instead of acknowledging the need for flexibility and inevitability of unexpected changes.
Engineers who believe in the “right tool for the job” sometimes turn into process czar when they become tech leads.
The opposite of process czae is someone who understands that process must meet the needs of the team and the work. See original agile manifesto principles.
Be careful of relying on process to solve problems that are result of communication or leadership gaps.
Look for self-regulating processes. Instead of playing a cop, see if the the process can be improved or automation enabled.
An obsession with process can be related to a fear of failure and a desire to control things to prevent the unexpected.

How to be a great tech lead.

• Understand the architecture
• Be a team player
  • take the boring and annoying stuff. But not always. Take some fun tasks from time to time
• Lead technical decision
  • If you make them all, the team blames failure on you. If you don’t make any, the decision drags on forever
• Communicate
  • listen and read carefully
  • Represent the team in calls

Assesing your own experience

• Does your organization have tech leads? Is there is a written job description for this role? If so, what does it say? If not, how would you define the role in your organization? How would a tech lead define the role?
• If you are considering becoming a tech lead, are you ready to push yourself? Are you comfortable spending some of your time outside of the code? Do you feel like enough of an expert in your code base to successfully lead others as they work in it?
• Have you asked your manager what he or she expects from the tech lead?
• Who is the best tech lead you ever worked with? What are some things that person did that made him or her great?
• Have you worked with a frustrating tech lead? What did he or she do that frustrated you?

4. Managing people

Starting a new reporting relationship off right

Build trust and rapport

Some useful questions:

• how do you like to be praised? In public or in private?
• what is your preferred method of communication for serious feedback? Writing to digest it first or less formal verbal?
• what are you excited about at work?
• how do I know 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? (E.g. religious reasons)
• are there any manager behaviors that you know you hate? (E.g. skipping or rescheduling 1-1s, neglecting to give feedback, avoiding difficult conversations)
• 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?

For more ideas:
https://larahogan.me/blog/first-one-on-one-questions/

Create a 30/60/90-Day plan

It can help detect mishires. The senior the person the more they participate in creating the plan

Encourage participation by updating the new hore documentation

You don’t necessarily have to go with the through the documents but you can establish the process

Communicate your style and expectations

E.g. what you expect like reports every week. Or how long should they try to solve the problem before asking for help

Get feedback from your new hire

First 90 days they still have the fresh perspective

Communicating with your team

• have regular session.
  • “regular 1-1s are like going to a psychiatrist when you’re fine and discovering you have depression”
• scheduling 1-1s
  • the default should be weekly
  • respect the “maker schedule” to not break focus workflow
• adjusting 1-1s
  • how often do you interact with the person during the week
  • how much coaching does this person need?
  • how much does this person push information up to you
    • if they are not good at pushing information they may need more face time
  • how good is your relationship with this person?
    • don’t make the mistake of spending all the time with problematic people assuming those who are going smoothly don’t need it
  • how stable or unstable are things in the team or company
    • 1-1s is the place to answer any uncertainty

Different 1-1 styles

• To-do list meeting
  • make sure that the list you and the reports bring are meaningful for verbal discussion
  • it feels professional but also a bit cold
• The catch up
  • if left unchecked may turn into complaining session or a therapy
  • Empathetic leaders can sometimes allow themselves to get sucked into an unhealthy closeness with the reports. The problems in the workplace need to be either dealt with or put aside by mutual agreement
• The feedback meeting
  • quarterly is frequent enough
  • if you have an employee with performance issues, feedback meetings should happen more often. And if you’re thinking of firing someone document the feedback meetings
  • when someone needs immediate corrective feedback, don’t wait for the meeting. Same goes for praise
• The progress report
  • getting progress from people you already work with is a waste of time
• Getting to know you
  • show them that you care about them as individuals

Keep notes in a shares document with the manager as a note taker.

Good manager, Bad manager: Mircomanager, Delgator

Work with the person to determine which meetings you should attend and help understand which details to escalate to you.

The hardest thing about micromanagement is that sometimes you need it. Junior engineers thrive under detailed oversight because they want that specific direction.

When you strip creative and talented people of their autonomy, they lose motivation very quickly.

Delegation is not the same 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
  • if the team is making progress, systems are stable and product manager is happy doesn’t make sense to micromanage
  • if the team doesn’t have a plan, use the details you’d want to monitor to help them create one
• gather information from the systems before going to the people
  • the worst micromanagers are those who constantly ask for information they could easily get themselves
• adjust your focus depending on the stage of projects
  • at the beginning you may want to be involved to set the goals and system design
  • later focus more on the progress details
• establish standards for code and systems
• treat open sharing of information in a neutral or positive way
  • you don’t want people to take blame and hide information from you until it’s too late

Creating a culture of continuous feedback

• know you people
  • what are they strengths and weaknesses
  • at what level are they currently operating and where they might need to improve to get to the next level
• observe your people
  • if you spend most of your time trying to get people to correct weaknesses it feels more like continuous criticism.
  • Sometimes it helps to have a goal, try to regularly identify people who deserve the praise. Every week there should be at least one thing you can recognize
• provide lightweight, regular feedback
  • it’s good to start with positive feedback. People are more likely to listen when you need to give them critical feedback
• bonus: provide coaching
  • not everyone needs coaching so save your time

Performance reviews

• 360 review: from the manager, peers, people you work with (e.g. product manager) and a self review
• reward time spent by providing a chance to synthesize more information about the person.
• they help see some patterns and trends easy to overlook with the day-to-day continuous feedback
• they go wrong because:
  • people aren’t given time to prioritize working on them
  • people tend to remember and overemphasize things that happened most recently
  • people suffer from biases and may criticize some people for things they don’t notice in others

Writing and delivering a performance review

• give yourself enough time and start early
  • start reading collected reviews and make notes. Then give yourself some time and then try to write the summary.
• try to account for the whole year, not just past couple of months
  • it will be easier if you keep notes on what has happened with each person
  • the goal is to recognize not only accomplishments but also the growth and change
• use concrete examples, and excerpts from peer reviews
  • it helps to eliminate bias
• spend plenty of time on accomplishments and strengths
  • these may be used to determine when people should be promoted so do not ignore it
• when it comes to areas for improvement, keep it focused
  • common themes:
    • struggle with saying no to distractions and end up helping with other projects instead of finishing their own
    • do good work but are hard to work with, tending to be overly critical or rude in meetings, code reviews, and other collaborative activities
    • struggle to break their work up into intermediate deliverables, and don’t balance planning and design with getting things done
    • work well with other engineers but do not work well with other departments or teame
    • struggle to follow the accepted best practices of the team, cut corners, or do sloppy work
  • sometimes you may want to filter the feedback from multiple people. If only one mentions sloppy work it could be that the reviewer has higher standards
  • if there’s not much meaningful feedback for improvement the person may be ready for being promoted or given more challenging work.
  • If the person isn’t ready for promotion but does good job, indicate one or two skills needed to become qualified for promotion
  • if people are ok with where they are, the tech industry still changes so they may want to focus on new technical areas
• avoid big surprises
• schedule enough time to discuss the review
  • discussing the score (e.g. meets expectations, exceeds etc) is the toughest part.
  • People are uncomfortable to receive anything below top ratings
  • come preprared to dig into the reasons for this score including examples of how the person could achieve a higher score

The potential can be tied to the actions and value produced. If the person has a strong visual design sense but is struggling with the day to day code tickets may do better in UX. A great firefighter who hates planning may be better suited to an operations-focused team.

Cultivating careers

You’ll look at the people on your team a couple of times a year, consider their job level, and ask yourself, are any of these people close to the next level?

Some companies have policies that until certain level you can’t stay on one level more than X years. If you don’t progress you shouldn’t work here.

The evidence for promotion often takes the form of projects or features they’ve completed independently, participation in oncall rotations or other support, and engagement in team meetings and team planning.

As a manager you need to learn how to play the “promotion game”. The fact that you are the manager means you could have understood it.

• How are these decisions made?
• How early do you need to start preparing packets
• are there limits on the number of promotions that can happen in any given year?
  Try to be fairly transparent with your team, tell them what goes into the process to understand what they may need to change.

You should also prepare yourself to start identifying promotion-worthy projects and try to give those projects to people who are close to promotion.

The more senior the people, the fewer opportunities there are.

Many companies expect you to be acting at the next level before you get promoted to prevent “Peter principle“

Challenging situations: Firing underperformers

Usually a company will have you write a performance improvement plan. It’s often not expected to be completed, but rather a “generous way of giving some time to look for another job”.

One of the basic rules of management is the rule of no surprises, particularly negative ones. The ideal is that you know exactly what the job the person is supposed to be doing, and if they don’t, you can say “You aren’t doing X, Y, Z. Do more of these things”.

If you avoid tackling negative feedback until it builds to a boiling point, you’re going to be met by a pile of excuses.

• Some managers will ignore the excuses at their peril, and lose employee after employee to an unwelcoming team that fails to onboard, coach, and give clear goals to employees
• On the other hand, some managers will accept any excuse until problems can no longer be swept under the rug, and the team is furious at management’s inaction with regard to the lagging employee.

You’ll always need to have a record of negative feedback. Not only does this protect you legally but it helps you treat your employees fairly.

“coaching out.” Make the situation clear to him. You have told him repeatedly what the next level looks like, and he has not been able to show that he can work at that level, so you don’t think that your team is the right place for him to grow his career. You aren’t firing him, but you are telling him that he needs to move on if he wants to progress.

Assessing your own experience

• Have you set up regular 1-1s with your direct reports?
• When was the last time you talked to your reports about their career development? If it was more than three months ago, can you make sure to put this in your next 1-1s?
• Have you given feedback to your reports in the last week? When was the last time you handed out kudos in front of the team?
• When was the last time someone behaved in a way that needed correction?
• How long did it take you to give corrective feedback? Did you give the feedback in private, or did you do it in public?
• Have you ever been given a performance review that felt like a waste of time? What was it missing that could have made it more valuable?
• What was the most useful piece of performance feedback you ever got? How was it delivered to you?
• Do you know how the process of promoting people works in your company? If not, can you ask someone to walk you through it?

5. Managing a team

• less time writing code. Rather bug fixes and small nonblocking features.
• more than writing code, identifies bottlenecks in the process
• identifies the most high-value projects and keeps the team focused on them
• identifies the headcount needs
• manages team members with different skills that their own
• communicates clearly expectations to all team members
• acts as a leader for the technical roadmap – communicates timeline, scope, risks
• identifies strategic technical debt, do the costs/benefits analysis

Staying technical

• Even though you may stop writing code, your job will require that you guide technical decision making
• at this level 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
• as the manager of a single team, you’ll be called upon to help guide what is possible and impossible to do in your system

Debugging dysfunctional teams: the basics

• not shipping
  • e.g. infrequent releases hide the pain points like lack of tooling
  • maybe the team lacks the skill of breaking down bigger work
• people drama
  • e.g “the brilliant jerk” or the negative person, or gossiping and playing us-against-them
  • sometimes the negative person may not be aware of the impact they have on the team
• unhappiness due to overwork
  • if the overwork is due to instability of the production systems, it’s your job as a manager to slow down the product roadmap in order to focus on stability for a while
  • in case it’s due to time-critical release
    • first you should be playing cheerleader
    • second, do everything you can to learn from this crunch period and avoid it next time. Cut features, push back unrealistic deadlines
• collaboration problems
  • consider some bonding activities

Managing a former peer

• acknowledge the weirdness of the transition.
• you’re going to have to be a little bit vulnerable with them
• as his manager you may have the ability to override their decisions but use this power very cautiously. They are going to be very sensitive to the feeling thet you’ve been “rewarded” even if they didn’t want to become managers themselves
• you do less of previous work, some new work. It’s an opportunity to give new challenges to others

The shield

Sometimes it’s appropriate to let some stress through the team. The goal is to help them get context into what they are dealing with. Humans need context into why goals have been set.

If layoffs happen in one part of the company, and the team finds this out from someone else, the team may feel something bad is happening and no one wants to admit it. Communicate these events in a straightforward, low-emotion way to alleviate the gossip.

You may be a shield, but you’re not a parent.

How to drive good decisions

• create a data-driven team culture
  • you could enhance product data with team data like productivity, or quality.
• 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 and will help figure out which areas of technology have the greatest impact
• look into the future
  • getting sense where the product roadmap is going helps to guide technical roadmap
  • many technical projects are supported if they enable features more easily
• review the outcome of your decisions and projects
  • was it true that the team moved faster after you rewrote that system
• run retrospectives for the process and day-to-day

Good manager, bad manager: conflict avoider, conflict tamer

There is a such thing as artificial harmony. Democratic style may not work because instead of manager guiding the team, the team seems to guide itself.
Creating safe environment for disagreement to work itself out is better than pretending that all disagreement doesn’t exist.

The dos and dont’s of managing conflict

• don’t rely exlusively on consensus or voting
  • people don’t have equal knowledge, context, roles
• do set up clear processes to depersonalize 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
• do address issues without courting drama
  • the goal is to identify problems that are causing the team work less effectively together and resolve them, not to become the team’s therapist
  • key questions to ask: is this an ongoing problem, is this something you personally noticed, is this something many people on the team struggle with, is there a power dynamic or potential bias at play
• don’t take it out on other teams
• do remember to be kind
• don’t be afraid
• do get curious

Challenging situations: Team cohesion destroyers

• brilliant jerk
  • it’s difficult to fire because you’d have to explain letting go someone who produces good results
  • it makes sense to reverse the “criticize in private, praise in public”. But only if it hurts the team, not undermines you only
• noncommunicator
  • if necessary make it clear that they’re not meeting expectations for their work
  • they may not feel safe sharing their work in progress, and that fear often sets an example for the rest of the team
  • if possible, address the root cause of the hiding
• the employee who lacks respect
  • simply ask if they want to work with your team
  • if yes, say what you expect
  • if no, start the process of moving

Advanced project management

• agile helps with short term goals, but as a manager you have to use high-level planning
• you have 10 productive engineering weeks per engineer per quarter
  • if you consider vacations, onboarding, meetins
  • Q1 is usually the most productive, Q4 usually the least
• budget 20% of time for generic sustaining engineering work
  • testing, debugging, cleanup
• as you approach deadlines, it is your job to say no
  • figure out which must haves are not actually must haves
• use the doubling rule for quick estimates, but do planning for bigger tasks
• be selective about what you bring to the team to estimate
  • to avoid unnecessary distractions

Joining a small team

It’s a different thing to be promoted from a software engineer to a manager in the same company, and different to be new to the team and the code.

It can make sense to go through regular onboarding for engineers and ask someone to walk you through the code. Try to release something within first 60 days. It’s worth it to know the system to get the technical credibility.

Assesing your own experiences

• What are your new responsibilities now that you’re the manager of a team? What tasks have you stopped doing or handed off to someone else in order to make time for these new responsibilities?
• How well do you feel you know the day-to-day challenges of writing, deploying, and supporting code on your team?
• How often does your team mark work as completed?
• When was the last time you wrote a feature, debugged a problem, or paired with a member of your team on some code he or she was struggling with?
• Are there one or two team members who cause the bulk of negativity on the team? What is your plan for getting rid of the problem moving forward?
• Do your team members seem engaged with one another? Do they smile in meetings? Make jokes in chat? Get coffee or lunch together? When was the last time you all sat down together without talking about work?
• How does your team make decisions? Do you have a process for assigning decision-making responsibility? What decisions do you hold yourself responsible for making?
• When was the last time you reviewed a completed project to see if it had achieved its goals?
• How well does your team understand why they are working on the projects they are working on?
• When was the last time you cut scope on a project? What did you use to determine which pieces to cut?

6. Managing multiple teams

• you most likely don’t write code anyway, but it makes sense to reserve at least half a day once a week to scratch the creative itch: blog post, conference talk, open source project
• you can still contribute by doing code reviews
• you need to communicate well to explain technical needs to business, and express business needs to guide engineers
• you’re responsible for general technical competence
• you spend some time researching new technologies and trends
• you help the teams set the goals and standards
• you may miss the code because it was full of quick wins

Managing your time: what’s important anyway?

• following up on task completion can become one of the biggest time sinks
• matrix important vs urgent
  • i and u: obvious work
  • i but not u: strategic, make time
  • not i but u: tempting distractions
  • not i and not u: obvious avoid
• a big challenge emerges when you lose sense of importance. Urgency is often more clearly felt than importance
• we tend to substitute obvious for urgent in determining something’s value e.g. calls
• one example of important but not urgent task is preparing for meetings so that you can guide them in healthy way
• as a manager of multiple teams you win back time by pushing an efficient meetings culture down to your teame
• meetings can be urgent and not important so you can decide not to attend. But you risk missing out on clues to catch problems early. E.g. boring meetings
• go to the meetings to gauge engagement
• ask what the team needs: an engineer or a manager. Would you suck at being an engineer, or be an engineer and inflict on the team that everyone sucks as a manager?

Decisions and delegation

• management is like plate spinning. Your plates are people and projects. Your job is to figure out how much attention each one needs at what time.
  • you’re still learning how to spin the plates and some of them will inevitably fall
• skipping 1-1s because you’re too busy is a great way to miss the warning signs
• simple and frequent tasks: delegate
  • e.g. running dailies
• simple and infrequent: do yourself
• complex and frequent: delegate
  • e.g. project planning, system design
• complex and infrequent: training opportunities for rising leaders
  • e.g. making hiring plans, writing performance review

Warning signs

• someone chatty, happy, engaged becomes quiet, comes in late.
  • could mean personal issues or a willingness to quit
• tech lead says all good but skips 1-1s
  • can be hiding something
• the team has no energy in their meetings, tech lead and pm do all the talking
  • the team isn’t engaged by the work or feels doesn’t have a say in decision making
• the team’s project list changes every week
  • they need better business direction

Challenging situations: strategies for saying no

• “yes, and”
  • e.g. “yes, we can do that project, and all we will need to do is delay the start of this other project that’s currently on the roadmap”
• create policies
  • when you start repeating yourself, it’s a good basis to say no
  • making a policy helps your team know in advance the cost of getting to “yes”
• “help me say yes”
• appeal to budget
  • it often falls back to “not right now”. But if you use it, remember that the “later” should actually happen
• work as a team
  • asking others to help you say no. E.g. asking finance to explain budget limits
• Don’t prevaricate
  • when you know you need to say no, it’s better to say it quickly

Ask the CTO: My tech lead isn’t managing

• it could be that they say they are busy. Remind them that this is also their work
• it could be that they don’t know how to push the junior. Ask how they have tried so far, and suggest different approaches

Technical elements beyond code

• interrogate every process to determine the value it should provide, and always ask yourself if it can be automated further
• questions to ask as an engineer
  • 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 evert day?
• signals of healthy team:
  • frequency of releases
    • does the process work?
    • how long does it take?
    • what to do if it goes wrong?
    • as a leader you’re reponsible for keeping your team happy and productive, and often the solution is ot cheerleading or paying them better, but enabling them to be more productive, challenging them to go faster, and do better work, and helping the find the time they need to make their work more interesting.
  • frequency of code checkins
    • it means the team knows how to break things down
    • people who write tests are usually better at breaking work down
  • infrequency of incidents
    • if you only react to incidents but do nothing to prevent them, you’re doing it wrong.

Good manager, bad manager: Us versus them, Team player

• identity-based team
  • focused on their superiority
  • prone to changes of leaders
  • resistant to outside ideas
  • empire building – competing for headcount, projects
  • inflexible to org changes
• purpose-based team
  • resilient to loss of individuals
  • driven to find better ways to achieve their purpose
  • open to changes that serve their purpose

The virtues of Laziness and Impatience

• impatience paired with laziness is wonderful when you direct it at processes and decisions
• practice modelling: figuring out what’s important, and going home
• any time you see something being done that feels inefficient, question it: Why does this feel inefficient to me?
• When you work later than everyone else, when you send emails if you don’t expect responses, people see them and thing it’s important to answer
  • queue up the weekend and overnight emails for the next workday

Assessing your own experiences

• When was the last time you reviewed your schedule for things that you’re
  doing but that aren’t providing a lot of value for you or your team? Look
  back on the past couple of weeks. Look forward to the next couple of
  weeks. What did you accomplish, and what do you hope to accomplish?
• If you are still writing code, how does this fit in with the rest of your schedule?
  Are you doing it after hours? What’s driving you to continue to spend
  this time?
• What was the last task you delegated to a member of one of your teams?
  Was it simple or complex? How is the person you delegated to handling
  the new task?
• Who are the rising leaders of your teams? What is your plan for coaching
  them to take on bigger leadership roles? What tasks are you giving them to
  prepare them for more responsibility?
• Does the process of writing, releasing, and supporting code seem to function
  smoothly on your teams? When was the last time there was a noticeable
  incident with part of this process? What happened, and how did the
  team respond to it? How often does the process encounter these exceptional
  conditions?
• When was the last time you pushed your team to cut the scope of a
  project? When you cut scope do you cut features, technical quality, or
  both? How do you decide?
• When was the last time you sent email after 8 pm or on the weekend? Did
  the person you sent that email to respond? Did you need him or her to
  respond?

7. Managing managers

• open-door policy doesn’t work. You have to look for the problems proactively e.g. by 1on1s.
• you have to rely a lot on instincts because you don’t know if something is important but you just sense it’s off

Skip-level meetings

• their purpose is to help you get perspective on the health and focus of your teams
• 1-1s with people who report to people who report to you
  • this doesn’t scale forever
  • let’s you keep treating people as humans and not resources
  • example questions:
    • what do you like best/worst about the project you’re 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 unhappy are you working at the company
    • what could we do to make working at the company more fun
• for more organizations idea could be lunch with the whole team
  • it’s to sende group dynamics and get feedback directly from the teams
  • of course people won’t share everything in front of the group. But you could get a sense where the team believed their focus needed to be, and you can answer some questions about company’s strategic focus
  • useful questions:
    • what can I, your manager’s manager, provide for you or your team? Anyting I should be helping with
    • is this team working poorly with any other team, from your perspective?
    • are there any questions about the larger organization that I can answer
• the meetings also help detect if you are being managed up
• it’s a constant balance between investing more time to get better information or less to get worse
• don’t neglect these meetings even if you have history with people from the teams

Manager accountability

• the job of the team mamagers is to make your job easier and let you focus on high level strategy. But not by hiding information
• if the team is struggling they are responsible for identifying the problems and escalating and asking for support

Good manager, bad manager: people pleaser

• internal pleaser wants to make everyone in the team happy, external pleaser wante to make every boss and stakeholder happy
• both lead to confusion and contradicting messages
• when you manage these, tell them that they exhibit these, and support them in saying no.

Managing new managers

• one signal to watch out for is overwork. It could be someone who didn’t let go their old responsibilitiee; or a control freak who makes all the decisions
• ask HR team if they have curriculum for new managers
• set the expectations to the new manager that you’ll hold them accountable for the team, and help them build skills to achieve that

Managing experienced managers

• managers create subcultures, and a manager who creates an incompatible one can be a problem if you want your teams to work together well
• culture fit may be more important and harder to train than specific area expertise. Especially when hiring managers
  • if you have dynamic, product-centric team, you need managers who understand how to work with teams who ship software frequently
  • if you want teams that operate with transparency, make sure the manager shares information, if you want teams that encourage exploration, make sure the manager schedules time and space for his team to explore ideas
• the coaching will be less about basics of management, and more about how they can have a larger impact on strategy and direction setting for their area
• experienced managers often need help expanding their network

Hiring managers

• look at the skills you expect from a manager and ask them about them
  • you can role play 1-1s. Or even ask future reports to describe their current or recent problems
  • you can role play difficult situation like dealing with an employee who is underperforming
  • a manager must be able to debug teams.
    • Ask them to describe a time when they ran a project that was behind a schedule and what did they do
    • role play an employee who is thinking about quitting
    • ask them how they coached employees who were struggling and helped great employees grow to new levels
  • ask them about their management philosophy. New managers may not have one, but experienced one that don’t have should be concerning
  • ask what they think the job of manager is?
  • how they stay hands on and how they delegate
  • you may have them give presentation to a group to see how they command a room, answer questions, structure their thoughts. But use it with caution – there may be great managers who don’t deal well with strange audience
  • you want to make sure they get enough technical skills to be able to establish credibility with the team. E.g. make sure they can discuss system design trade-offs that were made and why. They could even mediate a technical debate between engineers who disagree on the solution by asking good questions.
• another important aspect is culture fit
  • first you need to understand the company itself. E.g. does it have informal structure or does rely on hierarchy.
  • it’s important because managers shape their teams to their culture, and they hire people based on their culture ideas
  • reference to book High Output Management that talks about cultural valuee as one of the ways that people make decisions inside of a highly complex, uncertain or ambiguous circumstances where they value the group interest above their own
• do thorough reference checks
  • ask the references to describe they ways the person succeds as well as the ways they fail
  • ask if they would work with the person again
  • ask what they liked about the person and what drove them crazy

Ask the cto: managing outside your skill set

• it’s hard to know which details to focus on
• so be very curious. You’re not expected to know everything just because you’re a manager
• Ask the person to teach you about the work they do

Debugging dysfunctional teams

People are like black boxes. You insert the input and observe the output

• have a hypothesis
• check the data
  • e.g. chat, emails, tickets, code reviews, check ins
• observe the team
  • sit in their meetings. Are they boring, unnecessary
  • good meetings have discussion element. If managers always shut down conflict without letting disagreement air, it’s a sign of an unhealthy team
  • your presence may change the team’s behavior
• ask questions
  • do team members understand what they build for? Do they have part in deciding the goals?
• check the team dynamics
  • are people friendly, cold, formal?
• jump in to help
  • it can be an opportunity to teach the team manager to grow
• be curious
  • pursue the why

Setting expectations and delivering on schedule

• leadership may ask why something takes “so long” even though they didn’t like original estimates or didn’t ask for them at all
• you must be aggressive about sharing estimates and updates to them, even when people don’t ask, especially if you believe that the project is critical or likely to take longer than a few weeks
• estimates are often useful even if not perfectly accurate. It can help escalate complexity to the rest of the team. Business wants to plan and get ideas of costs and effort
• learning from mistakes. When estimates are wrong, what do you lwarn about unknown complexity
• when someone is pushing you can simply patiently remind them that things go as fast as they can. You can also show empathh converting blame into action

Challenging situations: Roadmap uncertainty

• changes to the strategy are unpleasent for the middle management because they can’t really push back, but the team is mad at them
• strategies for handling roadmap uncertainty:
  • be realistic about the likelihood of changing plans given the size and stage of the company you work for
    • if the plans change every year in the summer, just do promise anything beyond that point
  • break projects down into smaller deliverables
  • don’t overpromise future technical projects
    • the “later” will never come
  • dedicate 20% to “sustaining engineering”
  • understand how important various engineering projects are
    • helpful questions:
      • how big is that project?
      • how important is it?
      • can you articulate the value of the project to anyone who asks?
      • what would successful completion of the project mean for the team?

Staying technically relevant.

To answer that question, first understand your technical responsibility

• Oversee technical investment
  • there’s only a limited time that can go into improving the systems so you have to make sure the team is placing its technical bets in the right places
• Ask informed questions
  • you don’t do the research yourself, instead guide these investments by asking questions
• Analyze and explain engineering and business tradeoffs
  • you know enough about the system to know what could be complex
• Make specific requests
  • don’t relay requests from the upper management to the team, but use your knowledge to know what could make sense e.g. finish up this refactoring knowing what product work comes next
• Use your experience as a gut check

So to stay technical you can

• read the code
  • e.g. code reviews
• pick an unknown area and ask an engineer to explain it to you
• attend postmortems
  • it helps identify where standards are neglected or ignored, where the communications is lacking, tooling hurts more than helps
• keep up with industry trends in software development process
• foster a network of technical people outside of your company
• never stop learning
  • posts, articles

Assessing Your Own Experience

• How often do you talk to your skip-level reports? Do you meet with them one on one, or as groups? How do you proactively reach out to your teams? How much time do you spend seeking out information, instead of passively handling the information that comes to you? When was the last time you sat in on a team meeting?
• Without looking at your existing documentation, write down your view of the job description for the engineering managers who report to you.
  • What are they responsible for?
  • How do you evaluate them?
  • What areas are most important for success, in your opinion?
• Now, look at the job description your company uses. Are there differences in what you wrote compared to that description, or do they match well? Given that description, what things are you potentially overlooking in evaluating them?
• Finally, do a quick mental review of their current performance. What areas need coaching and development? Make time to cover this in your next 1-1.
• If you manage an area that is outside of your technical comfort zone, how often do you check in on that area to make sure things are going well? Have you taken some time to learn from the manager of that area a little bit about what it takes to succeed in that role? What new things have you learned in the past three months that help you understand that team better?
• If you have one team that is clearly operating more smoothly than others, what are the differences you notice in their processes? Their interactions? Is their manager doing things differently than other managers? How does the team interact with that manager, and how does that manager interact with you?
• What is your interview process for managers? Do you spend time talking about their personal values and their management philosophy? Do you have the team interview their potential manager, or do you keep them out of the process? Do you spend time getting references for candidates?
• What are your organization’s goals this quarter? This year? How are you merging product goals (if any) with the technical goals? Does your organization have a mandate that is well understood by the teams?

8. 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
• In the book High output management management tasks are broken into 4 categories
  • Information gathering or information sharing
    • synthesizing large quantities of information and sharing it in a way that others understand
  • Nudging
    • asking questions instead of giving orders
  • Decision making
  • Role modelling

Models for thinking about Tech senior leadership

• Common roles:
  • R&D
  • Technology Strategy / visionary
    • uses business and technology trends to guide decisions
  • Organization
    • org structure, staffing plan
  • Execution
    • helps aligns roadmaps, plan work, coordinate efforts
  • Face of technology, external
    • when the company sells software as a product.
    • participate in sales cycle
    • speak at conferences
  • Infrastructure and technical operations manager
    • cost-focused, security-focused, scaling-focused
  • Business executive
    • understands the industry

Example combinations:

• Business executive, technology strategy, organization, and execution: CTO or Head of Engineering (VP/SVP)
• R&D, technology strategy, external face of technology: CTO, Chief Scientist, Chief Architect, sometimes Chief Product Officer, usually for a company that is selling a software-based product
• Organization, execution, business executive: VP of Engineering, General Manager
• Infrastructure manager, organization, and execution: CTO/CIO, possibly VP of Technical Operations
• Technology strategy, business executive, and execution: Head of Product (or Chief Product Officer), sometimes CTO
• R&D, business executive: CTO or Chief Scientist, cofounder
• Organization and execution: VP of Engineering, sometimes Chief of Staff

What’s a VP of engineering

• has a solid handle on process and details. Capable of tracking several in-flight initiatives at once and making sure they’re all going well
• also a lot of management responsibiities: development roadmap, hiring plan, planning how teams have to evolve, coaching engineering management team,
• high-level and detail-oriented at the same time.
• heavily involved in helping teams set goals to achieve business deliverables, that means working closely with product-teams.
• interested in complexities of getting people to work together effecitvely

What’s a CTO

• is NOT the top of the technical ladder.
• the CTO must care about and understand the business, and be able to shape business strategy through the lens of technology. An executive first, a technologist second – Strategic technical executive the company needs in its current stage of evolution
  • strategic – thinks long-term, plan the future of the business
  • executive – take strategic thinking and make it real, break down problems and direct people to execute against it
• CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them
• part of your ability to shape the direction of the business and business strategy is putting people behind solving problems you believe will impact the business. You need to make space for these people to also share their ideas
• If the CTO doesn’t have reports they loose influence.
• if you don’t care about the business your company is running – if you’re not willing to take ultimate responsibility for having a large team of people effectively attacking that business – then CTO is not the job for you.

Ask the CTO: Where do I fit?

• CTO
  • if you answer yes to most of these:
    • Do you think you might cofound a company someday?
    • Do you want to help oversee technical architecture and set up processes and guidelines for evolving it?
    • Are you also willing to go deep into understanding the business side of things in order to ground that technical architecture in the company’s growth?
    • Are you willing to do external events, speaking, selling to customers, and recruiting senior managers and engineers?
    • Are you willing to deal with managing and mentoring senior individual contributors?
  • the fastest route to become:
    • be a technical cofounder
• VP of Engineering
  • if you answer yes to most of these:
    • Do you enjoy managing people?
    • Do you enjoy making engineering processes more efficient?
    • Do you like to have a broad view of the work being done by a team and a hand in prioritizing that work?
    • Are you fascinated by organizational structure?
    • Are you good at partnering with product managers?
    • Are you willing to exchange depth of focus into technology details for focus on the effectiveness of the overall team?
    • Would you rather sit in a roadmap-planning meeting than an architecture review?
  • the fastest route to become:
    • get management experience at a larger organization and then join a growing startup
• “Wanting to be a CTO (or VP of Engineering) is like wanting to be married. Remember that it’s not just the title, it’s also the company and the people that matter.

Changing priorities

• Leaders who are removed from the day-to-day schedules of the teams can forget that that teams have long priority lists that may have been mapped out weeks or months ago, and may take weeks or months to complete
• Do you know what the top priority is? Do you teams know what it is? Do the developers on those teams know?
• It’s often a matter of communication
  • often you have to repeat the same thing 3x times
• Saying something is top priority is one thing, the other is making the actual tradeoffs on the schedule to get people moving on it
• people above us or in different organizations don’t have the same detailed understanding of what the team currently focuses on
• be prepared to push both up and down to main or change focus. If you think a big project should be finished before slotting in a new work, get as many details as possible about the value of the project, its current status and the expected timeline.
• try to anticipate questions questions and be preapred for the answers. And don’t forget to sell this change a good thing

Setting the strategy

• do a lot of research
  • ask the engineering team where their pain points are
  • ask executives in various areas where they expect growth to come from in the future
  • ask yourself where scaling challenges are now, and where might be in the future
• combine your research and your ideas
  • draw out the systems in place at the company, slice and dice the systems and teams across various attributes
  • e.g. customer-facing vs internal systems, frontend vs backend
• draft a strategy
  • plan out actionable ideas to improve operational efficiency, expand features, grow the business
  • where to limit and where to expand information sharing between systems
• consider your board’s communication style

Good technology strategy may involve system architecture but also team structure, and the businees direction. It enables many potential features of the business

Challenging situations: delivering bad news

• don’t blast an impersonal message to a large group
  • e.g via chat or email. Especially with commenting function. The team deserve to hear it from your mouths
  • also don’t deliver to too many people at once. It’s hard to see the reactions
• do talk to individuals as much as possible
  • think about the people who are going to have the strongest reaction and tailor the news to them. Give them space on 1on1s to ask questions
  • if you have to deliver to bigger group you can give talking point to your managers first to deliver to their teams
• don’t force yourself to deliver a message you can’t stand behind
  • you can ask other senior leaders
• do be honest about the likely outcomes
  • e.g. in case of layoffs acknowledge that this isn’t fun but everyone needs to the company to survive
• do think about how you would like to be told

Ask the CTO: I have a nontechnical boss

• don’t hide information behind jargon, and be careful with details
  • your new boss is smart but doesn’t want to hear all the technical details behind decisions. You need to learn how to distinguish which information is valuable
• exepct that you will need to run your 1-1s with your new boss, so come preprared with a list of topics
  • CEOs are busy. You may send the list in advance to remind to honor your 1-1s time
• try to bring solutions, not problems to be solved
  • but don’t shy away from delivering bad news
• ask for advice
  • it shows respect
• don’t be afraid to repeat yourself
• be supportive
  • ask if there is more you can do to help
• actively look for coaching and skill development in other places
  • you no longer have a manager. You have a boss

Senior peers in other functions

• first-team principle: leaders should prioritize their executive team (their peers) over the functional teams they directly manage
• you have to let other peers own their areas
• you have to trust that they also care about the organization and not their own interests
• you may disagree, that’s normal. The values that make a great CTO are probably slightly different than those for CFO, CMO etc
• disagreements that happen in the leadership team don’t exist to the woder team

The echo

• you need to detach from the team
  • to not be accused of playing favorites
  • to lead effictively. That requires people to take your words seriously. If you try to maintain “buddy” image your reports can’t distinguish when you think out loud and you ask them to do something
  • you will have to make some decisions which you shouldn’t discuss with other people at the company
• you choose which behaviors you use in front of the team you want them to model
  • if you always ask the same set of questions about the project, people start to ask those questions themselves
• though it makes sense to treat people as humans, talking about their families and hobbies. As you detach more it’s easy to start thinking about people as cogs

Ruling with fear, guiding with trust

• vicious cycle when people hide information from you and don’t trust them even more
• correcting a culture of fear
  • practice relatedness
    • if you want a team that feels comfortable taking risks and making mistakes it requires a sense of belonging and safety
  • apologize
    • to model good behavior
    • short apology is enough. Just to show you takes responsibility for hurting others
  • get curious
    • when you disagree, try to understand
  • learn how to hold people accountable without making them bad

True north

• as a leader you set the baseline of what excellence looks like in this function
• some things that are generally considered bad are ok under certain circumstances
  • having a single point of failure
  • having known bugs and issues
  • being unable to tolerate high load
  • losing data

9. Bootstraping culture

• instead of talking about structure, talk about learning, instead of talking about process, talk about transparency
• it’s hard to overstate how many decisions need to be made in the context of a startup
• having no job titles is one decision, but can mean you no longer make other decisions which title to give
• reference to The tyranny of structurelessness – the unstructured grou can work together when
  • the group is task oriented
  • the group is relatively small and homogeneous
    • e.g. people from different cultures and backgrounds may understand things differently
  • there’s is a degree of communication
  • there is a low degree of skill sepcialisation
• that’s often reflected in startups that hire full stack engineers (spacialization) among their own social networks (homogeneous)
• there is a reason that you often find a lot of spaghetti code in early startups – refactoring involves identifying and explicitly drawing out structure
• structure is how we scale, diversify and take on more complex long-term tasks
• structure can come too early and cause harm by slowing a group down
• but can too late and the problems creep up slowly. E.g. a person who’s used to make all the decisions and often changing their mind. The cost of change becomes more and more expensive

Assesing your role

• understand your company:
  • people
    • modern companies often put their structural focus on goal setting instead of making all the decisions
  • Age
    • the longer a company is around the more habits become entrenched. But the more likely it is to survive
  • size of existing infrastructure
    • the more business rules, code you have the more clarity is needed how to handle it
  • risk tolerance
    • is the industry highly regulated? What’s the cost of failure?
• John Gall’s Systematics : a complex system that works is invariably found to have evolved from a simple system that worked
• when failure happens examine the factors and patterns. Maybe you need more or less structure
• applying lessons from a successful complex system will NOT let you replicate easily that success in other systems
• learning rarely comes for free. If the value of your future time is less than the value of your current time, then you probably don’t need to worry about saving future time
• When every new hire slows 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

Creating your culture

• culture is how things get done without people having to think about it
• the early employees will form the culture, for good or for bad.
• not every person will fit in at every company
• the founding team’s values will be reinforced, recognized and rewarded inside of the company. Employeee who embrace and exhibit all of the core values of the company tend to do well naturally

Applying core values

• define your culture
  • if you have a set of company valuee, map onto your team. You may add a couple that are special to your team
• reinforce your culture
  • by rewarding people for exhibiting its values in positive ways
• one of the most important uses of performance reviews is to evaluate the alignment between team members’ values and the company’s values
• using the core valuew to coach people in areas where they are misaligned can help you articulate what otherwise may feel like just ambiguous friction
• use this as part of interview process

Creating cultural policy

• a lot of companies share their policies so you can find an inspiration

Writing a career ladder

• solicit participation from your team
• look for examples
• be detailed
• use both long-form descriptions and summaries
  • how many levels? Two helpful questions: how do you pay people and how do you recognize achievement?
• consider how the ladder relates to salary
• provide many early opportunities for advancement
• use narrow salary bands for early-career stages
• use wide salary bands when and where you have fewer levels
  • they should overlap
  • it also gives wiggle room to hire people who are on the fence into lower level with the expectation that they will be promoted quickly
• consider your breakpoint levels
  • “up or out”. What is the level at which you feel comfortable to let people stay on forever – they do solid work but just don’t want bigger scope
• recognize achievement
  • it gives people bigger achievements to strive for beyond the next pay increase. E.g. promotion to staff engineer or director
• split management and technical tracks
• consider making people management skills a mid-career requirement
  • even when designin software you’re delaing with other humans and human needs
• years of experience
  • it’s an artificial one, but still it takes long projects to become a staff engineer
• don’t be afraid to evolve over time

Cross-functional teams

• in technology-focused structures the focus is on being the best engineer. In the product-oriented teams, the one that emerges as a leader is the one that has the best business sense, delivers features quickly and efficiently.
• even in cross functional teams the engineers need some time for generic engineering work like interviews or tech debt

Developing engineering processes

• without any process your teams will struggle to scale. With the wrong process they will be slowed down.
• a complicated process should exist only for activities that you expect to be rare, or activities where the risk are not obvious to people
• you should not put a complicated process on any activity where you want people to move quickly and where you believe the risk for change in that activity is low
• the processes should have value even they are not followed perfectly

Depersonalize decision making

• Code review
  • Be clear about code review expectations
  • Use a linter for style issues
  • Keep an eye on the review backlog
    • you may block assigning reviews to someone who already has too many
• The outage postmortem
  • you can also call it “learning review”
  • resist the urge to point fingers and blame
  • Look at the circumstances around the incident and understand the context of the events
    • try to detect patterns
  • be realistic about which takeaways are important and which are worth dropping
• Architecture review
  • Be specific about the kinds of changes that need architecture review
    • e.g. new languages, frameworks, storage systems, developer tooling
  • The value of architecture review is in preparing for the review
  • Choose the review board wisely
    • e.g. people who would be affected the most with the proposed changes

Assesing your own experience

• What policies do you have now? What practices? Have you written any of them down yet? When was the last time you revisited them?
• Do you have company values? What are they? How do you recognize them in your team?
• Do you have a career ladder? Do you feel it accurately reflects the team today? Does it reflect the team you want to have in the future? If not, can you improve it?
• What risks are most concerning for your team? For your company? How can you mitigate those risks without burdening your team with unnecessary processes and bureaucracy?

10. Conclusion

• you have to be able to manage yourself if you want to be good at managing others.
• meditation resources
  • https://www.tarabrach.com/
  • Pema Chödrön