Hey Folks,

For those who’ve been reading this blog for a decade or two, this article may seem a bit out of place. It’s not a cool hack or a game review or software that I’ve written. It’s honest advice that I give to managers in my org. Over the past 20 years my career has been an ever-increasing set of leadership initiatives, engineering challenges, and public mistakes. I’ve decided to start sharing a bit more of those aspects of my career. I’ll be cross-posting more from my leadership medium blog, and from Avvo’s engineering blog. This first article is based on a talk that I give to first-time managers and people leaders, and I hope it has value to all managers and leaders.

My first day leading a team at Avvo was very different from my first day leading a team. That’s because my first ever day leading a team was an unmitigated disaster. I had no idea there was a fairly set script for coming in as a people leader. I had to learn that the traditional way, through a series of disastrous career mistakes and embarrassing social gaffes. We’ll cover those in detail in future posts. For this entry, I want to cover my script for an incoming manager or team leader.

As an incoming people leader, you might be meeting this team for the first time. You might not. That doesn’t actually change what the team needs from you, but that might change how you go about forging the relationships you’ll need to become an effective leader.

There are three main phases to your first day (days) as a leader, and they correspond to the needs of your team.

Phase #1 — Humanize yourself, and state your expectations.

Depending on the size of your team, this phase may take the entirety of your first day or two. You need to make a personal connection with each member of your new team. This means 1:1 time. For the first day, you’ll give your introduction about who you are and what you represent, and you’ll listen. I like to talk about some of the larger mistakes I’ve made, balanced with some of the achievements that came from those tough learning experiences. It’s important that your team understands that mistakes will happen, but that it’s how we correct and prevent future mistakes that’s important. Humanize yourself, but more importantly state your expectations.

Buy your new report a coffee, and get yourself something large. Spend the next hour slowly sipping so you’re not tempted to talk unless asked a direct question. Out of the next hour, you should take at most five minutes to make your introduction, then the next 55 minutes should be spent listening and writing notes. You will be asked questions, but they’ll often be the light softball questions that occur when folks are feeling each other out. Make sure you state your expectations up front, and if there’s something they need to know, this is your five minute chance to let them know right off the bat. For me this is where I take five minutes to discuss ‘share of voice’ (the idea that everyone needs to feel like they have an equal share of the conversation), feeling respected and respecting others at work, and how our 1:1 conversations will go.

Don’t eat breakfast on your first day, as you’re going to be showered with free food and likely a free lunch. As a people leader you’ll need to get used to expensing lunches and coffees. Lots and lots of coffee.

You’ll also want to 1:1 with your product manager, UX/design/content strategist, qa/testers, data and business analyst peers. These are vital team members, and you need to understand the process and relationships from all viewpoints.

Phase #2 — Understanding your Team’s Challenges

Your first day or two full of 1:1s will be a deluge of information. Often there will be friction between business units (i.e. developers and QA should work hand-in-hand, but in a dysfunctional organization the natural tension between their roles becomes unhealthy.) There may also be friction around interpersonal dynamics within one business unit (i.e. there may be an underperforming team member, unhealthy deadline pressure, poor interpersonal interactions from frustrated developers, etc.)

Bring a notebook, and write it all down. Offer no solutions, as you don’t have a full picture yet. This is just your time to listen, and answer any questions around you and your background and leadership style.

Phase #3 — Public Goal-Setting

If you’re extremely lucky you’ll get to this on on your first day. Commonly this could be day two or three. Do not let this go past the first week. You need to be clear with a public goal, and it needs to solve a challenge that you recorded during your first week of 1:1 conversations. You may have heard, “first impressions are the most important” or “there’s only one chance for a first impression.” It’s not so dire as that, but there’s truth in these adages. The tone and expectations you initially set with your team will be the backdrop against all of your future requests and leadership. Similarly, the success you have with the team towards a shared challenge will be the backdrop against all of your future initiatives with the team. Are you a leader who can follow-through with their vision? It’s vitally important to the team that you are, and setting that expectation will pay dividends in future initiatives.

I can hear you thinking “But wait Hunter, my direct reports didn’t voice any major challenges, things must be perfect on my new team!” Okay, I can’t really hear you thinking that, because there’s no perfect team. Still, you know there are common areas that a team needs to improve in, and yours will be no different:

• code review and pair programming
• continuous integration and deployment speeds
• engineering focus and code quality
• interpersonal relationships and dev/UX process
• agile processes and agile readiness
• TDD / test coverage / test culture

If no improvements have been offered, pick one you know they need from the above list, create an MVP around it that solves an important aspect of the problem or sets the team up to be able to solve it themselves, and have it be something you know you can finish by the end of your second week. You’ll be asking your team to break stories down into smaller parts, and you should be able to demonstrate this paradigm as a team leader. Preferably choose something you’ve done in a previous position. Worked as a release engineer in another life? Automate the release process. Awesome at pair programming? Bridge that out to a pair schedule and sell it to the team. It’s vital you work to build trust with your team, and for an engineering team that means visible output.

And that’s how you start leading an engineering team.