Onboarding

You strut into a new company, ready to shake things up and lead the charge. On your first day, you take a deep breath, ready to dive headfirst into the unknown. You know you’ll be in for a ride. System to unravel, business jargon to decipher, faces to remember. The big question is, how would you approach this massive situation in front of you? Is there a pattern or principle to follow?

One of the most recent examples for me was when I switched companies almost a year ago. I joined a new startup that struggled on the technology side. I was immediately thrown into the deep end of the situation. I've built some rough playbook on how I approach this situation, and I was able to adapt it to my situations.

Approach

One of the most effective approach that I learned was: Understand – Identify – Execute. The mantra has been helpful for me in the above situation. Understand the scope of the issues. identify levers that you can adjust. Execute the change, rinse, repeat.

Technology

In reality, it's not as simple as that. As a technical leader, my first task was to understand and assess the "technology" side of the company. It means more than you might think. Beyond codebase, what are the tools that the company uses to operate? The hardware, software, and the people side of it. It may also includes tech policies, technology habits, regional culture.

Make a list, iterate on the list, make it even more comprehensive. Then rank it based on priority / business impact. The top 1 or 2 items would be your highest priority to tackle.

Technical Debt

Like humans and countries, companies have debts too. All technology companies have technical debts of various sizes. That is how the world works, and there's no way to avoid it. Don't believe it if someone told you otherwise.

How to approach technical debt by itself is a whole discussion by itself, which I would go in depth in the future. As I mentioned earlier, make a list, iterate of the list, and focus on it based on impact. Keep in mind, technical debt does not only impact the product, but also slows down engineering. That in turn makes the entire company slow. I categorize it as (1) business complexity, and (2) technical complexity. Often times, you can't fix (1) but you can and must fix (2).

One example in my case was around microservices and the way we do software development cycle on it. The team was dependent on running and testing their code on dev or staging environment. I made it my priority to unblock this, and it accelerated the development process.

People

A new team means new people to get to know and interact with. This is one of the more tricky parts of Onboarding. The way I currently think about it – I imagine my thoughts would evolve in the future – is to categorize it into 3:

1. Leaders.
   This includes people-managers and technical leaders. You want to build a rough understanding of their area, and empower them to own it. You'd hope that you have more of these than you actually have.
2. Executors
   These are the people in your team who know how to get things done. Many times, you need to give them direction, tasks, and hold them accountable for the outcomes. Almost all the time, they deliver.
3. Under-performers
   You need to diagnose why they don't perform. Usually, other team members have feedback about the under-performers in the team. Work with HR, make sure they understand that they're underperforming. Clarify what you expect from them. Manage them, or manage them out; otherwise it's going to be a risk for your team – and the company.

Build Allies

At the end of the day, you have to build trusted allies, from your team, and other teams in the company. This part is crucial because you're hired to make changes. Changes don't happen naturally, and most people will show inertia to changes. Trusted allies will help you execute changes, and give you the "insider insights" of how things are. Having allies is the shortcut to understanding the culture of the company in.

But how, you say? There's no secret answer here. Be good and do good to individuals, and show interest in what they do. Over the years, I learned that people love to talk about about what they do if you show genuine interest.

Processes

It is invisible to the outsiders, the flow of information, directions, and the rhythm of a company. As a technology leader, it is your job to discover and understand this flow, across the company. Which departments are perceived as superior and have all the powers? Moreover, which department is the helper, gets minimal resources and gets the bulk of the work?

More often than not, you see dysfunctions where the flow of information doesn't make sense to you. But, the company sees them as normal. Take a note, and I'd recommend not to jump into the conclusion that they are actual dysfunctions. Things happen for a reason. Understand the historical context and the culture of the people.

Different regions, different cultures, and different parts of the world have different ways. There's no one way to do it right. I take it as an opportunity to learn about different cultures and new way of doing things. Maybe they're right, maybe the perceived dysfunction is better for the company. Understand – Identify – Take Notes.

Share Findings

As a leader, share your findings with your boss, leaders in your team, and your allies. I usually get feedback from them, to make sure I understand things correctly. The challenges I found are actually challenges and issues, and to see if they share the sentiment. Share your opinions on priorities too. Which problems are time-sensitive and must be tackled immediately, and what can wait.

By sharing your findings, you're establishing your presence in the company as a leader. You're beginning to understand the company, the challenges, and start influencing the priorities. By doing this, you invest in your future work: the execution.

Establish Goals

After you understand the situation, you can build a prioritized list of issues and opportunities. It's time to get to work. My go-to way of executing the work is by establishing goals. This can be monthly, quarterly, half-year goals, or all of the above.

You need to create a compelling vision of how it would look and feel for the team when they achieve the goals. Set the timeline for when you aim to achieve them. For example, if your goal is to completely revamp and fix the development process, share some details. How would it be like in the "new world" where the development cycle is fast and simple? How would the team would handle projects, commit code, and release features? Additionally, as technology leader, it's your job to provide options on the "how". Especially if your team doesn't know how to get there. Get into the details of what tools to build, what process to adopt, and which technology to choose.

This is the starting point. You haven't actually changed anything or made any meaningful impact. But now you have a plan, you need to get to work. You got this!