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

by Camille Fournier

Especially as you become more senior, remember that 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, or how you want something more. 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.

Assessing Your Own Experience Here are some questions to consider as you develop this part of your career: Have you had a manager you considered good? What did this manager do that you found valuable? How often do you meet 1-1 with your manager? Do you come to 1-1s with your manager bringing topics to discuss? If your 1-1 is a status meeting, can you use some other means to convey that status? Do you feel that 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?

Listen carefully 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. Are you spending all your time thinking about what you want to say next? Are you thinking about your own work? Are you doing anything other than listening to the words coming out of his mouth? If so, you’re not listening well.

Clearly communicate With that said, 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. Therein lies the value of breaking the project down before the intern starts working on it: you’ve taken on some of the harder thinking up front. He may surprise you by finishing everything much faster than you anticipated, but what a happy surprise to have! Generally, you’ll need to provide some nudging and clarity along the way to keep the intern going in the right direction.

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 a culture of fear.

The alpha geek is usually an excellent, effective engineer who goes into management either because she was pushed into it or because she believes that the smartest person on the team should be the manager. She tends to undermine the people who work for her by belittling their mistakes and, at her worst, redoing the work of her teammates without warning. Sometimes the alpha geek will take credit for all of the work that a team does rather than acknowledging the strength of the team members.

At their worst, alpha geeks can’t let anyone else get any glory without claiming some of it for themselves. They are the origin of any good ideas but had no part in creating the bad ideas, except that he knew they would fail. The alpha geek believes that every developer should know exactly what she knows, and if you don’t know something, she will gleefully point out your ignorance. The alpha geek can be very rigid about how things should be done and closed off to new ideas that he didn’t come up with. Alpha geeks get very threatened when people complain about systems they built or criticize their past technical decisions. They absolutely hate it when they have to take direction from anyone they don’t respect intellectually, and can be very demeaning toward people in nontechnical roles.

If you’re ever in the position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role. 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.

Emotional labor is a way to think about traditionally feminine “soft skills” — that is, skills that address the emotional needs of people and teams. Because the outcome can be hard to quantitatively measure, emotional labor is often dismissed as less important work than writing software. It’s assumed to be something that should just be provided without financial recognition. I’m not suggesting that you should pay people extra money to serve as mentors, but they need to be recognized for the work they put in, and the mentor should be treated as a first-class citizen with respect to other responsibilities the person might have. As I said before, plan for it, and provide the mentor the time to do the job right. You have already invested in creating this mentoring relationship, whether it’s the thousands of dollars and many hours spent on hiring, or the overhead and coordination of creating a mentoring program. It’s worth continuing the investment through to fruition by recognizing that mentoring is work that takes time, but also yields valuable returns in the form of better employee networks, faster onboarding, and higher internship conversion.

Like mentoring like does make sense in one case — namely, having mentors from similar job roles. When the mentoring is expected to have a job skills training component, the best mentors are going to be people who are further along in their mastery of the job skills that the mentee is trying to develop.

Mentoring provides a great opportunity to cultivate curiosity and see the world through fresh eyes. When faced with a mentee’s questions, you can start to observe what about your organization is not so obvious to a new person. You might find areas you thought you understood but cannot explain clearly. And you’ll have the opportunity to review the assumptions you’ve collected in your time working that may be worth questioning. While many people think creativity is about seeing new things, it’s also about seeing patterns that are hidden to others. It’s hard to see patterns when the only data points you have are your own experiences. Working with new people who are learning things for the first time can shed light on these hidden patterns and help you make connections you may not otherwise have made.

It requires you to practice listening, in particular, because if you can’t hear the questions you’re being asked, you’ll never be able to provide good answers.

Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying. 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 development is a team sport in most companies, and teams have to communicate effectively to get anything done.

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. Whether you’re in the mentor’s seat or acting as the mentee, remember that your career is long and the tech world can be very small, so treat the other person well.

Assessing Your Own Experience Here are some questions to consider as you develop this part of your career: 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?

As with many titles in software engineering, “tech lead” lacks a common definition. The best I can do is draw from my own experience and the experience of 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. I could be the tech lead, despite not being the most senior person, because I was willing and able to take on the responsibilities of the role, while the rest of my team were more interested in staying purely focused on the software they were writing.

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.

