Career Trajectory: Helping your team map their career paths
Developing and refining career maps will help your team determine their future career. Allowing employees to work on what makes them happy, and best achieves company goals.
Here's the recap...On today's episode we talk about the importance of setting your team up for success and growth. A renaissance is coming where the idea of the only way to grow with a company is by moving up the corporate ladder. Employees will have 3 paths they can travel, and will not be limited to staying on the one defined path. We share some insights into what those paths are, and how best to support your team on whichever path they choose.
The full episode transcript can be found below.
Here's the link to Tevi's post about mentor leadership.
Vertical
If you want more 💰 and a better better title, there's only one way to go. Up! Almost every outdated manager has stated throughout history.
Sadly many companies still use this methodology. If you want a raise or better year end bonus, you need to be promoted from an associate to a team lead to a manager to an executive. If you have an employee who's hungry and wants to take over the world, this is a great path.
Forcing great employees into management roles they aren't interested in is a waste of talent and energy. In the end, the great employee (now leader) will burn out. They'll fail as leader, and no longer produce quality deliverable accustomed to. Their team will fail due to the lack the great leadership they need.
Independent Contributor (IC)
A superstar coder or salesperson who simply wants to write code or sell lots of software. They enjoy their craft and happy when doing what they love. They aren't interested in corporate growth, and when forced to do so will look elsewhere. Instead continually reward, motivate and incentivize them for their great work.
Horizontal
An employee that starts in one role. Support, marketing, or design for example. Through their work they become interested in a different role in the company. Their experience can be a fresh perspective only brought in from an outside team. A Support rep who understands your product better than anyone else in the company. What users love and hate, or why users are looking at your competition. This experience perfectly blends into a product management role. Taking vast knowledge of how the product is being used to help best build the future of the product. As a leader, you can facilitate cross department projects to help give this employee the experience they will need in the new role.
Final Thought
As a leader the best thing you can do is stand behind your team, and support their journey in whichever path they wish. Whether it's setting clear KPIs and milestones to achieve a higher level title, keeping them happy doing the job they love best, or enabling them to gain the experience to shift roles within a company.
If you've ever been thrust into a leadership role you didn't want, prevented from better compensation due to a glass ceiling, or missed out on a switch to a different team since you 'lack experience' we want to hear about it. Drop us a line with your thoughts and feedback.
Scott: (00:02)
Hey everybody thank for tuning into today's show. Tevi, how you doing?
Tevi: (00:07)
I'm good. How are you Scott?
Scott: (00:09)
Good, good, good. So today we want to talk about something that is very special in my heart and something that I think about a lot. I speak to companies about this quite often. Employee career trajectory. It's something I believe, Tevi correct me if I'm wrong, that's been asked and we ask in many of our interviews. I think it's one of those worst questions you could ever ask during an interview. Where do you see yourself with the company in three to five years? First, get hired and than worry about it.
Tevi: (00:47)
We'll see you in 2015, nobody' said in a pandemic. So it's really hard to answer that question.
Scott: (00:53)
That's probably very accurate. I certainly believe that should be the first question asked to an employee on the first day of work. We'll dive in there, but I think it's super important.
Tevi: (01:09)
By the way, it's also important as a job seeker to ask the potential employer, where is this going? Where will this role end up in three to five years? Where am I going from here?
Scott: (01:21)
Yeah, for sure. Maybe we'll start off there on the employee side. For people who have that ambition of where they want to see themselves, and have that mental picture. Today I'm a developer, and in five years I want to be an engineering manager. The dream goal is. I think it's also super important for the employee that's coming in or even beforehand to know what that path may look like in the company? Is there a clear trajectory, and a clear map that that's drawn out that will allow that employee to be able to successfully grow from A to B to C? In addition, to know those milestones in that path they want to go?.
Scott: (02:09)
I think Tevi, you're spot on and I think it's something that's super important for an employee to know before they even join a company. Whether there's that clear path for them to understand and know where they want to go and how they want to go. Yeah.
Scott: (02:29)
I'll put it in on the side of the management team. Every employee on day one sits with their direct manager and a senior person. So depending on the size of the company whether it's a CXO, the CEO at a smaller company, or a VP up the line in a larger company. In 3 years or 5 years, I think five is a bit too long. I think three years is probably a better fit.
Scott: (02:52)
When that trajectory is set, it's super important to put clear milestones. So, in 6 months, 12 months, 18 months, so on and so forth to put easily defined to do's. Things to check off that list for within there. So it's very clear for, someone coming in as a entry-level associate level designer or a developer or customer support person, whatever it may be. Okay, here's what the path looks like. You're going to start as a frontline customer support person and six months from now you have to achieve these five things. Then after that amount of time, you let's say you become a senior associate. After 12 months you've accomplished these additional things after that. You then move into a team lead position. After 24 months, you need to achieve A, B and C where you can move into a support manager role. Having that that career trajectory that is clearly defined.
Scott: (03:47)
So the employee again knows what they need to achieve and how to achieve it. The company understands what needs to be achieved for the person to move up, and obviously gives them a clear path to do it. I think for me, it's from the experience that I've had over the years, it makes the conversations a lot easier and a lot smoother. I remember in the early days of working, it's having that conversation with the boss about a pay raise or a title change. It's always something very nerve-wracking. I put together PowerPoint presentations of all the things I've achieved and having that discomfort of asking for some amount of money or a title change. If you have that clearly defined career trajectory and that map in place, those conversations really don't even need to happen. Six months you've, achieved these five things. Okay. Automatically that title changes. There's a compensation change obviously so long as the finances allow it. It is clearly defined so that the company doesn't need to debate and look into, well, did they really deserve it? Should they get the title now? Okay. It's clearly defined; end of story. The same thing from the employee side. I've done these things. I don't need to debate what I did, what I didn't do. Here's the items that were set, and I've done them. Move on. Tevi, tell me your thoughts.
Tevi: (05:22)
I actually, a little bit disagree. I think like you have to have leveling conversations with your managers or your directors. Whoever is overseeing you. When I say leveling, I mean what is the next level that you're supposed to get at? I don't think you can really pick your five-year goal. I think it's absolutely impossible. I think that on a quarterly or an annual basis, you might be able to say I'm looking to shoot to accomplish this or learn that. It may not be a people management position. I know that it seems that the normal way for people to go in careers is managing more people. Some people just want to get really into their their development or their design or whatever it is that they are best at.
Tevi: (06:14)
They may not want to actually oversee other people. So I think that that's one side that they might be able to just think about what you want to learn and how you want to grow. On the other side, I think you also have to think about it from an employee's perspective. What is the actual potential at that company, especially in the startup world. You know, not every startup has massive traction and that's outside the individual contributors control often. So if I'm a developer and I'm in a company that has only like four or five other people, then what I want in two years might be different depending on if there's massive traction or not. So it should be more of like a constant conversation at quarterly reviews or even monthly. Say, "Hey, I want to learn this or work on that." As opposed to saying in five years, I want to oversee a team of 30 people because that may not happen.
Scott: (07:10)
Yeah, I completely agree. So I'll clarify my initial statements, so we're both on the same page. There's a big Renaissance coming around something that you had mentioned of moving up the management track versus an Individual Contirbutor (IC) track. Historically it's always been thatif you want a bigger paycheck, better benefits, or a better title you need to move up that vertical ladder. Up the management chain. I've seen through my career so many times where that doesn't work with people. Where people like being an IC. People love selling software. People love writing code. People love writing blog posts and that's what they want to do.
Scott: (07:57)
What happens is management says, "Hey, this person's super amazing developer, let's go hire three or five and put them under them." Now that person is going to magically become the greatest teacher and build a team of five amazing developers just as good as them. Everything is going to work out, and everything is going to be wonderful and in hunky dory. But most cases that doesn't happen because again, in that scenario, the person doesn't have the desire to be a manager or team leader. They just like writing code. I wanted to clarify that there areabsolutely the two tracks. For the person who wants to go up that company ladder to define where they see themselves.
Scott: (08:38)
On the other side for someone who wants to remain an IC, that their milestones would be different. It's not, taking on project leadership responsibility or team leadership responsibility. It could continue to be quality of code or quality of sales or number of sales. Potentially maybe with a mix of helping onboard new people, not in a specific leadership position but in a mentoring position or a mentoring opportunity. We're hopefully on the same page here that there's definitely the two tracks and depending on the track that you want to go they'll obviously be more clearly defined steps to get there. To another point that you said, it's definitely not specifically written stone, but it's based around those reviews. Whether it's quarterly, or at the half year.
Scott: (09:39)
Historically review processes have been complete crap. It's been, "What have you done in the last six months or last year so I don't fire you today?" It's never been focused a I, as a leader, have I enabled you to achieve the goals that you need to do to move forward? To move your career up the ladder or, continually being able to do what you want to do. Reviews need to be 360 degrees. From the employee side, was I able to hit my sales numbers? Was I able to have this code quality or the criteria in whichever field it is. At the same time it's has management been supporting me along this path. Tevi, your thoughts and support?
Tevi: (10:26)
I actually wrote a little while ago about what I call mentor leadership as opposed to servant leadership. My perspective on that is focused on so many people entering the workforce, and the difficulty to get your first job without having two, three years experience, which is kind of crazy. It's very hard for new designers and product managers and developers to get that first job. So I say that it's up to the leaders to help get people productive. To get people ready to work. Therefore, I think that there's a missed opportunity if you're not investing in your people to be better and to grow. If you're only looking at what they've done, like in hindsight, and you're not seeing what they could do in the future, then it's like having your money in cash instead of investing it. Because people are able to grow, they want to grow, and when you help them grow, they feel better about their career. They see a future at the company. Then you end up with someone who is more skilled and more capable and can do better. It's just a missed opportunity if you don't help them.
Scott: (11:34)
I totally agree. Do you think it's the same for every type of role or position, or do you that it is more defined on perhaps the lifecycle of a company. Maybe in an early-stage company it's more difficult, or it should be looked on negatively at hiring more junior person because you need them to hit the ground running. Do you still believe that the value of someone who's hungry and who's dedicated and passionate? If you give them the right tools and the right mentoring, do they have the opportunity to be just as successful as someone that's more experienced?
Tevi: (12:16)
Well, I don't think you ever want your entire team to be new grads, but I think it's important to have a percentage of people that are fresh and new. I think that gives you a new perspective to your team, when you include younger people with new ideas. I think that having more experienced people on the team also allows more mentorship opportunity from the other side to those young new grads.
Scott: (12:41)
I like it. Last week I had a debate on social media around developers. I've seen this quite a bit, that many startups don't want to hire junior devs. They want someone who hits the ground running. There could be some issues with the code base or the quality of the code they write later. Not being a developer myself, it was hard for me to debate that technically. From the business strategic side, I see the value of bringing in junior people. Not everyone's junior people. Giving them the opportunities, the room for growth and giving them the skills. Because again, how does somebody become a senior developer or a senior salesperson? They had to get a job somewhere. They have to be a junior a sales person or developer at some point. Some one has to kind of take that chance on them, and give them the experience and opportunity.
Tevi: (13:39)
It is a cost of business. I've worked with lots of younger designers and younger product managers. The way I dealt with it was simply moved out expected due dates and timelines to accommodate their learning curve. To give them a chance to get productive and to learn the right way to give that private one-on-one review. To get them to iterate a little bit and fix things. So there is a cost to pushing out timelines, of course, but I think you end up with someone who'sreally happy and fulfilled in their job. Who is appreciative that you've taken the time to invest in them. The work, the work is good. Could be good.
Scott: (14:21)
You believe it's something that also should involve the rest of the team? Should the other members of that team be involved in mentoring and onboarding? Or you as a leader in design or development, do you take that role specifically yourself and be that person's guide the entire onboarding period?
Tevi: (14:42)
I have usually taken that upon myself as a leader because I don't want to hurt the other team's productivity. If somebody has an experise that they are uniquely good at, I'll ask them to share and help out the rest of the team to getting up to speed. On the product and design side, there's always these people with very unique skills and very unique experience that they bring to the table. I try to always fill out a team and make sure that everyone compliments some sort of gap that's in the team. If there's a product manager who's got a deep technical expertise or another product manager that has deep domain expertise, I try to fill out the team with those different things. I do try to create opportunities for people to share their knowledge and skills. Then those people actually feel valued for being given the opportunity to share. Within balance, you know, you don't want to pull down the rest of the team to help out one specific person.
Scott: (15:38)
So two follow up questions. Based on your experience of leading teams, so number one. What do you see as that optimal onboarding time that within this amount of time mistakes are given slack and after that time, it's reduced? If trouble starts arising after that point, then maybe it's not the right person. Alterantively, do you need somebody more senior to start off with that question first.
Tevi: (16:10)
That's a very good question. I've always hired people who were able to be productive out of the gate. The question might be productive at what scope. So I've hired designers who had amazing graphic design sensibilities and illustration sensibilities, but maybe didn't quite have the interaction design stuff. So I'd be able to give them a project scope that was maybe just one screen at a time and or one control or component. So they could work on their design, but perfect it by limiting their scope on a smaller area. Then gradually giving them more and more to work on. From the same with like product management, there was someone who came to me, and wanted to switch to product management from more of a support role. He had good technical understanding as well. He was leading some IT integrations on the technical side. I saw him as having a good potential in another area. So I gave him more like a technical integration product project. I taught him how to measure impact and think about the problem we're trying to solve on a bigger level and working with data. The project I gave him, he was able to handle if he had someone to walk him through the business and data stuff. Once he got past that, he understood how the other stuff was working. He was able to work in other areas. I gave him projects that kept pushing him to a different level. He turned out to be a fantastic product manager.
Scott: (17:47)
I love it. That has opened up two or three more questions that I had. So let me start with the other one I had originally. What do you see as the optimal hiring rate of a junior person? Let's say you hire two or three senior people and then bring a junior person? What is that right fit when you bring in somebody junior versus a more senior person?
Tevi: (18:13)
Yeah, that's a good one. I mean, I don't know that there's a single answer. It's up to the team, And the problems we're trying to solve. I think at the very beginning of a small team, you have to have people who are able to hit the ground running. Because you need that leadership. You need that expertise to get to a certain level. Then it's up to you as a leader to see where we can be a little bit more flexible in who we hire and start filling up the team. As I said before, you have to have balance. You can't just have only new grads. What do you think? Is there is a really like a one size fits all answer?
Scott: (18:50)
I agree with you. I think there's no one, size firs all. No answer that goes there. It's dependent on the skills and makeup of the team. What are the opportunity and needs that you have open, and how would that person be filling them? Mirroring what you said, you need the early team to hit the ground running, as they are building the foundation. Once that foundation has been set, then bringing in that that junior person to give the extra.
Scott: (19:30)
My next question, if you want to ask questions, feel free to jump in. Something that you brought up and I definitely believe in, is a third track. The vertical, the IC, and the horizontal move. I've tried to champion this within companies that I've worked with. Let's say somebody moving from a support to product role. I personally don't see any better person moving into a product role than a support person. Because there's no one within the company that has more of a finger on the pulse of what's going on with the users and understanding of the good, bad and ugly. Tevi, how do you see the opportunities within the teams that you have of moving people horizontally within roles?
Tevi: (20:28)
I think your question shows why it's impossible to have a five-year plan. People do stuff and realize, "Hey, I don't like this, or this looks interesting. I didn't know about this." Someone who's doing support and maybe that was just a job they got initially, and they've done it for a few years. Now that they've been in a tech company for a while and can see other roles they no idea about. I didn't know about product management when I was in high school. That was a non-existent role, I think at the time. Your career evolves, and your goals should allow you to evolve your career. So I would say that it's a horizontal move from a title or from a scope. I don't know. A Focus area perspective, because support and product are different. Similarly, with design people who may go from branding or graphic design into interaction with UX design. I've seen people come from everywhere from design and product. At this time, my focus is on product. So that's, I think you should allow people to make those moves and give them the opportunity to learn more. Why not?
Scott: (21:40)
I completely agree. From what I've seen from all these years of experience, it's similar to a junior role. If you are a support person, or a product person wanting to move to design, you don't have that design experience. You don't have that product manager title on your resume. As a manager or a leader you may have people on your team that want to move into a different role. Is there a best method to do that? Is there a way to kind collaborate? Now as a support person, work with the product team and do a project. I don't want to call it a test drive, but having some opportunity to get that experience on the product side. See if it works well for all the teams involved. Is it taking the chance on somebody internally moving between roles, or is there a better opportunity in running an internal project across teams to see if there's a good fit?
Tevi: (22:54)
I've done it many times in multiple companies, and I did it exactly that way. Where somebody came to me, like a designer who said he doesn't think he's that good of a designer and he really likes writing code. He asked if there was a project he could do where he writes more code,. Still be a designer, but what he wanted to write more code. We wanted to do an entire front-end design system. I said, "Hey, you know what, why don't you do the front end code for that as well?" As opposed to just only doing design. Maybe he could write the code for that. It would be like all tied together to the whole library was his graphic assets, as well as, code assets.
Tevi: (23:42)
I worked it out with the CTO. They actually happened be underhanded on the front end side. So he was like, yeah, why not? Let's do it. It worked out, and it was a project based thing. He decided that he really did prefer that. He ended up leaving to go join a different company as a front-end developer. That was cool, and I was happy for him. He found something that he liked. He did a good project that worked out for the company. It's all about trying to understand what they want. I think as a leader it might be hard because you want your team to do what you want them to do. Maybe you can't always afford to have them do something else, but if you could accommodate it might work out. In this case, it worked out with this project. But then I ended up losing a good player to somewhere else. We actually ended up working together again later. So that was kind of cool.
Scott: (24:33)
It's an amazing point. I'm definitely a believer that within a company you want that person to grow in whatever direction they want to go within your company. Giving them the skills, the experience, the tools, and different pieces to be able to achieve that dream goal that they have. Even if it's with a different company. Because there could be ceilings, people in the roles, no opportunities, or no funding,. Hopefully it's within your own company, but if not, it's still letting that person achieve that growth. And of course being supportive of them. That's what leadership is all about.
Tevi: (25:26)
Would you want someone on your team, Scott, who wanted to do something else but you didn't let them? Wouldn't you see that as a problem?
Scott: (25:34)
For sure. If they want to do something else it means they're not super excited at doing what they're doing now. So my focus would be, how do we allow them to do that? Whether it's in one quick jump in, moving between departments or that smaller project step. Let's work together with a different department and run a project together. See how you like it. See how it works. If that's the right optimal move okay, then do it . Because again, as a leader, I want you to be successful. I want you to be happy. I want you to enjoy what you're doing every day, because if you do, then I know you're going to give 110%. Keeping you stuck is not what I want.
Tevi: (26:22)
Yeah, exactly. I mean, the way I see it is it's a ticking, it's a ticking clock. If he comes to me and says, I want to do X instead of Y. I say, no, then he's going to look to leave. He's going to be unhappy now. Whereas if I say, yes, let's try to figure out how we can do X in your current job. It turned out to be a benefit. He ended up leaving anyway, but this way we actually got something good out of, and I maintained a good relationship. We ended up having another opportunity to work together later which is fantastic. Why would you want to burn that bridge and make someone unhappy and beat them down when they're going to leave anyway.
Scott: (26:56)
It certainly creates a negative impact on the happiness and engagement within the company. Whether it's hopefully going to be within a jump within your company, or it's going to be a jump externally but at least giving them that opportunity to do something that they're passionate about. Including project slack time. The well-known Google Slack time that created Gmail, Google maps and all those other things that came along with it. I think it's super important to give an opportunity and empower the employee to move in the direction they want and stand behind them. It's certainly not standing in front of them.
Tevi: (27:50)
Then the positive is the second case I gave with, with the product side. Where that ended up being a really big win for the team, in my opinion. Because we had a really great person with great customer service experience, that understood the customer needs, and understood the technology. He became a solid contributor to the product team. He stuck with the team and did great work. So that was an even better benefit. So the way I see it is you could create a culture which allows people to come to you as a leader with their dreams and desires for their career. You can provide a safe place and see if you can help them. Maybe they leave the team, but either way, they're going to be unhappy and leave the team. At least this way, there's a benefit of maintaining a good relationship with somebody who you might get to work with later. On the other side, the bigger benefit is they become an even better contributor to the team,
Scott: (28:41)
100%. Any last thoughts?
Tevi: (28:45)
I'm curious from your side. I know you've been managing support longer. Have you seen people transfer into support or try to change their direction within the team?
Scott: (28:57)
I haven't seen many people move into support versus going the other direction.
Tevi: (29:04)
All your people are leaving your team to join my team.
Scott: (29:07)
Exactly. It's a very good question. I believe that every company should do company-wide support. So everyone's doing support from the CEO down. In my experience, I haven't seen many people move into that role. I've seen people kind of brush up against it, especially on the development or maybe product side. I've definitely seen, seen people transition from a support role into a product role. Nobody knows the product and what's going with the users better than the support team. I've also seen them move into more technical roles. Understanding how the product works, but now wanting to be more involved in building it. I've even seen people move into design roles. Understanding the use cases are, and what's going on with the product. Being able to try to better the design of the product and move it forward. I definitely try to enable people to move into their right role from starting off in support, which I believe is probably one of the best places that you can start to branch out in.
Tevi: (30:17)
Yeah. I agree. I used to make designers sit on the phones. I remember I was doing user research once where I had to go to call centers and I was sitting on the phone hearing these conversations. I would say 90% of the phone calls that came in were always edge cases. So when your entire life is steeped in edge cases, as a support person, you get such a different perspective on the product than someone who designed the product with thinking only about the best case scenarios.
Scott: (30:51)
37 Signals or Basecamp folks were very much of this mentality. Especially at the beginning. Building something for yourself. My specific use case, my need, my whatever, building that for that initial product. It's a great opportunity to get from support and other customer facing teams that people are using it for the reason that you built it. As the product grows you have many other use cases of why they're using, including ones you probably would have never thought about. It allows a product and management team to get some perspective and understanding of know how else the product can be used. The how's and why's, and what's
Tevi: (31:41)
So what do think is the one thing you want to leave our listeners with regarding career trajectory?
Scott: (31:46)
As a leader, you want to be very supportive of where you people want to go. Whether that's an opportunity to move up the ladder and moving into a management position. Whether it's staying in an IC role and just selling software or building it. Alternatively it's in the horizontal role. Moving from a support to a product team or some kind of horizontal move like that. It's being supportive; it's trying to stand behind them and giving them the opportunities. Whether it's the leadership opportunities to move up in team leadership. Whether it's the project opportunities to move horizontally or giving them the engagement and reward for continuing to be the best salesperson on the team. Make sure you're standing behind and supporting. Definitely not standing in front of anybody preventing them from moving in whatever direction they're looking to. Certainly being open to all three directions, I think is super crucial. Not just the old fashion is either up or down. How about you?
Tevi: (32:49)
I think that's great. I think as a manager, as a leader, you want to leave your culture open enough where your team can feel comfortable to approach you with career question or a career request. I totally agree. You want to be supportive and see how you can help them. You know within the confines of the team and company, which can help the company. If they're not happy, then it's best for everybody that they leave. Instead of having someone who's presenting as resentful and bitter on the team.
Scott: (33:18)
I like to leave questions for our listeners. I'm curious for anybody out there listening. Did you ever have a horizontal move in your career? Did you ever approach a manager? How was that received? Share your story with us. We'd love to hear.
Scott: (33:32)
Yeah, please do. Tevi, thank you so much for the great conversation again today. Until next episode, we'll speak later.