Some of the best leaders I’ve worked with told me they’ve spent years observing things in their work. As part of their growth, they were mindful and took notes. Specifically, notes of the kind of “things not to do when I’m in charge.” I realized that I have a few good examples to share. Let’s go over how to lose an engineering org in 10 ways.
New: Want to improve your focus even faster? We’re almost wrapping up 2024. Has your team improved as much as you had planned? Do you see quality improving? Are people becoming noticeably more senior? You and your management team can delegate more and trust people? Join my free live stream Cracking Productivity: Why Can’t Your Team Improve?
Gatekeeping
Starting with a very subtle issue. Companies often get a ‘leg up’ when they spin off from other successful startups. That way, you get a burst of employees who already have experience working together and whom you trust. However, sometimes, this stabilizes with time to form a different ‘caste’ in the organization.
People who are not part of this clique find it harder to influence decisions, get promoted, etc. That, in turn, means that your talented people who are not part of this group will eventually leave for a place where this glass ceiling doesn’t exist.
Rapid Replacements
This is a similar scenario which, luckily, I only witnessed a handful of times. A new executive is in town, and they decide to rapidly hire a bunch of new people. Sometimes, this is because they don’t trust the current team. Other times, it’s just due to the need to move faster. Either way, this effectively creates a new caste, sometimes within a month.
When I saw leaders make this mistake, the rapid changes and the more attention and trust the newer hires got made the other employees suspicious and wary immediately. That triggered a cascading effect of people not sharing all knowledge, being reluctant to cooperate, or simply leaving (often the best ones choose the latter).
Eroding Trust
If you start making changes and moving things without making an effort to explain your thinking and motives, some people are bound to misunderstand. That’s even more likely to happen when you hide things from the team. Being explicit about your thinking will help ensure that people don’t place the wrong intentions behind your actions. They’re also then more likely to do things on their own that will align with your direction.
For example, when you fire a senior director, and that surprises many, you might feel like the respectable thing to do is to be short on words. However, without explaining at least partially what change you’d like to see achieved after this move, you might make people worried about whether they’re next in line.
Sometimes, some trust degradation will happen no matter what, like when you have to do a round of layoffs. However, even in these situations, there’s a vast difference between announcing it as a complete surprise and not letting people speak about it as opposed to being open about what happened, trying to aid those who are let go, and explaining to the team what actions are being taken to avoid having to do this again.
Preferential Leadership
There’s no person who likes all aspects of the job the same. Naturally, there will be areas that you are more drawn to or that you feel you have more of an advantage at. Nevertheless, the organization will suffer if you allow this to translate into neglecting other things under your responsibility.
Examples I’ve seen include leaders who prefer a particular team or department over others, leaders spending way too much time on technological aspects when there are clear people/process gaps, and executives focusing entirely on specific KPIs and letting others suffer.
Input Management
While it might be helpful in short bursts as part of blitzing out a specific solution, management by inputs is rarely the right way to go about it. By this, I mean the habit of tracking how much ‘effort’ people are putting in. You know how it goes: the person who answers Slack at any time of the evening or weekend, even when it’s not urgent at all, gets a pat on the back, and the rest are slightly worse for it.
I’m not accepting of slacking around, and that’s not what we’re talking about. The issue is that when we exert our authority as leaders, and the only pedal we step on is gas, we’re just asking people to do some performant coding harder. Instead, aim for better and faster outcomes. That means people will need to work smarter, not harder. Shifting gears, not grinding it out.
Letting Bad Behavior Roam Free
Mainly manifests as organizations grow past their initial stage and holding a coherent culture with shared values becomes harder. The examples here can vary widely and include seemingly minor issues, like people speaking in a way that feels violent to others, all the way to harassment. I’ve seen people who lost all their trust in an organization because one manager consistently got away with intimidating others in discussions, yelling, and banging on tables to get his way.
It’s your responsibility to handle bad behavior. It is not enough to address the matter privately with the offending person. Sometimes, the right thing to do is to discuss things openly with the rest of the group to make it visible to others that the leadership team is aware of the matter and addressing it. Otherwise, people might think you’re remaining silent and condoning that behavior.
Lack of Coaching
This should be straightforward, though that does not make it easy to tackle. For example, one VP told me about his director, who was certainly a star. The director was highly regarded, perhaps even more experienced than the VP, and could do things the VP couldn’t. However, due to that, the VP assumed there was no need to give this director any leadership attention unless he asked for anything in particular.
That, in turn, made the director feel abandoned or unappreciated. Coaching is one of the most important responsibilities we have as leaders, and when we neglect it, we’re signaling to our people that we don’t care enough about them. Not only does it miss out on the ability to help them grow faster, which is a win-win, but it also means that the star players are likely to feel like they’ve outgrown the organization much sooner.
Burst-Mode Attention
We all know those managers who capriciously decide to pay attention to something, only to then forget all about it within a few days. These bursts of attention and the failure to follow through on action slowly erode people’s attention and discipline. Because what we learn is that actually doing the work isn’t important. It’s enough to pretend to care for a day, knowing full well that the issue will make way for a new one very soon.
Making an effort to choose how you will be spending your time and attention, having real priorities that don’t change every single time your team talks to you, all these annoying leadership things—they are the work.
Creating Feature Factories
A feature factory is intent on cranking out features at the fastest possible rate without having the engineering team involved in shaping the tasks and without putting any effort into creativity or innovation. The reasons we end up creating such organizations differ.
For example, it might be because you, as a tech executive, find it easier to focus on tech and not ask questions about the product thinking behind it. I’ve also seen this happen a lot when there are contractors or outsourcing involved. I’m sorry, but those engineers are also people, and they are much more likely to be effective when treated like valuable members of the team.
Feature factories cap the impact and potential you can get from your team. The real A-players are not likely to stay in such an organization for long, and neither will the company be able to scale healthily.
Impact Disconnect
Lastly, there’s the matter of not creating a connection between the team and the outcomes of their efforts. I sometimes come across groups who are entirely detached from the business’s progress. They don’t understand the importance of different features or get to hear what people say about their efforts. In these scenarios, even when the team might be delivering and shipping software fast, they ship that code into the void. They never hear back about what they helped achieve.
With time, anyone who’s in a healthy spot on the tech-product continuum will find it harder to remain motivated. After all, assuming they’re not interested in just writing code for code’s sake, they need to see that their code is making a dent, however minuscule, in the universe. Routinely share things such as client feedback, business results, and the positive impact of work. One method that I recommend is impact retrospectives.