We’re obsessed with amassing more and more senior engineers. I don’t think I’ve talked to a single tech executive in the past year (and I’ve spoken with hundreds) that wasn’t bemoaning the lack of senior talent. I get it: when you onboard someone that already masters the tools and stack that you’re using, it can feel like a breath of fresh air. Some decisions become obvious; there’s less time spent researching the “correct” technical approaches to doing stuff. Who wouldn’t want that, right?

I won’t go into the fact that I believe companies should accept their role of educating their staff and cultivate seniority rather than import it. I’ve already covered that in the past (see What If You Never Hire Senior Engineers?). Rather, in this article, I want to focus on when the kind of seniority you’re interviewing for is not the type of seniority that you need.

Technical Seniority vs. Product Seniority

Technical seniority likely requires no explanation. As I described earlier, these are engineers who already master a certain subset of technology (e.g., iOS native development or data engineering). Product seniority, though, is trickier.

Coaching CTOs, I often hear similar issues: the leadership team (or the CTO herself) is overworked. Feeling overwhelmed is not rare in our industry, and in chapter 3 of my upcoming book, The Tech Executive Operating System, I describe the constant “juggling” that is required. It can feel like someone’s throwing more and more balls at you, and you’re just barely preventing them all from tumbling to the ground.

That’s obviously not a sustainable way of managing an organization, especially an organization that’s growing and thus generates more of these balls to be juggled. What I ask my clients is, “why don’t you pass some of these balls to your senior people?” The answers are different every time, but more often than not, they boil down to the same essence: those people are great senior (or staff, or even principal) engineers, but they’re not good product engineers.

For me, product engineers must possess two fundamental traits—broad shoulders and product mastery.

Broad Shoulders

Here in Israel, we have two slang terms that boil this down perfectly: “small head” and “big head.” A person who is a “small head” must be spoon-fed everything. They do not take on extra responsibility, they don’t see what’s coming, and they don’t act as force-multipliers in their teams. The joke is that if you ask a small head, “do you know what time is it?” they will answer, “yeah.”

In contrast, a “big head” is a person that takes ownership and manifests the agency and autonomy provided to her. She puts in the mental effort to think a few steps ahead and see where things are headed. She is proactive. In our case, she would be an engineer that’s not just focused on honing her technical skills and making the keyboard go *clickety-click* (no matter how fancy her mechanical keyboard is). Instead, she will reach out and talk to her counterparts in other teams, or even, *gasp*, with Product!

These are people you can wholeheartedly rely on—if you are overwhelmed, you can throw a ball or two at them, and they will help out. That’s at the core of creating an organization filled with people who are force-multipliers and who increase their leverage.

Product Mastery

Broad shoulders alone won’t cut it, though. Let’s say that you lucked out and just onboarded a couple of broad-shouldered engineers. They still won’t be able to get much done because they have yet to learn anything about the product, your users, and your business as a whole. This is what I call product mastery. Here’s a snippet from The Tech Executive Operating System that describes it:

Before going into creating product mastery, you should learn how to spot it and assess your current situation. If you need to imagine what this Product Mastery is, it helps if you’ve ever worked at an early startup. At the stages where every single person is sitting in the same room and aware of the vast majority of micro-decisions being made, it is likely for the entire team to have high levels of product mastery. That’s because they understand exactly why things are done the way they are, they know what their tangible goals are, and they have a real understanding of the users and their needs, either because they hear it first-hand from users or from the person that talked to them directly.

The onus is on you to ensure that your team is not merely filled with “generic” engineers who are masters of their craft but don’t truly grok the business. If that’s the case, you might as well outsource all development.

Cultivate Product Engineers

Now take a second and do a mental count: how many product engineers do you think you have? What percentage of your entire headcount do they have? How many of your so-called senior engineers are not product engineers?

If you realize that you need to increase that number, there are two aspects to start working toward. First, you have to work hard to get people with “big heads” and broad shoulders. That starts with your hiring processes, which should ensure interviews cover this skillset. You want to bring on highly motivated, passionate people who demonstrate agency. Unfortunately, I haven’t found an easy way to instill this in people if they don’t already have a small core of this mindset.

Then, work hard to coach all of your managers to ensure they don’t stymie your staff’s agency. There’s no place for micromanagement, lack of autonomy, and other such crutches that we tend to ignore from our manager “as long as the team is delivering.”

Second, you should bootstrap product mastery regularly. That means making it part of your onboarding process and ensuring that you update it regularly. The common hinderers of product mastery are Organizational Pigeonholing, relying on the old guard as a crutch, stressing technical mastery, and isolation from the clients and solution. Make your engineers rub elbows with customers. Have them shadow customer success. Make them “eat their own dog-food” and really use the product. That’s the only path forward, especially if you’re thinking of sustaining a “scale up.”