Back to the future: career development plan
How to get 10 years of professional experience in 10 years? Learn to write good career development plans. Start from vision, through gap analysis, and set actionable goals. I am sharing real world examples too.
When I started my career, I remembered researching how to chose my first job. My focus at that time was whether to optimize for salary or for learning, and I read a lot of articles about it. There was one sentence that stuck with me ever since.
To have ten years of professional experience, you need at least ten years.
I love this quote because it states interestingly what I also observed during my career: you can spend years on a job without growing professionally. While engineering managers are responsible for building high performing teams – which requires to help their team members to grow to reach their full potential – , it is ultimately a shared responsibility with the team member.
The best book I read about growth is Outliers by Malcolm Gladwell (I can highly recommend it), but to simplify it for a company setting, in order to professionally grow at a company, you need two things:
- Vision: To know what you want to become, and how that aligns with the company goals. It is always your responsibility, otherwise you are pushed around without arriving anywhere.
- Opportunity: Depending on the company and your seniority, you might have a way to influence this, but it is ultimately your manager's responsibility to give you opportunities to progress towards your vision. However, opportunities might not always present, that is why it is important to have a vision so your manager knows how to help you (or to recognize early if it is not possible).
The way to document your vision and to align with your manager on how you will reach it through small steps is the Career development plan. I am sure there are many way to write one, I am sharing what I usually do.
Career development plan
The career development plan is a living document with 3 main sections. The first that section captures your vision who you would like to become in mid/long-term. The second part is a gap analysis between your current skill and the skills of a person who you would like to become. And the last one is the the immediate steps you agree with your manager to make in order to eventually reach your goal.
The first version of this document is a conversation starter, working with your manager. For each section, I will share a real world example.
Vision
Before we can start, we have to know where we want to go. I usually see two problems: people are interested in everything, or they have a vague idea but they don't know how to write that down.
The first problem might means the person would like to be a generalist rather than a specialist, or they just afraid of making decisions, to commit to something. I usually resolve the latter by discussing why focus is important, and recognizing that transitions are almost always possible. No need to afraid of committing to something, but without making a decision, it is hard to keep on track.
If you already have a vague idea who you want to become, I recommend two things: define what the person you would like to become does, and to give examples of people who you think currently act in that role well.
Example
Long-term (3-5 years)
To become a senior engineering manager at ACME. For me, a senior engineering manager
- Builds up trust 360 by demonstrating the ability to be able to build up successful, high performing teams more than once.
- Has demonstrated experience in upscaling, downscaling teams successfully.
- Daily team leading activities (1:1s, performance reviews, reporting, planning) are efficient, doesn't exhaust him
- Leads a large team (8-12 engineers) or multiple smaller teams
- Leads cross BU projects and products (e.g. ACME Home / ACME Cloud)
- Contributes to the wider organization development by giving trainings, mentor other EMs, organizing activities (e.g., leading a chapter, owning engineering knowledge sharing meeting series, etc).
- Contributes to the company's vision by proposing new improvement, features, products (e.g., writing fast-forward funds) and executing them.
- Knows and expects from the team members scalable and reliable engineering practices.
- Product (user-centric) and business (company sustainability) mindset role model.
Role models: John Doe, the way engineering directors manage their teams.
Mid-term (2 years)
To build up a successful and high performing ACME A team. The ACME A team is high performing and successful when
- The team can operate self-organized to give time to the EM to grow and focus on responsibilities outside of the team.
- All team members have the right mindset. They always keep the user experience and our business needs in mind when making decisions.
- They recognize problems/improvement areas, but instead of complaining only, they are proposing solutions and leading the change. This leads to continuous improvement and less incidents.
- Team members are growing towards their career goals.
- Majority of EM → Team, and Member → Member communication is written: PRDs, RFCs, email, JIRA comments. This improves clarity, document commitments, and gives better control over people time.
- Team team organizes and produces written information efficiently, JIRA tickets and workflows are clear, confluence is easy to navigate, etc.
- The product is functional and reliable for business users, never has incidents that cannot be safely handled very quickly, and new features are arriving regularly to drive growth.
- Have only required meetings, the meetings have only the required participants, and they are well moderated and documented.
- Team camaraderie is good even when the team is geographically distributed.
Role models: Jane Doe, Max Mustermann.
Worth it to mention that it doesn't have to be long or perfect. What is important is to build up a vision and to have it written down.
Gaps
Once you have a vision, you can continue with looking at where you are and what you need to grow on. Some people are better in self-reflection than others, but most companies have level frameworks and performance feedback cycles to help answering these questions.
Get familiar with your company leveling system, and what are the expectations for each level. If it is possible, get the level of your role models, and try to assign a job level for the role you described in your vision.
To understand where you are, read through your recent performance reviews and talk to your peer to get feedback what you can do differently to be better.
The first step is always to get established on your level if you haven't already. Then you can look ahead by uncovering the gaps between your current skills and the needed ones.
Building this part is very personalized. You are not building some abstract path you need from Level X to Level X+Y but you need to know what you need to learn.
This is the section that your manager can keep in their mind to match with new opportunity that arrive.
Feel free to list only the major next steps, rather than a full path to your vision. The gaps are not immediately actionable, those will come to the next section.
Example
I wanted to break down the gaps to "Mid-term vision" and "Current level", but they overlap too much. The gaps are for both
- Set expectations through direct feedback. I give constructive feedback, but I have the tendency to deliver it soft that can make team members to undervalue their importance. We reward outcome, not effort. Suboptimal personal outcome leads to suboptimal team outcome that affects all team members and also the BU. As the company grows, the expectations for the same position grows as well. All of us need to improve even just to give the same performance in our current positions.
- Team transformation/organization (people & structure). Reevaluating if I have engineers with the right mindset and skills in my team allows me to reorganize the team to one that can work self-organized. This frees up time for me.
- Well organized, written communication. Having that allows me to eliminate discussions on them on meeting, improve clarity (single point of truth), and set expectations.
- Promotion of scalable and reliable engineering practices. Building up technical skills and make sure the team follows them. Incidents can happen but not caused by not following good engineering practices.
- Be more active outside the team. While I helped Jane Doe to organize the on-call quite a bit and I organized All-hands & the demo in Q1, I do not contribute to the wider organization as much as I should (e.g., engineering practices, Platform X chapter, etc.)
The gaps are prioritized for the goals.
Goals
The last section is about actionable goals that start to bring you to the right direction. While you should bring the first iteration, it is always a collaboration with your manager as more often than not these goals are also set for your career progression in the company.
There are a few things that help to shape this section.
Objectives and key results
I like to organize goals in an OKR (Objectives and Key Results) format:
- Objective: A high level, inspirational sentence about what you plan to achieve. You measure whether you achieve it through key results completion.
- Key results: A few, 2-4 key results that if they happen, we can consider the objective done.
I think it is a useful skill to be able to think and work in an OKR framework, but I am not overly strict when working with OKRs on personal goals. For example, Key results should be outcome oriented, but I often accept key results as milestones of a flow that someone is planning to go through.
Similarly, some key results can be defined with a variable. E.g. the first key results is to fill the uncertainty in the second key result (what document to write).
SMART key results
Regardless of the corners that were cut during key result definition, I am more strict on the key results needs to be SMART, or with other words
- Specific: State clearly what you want to do. Answer the who, what, and where.
- Measurable: Use exact numbers or data to track your progress.
- Achievable: Make sure the goal is realistic with the time and skills you have.
- Relevant: Ensure the goal matters to your broader life or work plans.
- Time-bound: Pick a firm end date or deadline.
I treat this more important to follow because it reduces ambiguity during evaluation, having less room for interpretation
Few objectives
You need to balance setting challenging goals, but not setup yourself for failure. My experience is that having fewer objectives 2-4, but they being challenging than having many easy objectives.
Example
The first gap is important, but I could not come up with measurable key results for it.
YYYY H1
- Objective: Prepare for Team A transformation in YYYY H2.
- Key result: Get align with my manager on the ideal senior engineer profile for the team and share the document with people partners by 15th Jan.
- Key result: Make the final decision on each team member's future and arrange the transitions if needed (internal move, etc.) by 15th Mar.
- Key result: Prepare for hiring by writing the job description and get funding by 15th of May.
- Objective: Improve team operational efficiency through written communication.
- Key result: Conduct a survey in the team that measures the team opinion on the state of our documentation and pain points by 15th Jan.
- Key result: Collect the most important and best ROI documents that we need to improve our efficiency by 31th Jan. Potential candidates: ticketing workflow, release guidelines, playbooks.
- Key result: Write those documents and keep them in a well organized space by 15th Jun.
- Key result: Conduct the survey again and compare the results by 30th Jun.
YYYY H2
Building on the first objective of YYYY H1, the focus will be on onboarding, and putting the new structure into motion. This includes not just the the people moves, but also reinforcing the mindset through continued direct feedback and role modelling.
My focus will slowly swift more to written communication and setting scalable & reliable engineering practices with a new hire and/or with practices learnt from the Team B. The goals will be set around these topics.
YYYZ H1
If the scope of the team doesn't change or it will be reduced (e.g., App A is phasing out), by the beginning of YYYY H2 the team should operate self-organized.
This is the time when I expect to have more time to be more active outside the team, and to grow towards my long term vision. This can also be a good time to strategically kick-off new products through Initiative X, or cross-BU collaboration.
Summary
That is basically it. It is a long post, but the actual process is easier than it looks.
Sometimes I meet with people who don't like to make a career development plans, who feel this is fake. I can understand why it feels like that, but being deliberate is the best way to avoid being stuck in a role, or to find yourself in a role that you don't like.
I often see this process as playing a board game, and there is nothing bad in that. It gives a framework to your progression, makes results easier to recognize, and helps to avoid wasting 10+ years on getting 10 years of experience.
