The Manager's Path - A guide for tech leaders navigating growth and change

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

Managers who care about you as a person, and who actively work to help you grow in your career. Managers who teach you important skills and give you valuable feedback. Managers who help you navigate difficult situations, who help you figure out what you need to learn. Managers who want you to take their job someday. And most importantly, managers who help you understand what is important to focus on, and enable you to have to focus.

One-on-one meetings with your direct manager are an essential feature of a good working relationship. 1-1s serve two purposes. First, they create a human connection between you and your manager.

Being an introvert is not an excuse for making no effort to treat people like real human beings, however. The bedrock of strong teams is human connection, which leads to trust. And trus, real trust, requires the ability and willingness to be vulnerable in front of each other.

The second purpose of a 1-1 is a regular opportunity for you to speak privately with your manager about whatever needs discussing. You should expect your 1-1s to be scheduled with some predictability so that you can plan for them, because it is not your manager’s job to completely control the 1-1 agenda.

The second thing to expect from your manager is feedback. the worse thing 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.

Praising in public is considered to be a best practice because it helps the manager let everyone know that someone has done something laudable, and reinforces what positive behavior looks like.

Asking your manager for advice is also a good way to show that you respect her. People like to feel helpful, and managers are not immune to this sort of flattery.

If you don’t ask your manager about a promotion, do not expect her to just give you one magically. If you’re unhappy with a teammate, your manager may not do anything unless you bring the issue to her attention.

The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.

My career goal is someday to become a CTO, what should I be doing now to make that possible?

My specific advice would be to seek out a workplace where you can get mentorship and training in the aspects of doing the job (such as testing, project and product management, and collaboration) as well as learn new technical skills. You want to build a strong foundation of skills because you will need them to succeed.

I also advice you to find the best managers and mentors you can, and watch them work. Try to find people to work for you who push you to succeed but also reward you for success, who inspire you to stretch yourself. Realize that stretching yourself is about more than just learning new technologies: great CTOs have strong communication skills, project management skills, and product sense, in addition to good technical sense. However, you also want to spend a lot of time writing code and getting really good at understanding how high-quality code is written.

I encourage you to create and build a strong network of peers. One thing that early career engineers often don’t appreciate is how their current peers will turn into their future jobs. This peer group includes everyone from your schoolmates to your teammates to the people you meet at conferences and meetups. Cto’s have to learn how to socialize with all sorts of people and create strong networks across companies.

Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.

In all of this uncertainty, the only person you can rely on to pull through it is yourself. Your manager cannot do that for you. 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.

When you are persistently unhappy, say something. When you are stuck, ask for help. When you want a raise, ask for it. When you want a promotion, find out what you need to do to get it.

When you have a problem, instead of demanding that your manager solve it for you, try asking her for advice on how she might approach the problem. Asking for advice is always a good way to show respect and trust.

Strong managers know how to play the game at their company. They can get you promoted; they can get you attention and feedback from important people. Strong managers have strong networks, and they can get you jobs even after you stop working for them.

In a healthy organization, this onboarding mentorship role is used as an opportunity for both parties. The mentor get the change to see what it is like to have responsibility for another person, and the mentee gets an overseer who is focused on him alone, without other reports clamoring for his mentor’s attention.

The first thing you need is some sort of project for this intern to work on. It would be nice if you, as the mentor, weren’t stuck coming up with the idea for this project, because doing so can be a daunting task. Without a project, your intern has a good chance of being completely lost and bored the entire summer.

Listening is the first and most basic skill of managing people. Listening is a precursor to empathy, which is one of the core skills of a quality manager. You need this skill wherever your career takes you; even principal engineers with no reports need to be able to hear what others are really saying. So, when your mentee is speaking to you, pay attention to your own behavior.

What if the intern does spend too much time asking you for help, without ever looking for help himself? Well, that gives you an opportunity to work on another management skill: communicating what needs to happen. If you expect him to do research on his own before asking you a question, tell him so! Ask him to explain a piece of code to you, or some product or process, and point him to the documents that you believe explain it. If he can’t do it even with pointers, well, you’re starting to learn something about the potential of this intern. If all else fails, give him the first milestone of the project and tell him to work on it alone for a day or two.

Effective teams have good onboarding documents they provide to new hires. Things like step-by-step guides to setting up their development environments, learning how tracking system work, and familiarizing themselves with the tools they will need for the job are crucial for new hires. These documents should constantly evolve to meet the changes of the workplace itself. Mentoring a new hire by helping her work through the documents, and having her modify those documents with any surprises she encounters during onboarding, provides a powerful message of commitment to her. It shows her that she has the power and obligation to learn, and to share what she’s learned for the benefit of your whole team.