Becoming a tech lead required me to change my focus. Work is now less about me and working on the most technically challenging idea or the most fun project; instead, my focus is more on my team. How do I empower them? How do I remove the obstacles slowing them down? Working on a rewrite, or some new exciting feature that helped me express the full extent of my technical prowess, might have been more fun, but what the team needed at the time was to tackle technical debt and to focus on operations. In the end the initiative was incredibly successful. The team reduced the number of critical paging alerts by 50%, and in the following quarter we almost doubled the number of deploys we were able to do.

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.

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 of groups of people. Finding places to apply agreed-upon abstractions to enable parallel work is key.

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.

As you can see from these descriptions, in the process of being a tech lead, you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others. Fortunately you don’t have to do all of these tasks at once. It may be uncomfortable at first, but you’ll find a balance with time and practice.

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

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.

Revisit the details as you get close to completion. Toward the end of the project, the tedium returns. It is time to really attend to the finishing details. What is missing? What testing? What verification? Run a premortem, an exercise where you go through all the things that could fail on the launch of this big project. Decide where the line for “good enough” is, socialize it, and commit to it. Cut the work that falls below the “good enough” line, and focus the team on the most important final details. Make a launch plan; make a rollback plan. And at the end of it, don’t forget to celebrate!

You get to write books, give talks, and create open source work — and with some luck and persistence, you earn a bit of industry-wide fame. No one cares that you’re a bit awkward or shy or expects you to evolve your communication style much, because what you say is so important. Everyone in your organization knows who you are, understands how valuable your work is, and is deferential to your opinions. In short, you have the perfect balance of engaging work, fame, and accumulated expertise that makes you invaluable and respected, highly paid, and influential.

Your manager is kind of a pain. She isn’t terribly supportive of your desire to open source a system because you think it provides a new twist on logging that the industry needs, and she suggests that if you want to give talks or write books perhaps you need to spend some of your personal time on those efforts. She seeks out your feedback on technical matters, but sometimes forgets to tell you about new initiatives until it’s too late for you to put in your two cents. You suspect that you are missing out on crucial information because you aren’t in the right meetings, but every time she invites you to sit in those meetings you remember how boring and inefficient they are, and how much valuable focus time you’re losing. And she doesn’t have much patience for your desire to be free of tedious work like answering email, interviewing, or responding to code reviews promptly. Still, you get to build things most of the time. You get to spend your time focused on technical problems, systems design, and engineering issues, and you don’t have to do all that much dealing with people or sitting in boring meetings. You can often choose your projects and can easily move between teams if you want something new. And you just found out that you get paid more than your manager! So, life isn’t all bad.

You can make decisions — well, some decisions. Realistically, you can maybe narrow down the things that will get decided. You can focus your team on some things, like writing better tests, but they still have a product roadmap to implement, and they have their own ideas for what technical tasks should be prioritized. So, more than making decisions yourself, you’re helping the team make decisions. Your manager gives you goals but then sometimes changes those goals completely, and it’s up to you to explain the changes to the team. You do set the standards for culture on your team, which is good and bad. It’s good when they take after your best aspects, and it’s bad when you realize that your team is also mirroring your faults. Your team does not naturally just agree with you, respect you, or even like you. You realize that authority requires more than a title. You find yourself scrambling to motivate them through tough periods when the projects aren’t going well, or when you have to tell individuals that they aren’t ready to be promoted just yet, that they aren’t getting a raise, that there’s no bonus this year. Some of them don’t bother to tell you when they’re unhappy; they just get fed up and quit before you’ve noticed there’s anything wrong. When the company is doing well, and you have lots of money to pay, and there are plenty of exciting projects, life is great; but when things are stressful, you see how little power you have to make people happy. And what’s worse, you...

As a new tech lead, be careful of relying on process to solve problems that are a result of communication or leadership gaps on your team. Sometimes a change in process is helpful, but it’s rarely a silver bullet, and no two great teams ever look exactly alike in process, tools, or work style. My other piece of advice is to look for self-regulating processes. If you find yourself playing the role of taskmaster — criticizing people who break the rules or don’t follow the process — see if the process itself can be changed to be easier to follow. It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.

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.

If you’re only doing the most boring work, stop that, too. You’re a senior engineer who has a lot of talent as a developer, and 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.

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. If you start to make all of the technical decisions without soliciting the input of your team, they’ll resent you and blame you when things go wrong. On the other hand, if you make no technical decisions and leave everything up to the team, decisions that could have been made quickly can drag on without resolution. Determine 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.

Assessing 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?

