The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

If you are interested in improving on purely the people management side of leadership, books like First, Break All the Rules1 are excellent references.

1-1s serve two purposes. First, they create human connection between you and your manager. That doesn’t mean you spend the whole time talking about your hobbies or families or making small talk about the weekend. But letting your manager into your life a little bit is important, because when there are stressful things happening (a death in the family, a new child, a breakup, housing woes), it will be much easier to ask your manager for time off or tell him what you need if he has context on you as a person. Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it.

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 trust, real trust, requires the ability and willingness to be vulnerable in front of each other. So, your manager will hopefully treat you like a human who has a life outside of work, and spend a few minutes talking about that life when you meet. The second purpose of a 1-1 is a regular opportunity for you to speak privately with your manager about whatever needs discussing.

The second thing to expect from your manager is feedback. I’m not just talking about performance reviews, although that is part of it. Inevitably, you will screw up in some fashion, and if your manager is any good she will let you know quickly that you did.

A great manager will notice some of the little things you’re doing well in your day-to-day, and recognize you for them. Keep track of this feedback, good and bad, and use it when you write your self-review for the year.

Ideally, the feedback you get from your manager will be somewhat public if it’s praise, and private if it’s criticism.

Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.

Your manager should be the person who shows you the larger picture of how your work fits into the team’s goals, and helps you feel a sense of purpose in the day-to-day work. The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.

responsible, for the most part, for figuring out what types of training you want. This is especially true for individual contributors looking for training in technical areas. Your manager is unlikely to just have a list of interesting conferences or training opportunities at his fingertips.

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. Seek out feedback, including constructive feedback on areas to improve. When that feedback comes to you, take it graciously, even when you don’t agree with it. 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

Your relationship with your manager is like any other close interpersonal relationship. The only person you can change is yourself. You should absolutely provide feedback to your manager, but understand that she may not listen or change no matter how much you think she should. If you find yourself starting to actively resent your manager for whatever reason, you probably need to move to a different team or look for a new job. If you find yourself resenting every manager you work for, you may need to think about whether the cause is them or you. Perhaps you’d be happier in a job where you don’t have a manager. Especially as you become more senior, remember that your manager expects you to bring solutions, not problems.

The first act of people management for many engineers is often unofficial.

Mentors are commonly assigned to junior members of a team, such as new hires straight out of school or student interns. Many organizations use mentors as part of their onboarding process for all new hires. Sometimes the mentor is another junior person on the team, perhaps herself only a year or two into the organization; someone who can still clearly remember the onboarding or internship process herself, and can closely relate to the new person. Other times the mentor is a senior engineer who can act as a technical mentor in addition to helping the new hire get up to speed on the process. In a healthy organization, this onboarding mentorship role is used as an opportunity for both parties.

The screening process for such students varies; many companies view these opportunities as a pipeline to hiring great talent straight out of college, but if you’re taking on someone who is more than a year from graduation, it’s more realistic to expect that the candidate will a) know very little, and b) probably go elsewhere next year for his internship unless he has an amazing experience. No pressure.

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.

onboarding, getting used to the office, meeting people, learning the systems. Sit with him as much as possible these first few days. Get him started installing the IDE and checking out the code. Touch base several times a day to make sure he’s not feeling lost or overwhelmed by the volume of new information. In the meantime, prepare yourself for his project. Once you have a project, start applying your budding knowledge of project management to the task at hand.

One of the early lessons in leadership, whether it is via direct management or indirect influence, is that people are not good at saying precisely what they mean in a way that others can exactly understand.

Be prepared to say anything complex a few times, in different ways. If you feel that you don’t understand something your mentee has asked you, repeat the question in a different way. Let him correct you. Use those whiteboards scattered around your office, if necessary, to draw diagrams.

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

Have a project for him to work on. The best internships are those with a clear project. The trick to deciding on an intern project is that you want something specific but not urgent, something relevant to the team but also something that could be completed by an entry-level engineer in the span of, say, half the time that your intern will be there.

My first job out of graduate school could not have been more different. Instead of being shown a desk and left alone, I was set up with a mentor. He encouraged me to ask questions. We did some pair programming so that I could learn the code base, and the way that testing worked for this project (my first taste of unit testing!). I was productive within days, and learned more in the first few months of that job than I had learned in the entire time I worked at BigTechCo. I credit this almost entirely to the mentoring I got when I started. Mentoring new hires is critical. Your job as a new hire mentor consists of onboarding, helping this person adjust to life in the company effectively, and building your and her network of contacts in the company. It can be an easier job than mentoring an intern, but the relationship and mentoring will usually go on for a lot longer.

The unspoken rule is that you don’t take vacation the week after Thanksgiving because you’re in ecommerce and that’s an important week for the business. A more subtle unspoken rule dictates approximately how long you are expected to struggle with something by yourself before asking someone else to help you.

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 systems 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.

When you are a mentor Tell your mentee what you expect from him. If you want him to come prepared for your meetings with questions he has sent you in advance, ask for that. Be explicit about your time commitment. And then be honest with him when he asks questions.