It’s very difficult to build a career at any company with multiple teams without building a strong network of trusted people to share information and ideas with. The workplace is built around humans and their interactions, and these networks form the basis of any career, whether it’s focused around management or individual technical contribution. You may be an introver or someone who does not find socializing easy, but conscious effort and practice in getting to know new people and helping them succeed will pay off. Your attitude about this will determine success or failure. Adopt the mindset that network building is worthwhile investment of your time and energy.

The best mentoring relationships evolve naturally and int he context of larger work. When a senior engineer mentors a junior engineer on the team in order to help him be more productive, they can work on problems together that are relevant to both of them. The senior engineer gets value because the code written by the mentee is better, requires fewer revisions, and develops faster. The junior engineer obsiously gets the value of hands-on instruction and access to someone with a deep understanding of the context he is working in. This type of mentoring is usually not a formal relationship and may be an expected part of the job for senior engineers because it delivers so much value to the team.

You’ll encounter an “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. The alpha geek values intelligence and technical skill above all other traits, and believes these attributes should determine who gets to make decisions. The alpha geek usually can’t deal with dissent, and is easily threatened by those she perceives as trying to steal her spotlight or who might upstage her. She believes herself to be the best, and responds only to messages that support that view. The alpha geek tries to create a culture of excellence, but ends up creating culture of fear.

Alpha geeks make absolutely terrible managers, unless they can learn to let go of their identity as the smartest person in the room and most technical person on the team. Highly technical hands-on managers can be good for small teams of senior engineers, but alpha geeks are often better off kept out of management and given more of a focus on technical strategy and system design and development focus across from an execution-focused Vice president of engineering.

The alpha geek culture can be very harmful to collaboration and can deeply undermine those who feel unable to fight back. Alpha geeks who believe that their value comes from knowing more than others can also hide information in order to maintain their edge, which makes everyone on the team less effective.

As you know by now, leadership requires human interaction to exist. Developing patience and empathy is an important part of the career path of anyone working in a team-based environment.

Don’t hire interns who are not going to graduate in the year after their intership. When you’re hiring only a handful of inters, you want all of them to have high potential for becoming full-time employees.
Hiring interns is relatively easy compared to hiring full-time graduates.

As you grow in your career, you’ll experience a lot of teachable moments, a lot of lessons in how things should or should not be. These can be “best practices” or scars caused by mistakes. This unconscious buildup can cloud our thinking and reduce our creativity. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Technology is always changing around us, so we must continually experience that change.

To work successfully with a newcomer or a more junior teammate, you must be able to listen and communicate in a way that person can understand, even if you have to try several times to get it right. Software developments is a team sport in most companies, and teams have to communicate effectively to get anything done.

The idea that the tech lead role should automatically be given to the most experienced engineer, the one who can handle the most complex features or who writes the best code, is a common misconception that even experienced managers fall for. Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. A tech lead who does this is not doing her job.

The tech lead role is not a point on the ladder but a set of responsibilities that any engineer may take on once they reach the senior level. This role may or may not include people management, but if it does. the tech lead is expected to manage these team members to the high management standards of RTR tech. These standards include:

Regular (weekly) 1-1 touch bases
Regular feedback on career growth, progression towards 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.

If a tech lead is not managing directly, they are still expected to provide mentorship and guidance to the other members of the team.

The tech lead is learning how to be a strong technical project manager, and as such, they are scaling themselves by delegating work effectively without micromanaging. They focus on the whole team’s productivity and strive to increase the impact of the team’s work product. They are empowered to make independent decisions for the team and are learning how to handle difficult management and leadership situations. They are also learning how to partner effectively with product, analytics, and other areas of the business.

It is not required that an engineer work as a tech lead to progress, but it is the most common way for engineers to grow from senior engineer 1 → 2 and is required to grow from senior engineer 2 to engineering lead. Realistically it is very hard to grow past senior engineer 2 without ever having acted as a tech lead, even on the individual contributor track, due to the importance at senior levels of leadership and responsibility.

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

Tech leads are in the position to act as strong technical project leaders, and to use their expertise at a larger scale so that their whole team gets better. They can make independent decisions, and they play a big role in coordinating with other nonengineering partners that their team might have. You’ll note that there’s nothing here about specifically technical work.

