This is a followup to Some Behaviors of a Catalyst where I said that I didn’t think you needed seniority to be one.

More than 10 years ago, I was interviewing college seniors for an entry-level position. Among the group of very talented students there was one obvious front-runner who we offered the position to (and who accepted). But there had been another candidate that impressed us.

They interviewed well and were qualified for our position. But, we preferred candidates with some C/C++, and they had less than our preferred candidate, maybe none, I don’t remember. In any case, that was probably the deciding factor. But in a lot of other ways, they were outstanding (in the literal sense of the word). They stood out.

Here’s what I mean. A bunch of the candidates had worked together on their senior, two-semester, capstone project. We heard about this project from several angles. Over and over, a candidate would point to another person as the reason the project went well. They would, of course, talk about their own contributions, but they would also specifically point out what this other person had done as well. The thing was, the other person was always the same person, the “outstanding” one.

Even with this clue, we didn’t hire them.

About a week after we had made our decision and the offer, my boss called me in. He said a friend of his (another tech business owner) had sent in an unsolicited recommendation for a student he knew. I think he had them as intern or something. In any case, the recommendation was effusive. The student was, of course, that same one who had been recognized by their peers.

At this point we felt as if we’d be idiots not to hire them, but we didn’t have a position. The good thing about junior developers, though, is that they are cheap and you should always have a position if you see a good one. So, we created a position and made an offer. I think this is the only time I recognized a junior catalyst before working with them—the key is that people like working with them and attribute success to them. When that fact comes to light without seeking it, it’s a good sign.

Yesterday I wrote that you should recognize catalysts, but didn’t say how. The problem is that so much of what they do is under the radar, but one tell is that they always seem to be part of successful teams and everyone on the team knows that they were an important member.

Catalysts can be technically great, but perhaps not the most technical person on the team or the best specialist on your corner of the company. In my experience, they are more likely generalists. They likely know the most about the other teams in your organization, which is why they can get things done with them. They often know who to go to, and those people often know them.

It’s not just the other teams, they also know the most about the architecture of other services. They might even have commits in repos they don’t own and in the third-party dependencies they use. When they need to get things done, they don’t limit themselves to just their own codebases.

Their colleagues like them and like to work with them. And the catalyst genuinely liked working with those people too (and they like people in general). They are often your best source of candidates. The best way to hire a catalyst is through a referral from someone on your team that raves about working with them.

Knowing what I know now, if I were to look for them I’d be looking for what Atlassian called “Feature Leads”, which were engineers that led a “feature” project. They often needed to orchestrate the work of several other people and perhaps several other teams. I guess to make sure they were good at it, I’d be looking for people that did it repeatedly at the same place. This work doesn’t rely heavily on their commits, but I’d be interested in people that had commits in disparate parts of the feature, not because of the technical skill it requires to do that, but because it would indicate a holistic view and might indicate a tendency to clear roadblocks, both of which are catalyst behaviors.

As I said in How Senior Software Developers Think, the more senior you are, the more you think of how your work relates to the mission of the company. Catalysts at any level do that. It’s often easier to have success as a catalyst the more senior you are, but I don’t see this as a requirement. Feature leads at Atlassian could be just past the junior level (pre-Staff/Senior level). It was a good indication that they should be promoted, but they didn’t need to have that level to catalyze.

I tried to pattern my career after An Unnamed Programmer in Peopleware, whose contributions weren’t always clear, but “had never worked on a project that had been anything other than a huge success.” She was overlooked by her management, so I learned that to do this, you needed to make your contributions clear.

As a manager, I didn’t always know how to hire for this quality, but I knew it when I saw it and made sure they were on the projects that mattered. And I keep track of them, too. I might not know if a new candidate is one, but once you know someone is a catalyst, you can always hire them at your next gig.