Krzysztof Witczak

Accidental managers

June 25, 2023

Ask yourself a question - who was the best manager you had in your engineering career?

Based on my experience, there is a good chance you won’t find this question that easy to answer. If you did, you’re amongst the lucky ones! 😂

There is a reason for this though - many managers haven’t been correctly prepared to fulfil this role and they were not aware, that it’s a different job and a new skillset is required to perform it correctly. It won’t build itself without conscious effort. I call managers and leaders who entered this role without enough preparation “Accidental Managers”. You may think that you’re more aware than most - but then - ask yourself this: do you know what your manager used to be doing on their typical day? 🤔

If not, read along about what this may cause…

How people become accidental managers

From my experience, there are many reasons and they often coexist at the same time. Let’s take a look!

Reason #1 - Limited career path options

The most popular one that I have seen - the organization has a single career path for engineers which ends up in management. A good software engineer who exceeds expectations needs to be promoted to be a manager or a team leader, with a strong reason given that with such a good, visible performance it should be easy for that person to translate these best practices towards the rest of engineers in the team and make it a successful one.

No real career choice

Reason #2 - False recognition of true employees’ needs

Sometimes managers hear from their reports that they really want to be promoted into a leadership role, and it’s often reflected by them chasing yearly goals, learning whatever they need to learn, and hitting KPIs. Unfortunately, they may not really want the new role, instead, they may want other associated outcomes:

  • They may want a bigger influence or power;
  • They may want a raise;
  • They may want better recognition or higher status.

Reason #3 - Big and rapid company growth

In some cases, there is not enough time to train or find the right people, especially if you’re recruiting like crazy due to the massive success of your product in the past quarters. Suddenly every person from the core team is leading a team of their own - there is no other way - every team requires someone to onboard them. Rapid pace of changes - you’re the victim of your own success.

Reason #4 - Short notice period

In eastern Europe it’s common to have two weeks of notice period in IT and around 26 days of vacation each year, sometimes more. Imagine that your technical leader or manager decides to leave the company in two weeks and picks all vacations left - the leader’s last day may be the next day after cancelling the contract… Usually, people don’t do such tricks to their employers, but it happens.

It’s a problem for both sides

For many people it sounds like leadership or management is a natural promotion path, and it’s often ignored how many new skills are necessary for the role and how different it is. Engineers are not aware of other possibilities like pursuing a Staff engineer or other strong senior IC roles. Lack of awareness and choices is the biggest sin.

This problem exists on both ends - the employee and the employer.

  • Ambitious employees are moving into a new career path, feeling forced to do so if they want to grow and earn more money, sometimes hating the new role for years to come, not realizing that they could select a different path.
  • Employers feel forced to promote those people so they won’t leave, because it’s so difficult to keep IT staff in the company these days. It may also be absolutely fair to promote them anyways because their performance may be through the roof. However their performance used to be through the roof for an engineer - not a manager! Additionally, sometimes there is no need for a new leadership position so it’s almost like organization is placing limiting external factors on themselves. I’m not sure if this is the reason why Meta has on average almost 9 layers of management, but I think it may be related… 😉

Typical issues with accidental managers

There is a saying, that “you’ve potentially just lost a great engineer and gained a bad manager” and this is what I call an “Accidental Managers” situation. It’s also a reflection of the so-called Peter Principle - “People in a hierarchy tend to rise to the level of their incompetence”.

What are the usual skill gaps once this happens?

  • Newly promoted engineers are surprised how suddenly they have almost no time to code and they sit too much on the meetings that they didn’t percept as “the real work”;
  • They are uncertain what their managers have been doing during the day so they are uncertain if they are doing it correctly (even stronger impostor syndrome than before);
  • Good managers are good with people, but good engineers rarely naturally poses required people skills - they are great with machines, numbers and arguments instead because that was needed to be a successful engineer for the most part;
  • They don’t fully understand manager vs maker difference and the concept of being a glue and the amplifier;
  • They feel exhausted at the end of the day, feeling they didn’t achieve anything at the end of the day compared to their previous role;
  • They miss puzzles and solving technical problems, feel worried about becoming technically rusty and don’t know how to prevent it;
  • They fall into the trap of “changing everything” without fully understanding why things were done that way;
  • They try to compensate by contributing to the work of multiple people, trying to help everyone, but often resulting in micromanaging others or applying “technical alfa” antipattern;
  • They don’t know how to and when to delegate, also how to provide feedback and grow people, they also miss the balance of work vs people;
  • They are not aware how their actions or behavior influence others;
  • They miss soft skills to correctly convince others of their opinion or technical vision;

When I used to be an engineer, I thought all of the things listed above are pretty obvious and I wasn’t worried that I might not learn them. Technical concepts looked way more complex and challenging. In the end, when you see “can work in a team” have you ever thought you don’t possess such skill? 😉 Now, do you know anyone from your team who certainly lacks it? Ask yourself: is that person aware of this gap? If not, what does it mean for you and the skills above? Side note: one of the most important skills listed in every chief-level position is “Good communication”. Everyone thinks they got it, rarely do people have it on the desired level.

In reality, you can spend years and years improving managerial skills and be mediocre at them - similar to technical skills and “repeating your experience” over and over. The challenge is that in a leadership position you receive less and less feedback than before and due to soft skills ambiguity almost every situation should be handled a bit differently based on the context. Additionally, mistakes you do early are difficult to correct since people quickly lose respect and trust towards the leader.


If you want to avoid a problem of “accidental managers” in your company, make sure to:

  1. Figure out the real needs of your employees and why they want their next promotion. Use intrinsic motivators exercise or just an honest conversation. Many times you can act on those needs without dropping a person on a path that they don’t really want.
  2. In your organization build career paths which allow Individual Contributors to stay in this role. Of course, expect more with every promotion - it still needs to be challenging. I suggest starting with Pat Kua Trident model or looking at a Dropbox level model.
  3. Finally, make sure to start training your future leaders early enough, knowing this promotion will change a lot in their lives and out of a group of potential candidates you may be left with a much smaller number of true candidates. Such training may take a year or more in many organizations and shouldn’t be left just for theory aspects - make sure to delegate to them some early management tasks as an exercise of proximal development. Place those people in teams tactically where you expect that they may be needed to take ownership soon.


I’m building such training myself - if you’d like to hear more, reach out through contact.

Good luck!