You can’t lead without engaging other people, and people skills are what we’re asking the new tech lead to stretch, much more than pure technical expertise. However, tech leads will be working on one major new technical skill: project management. The work of breaking down a project has a lot of similarity to work of designing systems, and learning this skill is valuable even for engineers who don’t want to manage people.

Being tech lead is an exercise in influencing without authority. As the tech lead I am leading a team, but we all report to the same engineering manager. So not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work.

The biggest trik of being a good tech lead: the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs. You have to stop relying entirely on your old skills and start to learn some new skills. You’re going to learn the art of balance.

Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving.

In the system architect and business analyst roles, you identify the critical systems that need to change and the critical features that need to be built in order to deliver upcoming projects. The goal here is to provide some structure for basing estimates and ordering work. You need not perfectly identify every single element of a project, but there’s a lot of value in spending time thinking through the externalities and issues related to a project. This role requires you to have a good sense of overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software.

Project planners break work down into rough deliverables. With this hat on, you’re learning to find efficient ways of breaking down the work so that the team can work quickly. Part of the challenge here is getting as much productive work done in parallel as possible. This can be tough because you are probably used to thinking about only your own work, instead of the work , instead of the work of groups of people. Finding places to apply agreed-upon abstractions to enable parallel work is key.

At this stage, you will want to gather input from the experts on your team and talk to the people who know the affected parts of the software deeply, so that they can help with the details here. You will also want to start identifying priorities as part of this process.

Software developers and team leaders write code, communicate challenges, and delegate. In your position as tech lead, you should continue writing code, but not too much. Even if you are tempted to pull a rabbit out of the hat yourself, you must communicate this obstacle first. Your product manager should know as early as possible about any possible challenges. Enlist the help of your engineering manager as needed. In a helthy organization, there is no shame or harm in raising issues early. Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on. As a large project nears its delivery date, there will be compromises on functionality. Start looking for opportunities to delegate work, especially if there is part of the system you expected to build yourself that you have not had the time to tackle.

Agile software development is great way to think about work because it forces you to focus on breaking tasks down into smaller chunks, planning those smaller chunks out, and delivering value incrementally instead of all at once.

Project management is the act of breaking a complex end goal down into smaller pieces, putting those pieces in roughly the most effective order they should be done, identifying which pieces can be done in parallel and which must be done in sequence, and attempting to tease out the unknowns of the project that many cause it to slow down or fail completely. You are addressing uncertainty, trying to find the unknowns, and recognizing that you are going to make mistakes in the process and miss some unknowns despite your best efforts.

Break down the work - Start with the biggest pieces, then break the big pieces down into smaller pieces, then break those down into even smaller pieces. Hand those tasks off to the people who can actually turn them into ticket-sized work.
Push through the details and the unknowns.
Run the project and adjust the plan as you go.
Use the insights gained in the planning process to manage requirements changes.
Revisit the details as you get close to completion.

You can switch tracks if you want. It is common for people to try out management at some point, realize they don’t enjoy it, and go back to the technical track. Nothing about this choice has to be permanent, but go in with your eyes wide open. Each role has benefits and drawbacks, and it’s up to you to feel out what you enjoy the most.

The principle of the agile manifesto are great summary of healthy process leadership:

Individuals and interactions over process and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan

If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. Learn it. Get a sense for it. Visualize it. Understand its connections, where the data lives, how it flows between systems. Understand how it reflects the products it is supporting, where the core logic for those products lives. It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.

With boring or frustrating projects, there’s often something obvious that can be spotted and fixed if an experienced person takes the time to look at them.

It’s reasonable for you to take on some of the harder tasks. You want to encourage others on your team to learn the entire system, and you want to give them chances to stretch themselves, but you needn’t always be self-sacrificing in what you choose to work on. Give yourself a fun task occasionally, as long as you know you have the time to do it well.

Determin which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve. In all of these cases, make it clear what the matter under discussion is, and communicate the outcome.

Your productivity is now less important than the productivity of the whole team. Often, this means that you pay the price of communication overhead. Instead of having every team member sit in a meeting, you represent the team, communicate their needs, and bring information from that meeting back to the team. If one universal talent separates successful leaders from the pack, it’s communication skills. Successful leaders write well, they read carefully, and they can get up in front of a group and speak. They pay attention in meetings and are constantly testing the limits of their knowledge and the knowledge of the team. Now is a great time to practice your writing and speaking skills. Write design documents and get feedback on them from better writers. Write blog posts for your tech blog or your personal blog. Speak in team meetings, speak at meetups, and get practice standing up in front of an audience.

