Onboard Tips for Devs

All Onboard!

The technology market is hot for a while, and the heat keeps increasing every day. Several opportunities arise in every developer LinkedIn mailbox everyday: agencies, recruiters, engineering managers are on a constant seek for the next talent.

Amid this turmoil, devs often take their chances to try out a new company aiming usually for reasons such as more challenges, different management approaches, better compensation, and so forth.

On the other hand, as companies grow their business, and also as an indirect consequence of turnover, there is a high exposure to opportunities to climb up to more senior roles, or switch to a leadership one on an increasingly fast track. It is not uncommon to see really young team leaders nowadays.

Every such change, whether it is a new role in the same company, or a theoretically equivalent one on a different company, requires some adaptation. A streamlined onboarding can be the difference between an exciting and thriving career path and a complete disaster.

Here I will present some techniques that I hope to be useful for boosting up the onboarding period, focusing specifically on the technology market. Several tips are taken from the excellent book The First Ninety Days combined with my own experiences as both an engineering manager and a developer over the past 10 years.

The First Quarter

Many companies use a quarterly cycle where goals between business and product areas are reviewed and aligned. A quarter thus, becomes an intrinsic milestone where people look in hindsight to get a sense of their accomplishments. Even companies that run officially longer cycles usually perform some sort of status check to get a sense of directions of their goals every quarter.

With managers and their direct reports, things are surprisingly similar. Over the course of a quarter, i.e, roughly 90 days, there is usually enough data collected to assess the performance and get a first impression; this is especially true and important for situations aforementioned such as new hires and recently promoted personnel. Creating that right first impression might be crucial to get the level of supportiveness from management that will pay off as dividends in the future.

So, without further ado let’s dig into a few tips.

Prepare Yourself

There is often a period prior to taking on a new role either at the same company or at a new one after you have accepted it, but have not yet officially started. During this period, do your best to collect data about the new company and or role.

Check any public material available such as medium posts, public github projects, glassdoor reviews, institutional sites and look for hints of cultural and technical aspects of the company.

If on a different-company transition, whenever possible, connect to your new hiring manager via linkedin and ask for some training material which would be useful for boosting up your technical skills. That level of proactiveness will, in the worst case scenario — assuming that you are not able to learn much — create a good impression on your new manager.

If on a promotion ask for any material related to the new role such as an official job description, RASCI matrix or presentation of any level. Also, connect to people which are already at the role you are getting promoted to and schedule one on ones meeting with them to understand their vision about it.

All in all, the key factor is to get as much information as possible about the expectations of the new role and as soon as possible.

Be specially interested in probing the following:

  • What are the strengths required for this new role? How do I fit in? What are my blind spots? What are the critical skills I will need to develop?
    - Is there any core technology that I would need to learn?
  • What sort of leadership adjustments do I need to make? Am I still expected to get my hands dirty on the code as often? How much delegation should I perform? Am I expected to mentor someone?
    - This is especially important if you are transitioning towards a manager’s path
  • What is the right balance between depth and breadth of knowledge at this new role? Am I expected to know code in detail or just the overall sequence diagrams?
  • If you are joining a new organization, how will you orient yourself to the business, identify and connect with key stakeholders, clarify expectations and adapt to the new culture? What is the right balance between adapting to the new situation and trying to alter it?

Last but not least, prepare your mindset to the transition state: be ready to eventually let go of former strengths and beliefs that made you succeed up till this point if they do not make sense at this new role. Adapt!

Accelerate your learning

Once you have joined your new role, it is time to dive deeper into it. Be the manager of your career and create a structured plan listing out things that you want to accomplish during your first quarter and actions on how to accomplish them. A monthly listing might be good enough, but make sure to create a few milestones to accomplish soon after your entry.

For the sake of clarity I will split the following content into sections for individual contributors and for managers.

Individual Contributors

There are a lot of expectations on devs when they join a company. There is also, definitely, a lot to learn and a period of ramp up is completely expected.

After your first days at the company, you will probably get access to some training materials, alongside access to internal tools (such as VPN, github, corporate email, etc). Besides, you will probably spend some time building up your machine and dev environment.

