How to write a growth plan as a programmer?

I have two problems with writing formal growth plans as a programmer.

The first is: for me, growth plans are useless. If I want to learn something, I will learn the subject regardless of whether the company approves it. In fact, if I waited for company approval, I would still work as a backend developer. Years ago, a manager disapproved of me learning anything about machine learning or data engineering.

For me, a growth plan is an administrative burden with no benefits. Of course, if I wanted money for a class or an exam from the company, I would need to write the growth plan and provide as much information as they require. However, a growth plan is required even when you don’t need anyone’s help.

I understand why they do it. They have to force some programmers to learn. Otherwise, they wouldn’t learn anything. Without external accountability and the growth plan, they wouldn’t put effort above the minimum required to stay employed. A growth plan increases the minimum effort by stating you have to learn or get fired. It looks like a good idea, but it doesn’t work. Have you ever worked with a lazy or incompetent programmer? We all had. They had growth plans too. Yet, somehow, they didn’t grow. You can’t force people to learn. You can’t force people to be innovative.

The second problem with growth plans: what if my growth plans aren’t related to writing code? What if I want to learn storytelling and writing because I want to publish a fiction book for children? I don’t plan anything like this, but what if I did? Right now, I want to learn persuasive copywriting because it’s a valuable skill regardless of the job title. I can’t tell my manager about this goal when we discuss the growth plan because the goal isn’t related to the job.

How to choose goals

I assume you need several goals. Usually, growth plans cover 3-5 objectives. I need an even number for my example, so let’s assume you write four goals.

Half of them must be project-related, even when your manager tells you otherwise. Those learning goals will get you promoted or give you a raise. When you choose a project-related personal goal, pick something you will do anyway. Don’t try to invent a new goal or push the project in a different direction. Build your growth plan on top of the already approved plan for the project and your team. Being perceived as a “team player” has never hurt anyone.

What about the other half of your goals? It depends. Do you want to learn something job-related? Can the company help you? If yes, it’s a win-win situation. You can make your entire plan project-focused. Pick some easy goals if you want to grow your hobby instead of job skills. Choose goals you can accomplish while working on the tasks assigned during working hours. In this case, you want to protect your personal life and free time.

A former manager told me once, “When the management scrolls through the company goals dashboard, you don’t want to be a person whose name displays in red.” Don’t pick anything too ambitious. It’s better to choose an easier goal and be an overachiever than need to explain why you failed.

How to write down the goals

If your company provides a template, follow the template. What if you have a blank page? The SMART goal framework is generally a good way to describe a goal, but I suggest a few modifications:

  1. You need 100% control over achieving the goal

    When you describe what you will achieve, focus on things in your control. For example, don’t promise to improve the ML model accuracy by five percentage points. It may be impossible. You may need access to a better-quality dataset that isn’t available for free. Are you in a position to make data purchases? Don’t promise anything you can’t guarantee. Instead of promising model accuracy improvement, say you will run three experiments.

  2. Process over actions

    If you need a lasting change, build a process.

    Years ago, when many teams tried making their applications GDPR-compliant, they had requirements checklists. Move all personal data to one database. Checked. Stop using email addresses as identifiers. Checked. Delete users’ data when they request it. Checked. Their systems were GDPR-compliant. Once. On the day when they finished the “compliance project.” Afterward, nobody was thinking about GDPR while developing new features. If they wanted proper GDPR compliance, they would need a process ensuring every subsequent code change doesn’t break the GDPR rules.

    If your personal goal involves changing how the company works, design a process and educate others.

  3. Nine-to-five

    Your growth plan shouldn’t need any effort after your working hours. Don’t promise any unpaid work. Even if, right now, you are ok with learning work-related topics after hours, it may change in the future. If you improve your work skills over the weekends or afternoons, don’t make your manager used to it. It’s good when you learn in your free time. However, you should be able to stop doing it at any time. Stopping will be easier if you don’t create an expectation that you do such things for free.

    By the way, working on weekends will hurt you more than it will help you. People hate coworkers who come to work on Monday and send everyone links to things they read/watched on the weekend. Seriously. You make them look bad when you do such things, and they don’t. Of course, sometimes it doesn’t matter. “Haters gonna hate.” You can choose to grow your career over having good relations with coworkers. Nevertheless, you should be deliberate about your choices and know the consequences.

    Also, if you are a manager, don’t say, “look what I found on the weekend” when sending a work-related link. “Look what I found” is enough. They don’t need to know when you found it.

Do I tell you to game the system? Yes. If you read this blog post, you are smart and ambitious enough to learn without formal growth plans. Unless you want your employer to pay for a course/book/exam, those plans are a burden you don’t need.

Did you enjoy reading this article?
Would you like to learn more about software craft in data engineering and MLOps?

Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!

Newsletter

Do you enjoy reading my articles?
Subscribe to the newsletter if you don't want to miss the new content, business offers, and free training materials.

Bartosz Mikulski

Bartosz Mikulski

  • Data/MLOps engineer by day
  • DevRel/copywriter by night
  • Python and data engineering trainer
  • Conference speaker
  • Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
  • Twitter: @mikulskibartosz
Newsletter

Do you enjoy reading my articles?
Subscribe to the newsletter if you don't want to miss the new content, business offers, and free training materials.