Don’t forget to listen during all of this communication. Give others a chance to speak, and hear what they say. Practice repeating things back to people to ensure you understand them. Learn how to hear what someone says and rephrase it in your own words. If you aren’t a good note taker, you may need to become one. It doesn’t matter whether you choose to dive deep into technology, or become a manager, if you can’t communicate and listen to what other people are saying, your career growth from this point on will suffer.

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.

One strategy is to ask series of questions that area intended to help you get to know the aspects of the person that impact your ability to manage him well.

Another approach that many experienced managers use is to help their new reports create a 30/60/90-day plan. This can include basic goals, like getting up to speed on the code, committing a bug fix, or performing a release, and is especially valuable for new hires and people transferring from other areas of the company. The more senior the hire, the more he should participate in creating this plan. You want him to have some clear goals that will show whether he’s learning the right things as he gets up to speed. These goals will also require some work from you and from the team, because it’s very rare that everything is self-evident, well documented, and totally obvious to a newcomer.

For early to mid-career hires, one aspect of onboarding will likely include contributing to the team’s onboarding documentation. A best practice in many engineering teams is to create a set of onboarding documents that are edited by every new hire as he gets up to speed. He edits the documentation to reflect processes or tools that have changed since the last hire, or points that he found confusing.

If you expect him to send you a weekly summary of his progress via email, tell him. Help him understand how long he should work alone trying to solve a problem, and at what point he should ask for help.

Get as much feedback as you can about the new hire’s perspective on the team in that first 90 days. This is a rare period, where a new person comes in with fresh eyes and often sees things that are hard for the established team members to see.

Regular 1-1s are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time. - Marc Hedlund

If you’re not a CTO with years and years of management experience, you should probably start by assuming that you need to do regularly scheduled 1-1s.

One or both parties comes in with a list of objectives to cover, and the parties cover these objectives in order of importance. Updates are given, decisions are made or discussed, planning happens. This style follows the “don’t waste time with pointless meetings” mandate and ensures that things will happen. The downside, of course, is that sometimes you wonder why you needed to do this in a synchronous manner.

My goal in a 1-1 is first to listen to anything my direct reports want to discuss. I want the meeting to be driven by them, and I want to give them space to bring up whatever they feel is important. I view a 1-1 session as much as a creative discussion as a planning meeting. The downfall of the rambling 1-1 is that, if it’s left unchecked, it can turn into a complaining session or therapy.

If you see or hear about a direct report doing something you want to correct, try to approach that person soon after. The longer you wait, the harder it will be for you to bring it up, and the less effective the feedback will be. The same goes for praise! When something goes well, don’t save up your praise, give it freely in the moment.

When you are managing only a handful of individuals, the only time you should be using a 1-1 to do progress reporting is when you have someone who’s off on a side project that you’re not personally overseeing. Getting progress reports from people you’re already working closely with is a waste of time because all you’re hearing about is the delta of work between now and the last standup or project review.

Try to keep notes in a shared document, with you the manager playing note taker. For each person you manage maintain a running shared document of notes, takeaways, and to-dos from your 1-1s. This is helpful for you to keep context about what has happened, and is useful for remembering when and what feedback was given. It will also be an essential historical record to refer to when you’re writing reviews or delivering feedback.

Trust and control are the main issues around micromanagement. If you’re micromanaging someone, chances are you’re doing it because you don’t trust that a task will be done right, or you want to very tightly control the outcome so that it meets your exact standards.

Autonomy, the ability to have control over some part of your work, is an important element of motivation. This is why micromanagers find it so difficult to retain great teams. When you strip creative and talented people of their autonomy, they lose motivation very quickly. There’s nothing worse than feeling like you can’t make a single decision on your own, or feeling like every single piece of work you do has to be double and triple checked by your manager.

When you feel like you want to micromanage, ask the team how they’re measuring their success and ask them to make that visible to you on an ongoing basis. Then sit on your hands if you must, but wait a week or two to see what they give you. If they have nothing to share, it’s a sign that you may need to do a course correction, which probably means digging into more details.

If the team is making progress on its goals, the systems are stable, and the product manager is happy. However that requires goals with a plan for people to be making progress against, and a product manager who can give you another perspective. When you are managing a team that doesn’t have a clear plan, use the details you’d want to monitor to help them create one. What are you holding them accountable against this month, this quarter, or this year? If you can’t answer that question, the first step is to help the team create those goals.