On your free time, I suggest you to focus on gathering the following information on your early days:

  • What are the main HR artifacts relevant to my role? Is there an official job description ? Is there a career ladder matrix ?
  • What are the cultural values of the company and how do these translate into concrete actions into day to day routine ? What exactly is expected from these sentences on the wall ?
  • How do we set goals and track progress ? What are the main OKRs and KPIs of my team ? Are there performance dashboards available ?
  • How is the development process of new features structured ? Do we use Scrum ? Kanban ? What are the rituals and where are my invites ?
  • Who are the main stakeholders I need to know ? Is there any “who is who” documentation anywhere ?
  • How does software get deployed into production ? How often do we release software?
  • How does communication flow ? What are the main channels I need to be part of and what are they used for specifically ? Are there chapters or other cross functional initiatives I should be joining in ?

Do not necessarily aim for a 100% understanding, but at least have good pointers to all of the above questions in the course of your first 2 weeks.

A mature company will do its best to have the aforementioned questions laid off in a good and well structured onboarding documentation, so make sure to ask your manager for it as soon as you join it.

By the end of your first month, I would consider a few extra bullets as important milestones:

  • Have your fist 1<>1 with your direct leader. Focus primarily on what is expected from you.
  • Have a skip level 1<>1 scheduled with the leader of your leader
  • Have a 1<>1 scheduled with your Product Manager and Product Designer
  • Have a few tasks shipped into production. This might vary largely from company to company; depending on the size of the company and moment of the project, it may be expected to have something shipped into production on the early days
  • Create a backlog of potential quick wins of improvements in both processes, product and platform to tackle down down the road. Share it with your manager and team.

An important tip is to listen carefully and try to understand in the best possible way why and how things are done in a certain way before trying to modify them right away. One might be tempted to put a lot of energy into solving delicate issues without a clear track of the history, culture, and politics that led certain things towards a certain direction, generating unnecessary conflict with other people that were eventually involved in those decisions. In your first month, as a rule of thumb, listen and track things prior to tackling them.

By the end of your second month you should be already fully acquainted with your team. In more senior positions, it is expected for you to be delivering things on your own already, whilst, for more junior roles, some level of guidance is still expected.

Here are a few extra milestone points for guidance that can be used either for the second or third month depending on the pace and moment of the company:

  • Have a draft of an Individual development plan that will help you to advance to the next level on your career ladder
  • Have one or two quick wins, from the backlog you created at your first month, discussed, approved and, in the best case scenario, deployed into production
  • Have a few relevant tasks deployed into production that can be referenced on your self assessment of the next performance cycle.
  • If possible, become a user of your own product
  • If possible, have a conversation with C-Level and ask them about their vision of the company and, particularly, of the product your team is developing

Managers

If you have direct reports, albeit the tips provided above are still valid, you will have to engage a lot more on conversations, culture and politics. Usually, the higher you get the less important it is to get details of things in depth, while you should still be able to have a really broad understanding of what’s going on. If you are a manager of managers, you will need to rely heavily on your direct reports to gather the level of information needed to get you up to speed, so make sure to establish a good relationship with them as soon as possible.

Besides the things that were already mentioned above that still make sense at some level, I would add the following for your entry days:

  • Schedule a presentation to your team covering, at least, the following topics:

— What’s your background

— What’s your vision for the team/area

— What do you expect from devs overall; what sort of behaviours do you treasure above others

— What you do not expect from devs

— If you are a manager of managers, what do you expect from the managers on your umbrella.

  • Gather a track record of your direct reports with HR.

— How have they performed on their last performance cycle?

— Are there any expectations around promotions ?

— Are there any people at risk of leaving ?

— Who is under a performance improvement plan ?

  • Schedule interviews sessions with your direct reports. Those should take anywhere between 30 and 45 minutes and should aim to provide you with, at least, the following:

— Their background

— Their most enjoyable projects at the company

— Their career ladder expectations and how they see their progress thus far

— Their drives and things that demotivate them

— What their team should stop, keep and start doing

