Make onboarding a breeze with a 30–60–90 plan

Whether you’re starting a new engineering job soon or have only just begun looking for new opportunities, taking the next step in your career can be a daunting experience. Set yourself up for success and stay on track using a simple 30–60–90 plan, which will help you prioritize your goals for the first three months at your new job and make your onboarding process smoother.

Wait, a plan? B-but, I hate plans!

Contrary to public opinion, software engineering is not about churning out huge amounts of code. Yes, having solid knowledge of a particular language or technology is a must, but at the end of the day, it is all the other qualities that define you as a professional. To name a few things, a good engineer needs to have a vision, empathy, intuition, and critical thinking skills. They need to be able to see the bigger picture, and they should always strive to be a team player.

So when you apply for that exciting new position, you might find that your killer CV and impeccable live coding skills just won’t cut it. All your hard skills might not mean much to a recruiter (or engineering manager) if you cannot explain to them what drives you, what your goals are, or why you’re even applying in the first place. Having a well-thought-out plan is a great way to communicate that you truly care about your work, that you know what you can bring to the table, and how it can help you and your new company grow.

Likewise, drafting a plan before or just after joining a new company can be beneficial in many ways. If you do it right and loop in your manager(s), it can serve as the first step towards successful onboarding, acquiring domain knowledge, and later on, building a more in-depth growth plan. You might find many other times when it’s good to use a 30–60–90 plan, such as after a promotion, performance review, or move to a managerial position.

With all that said, I should probably let you know that just a few months back, I didn’t know any of this. I relied on my skills as a developer and words like “planning” and “growth” didn’t really come naturally to me. It took changing my job and meeting some awesomely talented people to finally learn this.

In the next few paragraphs, I will tell you about my story of joining Productboard and formulating my onboarding plan. Later on, we will lay out some basic elements of a good 30–60–90 plan and part ways with some helpful tips.

I have a cunning plan

Earlier this year, I joined Productboard as a frontend engineer. I did not know much about product management but I had heard great things about the company and its product. What really appealed to me was the idea of being part of developing such an industry-defining piece of software. Later on, during the interview process, everyone impressed me with their knowledge and openness. I finally decided to give it a go.

This was a big step for me as my previous working experience had been with digital agencies. I didn’t want to underestimate anything, especially the first few weeks and months. That’s why I was thrilled when my new teammate Honza suggested that I write a 30–60–90 plan.

(By the way, Honza has recently published an amazing three-part article about engineering life at Productboard. I can’t recommend it enough!)

As one would expect, I jumped straight to writing up my plan before doing any research about how to actually do it properly. I thought — this will be awesome, I’m going to devise this fantastic master plan today and stick to it for the next three months! Needless to say, I was very, very wrong. Naturally, there is no way to have all the necessary information right from the start. I quickly learned that my plan was something that would need to be revisited and updated frequently. In short, the 30–60–90 plan is a living document and should be treated as such.

A 30–60–90 plan is not something to be written for others, it is written for yourself.

The first meeting with my engineering manager Joska offered another unforeseen revelation. A 30–60–90 plan is not something to be written for others, it is written for yourself. Your manager will not critique it and use it to evaluate you — it’s not an early performance review tool. It is simply a personal framework to guide you in your first few months. Something to bring structure, to help focus on learning and personal growth.

With that in mind, I came up with a somewhat better plan. In the first 30 days, I would focus on getting up to speed with my team’s processes and try to meet as many team members as I could. The following month would be spent getting to know stakeholders outside my team and starting to gather feedback. The last 30 would have me pivot towards long-term growth.

My 30–60–90 plan at Productboard
My 30–60–90 plan at Productboard

Even though these focus areas and some of the goals were good, it goes without saying that the plan was not perfect and some mistakes were made. As I noticed after a few weeks, some goals turned out to be a bit confusing. Some of them could be described as non-quantifiable, such as “Understand my team’s scope of work.” How exactly can this be achieved? How can I measure this? It became obvious I would need to skip or re-formulate this one.

Furthermore, a handful of goals were not defined clearly enough, such as “Complete a product ticket without oversight.” Hmm, what constitutes a product ticket? What exactly does it mean “without oversight?” Our developers work very closely together and frequently collaborate on tasks, be it via pair programming or simple discussions. It could be said that there is no work ever getting done without some form of oversight or collaboration. This goal was off the table as well.

Last but not least, some goals I simply failed to complete. An example of such a goal would be “Gather one-on-one feedback from teammates.” Although it had been defined quite well (even if it could have used some metrics), I just couldn’t find the time to meet everyone on the team individually. I might have been a bit too ambitious, considering the number of other goals I have set for myself.

All in all, even though my plan was clearly not perfect, it certainly helped me a lot during those first frantic few onboarding months. Not only has my path to becoming a full-fledged team member become much smoother, but I can also safely say that I even learned a few things from laying out the plan itself. It was a handy focus point for the initial one-on-one talks with my manager, it helped me understand how to set meaningful and measurable goals for myself, and I’m sure there are plenty of other lessons to be taken from it that I haven’t even realized yet.