Developing basic standards as a team helps everyone communicate with one another in code and design reviews, and it depersonalizes the process of providing technical feedback. For me, basic standards meant things like how much unit testing we expected to happen with each change (generally speaking, as some tests were always required), and at what point technical decisions should be reviewed by a larger group (like when someone wants to add a new language or framework to the stack). As with goal setting, putting standards in place here helps people know which details are important to think about when they’re creating the technology.

The goal here isn’t yo punish him with micromanagement for his failure to communicate status, because all you’re doing is punishing yourself and hindering his ability to be held accountable for his own work. Instead, your goal is to teach what he needs to communicate, when and how. A word of caustion, , though; if you treat a struggling engineer or project as a massive failure on the part of the individual or manager, she is going to feel that blame and criticism, and instead of giving you more information in the future, she’ll keep hiding it from you as a way of avaiding blame until it’s too late. Hiding important information intentionally is a failure, and getting stuck on a problem or making a mistake is often just an opportunity for learning.

Continuous feed back is, more than anything, a commitment to regularly sharing both positive and corrective feedback.

Few people are comfortable with providing one-on-one praise or correction, and this helps you get over the feeling of awkwardness.

Know your people - The first required part of successfully giving continuous feedback is a basic understanding of the individuals on your team.
Observe your people
Provide lightweight, regular feedback - Positive feedback also makes your reports more likely to listen to you when you need to give them critical feedback. When they believe that their manager sees the good things they do, they’ll be more open to hearing about the areas where they might improve. It’s best to give critical feedback quickly in the case of an obvious misstep, but continuous feedback is more than in-the-moment corrections. Use a habit of continuous feedback to talk about things that don’t seem to be going well as you start to notice them, rather than waiting until the review cycle to have uncomfortable conversations.
Provide coaching - coaching-based continous feedback means going beyond a simple “good job” to really engage with the details and form a partnership with your direct report where the two of you are working together to help her grow.

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.

Performance reviews takes a long time because you need to give and receive feedback from many different people. As a manager, you then have to gather all that feedback together and summarize it for the person being reviewed.

Start by reading the collected reviews and taking few notes, processing the information for a little bit before trying to write a full summary. Give yourself enough time to write and come back to what you’ve written at least once before you have to submit the review.

Keep a running summary of your 1-1s, including any feedback that was delivered. If you haven’t done this, I encourage you to look through your email to remember which projects launched, review what activities were happening month by month, and put yourself back into the perspective of that time period.

Forcing yourself to be specific will steer you away from writing reviews based on underlying bias.

You want to celebrate achievements, talk about what’s going well, and give plenty of praise for good work.

What about the case where you have very little meaningful feedback for improvement? This indicates that the person is ready to be promoted or given more challenging work. If the person is doing a solid job at her level but isn’t ready for promotion, the feedback should indicate one or two skills she needs to expand to become qualified for promotion. Some people may never need to be promoted out of their current level, but the nature of the tech industry is such that skills need to be refreshed to stary current, so you can also focus on new technical learning opportunities.

A person has never shown reasonable performance, and who has been with a company long enough for you to observe performance, probably doesn’t actually have potential, at least within that company. It doesn’t matter how good his school was, how articulate she is, how tall he is… If the employee has been with a company for a while with little to show for it, all that potential you are imagining is simply that, a figment of your imagination.

The important thing for you to sstart doing now that you’re in management is to learn how the game is played at your company. Every company has its own variation of the promotion process, and you’re probably in this role because you survived it. If you don’t know how it’s done, ask your manager for advice.

Keep this in mind as you think about your team’s careers. If there is no growth potential on your team because there’s no room for people to work at a more senior level, it may bea sign that you need to rethink the way work is done in order to let individuals take on bigger responsibilities.

This situtuation is why you start giving feedback early and often, and keep records of the feedback you’ve been delivering. Feedback, positive or negative, should be a conversation. If you avoid tacling negative feedback until it builds to a boiling point, you’re going to be met by a pile of excuses and then what do you do?

A final warning: don’t put anyone on a plan whom you wouldn’t be happy to lose. Most smart employees will take this formal warning as a sign that the organization is not a good fit for them, and leave as quickly as possible. I once heard a story about a great engineer who was put on a surprise performance improvement plan by his manager after someone in the organization complained that he had bowed out of a project. This manager, who had not been paying any attention to the situation and had approved the engineer focusing elsewhere, gave in to pressure to set up a plan that served to do nothing but poison any goodwill the engineer might have had for his manager and the company. It’s no surprised that the engineer resigned soon thereafter, despite having easily achieved the goals of the improvement plan.

