Since I talk to so many tech executives and am exposed to a lot of companies of different sizes, I often get asked what makes the best stand out. Even though this is definitely a frequently-asked-question for me, I refrained from putting this into writing earlier as I felt like this is straightforward. Recent discussions made me realize my readers would find this useful, and so I decided to publish this. I would love to hear your thoughts! Without further ado, here are the traits that I see most common in successful VPEs (and some CTOs).

Product Mastery

One of the concepts that I keep harping on. Everyone in Engineering, and especially leadership, should be proficient in the company’s business. One has to understand the product, the problem it solves for the users, the users, the market, the competition, etc. …

When it comes to taking charge of an engineering organization, it can be daunting. It is perfectly natural and fine to seek guidance, talk to others, and collect advice. Nevertheless, I often see taken to an extreme, resulting in a mishmash way of doing things and a culture that feels “generic,” and sometimes even utterly incompatible with the particular team.

For example, I can’t remember how many teams I saw trying to copy processes, systems, and methodologies from Google, Facebook, and other giant companies-when they barely had a dozen engineers. And, of course, there’s no need to mention the mission statements that might as well belonged to the company downstairs-there’s no telling them apart from one another (“We will benefit our customers and bring innovation in an ethical manner,” anyone?). This abdication on forming your own approach creates a timid and feeble environment. …

Time is the one resource that we cannot readily get more of. Alan Weiss always says that you can make another dollar, but you cannot make another minute. Time is of the essence, especially for executives. There are only so many work hours in the day, and you want to make the biggest impact on your team and your company.

However, I won’t go into simple time management techniques, as I’ve described in the past. In this article, I want to help you make a paradigm shift from reporting to your calendar to taking ownership of it. Right now, you-like most of your peers-are enslaved to your calendar. It is not a service, but something you serve. The calendar tells you what you need to do, and you listen. …

Being a consultant, you won’t be surprised to hear that I am often involved in helping companies go through changes. One common aspect that I see, either as I’m working with my clients or when they tell me about their failed past attempts, is that the executives often hold a much too simplistic view on how changes should be done.

Ideally, everyone would like to be able to announce a change, like a new process, and move on-the team would immediately adapt and make sure that everything works smoothly, letting you know if there are any issues. Unfortunately, that’s not the case in most organizations. Once the initiative is handed off, it gets derailed, abandoned, or progresses much too slowly. …

A few times, I’ve come across companies where managers were reluctant to engage in discussions about their employees’ growth. Leadership tried to avoid it, and the managers never initiated those sorts of conversations. Digging further, the underlying issue is often that they know a significant portion of their employees will want to discuss different promotional opportunities, which the managers don’t know how to manage.

If you know that by “opening the door” to a growth discussion, you will likely be inviting an employee to say she wants to become a manager-and no such position will be available any time soon-you are prone to steer clear of doing just that. This avoidance doesn’t actually do anything to fix the problem, though. Would you avoid going to the doctor if you think that lump you found might be bad news? Not addressing the needs and aspirations of your team is merely letting them get slowly annoyed and anxious. …

Frequently, leaders are disappointed with their team’s behavior, the developing culture, and collective habits. They don’t get why people come to meetings unprepared, or think that talking aggressively is acceptable. As someone who often sits as a fly in the room (or Zoom) to watch firsthand how companies operate, I often see a common source: the leaders themselves.

It might sound like a cliché, but it’s true: your organization around you acts like a sponge. They observe what you do and learn. Like it or not, you are continuously modeling your culture. That’s not to say that everything is entirely your fault: if someone yells in a meeting that doesn’t mean you have yelled at one before. …

The higher up the organizational ladder that you go, the farther removed you get from the code being your focus: the team is your precious project now. Refactorings give way for re-organizations. New frameworks and tools are out, new processes are in. Architecture diagrams step aside, you now deal with the org chart.

There are similarities between those two responsibilities, and a part of that is the fact that you can notice organizational smells, much like you learn to spot code smells quickly. To surface the most critical issues, I do an “org chart debugging” session when onboarding clients. …

Over the past month or so, I’ve consulted several CEOs who have had trouble with their tech executives. Some are now with or searching for their third or fourth CTO/VP of Engineering. More often than not, these mismatches are not the fault of just one of the parties: both sides need to be better vetting and expectation setting as part of the hiring process. Some also need more coaching or mentoring after the tech executive has joined (for the CEO, for the tech exec, or both). …