Okay then, where do I start?

On paper, it all sounds pretty simple. Creating a 30–60–90 plan means drafting up a plan for the following 90 days in three-time increments. The format is up to you — it can be a simple checklist, a kanban board, or even a roadmap.

Simple enough, right? Well, there are a few challenges to bear in mind. Finding the right velocity, formulating actionable goals, and figuring out sensible metrics are some of the things that can go wrong if you set up your plan incorrectly. Let’s have a look at some basic elements of a solid plan:

Focus areas

While you might be tempted to jump straight to writing concrete goals, it is a good idea to outline a few high-level focus areas and priorities. These can range from learning and onboarding to contribution and personal growth. Typically, you will focus on learning about a specific role in your first 30 days, then turn to contribution for your first 60, and finally shift your focus to personal growth for your 90-day goal.

Examples: Learning, Contributing, Taking initiative, Personal growth.


Once you have figured out your focus areas, it is time to break these up into concrete goals. This can mean learning a skill, mastering a new language, completing a set task, or meeting with a key stakeholder. Basically, anything that can help you in a specific focus area.

Examples: Learn Kotlin, Read through React docs, Have 1-on-1 meetings with all team members.


This plan is made to be revisited often. You will make your life much easier if you make your goals measurable. For certain goals, like meeting with a person or reading through the documentation, this comes naturally. For others, not so much — how do you set a metric for completing onboarding or performing at a high enough level?

Thankfully, not all goals need to be strictly quantifiable. For example, you can ask your teammates for feedback and use that as a metric of sorts. Whatever metrics you choose for your goals, be sure to revisit and reevaluate them with your manager frequently.

Examples: Complete 1 task, Have 2 pair programming sessions, and Gather feedback from 3 teammates.

Tips for your plan’s success


First and foremost, your goals should be SMART, according to the eponymous management mnemonic. That is to say, they should be specific, measurable, achievable, relevant, and time-bound.

So before you start drafting those few first goals, imagine yourself evaluating them in a few weeks’ time. Have I thought this goal through? How do I know if I completed it? Can it even be completed? Is it relevant to my team and position?

(The last one you get for free — our plan is in and of itself time-bound. If you really want, you can leave the T behind and think of it as the SMAR mnemonic. ️🏴‍☠️)

Be flexible

You might think that a 30–60–90 plan is some sort of binding document that should under no circumstances be changed. Nothing could be further from the truth. It is important to remember that this plan is intended to help you in your new venture, so it should be up to you to update it, reformulate some goals, or scrap them altogether.

Besides, when you are starting out in a new job, it is practically impossible to have all the information right from the start. Some goals can be finished sooner, some might become irrelevant, and new ones might be added later on. So feel free to go back to the drawing board once you learn more about the ins and outs of your company’s processes.

Be thorough

While drafting up a plan is fine and dandy, it won’t do you much good if you don’t stick to it. Make a point of revisiting your plan every week, whether it is during regular one-on-one meetings with your manager or simply on your own. I strongly suggest the first option, but if you go for the latter, make sure to at least set a reminder so that you don’t forget.

Be realistic

Do not overpromise. Pick a couple of things you know you can accomplish, even if you are a highly ambitious individual. Hey, you’re starting a new job at Faceflixoogle which is a huge challenge on its own. Cut yourself some slack and don’t try to do everything at once.

Final thoughts

Joining a new company can be a tough challenge, with lots of new information to be acquired and many new processes to be adopted. During this intense period of time, adding even more complexity in the form of a plan might seem counterproductive for some, especially for task-driven software engineers.

However, a well-crafted 30–60–90 plan can help us formulate priorities, acquire necessary domain knowledge, and keep focused on what is important, while showing proactiveness and personal growth to managers.

A reasonable 30–60–90 plan also brings with it an important mindset shift. Instead of focusing solely on your coding performance, you will think about the bigger picture. How do I function as a team member? What are the next steps in my career? How do I start laying out my long-term growth plan? Answers to all of these questions might just come more naturally to you if you have a solid 30–60–90 plan ready to go at the start of your new job.

Do you use a similar plan at your company? How do you stand out during a job interview? Do you have any tips for a smooth onboarding process? Let us know in the comments!

Interested in joining our growing team? Well, we’re hiring across the board! Check out our careers page for the latest vacancies.

You might also like

How to do a code review — some tips and tricks from the Productboard engineering team
Life at Productboard

How to do a code review — some tips and tricks from the Productboard engineering team

Tomáš Balvín
Tomáš Balvín
Why I switched from Java to Kotlin — and how I’m using it at Productboard
Life at Productboard

Why I switched from Java to Kotlin — and how I’m using it at Productboard

Pavel Spáčil
Pavel Spáčil
Engineering manager vs senior engineering manager – what’s the difference? 
Life at Productboard

Engineering manager vs senior engineering manager – what’s the difference? 

Jiri Necas
Jiri Necas