Generally, you want to make sure that long-term employees are capable of doing their day-to-day work independently, without a lot of oversight or help.

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

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, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t understimate the value of your technical skills as you work to become a successful engineering manager.

A critical part of complex project management is understanding the pieces of the system well enough to determine the best path to implementation. The more you understand the code in the system, the easier determining this path will be.

Using your managerial power to override technical decisions is usually a bad idea. Resist the temptation to micromanage people, especially those who used to be your peers.

You may be a shield, but you are not a parent. Sometimes, in combining the roles of shield and mentor we end up in a parenting-style relationship with our team, and treat them like fragile children to be protected, nurtured, and chided as appropriate. You are not their parent. Your team is made up of adults who need to be treated with appropriate respect. This respect is important for your sanity as well as for theirs.

You need to 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. Many technical projects are supported on the strenth of their ability to enable new features more easily.

The dos and don’ts of managing conflict :

Don’t rely exclusively on consensus or voting.
Do set up clear processes to depersonalize decisions.
Don’t turn a blind eye to simmering issues.
Do address issues without courting drama
Don’t take it out on other teams.
Do remember to be kind. It’s natural and perfectly human to want to be liked by other people. - Many of us believe that the way to be liked is to be seen as nice, that niceness is itself the goal. Your goal as a manager, however, should not be to be nice, it should be kind “nice” is the language of polite society, where you’re trying to get along with stangers or acquantances. Nice is saying “please” and “thank you” and holding doors for people struggling with bags or strollers. Nice is saying “I’m fine” when asked how you are instead of “ I’m in a really rappy mood and I wish you would leave me alone.” Nice is a good thing in casual conversation. But as a manager, you will have relationships that go deeper, and it’s more important to be kind. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying “Maybe you could get promoted,” and then watch her fail. It’s kind to tell someone that his behavior in meetings is disupting the group. It’s awkward, and uncomfortable, but it’s also part of your job as his manager to have these difficult conversations.
Don’t be afraid - Some fear is natural, and being sensitive to the outcomes of conflict is a wise habit.
Do get curious - be thoughtful about your behavior and it’s unlikely that you seek out unnecessary conflict.

Project Management rules of thumb

None of this is a replacement for agile project management.
You have 10 productive engineering weeks per engineer per quarter
Budget 20% of the time for generic sustaining engineering work across the board
As you approach deadlines, it is your job to say no
Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks
Be selective about what you bring to the team to estimate

The engineering director is responsible for a significant area of the technology team. The engineering director typically leads engineers across multple product areas, or multiple technology functions. Both tech leads and individual contributors report into them.

The engineering director is not generally expected to write code on a day-to-day basis. However, the engineering director is responsible for their organization’s overall technical competence, guiding and growing that competence in the whole team as necessary via training and hiring. They should have a strong technical background and spend some of their time researching new technologies and staying abreast of trends in the tech industry.

Becoming a great manager requires you to focus on the skills of management, and that requires giving up some of your technical focus. It’s a tradeoff and one you’ll have to decide if you’re up to making.

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

As a manager, I have this mental list of things about what my team needs. Things that I’m monitoring, things that I’m trying to fix, things that I’m trying to find for them. It’s my job to understand what is going on and what the team as a whole needs to be effective.

Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once. As tasks come at you, ask yourself: do I need to be the person who completes this work?

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

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

Start mastering the “yes and” strategy for saying no, particularly when interacting with your boss and peers, and see how it often transforms contentious disagreements into realistic negotiations for priority.

It’s important to remember that, as a technical leader, while you may not be writing code much, you’re still responsible for the technical side of getting work done. You’re also responsible for keeping your team happy and productive, and often the solution to this is not cheerleading or paying them better or praising them more, but instead enabling them to be more productive, challenging them to go faster and do better work, and helping them find the time they need to make their work more interesting. You have to be an advocate and push for technical process improvements that can lead to increased engineer productivity even if you are not implementing them all yourself.

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

Durable teams are built on a shared purpose that comes from the company itself, and they align themselves with the company’s values. They have a clear understanding of the company’s mission, and they see how their team fits into this mission. They can see that the mission requires many different types of teams, but all of the teams share a set of values. By creating a strong and enduring alignment between the team, its individuals, and the overall company.

Resilient to loss of individuals.
Driven to find better ways to achieve their purpose.
First-team focused.
Open to changes that serve their purpose.

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

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