— How do they picture the goals and opportunities beyond her team

— What do they expect from you as their manager

Also, in the initial weeks make sure to reinforce to people that you are available to help them ,should any critical matters arise.

Again, having these conversations in your very first two weeks would be ideal, but, of course there might be constraining factors to that agenda so aim to have these initial conversations as soon as possible.

By the end of the first month the manager should already start to get familiar with his/her own team and to get a sense of who are the top and low performers, who are the most supportive people and what are the motivations that drive them towards success. At this point, it is important to have had conversations with peers and key stakeholders, which leads to another checklist:

  • Have 1<>1 conversations with peers checking for good practices that you could apply, probing their style and agendas of common interest
  • Create a backlog of potential quick wins that you have a hunch could be executed in the next months, counting on your direct reports to validate the ideas both in terms of impact and effort to execute.

By the end of the first two to three months a manager should aim to have covered a few extra topics:

  • Have interviewed all your skip levels reports in case you’re a manager of managers, applying the same questions that were asked to your direct reports.
  • Have had 1<>1 conversations with the key stakeholders that interact with your area probing, especially, what they do expect from you and your area.
  • Have had these “five conversations” with your new manager:

— The situational diagnosis conversations (where the manager describes the overall scenario of the team, its goals, and long term objectives)

— The expectations conversations. (what are the raw expectations upon you)

— The style conversation (where you and your manager understand the style of each other)

— The resources conversation (where you negotiate the resources needed for the role)

— The personal development conversation (talk about your own career path)

  • Identify and engage on delivering a quick win for your team, be it on processes, platform, people or the product itself that would bring some initial momentum to your management path
  • Map potential supporters of initiatives you want to execute on the next months, as well as eventual opponents and persuadables. Who are the pivotal players that could help (or oppose) your agenda and what are their motivations ?

What should the company do ?

Finally, as a company it’s in your best interest to make sure that one’s onboarding goes as smoothly as possible. There are a lot of different approaches to tackle it, and while I do not intend to cover them extensively , I would like to highlight a few suggestions:

  • Create, preemptively, a 90-day plan for your new employee joining your organization that would help him to align on your expectations.
  • If the employee is replacing someone, make sure that the leaver creates a handover document with the most critical points to cover with the new employee; this is especially important for managers
  • Make sure to let your new employee have his time onboarding before he jumps into critical operational tasks
  • Have a buddy assigned that would act as the main point of contact of your new fellow whenever he has questions or concerns

In summary, prepare yourself in advance to make sure one feels comfortable onboarding into the new role

Conclusion

This is a very high level overview of good practices to follow on a tech onboarding process.

Also, the actions to take may vary a lot, depending on the moment of the company you are about to join. It is a completely different situation to onboard on an early stage startup compared to a successful big corporation which needs to sustain the pace, as well as ona company which is passing through a complex turnaround or realignment, or an accelerated growth stage. I believe the experiences I described here mostly apply to startup and accelerated-growth companies, which form the core of my own experience.

Changing jobs or roles is tough, so don’t neglect yourself during this period, take some time to rest and make sure your family and friends are there to support you. Let me know what you think of these suggestions. Are there other measures I missed ?

--

--

--

YAEM (Yet Another Engineering Manager)

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Organizational Culture

Stress and Leadership: My Experience as a Startup CEO and Some Steps to Cope

What others want? We do get it wrong almost always.

Six Questions to Ask Before Taking That Product Manager Job

5 Tips For Managing Your Next Office Move

Mentoring programmes: What works

How I switched from a full time career to self employed, remote working.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luiz Rolim

Luiz Rolim

YAEM (Yet Another Engineering Manager)

More from Medium

Why Agile vs Waterfall Doesn’t Matter: The Three Degrees of Perfect Projects

Brilliant Post Agile cartoon by Sam Laing after a talk by Jim Benson. https://www.growingagile.co.za/2016/11/post-agile-stress-disorder-sgza/

Project Management Basics

Project Management Basics

Creating Effective Tickets

The power of managing stakeholders

A group of people presenting to stakeholders.