We’ll talk about the main tasks required to manage people: Taking on a new report Holding regular 1-1s Giving feedback on career growth, progression toward goals, areas for improvement, and praise as warranted Working with reports to identify areas for learning and helping them grow in these areas via project work, external learning, or additional mentoring

Build Trust and Rapport One strategy is to ask a series of questions that are intended to help you get to know the aspects of the person that impact your ability to manage him well. 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 excell...

Encourage Participation by Updating the New Hire Documentation 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. As the manager, you don’t necessarily need to be the person walking the new hire through this process — that could be a job for a peer, mentor, or tech lead — but you may be the person to get this process in place, and you’ll need to reinforce it for everyone who joins the team.

The hardest thing about micromanagement is that there are times when you need to do it. Junior engineers often thrive under detailed oversight because they want that specific direction. Some projects go off the rails, and you occasionally need to override decisions made by your reports that could have big negative repercussions. However, if micromanagement is your habit, if it’s your default approach toward leading your team, you’ll end up like poor Jane, accidentally undermining the very people you need to be growing and rewarding.

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. This happens a lot when talented engineers become managers, especially if they pride themselves on their technical skills. If your value to the team has shifted from the thing you’re good at (writing code) to the thing you don’t yet know how to do well (managing people), it can be tempting to treat your reports as if they should be mini-mes. When a deadline slips, as it inevitably will, you view it as a failure to control the situation precisely enough, and so ratchet up the attention. You catch something not going the way you expected, and it seems to reinforce your belief that micromanaging the team is an appropriate use of your time.

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. On the other hand, delegation is not the same thing as abdication. When you’re delegating responsibility, you’re still expected to be involved as much as is necessary to help the project succeed. Sharell didn’t just abandon Beth — she helped Beth understand the responsibilities in the new role and was there as needed to support the project.

Treat the Open Sharing of Information, Good or Bad, in a Neutral to Positive Way Consider this scenario: Jack is having a hard time with a project, but hasn’t been asking for help with his problems. You finally hear about his struggles. At this point, it’s appropriate to tell Jack that he needs to be more proactive in sharing his progress, even if it means admitting he’s struggling. You could have Jack give you daily updates as a way of helping, but I would only use that much structure for a brief period. The goal here isn’t to 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 Jack what he needs to communicate, when, and how. A word of caution, 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 avoiding 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.

In the long run, if you don’t figure out how to let go of details, delegate, and trust your team, you’re likely to suffer personally. Even if your team doesn’t quit, you’ll end up working longer and longer hours as your responsibilities increase. If you’re already in this situation, try limiting the hours you’ll let yourself work in a week. If you were only allowed to work 45 hours this week, what would you do with those 45 hours? Would you really spend five of them nitpicking a junior developer’s code? Would you pore over the details of some project that is going smoothly, searching for any minor error? Or would you direct your attention to bigger problems? Would you take some of those hours to focus on the future instead of the details of the current moment? Your time is too valuable to waste, and your team deserves a manager who is willing to trust them to do things on their own.

This situation 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 tackling 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? 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 to fire someone in any environment where HR is active and a standard performance improvement plan is required. If you have no HR, I suggest that you still give people clear improvement feedback in writing, with a timeline for improvement, and have them acknowledge it in writing as well (email is OK). Not only does this protect you legally, but it helps you treat your employees fairly.

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?

Here is the job description that I used for the role of managing a team, which I called “engineering lead”: The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.

The person who fills this role is expected to have a large impact on the success of [the organization] as a whole. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs. The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their product group (pillar). They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team.

Not Shipping You may not think this is a dysfunction. Perhaps your team is in deep research mode on a new problem, for example. However, even teams doing research generally have goals and deliverables, even if they’re just in the form of initial findings. Humans, by and large, feel good when they set small goals and meet them regularly.

Sometimes, teams aren’t shipping because the tools and processes they’ve been using make it hard to get work done quickly. A common example is that your team only tries to release changes to production once a week or less. Infrequent releases can hide pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers who don’t know how to break their work down. Now that you’re managing the team, start to push for the removal of these bottlenecks.

You have to be brave and nip people drama in the bud quickly. It’s OK to ask your manager for help with this, especially if it’s your first time doing it, but be aware that your manager may actually have an even harder time dealing with the brilliant jerk than you do. She isn’t seeing the immediate impact on team dynamics; she’s just seeing someone who gets things done. Be prepared to have a series of conversations with both the employee and your boss. It may be that a move to a different team will clear up the situation.