You’re going to be pulled in many directions, and figuring out how exactly to spend your time to maximize your leverage across your teams will be critical. In order to do this well, you’ll need to practice honing your instincts, and this practice will require you to follow through on things that you’re not sure are actually important, but you just sense are off.

What is a skip-level meeting? Put briefly, it is a meeting with people who report to people who report to you.

When you’re managing a people pleaser, one of the best things you can do is show the person that he’s exhibiting the behavior, and highlight the downsides. Sometimes all it takes is awareness that his habit of saying yes is a problem for the team. Recognize that this usually comes from a personal value of being selfless and caring about others, and honor these values even as you try to correct unhealthy behaviors. People pleasers, after all, just want to make you happy.

A sign of a poor debugger is a person who, when he adds a log statement to a piece of concurrent code to attempt to find an error and sees that the error can’t be reproduced, assumes that he’s fixed the problem. It’s a lazy habit, but a common one.

To properly debug a system, you need a reasonable hypothesis that explains how the system got into the failed state, preferably one that you can reproduce, so that you can fix the bug. To debug a team, you also want to look for a hypothesis around why the team is having problems. Do this in as minimally invasive a way as possible, to prevent your meddling from obscuring the problems.

We become better leaders by pushing ourselves and our management teams to really get to the bottom of organizational issues, searching for why so that we can more quickly resolve such issues in the future.

Strategies for handling roadmap uncertainty

Be realistic about the likelihood of changing plans given the size and stage of the company you work for.
Think about how to break down big projects into a series of smaller deliverables so that you can achieve some of the results, even if you don’t necessarily complete the grand vision.
Don’t overpromise the future of technical projects.
Dedicate 20% of your team’s schedule to “sustaining engineering”
Understand how important various engineering projects really are.

Having accountability for the team’s technical investments doesn’t mean that you personally do the research to find potential investments. Instead, you guide these investments by asking questions.

How should you invest your time in order to stay technically relevant?

Read the code
Pick an unknown area, and ask an engineer to explain it to you.
Attend postmortems.
Keep up with industry trends in software development processes.
Foster a network of technical people outside of your company.
Never stop learning

Management tasks into four general categories:

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

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

What does a CTO actually do? A CTO must care about and understand the business, and be able to shape business strategy through the lens of technology. He is an executive first, and a technologist second. If the CTO doesn’t have a seat at the executive table and doesn’t understand the business challenges the company faces, there’s no way he can guide the technology to solve those challenges. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that aligns with the overall company strategies. Ensure that the technology is always evolving to anticipate and enable the potential futures of the business and product roadmap.

CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them. If he is focused on recruiting, retention, process, and people management, that’s because it’s the most important thing for the technology team to focus on at the time.

My advice for aspiring CTOs is to remember that 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, 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.

As a person in senior leadership, you’ll need to excel at communicating sensitive information to large groups.

Don’t blast an impersonal message to a large group.
Do talk to individuals as much as possible.
Don’t force yourself to deliver a message you can’t stand behind.
Do be honest about the likely outcomes.
Do think about how you would like to be told.

Reporting to a nontechnical manager can be a total culture clash. Fortunately, a few best practices will help you mange this relationship.

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.
Ask for advice.
Don’t be afraid to repeat yourself.
Be supportive
Actively look for coaching and skill development in other places.

We undermine ourselves when we fail to talk so that nontechnical peers can understand what we’re saying. Throwing out jargon to people who aren’t familiar with it, and who don’t even need to be familiar with it, makes us look stupid to them. We therefore need to figure out how to communicate the complexity of our work in a way that an intelligent but nontechnical peer can understand.

Socializing heavily with your team outside of working hours is a thing of the past. You need to detach for a few reasons. First, if you don’t detach, you’re likely to be accused of playing favorites. In fact, you probably will play favorites if you maintain very strong social ties with people who report to you on the team.

Second, you need to detach because you need to learn how to lead effectively, and leading effectively requires people to take your words seriously.

Detaching also means being thoughtful about where you spend your time.

You’re going to be part of hard decisions that will impact the whole business, and these decisions may cause you a great deal of stress.

You may not be “one of the team,” but that doesn’t mean you should stop caring about the team as individuals. In fact, I encourage you to care more about people as individuals, at least in a small way. Taking the time to get to know as many people as you can as humans, asking them about their families or hobbies or interest, is a good way to help them feel like they’re part of a group that cares about them.

