Why You Should Avoid Being Technical in Technical Leadership

Nearly four years ago, I managed to convince Mike Skeehan, Managing Partner of Salted Stone, that I knew what I was doing... and he hired me on a two-week trial basis as a Front-End Developer. That trial turned into a full-time position, which led to a couple of years as the Dev Team Lead, and more recently, a promotion to Director of Technology at Salted Stone. 

One of the first things I did in my new role was write out a list of goals as Director of Technology. Then, I broke down the goals by quarter. And, because I’m obsessively organized [read: a control freak] I broke down the quarterly goals by week. But, the thing about being a control freak is you quickly realize that things don’t usually go as you planned. When I look back now on my original list of goals, a lot of them were technical. Makes sense, right? These were Dev Team goals, after all.

A few of my initial goals: define and set up an onboarding process for new developers, achieve consistent code through defined best practices, and implement better version control across our team.

As I reflect on what I’m actually doing now, my biggest impact on the team isn’t development-focused. It involves working with even more complicated machines — other humans.

Managing Humans

I firmly believe that you can’t effectively lead a team without knowing your team members. You need to understand their motivations, as well as how they communicate, at any point in time.

If you approach this from a strictly-technical perspective, you’d believe that people’s motivations and communication styles are what they are — and never change. In this understanding, your connection with the individual doesn’t matter so long as you can figure out whether you need to dangle a carrot or wield a stick.

The truth is, people are constantly changing. A core aspect of my job is helping people improve on their weaknesses and cultivate their strengths. This has been true since day 1: when I was a Dev Team Lead, I was trying to figure out who the best developer for a single task was. Now that I'm the Director of Technology, I'm selecting someone to advance into a particular role. This way, I’m always surrounded by smart people who can help pick up my slack.

Collaborating On a Long-Term Plan For Growth

One thing that became apparent to me early on was the importance of meeting with each developer one-on-one. As much as I love my lists and agendas, I didn’t want these meetings to be structured in any particular way. The only unofficial structure for each one-on-one is that it’s weekly and we go out for a walk. We’re in front of computers all day, and I think it’s important to get out and enjoy some fresh air.

Also, some team members have an unhealthy (but totally relatable) love of Wendy’s and instant ramen shipped straight from Japan — so this way I can trick them into getting some exercise during the day ;)

One-on-Ones

During our one-on-ones, which occur every week, we talk about everything from what we did over the weekend, to project roadblocks, to longer term goals. It’s not just a time to catch up—it’s a time to provide guidance around obstacles while trusting them to ultimately take responsibility for their tasks and projects. Sometimes, my sister’s dog Kodi (photographed below) joins us…he’s been known to provide some pretty good insights into challenges we face.

As a leader, one-on-ones are incredibly valuable. I often bounce ideas off my team members, and hearing their feedback helps guide me in how to best manage the team. Additionally, consistent one-on-ones give insight into an individual’s happiness and how engaged they are in their work. A lot of the things I learn during these meetings help me intentionally work towards career growth plans and plan performance reviews.

Performance reviews exist so that team leaders can collaborate with people to help them grow and move forward on a clear career track. But it’s not enough to meet once a year and then check in a year later and say “Oh right, remember those things we vaguely discussed a year ago? Did you do them? Check yes or no.”

It’s important to continue checking in with your team members and to see how on-track their goals are. Consistent check-ins also help you get them back on course early when they start to lose direction.

It’s intimidating to sit across from someone as they review your performance. But if your team has to go through it, then so should you. I believe that a performance review is a two-way street: don’t be afraid to ask people how you’re doing as a manager. I get it. The answer can be scary. But if you make someone a steak and it tastes like complete garbage, wouldn’t you want to know?

Developing a Unique Culture

Developing a unique dev team culture isn’t something I intentionally set out on doing—it just happened as a by-product of working with awesome and talented people. I’ve been so fortunate to be part of a team that feels more like a family than a group of colleagues. We’ve even got a designated “Dev Dad”, and yes, one time a "dev foot huddle" happened. 

One of the things we do as a team is go to Dev Team Lunch every month. I look forward to these lunches, because I always go in wondering what ridiculous conversations we’re going to have. Once, we weighed the pluses and minuses of a Chevy Suburban during a zombie apocalypse, which turned into a discussion of the best defensive attack positions in our office, if said zombies were to attack.

When we first started going to team lunches, we went to a lot of All-You-Can-Eat places, because we wanted to get the most bang for our buck. Our #MEATSWEATS culture evolved from one lunch where we went to AYCE hot pot, proceeded to order and eat [almost all] 15 plates of meat. Since then, our method of team bonding has involved eating until we’re uncomfortably full. One time, we ordered 80 nuggets from McDonald's. For real.

Additionally, we stack our phones at the beginning of every lunch. We call it “Phone Stack” because we’re developers, not copywriters. The first person to reach for their phone before the check is paid has to buy everyone on the team dessert — which has yet to happen because we’re busy chatting with each other. (I’m still on the fence about whether or not this is a good thing. I really love dessert).

Development is largely collaborative, and the chemistry my team has when we’re figuring out the best strategy for All-You-Can-Eat Korean BBQ (order non-marinated meats before marinated meats, so you don’t get full as quickly) mirrors the chemistry we have when we’re huddled around our monitors at 8pm coordinating a site launch. 

Providing Context and Transparency

It’s easy for a developer to just see the task in front of them. Ask a developer to build an email template on HubSpot? Sure, no problem. Ask that same developer what that email is going to be used for and they may respond with less confidence.

Or, they may get distracted and become "hacker" stock photo models.

It’s easy to feel like a cog in the machine, to complete task after task without truly understanding context around what you’re doing. Which is why managers are responsible for providing transparency and context around an entire project. Without context, there is no meaning. And maybe the developer doesn’t care how many of their emails will be triggered in a lead nurturing campaign, but they’ll know why it needs to be completed by a certain date. 

Transparency around processes is the only way to promote change within an organization. My goal for my team, myself included, is to over-communicate as much as possible. For me, transparency means working with my team on better processes and being upfront with my expectations for them and for myself. It’s also a way for me to say “Hey, I trust you with this information.” And then I use that leverage to guilt-trip them into telling me all their secrets. Then we play with Nerf Blasters...

All kidding aside, because of the transparency I provide to my team, each and every one of my team members knows that they can trust me to have their backs. I don’t have a secret agenda, because my ultimate goal is to coach them to success.

In Summary...

Taking a people-first approach to team-building (even in a technical capacity) means better communication, more efficient skill building, stronger camaraderie, greater insight into areas of improvement, and more #MEATSWEATS.

If you're looking for more culture and team-building inspiration, follow @SaltedStone on Instagram. Keep up with our team lunches, shenanigans, and (of course) our big, weird family.