Seamas Markey

What QA taught me about managing people

Most engineering managers came up writing code. I came up breaking it.

That's a bigger difference than it sounds. Spend enough years in QA and you develop a specific reflex: before anything ships, you ask what could go wrong. Not as pessimism. As process. You learn that the failure is usually already sitting in the system, and the only real question is whether someone finds it before the customer does.

When I moved into management I kept doing that. The system was just the team instead.

Where are the gaps in how we work? What has everyone noticed and nobody said? What are we going to regret in six months?

Most team problems aren't surprises. They're bugs that shipped. The engineer who's quietly checked out didn't check out last Tuesday. The two people who can't work together didn't start disliking each other this sprint. The project that slipped a month didn't slip in the last week. In every one of those, there was an earlier moment when it was cheap to fix and somebody decided not to say anything.

QA teaches you that finding a problem late isn't a discovery. It's a process failure. The same is true of people.

The other thing QA gives you is a working relationship with being the person who brings bad news. Nobody likes the tester who says the release isn't ready. You get used to it. You learn to do it without being a jerk, and you learn that the discomfort of saying it now is always smaller than the cost of saying it later. That transfers directly. Most of management is telling someone something they'd rather not hear, early enough that it's still useful to them.

The downside is real too. Coming from QA means I've never been the best engineer in the room and I never will be. For a long time I thought that was a gap to hide. It isn't. It means I hire people sharper than me at the craft and I actually listen to them, because I've got no ego tied up in being right about the code.

The instinct I brought over wasn't technical. It was the habit of looking for the failure before it arrives.

How much process is the right amount

Every team I've joined has been either drowning in process or allergic to it, and both groups think they're being pragmatic.

The teams with too little call it moving fast. What it actually looks like is the same conversation happening four times because nobody wrote anything down, work getting dropped between people who each assumed the other had it, and a release process that lives entirely in one person's head. That isn't speed. It's borrowing time from later.

The teams with too much have the opposite problem, and it's the one I'm harder on. A lot of heavyweight process isn't there to help engineers. It's there so that when something goes wrong, a manager can point at a document and demonstrate that they did their part. That's not process. That's insurance, and the engineers are paying the premium.

The test I use is simple: does this exist so people know what's expected of them, or does it exist so somebody has cover?

Status meetings where everyone reads their Jira tickets out loud are cover. A written definition of done that the team agreed on is clarity. Requiring three approvals on a config change is cover. A code review norm the team wrote themselves is clarity. The format doesn't tell you which one you've got. The reason it exists does.

The right amount of process gives people enough structure that they aren't guessing, and then gets out of the way. It should reduce the number of decisions someone has to make about how to work so they can spend those decisions on the actual problem.

Most importantly, it should be something the team can change. If a process can only be modified by someone outside the team, it stopped being a tool and became a rule. Those are different things, and engineers can always tell which one they're living under.

I hired him because I liked him

My first hire as a manager quit after one day.

I had run what I thought was a great interview. We talked easily, we laughed, I came out of it certain. I told my boss I'd found the guy. He started on a Monday, and by Tuesday morning he'd sent an email saying it wasn't for him.

What I'd actually done was spend an hour confirming that I enjoyed his company. I never asked him to walk me through something hard he'd worked on. I never asked what he wanted his next two years to look like. I never described the actual day-to-day of the job and watched his face. I liked him, and I let that stand in for evidence.

Liking someone and knowing whether they'll do the job well are two entirely separate questions. The interview is only useful if you're answering the second one.

The thing I'd tell anyone hiring for the first time is that a good conversation is not a signal. It's the absence of one. Charisma is the easiest thing to detect in an hour and one of the least predictive things about whether someone will be good at the work. Meanwhile the things that actually matter, like how someone handles being wrong or what they do when a project is underspecified, take deliberate effort to surface. They don't come up on their own.

So now I ask people to walk me through a real piece of work in detail, until I understand what they specifically did. I ask what they'd do differently. I describe the job honestly, including the parts that are tedious, and I pay attention to whether that lands as a warning or a shrug.

And I've made peace with the fact that some of the best people I've hired were people I didn't particularly click with in the room.