Camille considers herself to be a good leader: technical, charismatic, capable of making decisions and getting things done. She’s also sometimes short -tempered, and when people don’t live up to her expectations or things go wrong. She can be visibly annoyed and openly angry. She doesn’t realize that this hard edge and short temper are making people afraid of her. They don’t want to risk getting blamed for failure or openly criticized for making a mistake, so they take fewer risks and hide their mistakes. Camille has accidentally created a culture of fear.

Micheal is a good leader: technical, charismatic, capable of making decisions and getting things done. He’s also good at keeping his cool. Instead of getting tense and angry, he gets curious when things don’t seem to be going well. His first instinct is to ask questions, and these questions often cause the team to come to their own realization about what’s going wrong.

Correcting a culture of fear :

Practice relatedness - 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 a little time for small talk. Ask people about themselves, get to know them as humans, and let them know you. Most people are scared to take risks in front of people they think will reject them if they fail.
Apologize - The goal of apologizing is to show people that you know your behavior has an impact on others, and to role model for them that it’s ok to make a mistake but that you should apologize when you hurt other people. You’re showing the team that apologizing doesn’t make you weaker, it makes the whole team stronger.
Get curious - When you get curious and learn how to turn that disagreement into honest questioning, you can learn more about other perpectives on the because your team will open up. This is how you get the most information out and help everyone make the best decisions.
Learn how to hold people accountable without making them bad.

True north represents the core principles that a person in a functional role must keep in mind as he does his job.

For a technical leader, true north means making sure that you’ve done your job getting things ready to go into production. It means you have honored you're agreed upon policies for review, operational oversight, and testing. It means that you won’t put something into production that you don’t believe is ready for users to experience. It means you’re creating software and systems you’re proud of.

True north leaders rely on the wisdom they’ve developed over time to make fast decisions when they don’t have time to delve into all the details. If you want to become this type of leader, you must spend enough time early in your career to hone these instincts in order to be comfortable making fast judgment calls. That means staying technical. following through with projects, languages, or frameworks long enough to learn more than their basics and also pushing yourself to keep learning new things even when your day-to-day doesn’t involve writing code.

If you want to create healthy teams, you need to have a sense of what is important to you, to your company, and to your growing group of colleagues. Consider not only what you care about, but also how you can scale that knowledge and effort effectively as the company and team grows and evolves.

Structure is how we scale, diversify, and take on more complex long-term tasks. We do it to our software, we do it to our teams, and we do it to our process. In the same way that strong technical systems designers are capable of identifying and shaping underlying system structures, strong leaders are capable of identifying and shaping underlying team structures and dynamics and going so in a way that supports the long-term goals of the team and equips the individuals to achieve their best.

The more people you have, the more thoughtful structure you need to get everyone moving in the right direction. Leaders who want a high degree of control over their organizational tend to need more structure in place to make sure their wishes are enacted.

Failure is the best place to investigate and identify where your structure needs to change.

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. Think about how often the failure happens and its cost, and use your best judgment about the changes that need to be made.

First, define your culture. If you have a set of company values, map those values onto your team. You may add a couple of values that are special to your team.

Second, reinforce your culture by rewarding people for exhibiting its values in positive ways. People can share core value stories at company all-hands meetings.

Understand what your company’s values are, understand what your team’s values are, and think about what you personally value. 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.

Writing a career ladder

Solicit participation from your team.
Look for examples.
Be detailed.
Use both long-form descriptions and summaries.
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.
Consider your breakpoint levels.
Recognize achievement
Split management and technical tracks
consider making people management skills a mid-career requirement
Years of experience
Don’t be afraid to evolve over time

People who design complex systems or who know the details of the latest iOS are the leaders and role models for the teams. In a product-focused structure, the leadership focus changes. Now the engineers who have the best product sense, the engineers who are capable of getting features done quickly and efficiently, and the engineers who communicate the best with the other functions will start to emerge as the leaders of the team.

Instead of calling the process a postmortem, many have started calling it a “learning review” to indicate that its purpose is not determining the cause of death but learning from the incident.

Resist the urge to point fingers and blame
Look at the circumstances around the incident and understand the context of the events.
Be realistic about which takeaways are important and which are worth dropping.

Great managers are masters of working through conflict. Getting good at working through conflict means getting good at taking your ego out of the conversation. To find a clear view of a complex situation, you must see past your interpretations and the stories you’re telling yourself. If you want to be able to tell people hard things and have them hear what you have to say, you must be able to tell them without embellishing the facts with your storyline. People who seek out management roles often have strong views on how things should be. That decisiveness is a good quality, but if can hinder you when you fail to see your interpretation of a situation is just that: an interpretation.