In our professional lives, growth is a constant pursuit, not merely for our development but also for the organizations we represent. We’re all learning all the time, albeit in different ways and at varying paces. In nurturing an employee’s growth within a role, two approaches frequently come to the fore: mentoring and coaching. While both are powerful tools, they serve different purposes and are best applied in specific contexts – sometimes, we need a guide, and sometimes we need a goal-oriented strategist.
Choosing the Right Approach: Context is Key
“Coaching is for performance. Mentoring is for potential.”
The choice between coaching and mentoring hinges on the context. Here are some hypothetical situations to illustrate this.
Consider an employee who is a subject-matter expert, consistently delivering quality work but struggling to make presentations to stakeholders. In this case, a coach could help the employee improve their communication and public speaking skills, with clear, measurable objectives for their progression.
In contrast, imagine a new recruit with immense potential but little experience in the industry. With their wealth of experience and industry knowledge, a mentor could provide this newcomer with invaluable insights about the sector and career development advice, supporting their long-term growth.
When explaining the difference, I often contrast these roles by saying, “With mentoring, I will give you my opinion. With coaching, I will ask you the questions necessary for you to form your own approach with my guidance.”
The mentoring approach works better for more experienced professionals expanding their skills to new areas. The coaching approach is better for someone who needs to deepen their skills in an existing area. Coaching is also effective when helping someone in an area where you don’t have as much direct experience. You can leverage your experience in other areas to help the person figure out the answer themselves.
Be explicit in your choice of method
Know if you are taking a coaching stance or a mentoring stance when helping someone. That does not mean you can’t give advice when coaching or ask prompting questions when mentoring. It means you and the person you are working with understand how you will approach the interaction. It sets the tone and expectations.
“Mentoring and coaching are not an ‘either-or’ proposition but a ‘both-and’ necessity.”
While mentoring and coaching have unique strengths, it’s essential to recognize that both are integral to fostering a growth culture in an organization. The mentor-mentee relationship builds a knowledge-sharing culture, and coaching empowers individuals with specific skills to excel in their roles.
In our pursuit of growth, remember that we’re not merely ticking off a checklist. We are on a journey that requires us to understand when to take the scenic route of mentoring, appreciating the broader view of the professional landscape, or when to go straight ahead with coaching, focusing on the immediate roadblocks ahead.
Remember to share your insights and experiences as you continue on this journey. We are all co-travelers in this quest for growth and learning; every insight contributes to the collective wisdom.
A former co-worker reached out to me recently. They are a director of engineering at a midsize startup and just got their first headhunter inquiry for a CTO role. Having never been in the role before, they wanted to know what the position was like and how to prepare for the interviews.
I realized that while there are some books on technology leadership careers, there aren’t many resources explaining the most senior levels. My goal is to provide some insight and advice for those interested in someday becoming a CTO.
I’ve been a CTO for five and a half years
I’ve worked at a hundred-thousand-person company, seed-stage startups, and many of the variants in-between. I started as a developer and followed a traditional path of moving up to more senior levels on the development track and then moving to lead, engineering manager, director, VP, and now chief technology officer. I’ve been the CTO at three different companies in two countries and three parts of the technology industry. I’m part of a few networks where I meet and talk with CTOs of all sizes and stages of companies.
I’ve learned that one reason there isn’t a good reference for the role of the CTO is that the size of the company and the expectations of the CEO define the job. Some of my role expectations and responsibilities are like those of many of my peers at similar-size companies. However, there are also significant differences in our expectations from our executive peers and boards.
Because of the variability of the role, I will broadly share my direct experiences, joined with an understanding of the expectations of other CTOs that I know.
The early-stage company CTO is often the developer-in-chief
At earlier stage companies, the CTO is often the technical co-founder. They are likely the developer who built many of the earlier versions of the software and helped hire the original development team. Their responsibilities are primarily technical: driving architecture, doing advanced development tasks, and creating technical vision.
Frequently, the first CTO of the company is hired for their ability to code and not their ability to grow or manage a team. Depending on the person, they may also lead the development team. Still, often the team’s management will eventually move to another person, an experienced manager, who may report to the CTO or be a peer to them.
The early-stage CTO is the leading technical voice for the company externally, especially if they are a co-founder. They talk to investors and potential partners and meet with potential vendors. If they also manage the development team, they will solely represent engineering in the senior leadership team. As a result, they will have responsibility for the decisions made by the engineering team. Nevertheless, if they do not manage the team directly, they might not be involved in the decisions around the day-to-day operations.
A mistake that inexperienced founding CTOs often make is that they don’t understand their role beyond coder-in-chief. They focus solely on the technology and are not active participants in the company’s leadership. As a result, they do not work cross-functionally. CTOs fixated on the how without the why or what will not be in the role very long once the company grows.
If they have no experience leading an engineering team or organization, the early-stage CTO will be challenged to grow with the company. If they cannot scale, eventually they will end up in a subordinate role reporting to a more experienced CTO hired to replace them.
The midsize company CTO is responsible for leading the organization, corporate strategy, and making technical decisions
Once a company reaches a size at which it needs new processes and structures, the scrappy leaders who helped get the company off the ground are often replaced with more experienced leaders knowledgeable in taking companies through the next growth stage. If the CTO hasn’t grown into the larger role, they will be part of that replaced group.
The midsize company CTO is a full-fledged executive team member working cross-functionally and meeting with partners, investors, and customers. Frequently, the midsize company CTO will also manage the engineering organization. The CTO is responsible for setting technical direction, making sure good architectural decisions are being made, and establishing best practices and working methods. They are still expected to have good technical depth, but don’t often actively contribute to shipping code. A red flag for me personally is seeing a CTO role description where the expectation is to lead a 50-plus-person organization while also actively coding on the product. It means the executive team does not have appropriate expectations for the role.
A midsize company CTO spends significant time establishing culture and practices for the teams they are responsible for; they are also very directly accountable for the organization’s decisions and its track record of delivery. The CTO meets internally with members of the other functions, such as sales, marketing, HR, and finance, to share direction for the organization and get feedback. The CTO is responsible for the administration of the teams, including the budget.
The CTO is also responsible for hiring, performance management, and team structure and may be very active in their teams’ recruitment and interview processes, especially in a scale-up type of company.
A CTO leading a more extensive development organization must be a generalist, understanding different roles and responsibilities. Their remit may include Corporate IT and Technical Support. In some companies, they may also manage the business analytics, security, product, and UX teams. A CTO who is too focused on the areas closest to their background or does not respect non-coding functions will not succeed.
As a midsize company CTO, you will often spend as much time with your peers and their teams as you spend with your own. As a result, you will need to learn about their functions and how your teams can work together. CTOs who “stay in their lane” will not be seen as an equal member of the senior leadership team and may lose their say in decisions that affect the organization.
It is very unusual for someone to move into a midsize company CTO role without having some experience leading a multilevel-development organization and working with other business functions.
Growing (or moving) into the CTO role
If you are a manager or a manager of managers with the goal of being a CTO, there are a few things you can start to focus on that will help you on your path.
Learn about the business your company is in
Offer to sit in on sales calls, on user research interviews. Try to understand the company’s financials when the CFO presents them. If you can’t, make a friend in the finance team and ask them to explain them to you. Understand the KPIs not only for your team, but also for the teams around you.
Learn about the other functions
Get recommendations of reading or conference talks from your peers in the product, UX, and marketing teams. Think about how their work influences yours, and yours influences theirs.
Respect and learn other technology areas aside from your own
If you lead an area you don’t have personal experience in, approach the people in that function with respect and a genuine desire to understand their work. They want to help you know what they do and how they do it.
Hone your craft
Hopefully, you are already working on deepening your skill as an engineering manager or director, but are you trying to understand the bigger picture? Read other companies’ (public) handbooks, engineering blog posts, and conference presentations about their ways of working. What practices are interesting? Which can you try in your team? How do you think they will scale, or what issues do you think they may have?
Ask your CTO if there are tasks they can delegate to you
The best way to learn the job is to do the job. Even better is having someone who is already doing the job explain to you how they perform it so you can help them.
Start thinking in terms of strategy
The main difference between the expectations of line managers and senior managers is the emphasis on strategic thinking. Executives contribute to the company’s strategic planning and use their understanding of the company’s goals and the current situation to make sure that their teams are setting up the conditions for the company’s success. Strategic thinking is a learnable skill, but it takes practice.
The rewards of being a CTO
Being a CTO was not what I imagined it to be when I first decided it was my career goal. It is a lot of work, carries much stress, has fewer perks than you might think, and can be somewhat lonely. However, it is also the most personally rewarding job I have ever had. With the challenges, there is also incredible responsibility, tons to learn, the ability to influence the company’s direction, and the chance to affect the lives of dozens or hundreds of people on your team. I have yet to regret my choice to pursue this role.
By letting go of writing code, you open yourself up to excelling as a manager.
I am a computer programmer.
I was one of those people who started coding at a young age – in my case, on a TRS-80 Model 1 in my school’s library. I loved the feeling of teaching the computer to do something and then getting to enjoy the results of interacting with what I built. Since I didn’t own a computer, I would fill spiral-bound notebooks with programs that I would write at home. As soon as I could get time on the computer, I would type it in line-by-line. When I learned that I could write software as a job, I couldn’t imagine anything else that I would want to do.
After university, I got my dream job writing 3D graphics code. I was a software engineer! I defined a successful day by the amount of code I wrote, the compiler issues I resolved, and the bugs I closed. There were obvious, objective metrics that I could use to measure my work. Those metrics and my job defined me.
Today, I am a Chief Technology Officer, leading software development organizations. If I am writing code on the product, it is probably a bad thing. I now have to define my success by much fuzzier metrics: building good teams, hiring and training good people, setting multi-year technical strategy and vision for the company, collaborating with other departments, and setting and managing a budget. I may have a good day or a bad day, but I have to measure my success based on quarters or years.
My achievements are now always tied to the successes of others. Getting to this point wasn’t easy, but I wouldn’t have it any other way. It was a journey that took years, and the first challenge was understanding that coding was no longer my job.
Why is it hard to stop coding as our day-to-day work?
When I speak to engineering leads or managers working to grow into more senior engineering leadership levels, the question of ‘How much do you code?’ is very often raised. We usually have a hard time imagining that we can still be useful if we don’t code for a significant part of our time. Why is that?
We’ve been traditionally bad at hiring managers in the software engineering industry
Usually, companies choose development leads because they are the best, technically, on the team. I would guess that the reasoning behind this is that it’s assumed that the best developers are the right people to supervise their peers. This practice creates the impression that managing others is a promotion for a skilled developer when, in actuality, it is a career change away from what made them successful in the first place.
The worst managers I’ve had were very talented developers who hated having to spend time doing the boring stuff that wasn’t coding. They resented the time spent away from the keyboard and weren’t always good at hiding that fact.
Many companies now feature dual career tracks for technologists, giving them a choice to advance as an individual contributor or move into management. This choice of career is an excellent thing. It means that if you want to spend your days coding, you can do that without sacrificing your career. It also means that if you desire to find joy in leading teams and growing others’ development and skills, you can do that.
We fear becoming ‘non-technical’
We joined the technology industry to be close to technology. We fear that by moving away from coding, we will morph into the classic ‘pointy-haired boss’ – ridiculed by the people on our team and unable to understand what the developers are discussing. I won’t say this can’t happen, but it won’t happen on its own. It will only happen if you choose to avoid technology once you move into the management role.
As you take on broader leadership responsibilities, you will need to learn and understand new technologies. Moving beyond the specifics of your expertise is necessary for you to move up in management. I have managed developers coding in at least a dozen languages on the backend, frontend, mobile, operating systems, and native applications. I have also managed testers, data scientists, data engineers, DevOps, Security, designers, data analysts, program managers, product managers, corporate IT teams, and some other roles I don’t even remember anymore. It isn’t possible to be an expert in all those fields. I need to take the lessons from my time as a developer and use them to inform my understanding, help me learn new areas, and give me empathy for the people who work for me.
It isn’t that you will become non-technical. It is that you will become less narrowly technical.
As a new manager, we are often expected to continue coding
It is common to move from being a developer on a team to managing that team. As the new manager, this means you are still responsible for part of the codebase. Unless you immediately start leading a large group, your new role still requires that you spend a significant portion of your time coding. This expectation makes the transition to the new role more comfortable – but it can also be an anchor that holds you back from embracing your new role as your management responsibilities grow.
We still see ourselves as a resource that can ‘save’ a deliverable
As a manager, you are accountable for the results of your team. If the group is struggling to make a deadline, it might be tempting to jump into the weeds to try and help the team finish the project on time. While this is sometimes the right decision, it can also make the problems worse because the team loses the person who looks at the more significant issues and coordinates with other teams to get more help or prepare them for the delay.
Why do we need to stop coding eventually?
We don’t need to stop coding, ever. However, once you move into engineering leadership, it will need to become a smaller and smaller part of your job if you are working to lead larger teams or broaden your responsibilities scope.
I had led teams before I was a manager at Adobe, and I had always spent a significant part of my work week contributing code as part of the groups I was in. At Adobe, though, my team had grown to be fourteen people, with another four dotted-lined to me.
I had been the primary developer for a part of the project, and I took pride that I was still contributing important features to every release. However, my management responsibilities were starting to fill my work weeks. Between 1:1s, sync meetings with other teams, and other manager work, my feature development time was increasingly moving into my evenings and weekends. My features were often the last to be merged and usually late.
The company had two mandatory shut-down weeks. To work during this time, you needed the prior approval of a Vice President. The team was preparing for a release, and my features were still in the to-do column; I met with my VP to get his permission to work over the shut-down week. He asked me, “Who is the worst developer on your team?” I hemmed and hawed – I didn’t want to call out anyone on my team, and I hadn’t even really considered the question. Seeing my uncertainty, he answered for me. “You are! You’re always late with your features. The rest of the team is always waiting on you. If you were a developer instead of the manager, you would be on a performance improvement plan.” He was right. My insistence on coding was hurting the team, not helping it.
Taking on the lead role doesn’t mean you should stop coding immediately, but it does mean that your coding responsibilities should now be secondary to your leadership ones. There are other developers on your team, but there aren’t other leads. If you aren’t doing your lead job, no one else will. Similarly, your professional development’s primary focus should now be on your leadership skills, not your coding skills. You are moving into a new career, and if you don’t work to get better at it, you will find yourself stuck.
As your leadership responsibilities increase, you should transition your development responsibilities to other people on the team. This transition is good practice because delegation is an essential part of leadership.
How do you stay ‘technical’ when coding isn’t your job anymore?
As I said earlier, staying technical is a choice that you need to make. Hopefully, one of the primary reasons you chose to make a career in the technology industry was that you were interested in it, so this shouldn’t be a problem.
As I also said earlier, as you develop as a technology leader, your focus broadens as your scope widens.
The best way that I have found to remain a credible technologist for my teams is to be interested in them and their work. To do this, talk to the people on your team and take a genuine interest in the things they are working on. If a technology comes up in a meeting or 1:1 that you don’t know, add it to a list of things to research later. Then, dedicate time in your week to go through that list and learn about the technologies well enough to have your own opinions about them. This practice allows you to have further discussions with whoever mentioned the technology to you.
If you get interested in what you learn about the new technology, you may want to keep trying to understand it better; you may read more or embark on a personal project using it to gain more practical knowledge. As I said, it isn’t that you have to stop coding, it is that, eventually, it shouldn’t be your day job anymore.
By taking an interest in the technologies your team uses in their work, you deepen your empathy for them and expand your own knowledge. You’ll be able to discuss the work, ask reasonable questions, and make connections to other things happening in the organization and your own experience. This way, the people on your team know that while you may not be able to step in for them, you understand their work and care about it.
Success is defined differently when you lead people
The feeling of accomplishment that comes from completing a cool user story, deploying a new service, or fixing a difficult bug is significant. It is a dopamine hit, and just like other dopamine-inducing behaviors, it can be hard to stop.
Having a great 1:1 or leading a productive team meeting can also feel good but in a more esoteric way. As a team leader, you need to learn to perceive the success of making others successful. Success takes longer, but the feeling is more profound and more rewarding.
Having a release resonate with your customers, being able to easily justify the promotion of a developer that you have mentored, and having someone accept a job offer for your team, are all fantastic feelings. In the day-to-day, watching stories get completed, helping resolve the issues when they aren’t, and seeing people get excited about the direction you’re setting for the team can leave you feeling satisfied at the end of the day.
Being a technical leader doesn’t mean writing code every day
As you grow in your new leadership career, you will need to devote your time to mentoring, developing, and leading your team. As you spend less time in your code editor, you will find new challenges in strategy, clearing roadblocks, fixing broken processes, and new tools like HR information systems, slides, and spreadsheets (it isn’t as bad as it sounds). You will spend less time learning all the intricacies of a specific language or toolchain and instead learn about how systems interact, understand when to build vs. buy, and learn about entirely new areas of technology. And you can still code, but make sure that you aren’t the developer holding your team back.
In September of 2019, I gave a talk “Developing Your Developers: Constructing Career Paths For Your Technologists” at the Honeypot Hive Conference in Berlin, Germany. The slides from the talk are below. There were many questions from the audience that I didn’t have time to answer. The questions and answers are here. The talk was recorded. I’m hoping that the video will be posted in the near future.
How the organizations you worked in were going about diversity recruiting? What kinds of initiatives were being taken?
In companies where we have had made good progress on diversity recruiting, we used a few different initiatives:
Made it clear to the organization that it was a priority by regular communication, and updates on our progress
Engaged the recruiting team to ensure that hiring pipelines included a reasonable slate of candidates from underrepresented groups, even if that meant taking longer to fill the role.
Incentivized external recruiters with bonuses when we hired candidates from underrepresented groups
Actively participated with external groups supporting underrepresented people in the industry
Ensured that every hiring pipeline included a diverse panel
Can you give an example of what you retroactively changed in a career framework without being too intrusive?
At Spotify, we created a new framework where there had been none. At Avvo, we completely replaced a very traditional structure with one more suited to our culture. At Onfido, we are currently evolving our framework. We are making conscious deltas from the previous career-pathing model to support how our culture has evolved. We have clear goals and will follow the path described in my talk to make sure that the team understands and supports the changes.
How did you test the distribution?
We tested the distribution by doing an exercise with all the managers where we did a preliminary slotting of each person into what level we thought they would go into, including doing a calibration across teams. We then compared the resulting distribution with the one we expected to have when we designed the framework. This simulation also served as part of the training for the managers in the organization.
How do you roll out an updated growth framework in a company where you have something in place? Do you then re-map existing people within new levels?
You should roll out a new framework in a similar way to creating a new structure from scratch, but you should make the process of how you will map from the existing framework to the new one explicitly part of the plan. The mapping will be unique to the old and new pathing models, but you should do a calibration step to make sure that people get mapped fairly.
A lot of companies do give you more money only when you threaten to leave. Should people be rewarded for staying also when they don’t get promoted with a title?
If the only way for an employee to get a raise is for them to threaten to leave, then the company’s compensation system is broken, and they will struggle to retain employees.
Do you think there is a possibility to develop an application for career development? (If yes, let’s meet :))
I know of one, https://www.progressionapp.com/, our design team uses it at Onfido. In general, it is hard to develop a career development tool that would be useful for multiple companies because, by requirement, it would need to be generic. I’m advocating for each company to build a unique career development framework. So, there is a mismatch there.
Is there a single company doing all of this well?
I think that many companies do this well. I only have direct experience with the ones that I have worked at, though.
Thank you, Kevin, for your interesting speech. I don’t have a question but as introvert I wanted to thank you for bringing up this issue.
You are welcome!
What about the people who are not promoted, do they have to work on continuous improvement to reach the goal.? Or are they considered as under achiever.
That will be contingent on the company culture. Some companies have an “up or out” culture that expects people to be continually working towards the next milestone in their career progression, or they will be moved out of the company. Other companies support folks who do not choose to pursue the next level. It’s a decision that must be incorporated into the design of the framework itself.
What to do when someone wants to be a manager but is clearly not going to be a good manager – how do you present other options to them?
You should have tracks that support people who want to remain and progress as individual contributors as well as those who want to move into management. If people can move forward in their careers in either track, then there is no pressure to move into management to advance in their career.
If you have good IC and manager paths and someone wants to move into management even if they aren’t suited for it, then you can have an honest conversation about how you see their skills relative to the role that they want.
You mention candidates having all the criteria for the next role. In some cases is it not impossible to have this without experience in the next role?
It is the responsibility of the manager to help people progress in their careers by allowing them to grow by taking on additional responsibilities when they are ready.
The manager should be giving the employee chances to get the experience needed to progress.
Any tips on creating a meaningful growth path in a small company without much hierarchy, where vertical growth is very limited?
In a smaller company, people can feel meaningful growth and career progression without a formal career path. If you do create a career path, you have to build it so that people can progress even without company growth.
Rather than building a career path, instead, focus on making sure people have opportunities to learn new things and take on new responsibilities and then find ways to celebrate them when they do. You can give people meaningful milestones in their personal development without having to make a formal career path.
This mostly considers a straight or slight forking line of development. What about moving across the business. A dev becoming product etc. How do you roadmap?
You can decide if you want to support this in your career pathing design explicitly. It does not tend to happen that often, so unless you want this to be part of your culture, you can probably treat it as an exceptional case.
If you don’t want to be explicit about how to transfer between functions, you can have people apply to the role they would like to switch to and evaluate their level against the new career path just like any candidate.
How can you make an attractive offer in regards to career development for developers? Can you give some concrete examples?
Make your career path and core parts of your culture public, given documentation on them to candidates. When you interview the candidate, ask them where they want to go with their career and then discuss how your career pathing framework can support their development.
I’m not sure I understand what you mean by concrete examples here. Feel free to clarify in the comments.
Would you recommend including values into the promotion process? If yes, how?
Your company’s values should be part of your career pathing framework and, therefore, part of the promotion process. If your companies values are not part of your career pathing, then you send a message to the organization that the values are not real values.
One way to tie the values into the pathing is to think about how each value would be demonstrated at progressive levels of professional maturity and use that as part of the requirements for each level.
What do you think about creative naming of roles? A lot of companies are renaming roles to make them sound more exclusive etc does this confuse career paths?
At this point, I think software engineering titles are so polluted from title inflation that it doesn’t matter what we call them anymore.
There are two benefits I see from using a more “traditional” title naming scheme. One advantage is that the job posting is easier to find, and when a recruiter contacts a candidate about the role, it may make it easier to decide if the candidate approaches them back. The second benefit is that people may have a title that they are mentally aiming for, “Principal Developer” is more likely to be someone’s career goal than “Master of the coding arts.”
You can always choose to have internal and external titles. One is the title that people inside the company use when talking to each other, and the other is the one that people use when talking to external people. People will do that naturally when speaking to outside people anyway, rather than try to explain some unique title naming scheme.
How do you make sure we don’t bias towards the people we have now, while ignoring the people who may join in the next year with different motivations?
If you have experience working in companies at different stages, you can try to anticipate what the next set of joiners may want, but it is probably a futile exercise. Focus on the company you are today. Make sure that you revisit and revise your career pathing framework with a reasonable frequency so that if it doesn’t perfectly align with the motivations of a new joiner, then they know they will have an input into the next iteration.
My last company decided to create a career path when I asked and for me that was a red flag. It means they were not thinking about employee progression. Agree?
Without more context, it is tough for me to make a sound judgment. In my talk, I make the point that you can create an employee progression framework too early. The company needs to move from the phase of “will the company exist a year from now?” to “what will my role be if I choose to stay another three years?” If you are asking the second question at a seed-stage startup, you are probably in the wrong place.
Many companies treat tech career pathing by intertwining seniority and leadership. What about people who want to grow and not lead? There can only be one CTO?
I am going to rephrase your question in the way that I believe you intended to ask. Please correct me in the comments if I got it wrong. I think you meant “intertwining seniority and MANAGEMENT.” I expect senior individual contributors to be technical leaders just as much as I expect senior people managers to be leaders.
In my talk, I make the point that companies should not intertwine these two things. There should be an individual contributor track and a management track, and as much as reasonable, the responsibilities and pay should be comparable, right up to the C-level.
As you say, there can be only one CTO. However, there can also be a Chief Architect, who may not be part of the executive team, but who has a level of responsibility and leadership equivalent to an SVP or similarly senior role.
When you have built a well functioning engineering team and things have stabilized, how do you keep career progression open?
I have been privileged to work in some very stable, well-functioning engineering teams, including people with multiple decades of tenure.
The biggest challenge to keeping career progression open is an unhealthy retention rate (too high), especially if organizational growth is near flat. I have seen this create a problem in an organization where up-and-coming talent leaves because they have a cap on their growth since there are no senior roles available. This describes one company I left after several years of very positive career growth. I knew that I had reached a level where I would be stuck, potentially for many years, because there were no roles likely to open above me for some time, and the company kept headcount flat year over year.
The best thing you can do in that situation is to help your up-and-coming talent find new roles outside the organization, and then keep in touch with them, so that when a senior role does open up, you can hopefully get them to return.
How do you know an idea is worth stealing/it makes sense in your organisation?
Has the idea worked in an organization your size? Do you see it scaling up or down to your dimensions of an organization? Does it align with your culture? Would you need to do some culture change work to implement it? Is there a way you can try it in a limited way to test it in your organization? And of course, does it sound like a good idea to you? An idea that you can champion?
Do you think it’s good to have career path development for start up with 60 people?
How old is the company? What is the average tenure of an employee? If both of those are low numbers, then probably not. It is maybe too early for you to focus on career path development. Unless managers are getting questions about career development commonly from employees, that should be your first warning sign that it is time to think about career pathing.
Doesn’t waiting for the timing to build a career pathing seem reactive? Ideally an organization should be proactive i.e think ahead of your employees.
Yes, it is reactive. I think about it this way: One of the most attractive elements of a startup is the flexibility and freedom that come from being a small, growing company. Trying to impose structure and process too early can feel “corporate” too soon to those employees. It is also hard to establish what responsibilities levels should have as the team is still forming. You are likely to build a framework that matches current employees (who don’t want structure) instead of the one that will work for the employees who join later and are expecting more structure.
If your company is already established and is of a certain size and attracting employees who want more structure, then you have probably waited too long.
Do you think a good career development framework kan help with developer retention?
A useful career development framework primarily exists to support retention. Beyond establishing career paths for employees, it also helps benchmark salaries for new hires. A career development framework ensures that pay is fair relative to the market (which is also essential for retention).
If you read the slides and have questions not answered above, please ask them in the comments.
This is part two of a three part series on how we created a technical career path for individuals at Spotify and what we learned in the process. This post contains the actual version one of our Technical Career Steps. This is the complete document, so it is a bit long. In the next and final post, I will talk about the mistakes we made along the way and the good and bad lessons we learned. If you haven’t read the first segment, you should start with that.
As Technology within Spotify has grown over the years we have learned that people striving to increase their impact often wanted to become a Chapter Lead or Product Owner even if they might have preferred the role of an individual contributor engineer. Everyone in Spotify Tech should have a way to grow their careers and expand the impact of their -work no matter what role they play. A shift into a Chapter Lead or PO position is not necessary.
The Steps Framework provides a way to do this.
The Steps Framework
As your career evolves within Spotify, you will likely take on a variety of roles, in a variety of contexts. You will work with multiple teams, on multiple projects, perhaps in very different domains or perhaps in a smaller area of specialty. You will build capabilities and mastery. Your impact on Spotify will grow, and so likely will your sphere of influence.
Your career development within Technology will therefore be a journey — sometimes sideways, sometimes forwards, and always flexible. There are some common patterns in the series of roles people decide to take on, and in which disciplines and expertise areas they focus, but this is not rigidly defined. It is up to you, with the help of your manager, to choose a path that aligns your interests and the company’s, and that helps you develop, grow, and meet your own unique personal goals.
Throughout this journey, as you gain experience and develop your skills, you will have greater and greater impact. In other words, the degree to which you contribute to the success of Spotify — its team and its mission — will grow over time.
The Steps Framework is designed to provide you with:
The opportunity to explore new roles, skills, contexts and disciplines over time, avoiding a specific, rigidly-defined “track”
A way to understand your progression toward greater and greater impact, independent of specific role or discipline
A set of well-defined expectations corresponding to defined points in this progression
In practice: Disciplines, Roles & Steps
In practical terms, supporting this development journey requires a more complex framework than a typical vertically-oriented hierarchy or “career ladder”. There are three key elements in the Steps Framework:
A Discipline is a domain of expertise and impact. Examples include:
coaching
software development
testing
project management
A Role is a way in which you engage with a team, a project, or a discipline. They are not all formally defined, but there are some common ones. Examples include:
software engineer
tester
road manager
technical product owner
chapter lead
agile coach
A Step is the combination of a well-defined set of expectations and behaviors associated with a particular degree of impact on Spotify. As you take Steps on your career path, your impact grows.
In the end, your path will involve taking Steps forward, growing your impact and broadening your influence while you evolve through specific Roles in various Disciplines. Your compensation is influenced by your Step, aligning your performance to the positive impact you are able to have on your team, your product, and Spotify as a whole.
Moving to a new Step in a given domain represents both an acknowledgement of what you have done and a commitment from your manager that you will get bigger challenges in the future.
Your Step is a measure of your personal growth and is intended for use in discussions about career development between you and your manager. Your Step is private: only you and your manager can see your Step. But we believe in transparency, and so will re-evaluate whether everyone’s Step should be public in some form after we have lived with the framework for a while. It is much easier to share this information later than to un-share it if it becomes problematic.
Behaviors and our expectations at different Steps
We have identified five sets of behaviors that provide a framework for understanding and talking about the expectations on all of us, at different levels of impact. They are:
Values team success over individual success
Continuously improves themselves and team
Holds themselves and others accountable
Thinks about the business impact of their work
Demonstrates mastery of their discipline
The greater the impact, the more we expect in each of these areas. A “senior” technologist who’s helping to set company-wide strategy will need to make these values manifest in different (and more sophisticated) ways than a fresh-out-of-school member of a squad.
The path
There is no one path through this framework. It is up to you and your manager to navigate the set of roles and the contexts in which those roles can be played, finding good ways to align your interests and your organization’s needs. Through this process, you will always learn and grow, increasing your impact on the company, and thus moving to different Steps. There is no expected amount of time that you will spend on each Step. Some people will move through them faster, and some will go slower. Some will reach a Step and choose not push towards the next Step, instead growing in other ways. The steps themselves are a measure of professional maturity and are therefore cumulative. A Tribe/Guild-step contributor shows all the behaviors of the Individual-, Squad/Chapter- and Tribe/Guild-steps.
Career Steps for Tech employees
There are five characteristics that every individual in Tech should develop as part of their professional growth at Spotify:
Values team success over individual success: We are a team and not a collection of unaffiliated individuals. You may be part of several teams: your squad, your chapter, your guild(s), your tribe. Contributing to the success of each of these groups is more beneficial to the company, the product, and our customers than chasing your own success at the cost of your teams.
Continuously improves (self and team): Spotify believes in never settling for the status quo. We are always focused on learning and growing.
Holds themselves and others accountable: As a company we value transparency and autonomy. These values must be coupled with accountability if we are to succeed. Taking responsibility for your own actions and the actions of the team and holding others to this standard is critical for us to be able to trust and work with each other.
Thinks about business impact: Spotify is a business. If we wish to keep working within this culture that we’ve built, we need to make sure that we are aligned with that business. Understanding how the choices you make affect the company is important for your growth as a professional.
Mastery: While the other characteristics talk about expectations and behaviors that are independent of your domain or role, mastery is specifically about becoming a better software engineer, agile coach, technical product owner, QE, QA or TA. There are items marked for each of these disciplines. Anything that isn’t marked is expected of all roles.
We have also identified four Steps in your career path at Spotify. Each Step is marked not only by increased responsibility, but also by your increased impact within tech.
Individual Step. At this step, you are focused primarily on being a useful contributor, gaining experience and learning how to be effective on their team. It is not expected that a member of technology would remain at this step during their entire time at Spotify. At this step, your focus should be on growing so that you can support your team. This is the only step where there is an expectation that all members of technology should move toward the next step.
Squad/Chapter Step. At this step, you are a resource for your chapter or your squad, either as a domain specialist for your team, or as a generalist/problem solver for them. You should be able to lead smaller efforts coordinating with other members of your team and drive them to completion and/or dig into tough problems and solve them independently taking in feedback from your peers and focusing on the outcome.
Tribe/Guild Step. At this step, you have an impact across squads or chapters. You are a resource for a larger group as a domain expert or generalist. You will lead cross-team (squad/tribe/chapter) efforts involving more people and drive them to completion and/or you will take on large challenges, working with diverse stakeholders in multiple teams to solve a problem that affects your larger organization.
Technology/Company Step. At this step, your focus is significantly on supporting Tech-wide or company-wide initiatives. You will Road Manage projects that span tribes and be responsible for solving Tech-wide problems, and/or you will also represent Tech in company and/or industry forums, and/or you will be a go-to person across the company to solve very complex problems
On recognition and promotions
When you are consistently demonstrating the behaviors and sustained impact of someone at a wider Step, your manager should recommend you for an official promotion (as long as you are willing to accept the increased expectations going forward).
The process for promotion depends on the Step involved:
A chapter lead can promote one of their individual step employees to squad/chapter step without outside approval, though the chapter lead will make this decision in part based on feedback from that employee’s peers in the squad and chapter.
Promotions from squad/chapter step to tribe/guild step must be approved by the relevant tribe lead, after consultation with tribe-level leadership.
Promotions to technology/company step must be approved by the CTO, after consultation with technical leadership, including people currently at the technology/company step.
Since we place so much value at Spotify on being an effective member of a team; promotion to the next step, at all levels, should involve consultation with a varied group of the person’s peers. This can be done using the loops tool in addition to direct conversation, for example.
Formal promotion to a new Step will normally come with an immediate compensation increase, as well as an immediately increased scope of responsibilities. The promotion represents a commitment from both sides: you will keep executing at the more advanced level, and your manager will continue to provide opportunities to have broader impact.
Examples of broader responsibilities as part of being at a more senior step for a developer could include things like:
driving the technical implementation of a new feature for a squad at the squad/chapter step
figuring out how a tribe should adapt their systems for anonymization at the tribe/guild step
leading the CDN technology strategy for content delivery, including technical feasibility, cost/benefit analysis, and vendor selection at the technology/company step
Public recognition will frequently be decoupled from formal promotion. We believe it’s more effective to recognize people for successful completion of important projects than for reaching a (somewhat rare) career milestone. So we expect to see more announcements like “Please join me in congratulating Jane Jones, who drove this project to completion over the last few months” and fewer announcements like “Please join me in congratulating Jane Jones, who has officially been promoted to the Tribe/Guild Step”.
On Setting the Step for a New Employee
It can be hard to tell what step a new employee is on based solely on their interviews. To give the employee time to acclimate to Spotify and their role, their official step will not be determined until their six-month review. During that review, the step is set through a discussion between the new employee and their manager.
The new employee should do a self-evaluation with the framework to see how much they believe each behavior represents them. The manager should talk to the peers of the employee and use their own knowledge and experience from working with the employee to do an initial evaluation of how the different behaviors in the framework describe the employee. A discussion between the manager and the employee will show where they agree and where they differ, and allow them to reach a decision on which behaviors describe the employee today. This also sets the context of areas to focus on in the near future for growth.
On Compensation
Your compensation as a Spotify Employee within Technology is influenced by the Steps Framework: having a bigger impact on the company should lead to higher pay in a straightforward and transparent way.
We want to make sure Spotify salaries are following the market. Therefore we get salary benchmarks from specialised suppliers and industry leaders in this area. Since the salary benchmarks are used as a recommendation and not as strict guidelines when setting salaries we will not share them internally. We’ve always used market data to help guide our pay principles. Since H2 of 2015 we are matching them to work within our steps framework.
The salary benchmarks for Steps overlap each other. This means that a person at the Individual Step can earn as much as someone at the Squad/Chapter Step and vice versa.
On Titles
Steps do not map to titles. We approach titles differently depending on whether we’re talking about internal or external use.
Internally:
Scopes of impact have defined names — the Individual Step -> Technology/Company Step.
Roles have defined names — some more formally defined than others.
Roles are typically more useful for internal communications than anything else.
Externally:
Employees have a tremendous amount of flexibility regarding how they represent themselves externally.
They can use their roles, they can use more standard titles that they feel are more communicable.
We may in the future provide examples of external titles that commonly map to our internal role names to facilitate this.
We expect employees and their managers to work together to come up with appropriate external title usage.
Expectations for each Step
On Requirements vs. Examples
A few questions are common around the examples provided in the framework: are the behaviors in the bubble diagrams hard requirements? How many of behaviors must someone be demonstrating, and how consistently, and for how long *must they be demonstrating them before they are considered to be at a particular step?
The most important point is that managerial judgment is always required: this framework provides a structure for fostering conversation between managers and employees, but it cannot ever provide a detailed recipe for how to handle any particular situation. So the answers are intentionally not black-and-white.
The intention of the Steps Framework is to describe what it looks like for an individual to have increasing levels of impact on the Spotify tech organization. But the truth is that there are lots of ways to have big impact, and we want to support all of them. Someone might be moving the whole company forward through their deep expertise in a particular technology, and by putting on their headphones in a corner and singlehandedly writing a huge and critical piece of infrastructure that accelerates the work of hundreds of other people. Someone else might move the the whole company forward by spending lots of time in meetings, driving consensus and resolving conflict as the company does something new. These, and lots of variants in between, are all valuable.
So the answer is that the behaviors in the bubbles are mostly examples: many of the bubbles describe a specific activity more than a general behavior. These “activities” are mostly meant as examples of step-appropriate behaviors, as opposed to specific activities required to demonstrate that behavior. In aggregate, they paint a picture of what we mean when we say “tribe and guild impact”, “squad and chapter impact”, etc. But they should be treated as triggers for discussion rather than a checklist. Are you doing this thing? Would your work have more impact if you did? In general, we think these are all valuable things that people in tech should do. But it’s not about seeing a behavior once and checking it off, or seeing a behavior consistently and checking it off, or about checking off 80% of the bubbles at some level or 100% of the bubbles. It’s about the impact that your work has over time, and these bubbles are a loose proxy.
FAQ
What about my special situation?
These guidelines should never trump common sense. People are complicated, and there may be some special cases that this framework does not address well. Managerial judgement will always be needed, in all cases.
I do not see myself as a developer, QA, TPO or a coach. My discipline is not mentioned in the framework, what expectations are set on me?
The framework provides examples for four of the most common disciplines within tech, but there are others. It would not be possible to define good examples for all possible disciplines or combinations of these. The existing examples should inspire and help you and your manager to set the expectations for you even if the names of the disciplines are not a perfect match. If a tribe after evaluating the framework later comes to the conclusion that the present disciplines are not helpful enough and need arises to define new examples for other disciplines they can introduce new ones.
Is there a set of formally-defined roles?
No. As context and ways of working differ across Technology, formal, pre-defined roles would not fit into a lot of squads. We do have disciplines (e.g. coaching, software development, toolsmithing, quality assisting, …) to guide skill sets and expectations, but as an individual contributor at Tech we do not forcefully limit our work to one of these.
What is the connection between Roles and Steps? Do I have to be at a specific Step to take on certain Roles?
Not for most roles – but some. Examples: You won’t be a good chapter lead if your sphere of influence is Individual, hence being squad/chapter step or above is needed. To be a Chief Architect your sphere of influence needs to be on a company level.
Is this a reporting hierarchy?
Reporting is based on your Role and Discipline, and not your Step. Based on their role, a Software engineer of any step can still report to a Chapter Lead.
Are Steps like “Senior”/etc. designations?
Steps are a tool to facilitate career development and do not confer any title.
Do I have to demonstrate the behaviors in all value areas to be considered for a wider Step?
As a rule, yes. Steps are intended to reflect growing spheres of influence and impact. We believe all the competencies listed are necessary for someone to really have the increased level of impact that a new Step represents. However, people are complicated, and there may be cases where someone’s strength in one area compensates for a weakness in another.
Do I need to continuously move through steps during my career at Spotify?
This is something to discuss with your manager. While we expect engineers to continuously improve their skills there is no rule that one must also continuously increase their sphere of influence. Individual step is considered an introductory step for an inexperienced contributor. We do expect that employees will move from the individual step as they become contributing members of their squad.
What happens if I want to move to a step with less impact?
You may choose to embrace a new discipline where you have a significantly lower level of mastery. There may be other situations that lead you toward this choice. Again people are complicated and we neither can or should try to anticipate every situation. If you decide that you want to make this kind of change, discuss it with your manager. Note that your compensation is tied with your Step.
How does this relate to loops?
Loops is a tool focused on performance development that puts employees in the driving seat. It can be very useful for your career evolution. Promotions are a separate process from Loops.
How does this relate to Priorities and Achievements?
Priorities and Achievements are a way for you to make commitments to goals and measure your performance against them. This can help determine your salary adjustments within your range year to year, but it is not tied to your step which will determine your salary range itself. As you increase your impact by moving to wider steps, your priorities and achievements should reflect that.
When can I get promoted?
When you and your manager agree that you are consistently operating at the next Step. Specifically, promotions do not need to be tied to the annual salary review cycle. See “On Recognitions and Promotions” for the details on how the promotion process works.
To what extent is this a tool, guidance, or a formal policy?
This framework is intended to provide a concrete toolset for employees and their managers. It is the model all of Technology is using. While deviations may make sense and be needed in some cases, that is the exception and is something that should be discussed at the tribe leadership level.
How does my Career Step affect my salary?
Your career step is used to determine a range of pay based on people at a similar sphere of impact in similar disciplines. This pay range gives guidance to managers on competitive rates of pay in the industry. It does not set your salary from year to year. Your pay change set in your yearly salary review is based on your performance based on expectations during the previous year.
Do I need to be promoted to increase my salary?
No. You can stay at a step and continue to increase your salary year over year. The salary ranges from step to step overlap significantly and they track the market (which is evaluated every year). Your salary increase is based on your performance, your behaviors, and the market.
How do I as an introvert fulfill the expectations on communication and networking in this framework? It seems to be tailored for more extroverted people.
The important thing is to make a positive impact. Given that, you have to find your own way, something that you feel comfortable with. Some people prefer the written language, others the vocal one. Some people share their ideas right away, others prefer to take time to think and elaborate. You just need to make sure you are communicating in an effective and constructive manner.
Spotify launched a career path framework for individuals last year. Since then, I’ve spoken to leaders at several other companies about it. This seems to be a bit of a hot topic, so I’ve decided to write about our model and how we arrived at it. Hopefully, this may be useful to your company.
This will be a three part series. In this, the first part, I will talk about how we created our framework. In the second segment, I will talk about the framework itself. I will talk about the hard lessons learned in rolling out this kind of program in the third part.
The road is more important than the destination
If you are trying to figure out how to approach career paths in your company, it will be tempting to take ours (or someone else’s) and just use that, cargo-cult style. I would highly recommend against this though. How a person matures within your company is a critical part of your company’s culture. As I’ve written before, your culture is unique; a career path framework from another company will not build on or reinforce the values that make your company great.
When should you create a career path framework?
I saw a YouTube video of a panel on career pathing for tech startups at some point. One of the speakers made the argument that you should create a career ladder later than you think you need it, a little bit after it is really necessary. I think this is very good advice for a few reasons. A career path framework is unnecessary in the early days of a company and creates unnecessary process that can be as much of a distraction as a benefit. One of the great things about the early stages of a company is that roles people have are constantly evolving. Formalizing them too early can stunt the natural development of the organization and the individuals within it.
Eventually, as a leader, you will start hearing about people wanting to know what their future at the company looks like or how they can take on more responsibility. Â When this shifts from an occasional idle question to a more of a groundswell, then you know that it is truly time to create something more formal.
At Spotify, we’d waited almost eight years before deciding that it was time to create a career pathing framework. The company’s anti-hierarchical culture probably was a large part of the reason for not seeing this as a need. Honestly, this was likely too long to wait, and some of the issues we had when we rolled it out were presumably due to the fact that we hadn’t done it sooner.
There were a few things that made it clear that it was now past time to do this. There was no formal way to acknowledge career growth (via title, salary or responsibility increases) in the individual contributor role. There was a strong belief within the organization that the way to be “promoted” was to become a Chapter Lead (line manager) or a product owner. In fact, switching to these roles at Spotify is more akin to a career change (to management or product) than it is to developing as an individual contributor.
In the spring of 2014, at a technology leadership offsite, we decided to create a “career ladder” for Spotify and quickly drew up something simple to start with. I was made the Road Manager (driver/leader) of the effort to flesh it out and then roll it out to our large organization. It seemed like a straightforward task at the time. That assumption turned out to be very naïve.
Defining technical career progression, the Spotify way
At other companies, especially companies the size of Spotify, creating a career ladder would be something that would probably originate from and be driven by the human resources organization. Within the technology organization at Spotify though, we tend to take a more direct responsibility for the things that impact our culture. We feel strongly that our culture is an important advantage in the effort to build our product. So in Spotify Tech we take these kinds of projects very seriously and are vocal and involved partners with our HR peers. Even to the extent of driving some of these programs ourselves in partnership with HR instead of the other way around.
The goal was to create a framework that would make sense with our culture, would work for employees from a diversity of backgrounds, in the US and Sweden, at all levels of experience, and in many different (some unique) roles. It was clear that this would require a team that could represent, as much as possible, the whole organization.
Build a working group that is representative of the organization
I put out a call to the technology organization for people who were interested in solving this challenge and who were also willing to commit the time to do it right. From the responses I received, I selected the group based on location (to maximize the number of offices represented) and on the role of the volunteer (to have a good cross-section of technology).
I also tried to get a diversity of opinions on the concept of career development. We had a few people who had been vocal in their skepticism of career ladders in general. I wanted to make sure that those voices were present as well.
We were lucky enough to have our CHRO join for several of the early meetings. Naturally our HR Business Partners for technology were also involved. Their domain expertise was critical throughout the process.
Doing it right takes a lot longer than you’d expect
At first, I thought that a few months of twice-a-week meetings would be sufficient to conceive and launch the program. Â That turned out to be ridiculously optimistic. We were able to largely define the framework in a few months, but to create something like this, in an organic, bottom-up manner, for a large organization, requires many cycles of feedback gathering and incorporation. In the end, it took nearly six months from the beginning of the working group to the official RFC. It is now over 18 months since that initial working group meeting, and it still feels like we’re getting used to having the program in place, even as we prepare for the second iteration. We definitely have spent a lot of the last year supporting the rollout and adoption of the framework.
Some guiding principles
The working group began as you might expect, talking about the aspirations for the effort and comparing our own past experiences with career ladders at other companies. We talked about which of those elements made sense in Spotify’s culture. Quickly, we realized that the simple career ladder proposed by the tech leadership group wouldn’t make sense. Within the first or second meeting, that proposal was officially dead, and we started from scratch.
We agreed on a few principles early on:
This would not be a “ladder,” with an up-or-out mentality. We wanted to support people who wished to maintain their current level of responsibility.
The basis for advancement was a demonstration of behaviors and not achievements. We wanted our framework to be a true model of professional development. It should be about who you are, and not about what you’ve done. In a failure-safe environment like Spotify, we didn’t want to penalize people for taking big chances.
We wanted to support the changing of roles without punishing people for developing themselves. In other career ladders we’d seen, the role becomes a silo. Switching roles could mean a literal demotion since the requirements of a level are  tied to specific areas of achievement in a specific role.
We wanted this framework to reflect our team-oriented and autonomy-driven culture. Teamwork is critical to our way of working and we wanted to make sure that this was part of personal development.
We wanted to support both generalists and specialists. Many folks at Spotify move around the organization to develop a breadth of skills, while others like to get especially deep in specific technology areas. We wanted to support both of these types of people.
We believed that career progression is marked by the impact you have on progressively larger areas of the organization, your sphere of influence.
We shunned the word ladder from the start, influenced in part by our career ladder skeptics and our desire to support multiple ways of development. Struggling for a way to describe our model of career pathing, we eventually came upon the word “steps” thinking more about rocks in a stream than a staircase. The rocks would let you move side to side, or even backwards in order to eventually move forward. The framework was named Spotify Career Steps.
A set of five characteristics
We were able to build on some of the efforts that had come before in the technology organization. Specifically, the Agile Coaches guild had spent time developing a common set of core capabilities they thought each Spotify developer should have. This became the basis for the areas of development of our framework. We then added two additional areas to reflect professional development within our culture.
The five characteristics of Spotify employees that we identified were:
Values team success over individual success
Continuously improves themselves and their team
Holds themselves and others accountable
Thinks about the business impact of their work
Demonstrates mastery of their discipline
I will go further into these characteristics in the next part of the series.
A set of four steps
There was some discussion around the number of “levels” to have. We decided that it was easier to add more levels later than to remove them if we created too many. Given that we had decided that being more senior meant being a resource for larger and larger parts of the organization, mapping “levels” to our levels of organization seemed like a reasonable first approach.
The four steps of career development at Spotify that we decided on were:
Individual — at this level, you are new to working and are figuring out how to be productive and contributing member of the company.
Squad / Chapter (these are the teams that people primarily belong to) — you are now a contributing member of a team and are a resource for the people you work with every day.
Tribe / Guild (these are the larger teams organizationally or functionality that people are part of) — now you are a resource beyond your immediate team. Either because you have depth in a technology (and help others or other teams around that technology); because you are skilled at solving difficult problems that span teams; or because you can be counted on to lead other developers in your tribe to solve large cross-squad problems.
Technology / Company (the highest levels of the organization) — The developers at this level are resources for the entire company based on their technical and leadership skills and are expected to spend a significant amount of their time working across the organization.
A map of career growth at Spotify
The five characteristics and four steps created a map of professional development at Spotify. We then spent significant amounts of time defining each of the characteristics for each step.
One decision we made that I think was especially good was that mastery was only one of the five characteristics. That is the only area where we differentiate based on role (since mastery as a coach is significantly different than mastery as a mobile developer). This also helped reinforce that switching roles didn’t necessarily mean moving backwards in your career development as most of the characteristics were universal.
Much of the focus of the feedback we got was on the content of this map. This makes sense because this was essentially where the model got concrete for people. We were defining would be expected of employees in technology, after all.
A group editing process
We settled into a rhythm of working in a shared google document, mob editing. Non-pair changes followed our code review guidelines: an edit was made in the doc as a suggestion, and two separate approval comments to the suggestion were needed to accept the change.
The current version of the document (we would “fork” or create a new copy of the document on a regular basis) was then shared with progressively larger groups of managers and employees to get their feedback. Their comments and suggestions were then incorporated, after which a new version would be shared.
The rounds of feedback and tweaking were extremely valuable. We realized that we weren’t doing enough to support introverts in the initial versions, for example, and had to go back and make significant changes.
After several months of revisions and sharing to larger and larger groups, we finally created an official RFC version, which was then shared with the entire organization for comments, and suggestions.
This particular collaborative editing and progressive review process ended up working quite well. There were some improvements that I will recommend in the third part of this series.
At this time, I want to recognize the initial working group that was instrumental in the creation of the process and the document. We worked so well as a group that in retrospect it is hard to remember whose ideas were whose. Any idea that any of us had was definitely improved by the others involved. While I am writing about what we did, the work itself was a true collective effort by Chris Angove, Daniel Prata, David Poblador I Garcia, Eli Daniel, Henrique Imbertti, Jessica Joelsson, Kevin Goldsmith, Kinshuk Mishra, Olof Svedström, and Will Meyer.
Part two: the result of the process
In the next post, I will share the framework itself that was the end result of this process.
