![wide: Sunset in Austin. &copy; 2021 John Apostol](hero.jpg)

After a career of writing software for 7 years, I accepted the responsibility of leading my first engineering team.

As a newly minted engineering manager, it was my job to enact the process changes and efficiency tweaks I had already been advocating for. I could pave the way for useful cross-team guilds. I would get more face time with our engineers to understand their motivations.

Becoming an engineering manager felt like an additive to what I had been doing. There were a lot of new tools at my disposal; and I was happy to use them. I greedily filled my cup of knowledge as I embraced uncharted territory.

## I didn't expect to lose my ability to write code
I was sure I could still devote at least a third of my time to reading and writing code. It would be possible to stay up to date with our codebase, as long as I put the effort in. I was confident I could balance with one foot in both worlds.

To that end, I scheduled myself a monthly recurring "code day" clear of meetings. There were a few product tickets I self-assigned, small ones that wouldn't be missed either way. I told the team that I was doing this to keep up with them. As a way to maintain sympathy with the development process. Below the surface, I was mostly doing this to maintain my skills.

I compared myself with other managers; both at that time and from earlier in my career. Specifically, I was comparing our technical skills. Were others maintaining their technical edge alongside the teams they were cultivating?

![center: Climbing the steps of the Fushimi Inari Taisha shrine in Kyoto, Japan. &copy; 2021 John Apostol](inari.jpg)

Some senior managers still wrote code as a form of stress relief. Other managers, I remember, wrote code because there just weren't enough developers otherwise.

> Like some sort of secret weapon hidden behind Jira tickets in the backlog.

Others didn't write code. They were people leaders, project managers and partners across the organization. They greased the wheels and filled in the blanks so the dev teams could keep moving.

A few people had proudly said they could always get their hands dirty&mdash; if they needed to. Like some sort of secret weapon hidden behind Jira tickets in the backlog.

The first manager I had didn't let go of his technical side. He burned both ends of the candle; hustling to make sales for the company he built, while foregoing sleep and rest to make designs, and write code for clients' websites and emails.

He would take me aside and say, "John, we eat what we kill." We were lionesses hunting for the pride. We needed to hustle to make things happen. He would say this with bags under his eyes from pulling an all-nighter. I emulated him a few times, burning out with regularity every few months.

---

## The first year
My attitude when I first started managing a team was that I should be doing doing more than 100%. Managing the team day-to-day was an addition on top of what I did as a software engineer. I was striving to be the technical lead and the manager. My motivations were fear and safety.

I was good at writing code. I was a technical leader on the team, at least. I was afraid that if I wasn't writing code, things weren't going to get 'done right'. I was afraid of my team failing; and so I was reaching for the methods I knew best.

My first year as a manager was tumultuous. I couldn't find balance between what I needed to do and what I desired to do. I spent lots of time reading code reviews. I stole moments to write unit tests. I joined in the dev chatter about the latest trends in open source.

My cup was often running over and I was slipping in the puddles.

![wide: Suspended above sulfur vents on Mt. Ōwakudani in Hakone, Japan. &copy; 2021 John Apostol](sulfur.jpg)

---

## 2 teams, no time for code
There was a turning point when I picked up a second team to manage.

A colleague was having a baby and would be on parental leave. I was craving an opportunity like this to test and grow my capabilities as a manager. I felt I could manage two sets of priorities, two business stakeholders, and two teams of engineers.

I also knew I had to drop code altogether in order to make it work. I figured it was a temporary thing, until I went back to managing one team.

> There was no discernable dip in quality. It was going up, actually.

Honestly, it was surprisingly easy to avoid writing code cold turkey. My mind was filled with other logistical puzzles, and I never had time to entertain a line of code. The new team's codebase was fresh and unfamiliar. It would be difficult to ramp myself up to become an efficient code contributor. My original team had plenty of experience together, and needed project guidance, not technical help. Everything was more important than me writing code.

To no one's surprise, **features were still shipping**. Code was being reviewed. There was no discernable dip in quality. It was going up, actually.

It was stressful managing two teams. I wouldn't be able to keep that up for a year. That said, it was freeing to step away from my code editor.

In time, I separated from my first team and started managing the second team full-time. I had successfully removed myself from writing code at this point.

I repeated to my team what I knew was true, "You're the experts of our code, let me know how I can support you." Every now and then I would slip with a technical assumption. The devs would humble my thinking with their observations and plans for our work. They have my trust.

---

## I'm not the secret weapon
2 years into leading developers, I haven't lost my ability to write code. But it's different now.

![center: Alongside my wonderful colleagues at a STEM career fair at Texas State University. &copy; 2021 John Apostol](txs.jpg)

I've welcomed the overall shift, because it's allowed me to achieve balance and become a better manager and mentor overall.

My default way of approaching a software problem is as a system of possibilities, anchored to developers who will ultimately find the most pragmatic solution. All I have to do is bring the problem and surround it with context. I have a vibrant team of thoughtful software developers who are the experts.

Every now and then I may dabble in an internal tool to improve the developer experience. I'll forget some syntax here or there, and have to spend more time reading documentation to get back up to speed.

I still read a few code reviews to see how the team is collaborating, but not to stroke my ego as I did before. I try stay out of technical discussions, opting to tag a developer in my place. I've also changed my monthly recurring "code day" to a "docs day", where I read and write documentation, mostly about our team processes.

