When you choose the dark side (management 😈) in a digital transformation company, one task will come your way sooner or later is creating or improving the career path of the company.
Consider the scenario in which there are many consultants (thousands) and a zillion different combinations of engagements, projects, systems, environments, methodologies, and so on… on top of that there will be people with toolbelts so diverse that you will inevitably start making a few abstractions here and there. For example: developers, there are backend devs, frontend devs, database devs, fullstack devs, devops, you name them; creating a path per each ramification a technology profile can take would be a mastodonic effort.
Tracks
So how do you start? If you think about software engineering, out of the many differnt types of profiles, people (generally) will choose between 3 paths:
- Consulting
- Project Leadership/Architecture
- People Leadership/Management
Consulting
Many people (specially in Software) will prefer developing their careers as close as possible to technology, trying to get distance from all the issues that can arise from having to lead other people.
Project Leadership/Architecture
Not everybody wants to be a leader. That’s a fact. Driving a project from the tech point-of-view means carrying (a good chunk of) the weight of delivery while depending on the abilities of the rest of the team. This is when you start splitting your time between coding and non-coding activities (reviews, meetings, etc.) and not everybody wants to stop coding full-time.
Project Leadership/Architecture
A very few people, unfortunately, want to be a leader the whole time, as opposed to being a leader only under the scope of a project such as tech leads/architects. These people have a special gift which is servicing other people. They understand that the best people to take care of the technical people are technical people themselves so they don’t mind spending part of their time servicing their team members, and making sure these team members are connected to the organization.
Levels
Now you have 3 main tracks. That means that from a high-level now there are 3 different paths that need to be fully defined so what is next is defining the levels. Levels are tied whether we like it or not to salary bands, even though overlap needs to exist among bands. The more responsibility and impact, the better the compensation should be. The market after COVID is way too hot, people no longer wants to wait several years for a promotion because the competition is so fierce that they will likely get the promotion elsewhere. That means there needs to be a balance between the number of levels so that people can jump fast enough without compromising the stability of the company.
Names of levels everybody knows are: Junior, Intermediate, Senior; but these are only 3. How much time one person needs to get a promotion from jumping from one to the other?
You have to consider if you hire people right out of college then it means you will need more junior or entry levels before you can call someone a senior. How much time does a person needs to become a senior engineer in technology? I will not answer that here but that’s an important question in the puzzle of creating a career path. Once a person has reached a senior level, what’s next? That’s another question to think about.
Jobs
In combination with the tracks and levels, there comes the actual jobs that will be created. One clear example could be the path for Mobile Developers. A Mobile developers can grow on the Consulting track, or eventually become a Mobile Architect, or eventually become a Mobile Dev Manager.
Main Skills and Observable Behaviors
Now there’s pretty much a birdseye view of the different decisions a developer can take to grow their career. Now, how do you know the person can actually be promoted to the next level? This is where the work gets interesting because a Consulting firm delivers works very closely with the clients in the delivery of their solutions. It’s very rare (I would dare to say non-existing) to find instances in which the client says “build this for me” and then turn their back completely during the whole process. Specially in Agile environments where we want constant feedback of our clients, it is impossible not having to adapt to the way the clients work, and that’s not necessarily a bad thing but it indeed causes difficulty when having to assess the levels of the engineers in the company (remember that there are thousands of them).
This is when Observable Behaviors come handy because, as the name implies, they are supposed to be something that evaluators can obseve and check off. An ideal consultant is a cambination of their technical expertise plus other important soft skills such as Teamwork, Communication, Leadership, etc. That means that you have to define the Observable Behaviors that are relevant to how the firm operates and delivers, including the technology aspects of the job. Luckly for software development, there are a handful of main activities such as design, coding, testing, deploying. And then many different categories that could be relevant to the job such as performance, security, design patterns, etc. There should be between 3 and 5 observable behaviors for each of the Main Skills a job should have. There could be more but be aware that the management and review process will be very lengthy so again a healthy balance needs to exist. Going too granular and detailed will probably not pay off.
Levels of Main Skills
An alternative to reusing observable behaviors across jobs is to create levels for the main skills. Do not confuse these levels wit the job levels (e.g., Jr, Intermediate, Sr). Levels could be as simple as “Learner”, “Doer”, “Teacher” or “1”, “2”, “3”, and they should reflect how the main skill is developed by the person.
For instance, imagine that Testing is an important skill for the job and let’s use “Learner”, “Doer” and “Teacher”. The observable behaviors could be defined as follow:
Learner
- The developer should be able to write a unit test of a small function
Doer
- The developer should be able to write integration tests to validate different flows inside the application. For the scenarios in which external systems exist, the developer should be able to use mocks/stubs.
Teacher
- The developer should be able to create e2e tests orchestrating the different use cases of the application.
- The developer should be able to set up Continuous Integration strategies from scratch.
Mapping Main Skills and their Observable Behaviors to Job Levels
Finally, all these observable behaviors are assigned to each of the Job Levels to clearly differentiate the expectations so that each person knows what to focus on next to be able to check off an item of the next level.
Finally…
This is one of many different strategies Consulting firms could use when creating career paths. This is by no means perfect in any way. There are pros and cons when it comes to creating career paths for people in Consulting. Most likely each organizaiton needs to review what they have, how they operate, how they deliver, where they want to go, and all aspects that are relevant to the career progression they want to offer for their people.
Most important is that the exercise of creating career paths should not be top-down. People that do the job, people that lead other people, technical managers, they all should have represenation. Also an Agile approach will help beacuse this is not an easy task. Aiming for the best career path ever is unrealistic. The whole thing will be refined on each iteration as the team gains experience.