How I Learned to Onboard Effectively in an Engineer Manager Role
Understanding my behaviors from starting new roles over the years
Onboarding at a new company is an immensely engaging experience, where the difference between an effective or ineffective onboarding is an action away. As a software engineer manager, I’ve reflected on the unique behaviors I prioritize. This post will cover the gestalt of my successful onboarding experiences within the first 90 days.
Starting with Having Good Tact
The onboarding process is a bit of luck, timing, and keeping in mind good tact. Good tact is the ability to deal with others to maintain good relations and avoid offense. To say and do the right things at the right time, to behave in a way that promotes cooperation and reciprocity.
There is a wide range of impactful behaviors that I consider good tact. My go-to’s are to make myself available, never criticize a previous decision, and avoid being standoff-ish. With these tips in mind, my initial actions include orienting within the company, shadowing, listening, building relationships, finding leaders, and succeeding at the first mission. First, I will familiarize myself with the organizational structure.
The “I Am Here” Metaphor
In starting a new role, I orient myself within the organization. Above me, senior leaders. To the side of me, my peers, and my allies. Finally, below, my directs. Building this mental model provides areas to build relations. I call this the “I Am Here” model, a graph of people that will help make myself and others in my radius eventually effective.
In the beginning, I draw this graph out, giving names, labels, and their accountable domains. This map prioritizes people to have conversations with, with proximity to my teams as the driving factor.
Building Lateral Partnerships, the Skip Levels, and 1:1's
While building a mental model of people around me, I get to know them. For peers, having a coffee or tea with them can be effective. These connections avoid ineffective future fire drills, such as when my team needs help. This new relationship can contribute to solving an emerging problem.
I’ll begin continuous rounds of 1:1’s to build trust for the team members who report to me. I start the conversation as one team — in a newly minted reoccurring staff meeting. I will announce the 1:1 meetings, the goal of the discussions, and take on any questions they have. Then, I roll them out.
I’ll also schedule skip-level meetings with other senior leaders above me. I start with having the support of my manager in this process. Once I have support, I’ll meet with directorship and higher levels. I’ll ask questions about the vision, direction, and the pain points of the organizations they lead, to calibrate where I can focus, building a horizon roadmap. These skip-levels inform me of the larger mission — the why of the work.
Listening, Seeing Inside the Team, and Setting Ground Rules
As I settle, I’ll add myself to meetings to shadow others. I will ask questions to know more details about the processes of work and team agreements.
Remembering the “I Am Here” metaphor is essential. The initial conversations with management will inform me how to calibrate the team goals desired by the organization. In my opinion, an engineer manager is the shepherd and translator of these desired outcomes — bringing personal flair and philosophies of what needs tending.
The challenge is to balance the listening and to enact process change. Steering my behaviors is a mix of experience and intuition. I’ll take a moment to review my previous experiences.
Solving the First Gnarly Problem
Some weeks in, I pattern-match the problem in the organization where I can align my team to tackle. In years as a new manager, I realized I was hired for something that may have been tactical, in addition to the strategic investment focus of growing an organization, sponsoring others, and creating a blast radius going well beyond myself — the reason why managers exist. Finding my first mission and expected outcomes aligned to leadership goals is vital.
I call this “The first gnarly problem.” Such problems include delivering a minimum viable product (MVP) from a team, becoming a janitorial expert in cleaning up the product and technical debt, being part of a reorganizing effort, or growing new teams while delivering migrations and new products. A path will appear where an approach needs directing that I’ll be solely accountable! My goal is to find the essence of this mission with peers and senior management in the first weeks. Once the task is clarified, I’ll be explicit about change.
Be Explicit About Change
I have been known to repeat an expectation numerous times in front of the team. In a room of ten people, I say the “thing” ten times for one person to “get it.” Being specific about change means being explicit. One of the lessons I’ve learned as an engineer manager is being implicit or nuanced is considered cruel to the team.
Being explicit is an easing function of reducing the cognitive load of the team. Providing clarity about a difference, communicating, and enacting, allows the team members to focus on what matters. The practice will reduce second-guessing motivations. Setting expectations is essential, such as which measures we are optimizing.
As I make the first real change to align to the gnarly problem, I identify the perceived problematic behaviors leaders frown upon and avoid acting that way, finding alternative routes. For example, complaining about the number of meetings but not presenting alternatives to increase their quality (such as experimenting before a pitch).
My approach to change is to continually ratchet based on the evidence’s the team’s efforts. If a ground-rule must pivot in a positive direction, I will use evidence to prove this is a supported decision. In addition, I remind the team of the why of the work. Change builds upon other previous findings, sometimes documented.
Change Means Documenting
For decisions that have come before me, there is documentation I can discover. By seeking out these documents and reviewing them with the team, everyone will understand how the previous decisions were made.
I call this document for inversion of control. The best way to build trust with the team is to look at documents prior (a team agreement, charter, a design doc), have a conversation, introduce a change, and bring in a new idea. And then, document it!
There will be points where my gut will tell me something needs to change where evidence cannot be presented. The best I can do is focus on the why and back it up with my experience. Then, I write a new document, broadcasting it to the team as a working session. The document will be a part of a decision library, ultimately scaling the team knowledge.
Sitting on the same side of the team by actively working through a plan, a decision, or some rough architecture builds trust in an immeasurable way. I label this as an “inversion,” the document being in the middle. Including problem solvers at a higher level affirms my commitment to the team and understanding the working conditions. They also get to know me well, uncovering the first deep problem I am held accountable for delivery.
Healing the Gaps, and Future Plans
In these first months of the gnarly problem, I attempt to find gaps where my specialty can shine, and I light the candle. My goal is to create a space to solve this problem. I see myself as a value add — actions like making a decision, finding others to help, applying a technical skillset, or creating the space for my team to work. I build buffers to solve the problem.
As the mission is clarified, one of the more challenging problems I’ll solve is to remove work burdens and liabilities. The team will have work in their queue that doesn’t align with the mission. It is on me to work with product and project management to refactor away. Creative thinking, rerouting, and renegotiating are the methods. It is always easier to add work than to remove work. To unburden the workstream, to cover, is a skill set I continue to hone for my teams.
While the team is steering to delivery, I will also get involved in OKR development, KPI clarity, and road mapping. These strategic exercises will become familiar, where my inputs will set the stage past the first win. Bringing in the team for estimation exercises is vital during future planning, even wild guesses. I incorporate estimation with letting the people on the team craft the plan, and in doing so, own the plan we come up with. This practice uncovers the subsequent gnarly problems.
In The Gnarly Problem, Hire and Find The Next Leaders
When work happens, I will see behaviors and patterns of potential leaders in the team. I keep an eye on those excelling at collaboration, skillset, unblocking others, and similar behaviors I would like to see more of. For what I can or hear directly, I set time to recognize their efforts and attributes.
There will be times of stress in execution. With this narrowing, the natural leaders within the team rise. At the same time, I observe people doing the glue work, and the collaboration efforts are not visible to those who churn out the delivery. I consider glue work as daily mentorship, unblocking others, and filling gaps that aren’t obvious. I call upon them and make them known to upper management.
In executing the gnarly problem, I review capacity, start the plan, and hire others. I expect hiring to begin as soon as there is a project plan. I’ll reach out to recruiting, start a dialogue, and find my way to create the hiring loops. I’ll make my first hire within six months.
There will be moments where I will find contributors not doing well to newly set expectations. These moments are an excellent chance to start giving feedback and micro-goals to each of these contributors, offering an opportunity for them to course correct. This first mission is a proving ground for adjusting the values I am bringing into the team. I will reinforce these values, being explicit and enacting change. As the manager, the team ultimately reflects what I accept, so I adjust team members according to their strengths.
Taking a Side Quest Initiative
While my main execution line is running, other problems need solving in the organization, and no one is asking me to lead these. Whether it is a problem my peer is having, senior management is struggling with, or an observation about the environment, this is my chance to identify and act on it.
These projects vary wildly. Some projects include improving hiring pipelining, maturing the organization from a developer experience perspective, or running sponsorship and internships. These side quests, also called initiatives, may quench my thirst as an individual contributor or coordinator, and at the same time, these initiatives grow the organization.
These initiatives grow a social network, ultimately helping my team(s), management, and peers. I find disparate initiatives exciting, potentially having a positive impact on the organization and myself. They are creative outlets.
The First Celebration Moving Past the 90 Days
In the journey, the gnarly problem will come close to a resolution. My plan continues as to what I described above. I keep clarifying, redirecting, filling gaps, and maintaining the motivation, ensuring the team delivers the outcome. And at the correct times, delegate work.
Once the outcome is achieved, I coordinate the celebration with the people and team(s) that reached the results. For me, this is the validation of a successful onboard — to follow through with something larger than myself.
The celebration means the onboard is complete. The process repeats, with continual refinements, improvements, the growth of others with promotions, and finding new initiatives.
Keep Going!
While onboarding as an engineer manager can be exhausting and exciting, there are points in between where there is extreme satisfaction. Seeing my team get their first win, impacting users with a superb product, promoting someone because of these accomplishments, and maturing processes.
My onboarding goal is to keep good tact and know where I am in the organization. Then, listen, see how the team operates, be explicit when it becomes clear where I need to steer. I’ll discover and solve the first gnarly problem. I’ll hire, find the next leaders and give feedback to those who aren’t performing. At the same time, I take on a side quest to grow my craft and the organization.
Management is a complicated arrangement of getting people to do what they don’t necessarily want to do and becoming an umbrella as a promoter, a shield for the team. But in the end, I enjoy being a manager. Onboarding effectively in the first 90 days is challenging as it is rewarding.