Each software project is an opportunity to hone our skills. Formerly, as a software engineer, I felt that opportunity knocking every sprint. As an engineering manager, I'm happy to do the knocking.

Letting Go of Code to Find Growth

![wide: Welcome to The Zebra! &copy; 2021 John Apostol](hero.jpg)

There's a non-trivial amount of preparation you made when hiring for your team. You had to anticipate the need, make the requisition, screen candidates, interview the best ones, and finally make the offers.

There's a moment of triumph you feel after a candidate signs. Recline, spin in your chair, you're done.

**But you're not.** You're forgetting something. You have the biggest opportunity you will ever have to set them up for success.

Employee experience begins with the application, continues through the interview, and then kicks up after accepting the position. Your new hire is excited and likely anxious about what comes next.

You have a captive audience. Welcome them properly. The goal here is to ensure they land on their feet and know what's expected of them.

I like to do this by answering some common questions that run through a new hire's mind.

---

# How do I set up at your company?

I'm glad to work with a great company onboarding team that takes care of all the prerequisites. My new hires are set up with their essentials. It's a straightforward, turn-key process for me.

That said, it's still important to remember that onboarding at the company is top of mind for your hire.

Remember, they've made a big life decision to work with you. **All** of the basic questions around compensation, PTO, acceptable work hours, equipment, and relevant access must be answered first. Make it as easy as possible to work for your company, before considering how they will work for you.

I tell it straight.

> "Make sure you have your direct deposit information, HR forms, and all the other pieces solid before worrying about your first project."

I give them space to figure all those things out. People want to 'hit the ground running' and give you a good impression, but that's unnecessary pressure on top of all the changes being reckoned with.

If you effectively **are the people team**, then do take care of this stuff first. Make this your only priority. Your new hire can't effectively deliver on the team's goals if they're unsure when they'll get their first paycheck or how to log into their new email account.

Get them what they need.

---

# How will I work with my manager?

You new hire is a stranger. They have an impression of you, but they don't know what it's like to work with you. Give them a headstart and save trouble for the both of you.

I like to do this by sending a personal welcome email after they sign. In that email, I express my satisfaction in them coming aboard, make it clear to prioritize getting set up. Crucially, I take it a step further by sharing [a one-page guide on working with me](/about/manager).

*I'm honestly proud of what I wrote there and seeing my latest hire's reaction prompted me to write this post in the first place. Feel free to reference it for your own.*

I encourage every manager to think about what makes them tick. Think about what success means to you and how your reports can be successful working with you. If you're a lock, this is the key. Write it down and give it to your people. They will love the cheatsheet. It serves to clear anxieties and level set on your expectations.

You don't need to have it on a website, but I do recommend you have it digitally so you can share it as needed and refer back to it when you need to ground yourself. **Spend real effort on this.** It will pay off down the line.

---

# What's expected of me?

If you've given your new employee your one-pager, you're already partway to answering this one.

While every new hire should be able to receive your one page guide, most new hires require a personalized 30/60/90 plan.

For clarity, a 30/60/90 plan lays out expectations for your employee to meet within 30 days, 60 days, and 90 days. These are the milestone steps that they will center on to ensure success.

Here is where you can lay out the projects ahead of them and what deliverables would be required. I find it's best to keep the 30/60/90 light and digestible. There should be room for interpretation, both yours and theirs, such that success is defined but the details aren't precious.

Here's a plan very similar to one I've given in the past.

```
## 30 days
- Read & learn
- Ask questions. Get answers.
- Get some useful code into production

## 60 days
- Find your groove
- Overcome some challenges
- Start contributing to our roadmap initiatives

## 90 days
- Focus on roadmap initiatives
- Improve our team
- **Own** your code
```

My example here is purposely vague for when I was hiring a generalist engineer. I've given much more specific ones as well. You should tailor the 30/60/90 plan to guide their expectations on what you're looking for.

Make it accurate and hold them to it.

---

# How do I work with my teammates?

If you want your new hire to transition well, they need to understand all the relevant personalities they will work with. Thankfully, you don't need to spend much effort here. This should be delegated to your team.

I like to do this by scheduling 1:1 meetings between my new hire and each person on the team. I space them out at least 1 day apart and account for 45 minutes on the calendar. Why 45? Not conforming to a 30 minute or 1 hour meeting gives some fluidity and ambiguity, which is perfect for meeting someone new.

In the event description I write something like the following:

> Please meet <teammate>! She is our team's Quality Engineer, working to make sure that we ship appropriately functional products. <teammate> joined us back in <year of hire> and has a great knowledge of our team's services and how they interact with other services.

I also provide a *proposed* agenda, which they could honestly do without. I think it gives some touchstones and guideposts for them if they need it.

Make sure both of them can manage the meeting in case they need to reschedule or add a video conference link.

Lastly, remove yourself from the equation by declining and removing yourself from the guest list. It's not about you.

---

This isn't all-encompassing but I hope it was helpful for anyone wanting to give their new hire the best experience and all the tools they need to be successful. Remember, their success is your success.

*If you found this useful and are looking for a great opportunity managing amazing humans at a company with an unmatched culture, please consider browsing [The Zebra's careers page](https://www.thezebra.com/about/careers/).*

John Apostol

Posts about Management

Letting Go of Code to Find Growth

How to Welcome Your New Hire