Blindspots

play();

I’ve endured ~10 concussions ranging from skateboarding, biking, intoxicated cliff diving, and a bunch while snowboarding. The challenge in counting concussions is that they become hard and harder to remember.

In the worst accident, another rider collided with me at a ~65° trajectory. We both bombed 2 separate steep trails that joined together.

To make matters worse, I’m regular and he was goofy-footed AND neither of us were wearing helmets, nor saw it coming. After the high-energy collision, he apparently rode off while I was knocked out with a badly broken nose and bleeding heavily. On a ski slope, that’s called felony hit-n-run.

I lost temporal memory and all details of my self for about 6 hours. I knew I had a name, but couldn’t tell you what it was. My phone number, address, etc… temporarily wiped.

Today I returned to the accident scene at Bear Mountain and rode past the spot where it occurred 26 years ago.

It reminded me of a major principle I live by in work and in play.

The teachable moment was that in order to avoid surprises, one must always have their “head on a swivel”. Like a hockey player or wide receiver.. and just like a tactical operator “check your six”. It’s all about continually scanning your blind spots.

work();

At VideoAmp, I’m spending considerable amounts of time interacting with our ahhh-mazing data and engineering teams. Some of this happens during the hiring phase, then in an on-going ritual of skip-level 1:1s. Much of the interesting information lies below the surface.

The purpose of close interaction in the hiring phase is to make sure we’re hiring appropriately. My role over time has moved to the end of the funnel, so by the time we talk, it’s clear that a candidate has the chops. But I want to know more, so we dive into other factors with wildcard questions.

The biggest mistake a burgeoning engineering org can do is to hire intelligent assholes, status jockeys, and immature kids with chips on their shoulders. We front-load our efforts by looking for key traits in candidates.

hacker.reflect();

Skip-level 1:1s serve serveral important purposes within an engineering org:

1) they give the engineer an outlet for multi-directional feedback, and a prescribed and safe venue to share these thoughts, and

2) they provide an open dialog from the “top down” and added context about the importance of the work they are doing.

The format is pretty simple. It’s 90% the candidate’s agenda. When they finish their list, we focus on manager / peer feedback and on career pathing. During this time it’s important to keep an eye out for “blindspots” because surprises are never good, and they tend to come back and bite you when you least expect it.

Let’s explore some of the most common blind spots to be aware of…

Are you new here and are “in over your head”?
This has become less common as we’ve ratcheted our hiring disciplines, but it happens. It’s possible for someone to “wow” their way into the door, and even ace coding assessments; but they can’t handle the total work expectations.

It is also very common for these candidates to play their cards close to the vest and hide it in every way possible. Everyone is expected to ship meaningful features in their first month, and most do this in their first week or two. When coming up short, they blame external factors, tooling, processes, people… rather than stepping it up.

Eventually this catches up and we have to confront it one way or another. My intention is to catch this as early as possible, and to assess the options. Sometimes the best option is to cycle out. Other times, it’s to lateral or reduce the expecations by moving to another team, while getting the necessary guidance and training from within the org.

Have you been here a while and you’re bored?
This one is sometimes difficult to detect, but just as important as the first example. Let’s face it. Human Animals need diversity. If every day is repeating like Groundhog Day, coming to work seems more like a Bataan Death march vs. a 007 movie.

We’ve hired a handful of engineers who worked at large corporations in LA and whom could get their job done in 3–4hrs / day. This was unfulfilling and caused them to go back into the market. Their management simply didn’t care to grow them further…. So they bailed.

Do you want to lateral, but can’t have that convo with your direct management for fear of loyalty optics?
Often an extension of stagnation is that bored engineers are hesitant to raise this with their immediate management structure, because they fear it telegraphs a lack of loyalty. The reality is that it is valuable to the Org and the Individual for them to lateral to another team, a heightened role, and a new area of growth and learning.

We’ve had many engineers transform their careers by taking on whole new disciplines. Becoming “full-full-stack” and well rounded system engineers.

Do you feel you’re under-compensated?

We’ve fixed this lately with a prescribed ladder and leveling of pay grades based on a hybrid of market rates, career achievements, and to a lesser extent the total history of their career.

We also assess comp only annually, however sometimes engineers go well above and beyond, and are looking for more than just salary. Other forms of compensation can include increased equity grants, a bonus, and/or yuge public recognition…. aka “BIG UPS”.

Is there positive / negative feedback about a specific team member or management?
One of my mentors and friends who CTO’s a sizable org explained it perfectly one day how he addresses new hires:

“Every day when you come to work, you and your team are going into a dark cave after a bear. Each one of you is carrying a big stick. There are several possible outcomes:

1) You are either individually or as a team going to beat that bear down, or
2) the team is going to beat you for lack of participation, or
3) the bear eats you all….”

It’s morbid, but it’s realistic. The work we do is hardcore. We’re not talking Yogi Bear here, but The Revenant Bear.

In the very rare instances where we’ve mis-hired someone, or when a team member goes “off the reservation”, we have a fail-safe. When an entire team offers unsolicited feedback about a member who is absolutely not performing, we have a process for handling this.

If you do not ask, you will not know. This is one of the worst issues to NOT address, because the morale of a team suffers greatly when an org tolerates “checked out” team members. Read Glassdoor reviews of companies, and you will see this type of feedback very frequently.

One very interesting outcome of terminating lax engineers is that after they’re gone, the morale and productivity of their team goes through the roof. We have empirical evidence by running “Gource” against the Git repositories they worked in, and in all cases they “buzzed” with activity.

self.close();

Hunting blindspots is not just about looking for negative effects… sometimes people have done amazing things, and their management chain has not recognized it. Be aware of the sometimes subtle queues that an engineer has gone the extra mile, achieved amazing feats, etc… and give the praise that is well-deserved.

They say “Bad news early and often”, but you can lump good news into this as well. If you lead an engineering org, I strongly suggest that you 1:1 with your entire group as often as possible. All kinds of issues for better or worse come to light.