When you are a mentee Think about what you want to get out of this relationship, and come prepared to your sessions. This advice is especially relevant if you’re getting mentorship from someone outside of your company, who is not being paid but is volunteering as a friendly gesture. You owe it to this person not to waste her time.

Tips for the Manager of a Mentor What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals.

These programs can be nice, but often the mentor and mentee are given very little guidance beyond the fact that they have been matched together. Most of the time, these programs yield very little to either party. If the mentor is not engaged or is too busy to spend any time on this project, it’s a disappointment for the mentee. If the mentee doesn’t know how to ask for help or what to do with the mentoring relationship, it often feels like forced socializing and a waste of time for both parties. So if your company is setting up 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. Secondly, recognize that this is an additional responsibility for the mentor. If the mentor does a good job, her productivity may slow down some during the mentoring period. If you’ve got an engineer involved in a time-sensitive project, you may not want to push him into mentoring at the same time. Because this is an additional responsibility, treat it as you would any other important additional responsibility you might hand out. Look for someone that you believe can succeed in the role, and who wants to distinguish herself beyond her coding ability.

Finally, use this opportunity to reward and train future leaders on your team. 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. Brilliant, introverted developers may not ever want to formally manage, but encouraging them to mentor 1-1 helps them develop stronger external perspectives, not to mention their own networks. Conversely, an impatient young engineer may find a degree of humility when tasked with helping an intern succeed (under your supervision).

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. There is simply less demand for interns, and thus you should

Key Takeaways for the Mentor It’s important to focus on three actions for yourself as a mentor. Be Curious and Open-Minded

Your career ultimately succeeds or fails on the strength of your network. Mentoring is a great way to build this network. You never know — the person you mentor could provide the introduction to your next job, or even come work for you in the future. On the flip side, don’t abuse the mentoring relationship.

everywhere. 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. But what is the job of tech lead, really? What do we expect from this person?

others. My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process.

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 touchbases 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

This is a senior engineering role, but it’s a mistake to tie the notion of tech lead to one that boils down to the best or most experienced engineer on the team. 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 the work of designing systems, and learning this skill is valuable even for engineers who don’t want to manage people.

You’re a tech lead, which means you know something about software, and your manager thinks you’re mature enough to be given greater responsibility for projects. Having the technical chops and maturity is nothing, however, if you can’t figure out the biggest trick of being a good tech lead: the willingness to step away from the code and figure out how to balance your technical commitments with the work the whole team needs. 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.

The worst scheduling mistake is allowing yourself to get pulled randomly into meetings. It is very difficult to get into the groove of writing code if you’re interrupted every hour by a meeting.

Systems architect and business analyst In the systems 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 the 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.

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. Which pieces are critical, and which are optional? How can you work on the critical items early in the project?

Software developer and team leader Software developers and team leaders write code, communicate challenges, and delegate. As projects move forward, unexpected obstacles arise. Sometimes tech leads are tempted to go to heroics and push through these obstacles themselves, working excessive overtime to get it all done. 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 healthy organization, there is no shame or harm in raising issues early.

most important learning experiences of my career. Doesn’t agile software development get rid of the need for project management? No. Agile software development is a 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.

Ultimately, the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. A degree of forethought, in places where you can reasonably make predictions and plans, is the goal. The plan itself, however accurate it turns out, is less important than spending time on the act of planning.

Managing a Project 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 may 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. Here are some guidelines: Break down the work. Get out a spreadsheet, or a Gantt chart, or whatever works for you, and start breaking down your big deliverable (say, rewriting your billing system) into tasks. Start with the biggest pieces, then break the big pieces down into smaller pieces, then break those down into even smaller pieces. You don’t actually have to do it all yourself. If there are parts of the system you don’t understand well, ask for help from the person who does. Get the big stuff broken down some, and then turn your attention to the ordering of the work. What can start immediately? Hand those tasks off to the people who can actually turn them into ticket-sized work. Push through the details and the unknowns. The trick of project management is not to stop when you feel a little bit stuck, or tired of it. It is tiring and tedious, as I said earlier. And it’s not something you probably know how to do well. So keep...

How to Be a Great Tech Lead Great tech leads have a number of characteristics, but these are the most important. Understand the Architecture 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.

Be a Team Player If you’re doing all of the interesting work yourself, stop. Look at the tricky, boring, or annoying areas of technical need and see if you can unstick those areas.

Lead Technical Decisions You’ll be involved in most major technical decisions for your team. Involved, however, is not the same thing as being the person who makes all of them alone.

Communicate 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.

These questions might include: How do you like to be praised, in public or in private? Some people really hate to be praised in public. You want to know this. What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback? Why did you decide to work here? What are you excited about? How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of? Maybe a direct report fasts for religious reasons, which sometimes makes him cranky. Maybe he always gets stressed out while on-call. Maybe he hates reviews season. Are there any manager behaviors that you know you hate? If you asked me this question, my answer would be: skipping or rescheduling 1-1s, neglecting to give me feedback, and 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, that I should know about? Things like: Where are my stock options? You promised me a relocation bonus and I haven’t gotten it yet. Why are we using SVN and not Git? I didn’t expect to be so productive already! For more ideas, see Lara Hogan’s excellent blog post on the topic.

Create a 30/60/90-Day Plan 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.