Your company doesn't need a hero but a team! - Work culture

What I like about working in startups and small-mid companies is that they’re flexible and you can have a visible change and a direct impact. Ironically that's the same reason why heroes and heroism find their way in that ecosystem.

If you have been working in the IT industry for some time and especially in startups, mostly you would have met that kind of people at work ... heroes!

Who are "heroes"?

So who exactly is a "hero"? (sometimes also called "Ninja")

Heroes are some people at work who can do crazy stuff. They are doing everything needed to get things done. They have all kinds of access and privileges. They know all the info that cannot be found anywhere. They are doing the hard tasks that only they can do and solve problems that no one one else can solve. However, all of that’s mostly done with no clear mid- and long-term planning, undocumented, and on an ad-hoc style! (so being a hero is not about performance but work practices)

Managers mostly like them because they, the heroes, get lots of things done quickly for the company. In fact, heroes don't need to be bad people, assholes, or jerks. On the contrary, they could be good and nice but their way of work is just harmful!

How harmful could it be?

Wait a minute! Doesn't that sound good? Many things are getting done fast and on time! Isn't it better if we have more of those heroes?

NO!, unfortunately not! All of that comes at a cost!

Toxic culture

First of all, heroes are heroes because the rest are "normal". Those heroes simply limit the other people in the team and keep them from growing, and the only way to pair with heroes is to be another hero, just like them. But in the end, a company is like a film, there is no film full of stars!

Not only that but also wrong expectations raised against other team members when they don’t do the hero-way! Why aren’t they the next hero?

Technical debt

What heroes are actually doing is like getting a loan, you have a lot of money to spend now, but you drown in debt later ... the technical debt. Maybe everything works "just fine" for now, but later, many things will not.

Teams (and maybe the whole company) will end with fire fighting and an ad-hoc work style. And then when you realize what was wrong, the cost of re-engineering the mess, and fix it, is usually horrible.

Limited growth

When heroes are off or on a vacation, other people tend to be afraid of making changes, because it's not clear how things are working. Furthermore, when heroes are not there, many incidents happen because most of the time they keep things “just work”.

Also if the heroes are not communicating their work (through documentation, short presentations, awareness sessions, etc), then their absence due to any reason (death, accident, etc) means that their team and maybe the whole company are paralyzed.

After all, those heroes are humans and have their limits, hence companies cannot depend on people "individually" but as a "team".

What are heroism signs?

It's not so hard to find traces of hero practices … you just need a closer look, especially on the team level.

  • Do all team members have a common understanding of what they do?
  • Do the team members say "no" from time to time or is it always "yes"?
  • Does the team work extra hours or until late?
  • Does the team have a clear mid-term plan? (between 6 to 12 months)
  • Does the team have a proper onboarding plan for a new member?
  • Is the team in a "freeze mode" when a member is off or on a vacation?
  • How much does planning take place before the actual implementation?
  • How many returned incidents does the team have and on which interval?
  • How many parts of work are undocumented or have no clear way to do them?
Those are the most common signs. The more you have, the bigger the problem.

Reduce heroism and build sustainable solutions!

At the end of the day, when you realize how heroism is harmful to the company, it's probably too late. Mostly you will be on the horns of a dilemma!

If you keep heroes and their way of work, the longer they stay the harder to change. And if you tried to get rid of those practices quickly, you put yourself and the company in an ultimate risk!

It's also worth mentioning, and believe it or not, having heroes as a part of a company is not really a problem per se! In the early stages of the company life, they could help the company growth a lot. The actual problem is when the "hero-way" becomes the default way to work with no proper plan to move towards sustainability.

Unfortunately, there is no silver bullet to fix this. But here are some takeaways you could think about:

  • Plan, plan, plan. It's the way to a smooth transformation and mitigate the hero effect.
  • Build a work culture and practices. Something like Agile and DevOps that encourage teamwork instead of solo work.
  • Sooner rather than later. But if something will not be done now, there should be a reference and plan for it.
  • Get rid of silos. Silos are the best place to grow heroes.
  • Be prepared. Mostly, heroes will leave once there are a process and a proper workflow.
  • People are different. Having a process doesn't mean you ignore individual differences.
  • Change is a risk. Most of the time it needs to be done slowly, but also firmly.
  • Finally, don’t go so far! Having sustainable processes is pretty important, but too much of “process” also hurts! Find the sweet spot of balance, otherwise you will lose “agility”.

That's all! And I hope you have more sustainability and less heroism. :-)

Continue Reading »


DevOps, J-Curve, and change management - Agile

I've been working professionally in the tech industry for more than 7 years. The change was always one of my things. It didn't matter what was the role or the level, I started to do that starting from my first day in this career!

And that's actually why I do love "DevOps movement" because it's about "change"!

DevOps and Agile are two different things but mostly they show together like two sides of the same coin. Flexible change is always part of Agile, but in the end, change is "risk" and it should be planned and be part of Agile processes and strategies.

When I move to a new company I normally do something: once the onboarding starts, for the first one or two months I take notes, watch, and learn. What's good? What's bad? What could be better?

Then I start to discuss this with the team and managers. I used to do that verbally. But a few years ago, I saw this graph called "J-Curve"! So I do a presentation and make sure the whole team is aware and ready for the next steps ... to the change!

So what's going on here?
With any change, there is always a "deterioration" of something related to that change (that could be actually anything, velocity, efficiency, or anything else).

For example, if we have a manual task and we want to automate it, working on the automation for this task will consume time, which means less time available for the actual tasks!

If the task is done manually in 10 min, maybe it could be done in 20 min while working on the automation! But once the automation is finished, it will be done in 1 min (and it's not just about time, but more accurate with fewer errors).

So when we have some slowness with the task during the automation phase, people don't panic because the goal of the change was to make it "better"! Hence it's important to make it clear that this deterioration is actually part of the change and already expected!

Also, I explain that the bottom of the curve, first and last, depends on all the people who are involved in the change ... it depends on "all of us"! So we could actually get a different path/result. That's the dotted line in the curve.


The nice thing is that every time people are aware of "what's next", they are more likely to want to adopt the change at an earlier stage. And that gets you pretty good results.

On the other hand, you will always find people not in favor of "change"! Some are against "change" in general! Some will just deal with the situation as it is and don't try to fix the root causes because it requires "change"! Some are afraid of "change"!

You need to deal with it and plan accordingly. But never let your anger control you! First of all, you need to remember that some people will never change ... that's life!

However, also remember that some people are not really against change per se but they could be just "shy", not "early adopters", or just want to "see" more the benefits of change. You just need to find the sweet spot to deal with that.

That's it! Keep moving, keep the change!

Continue Reading »




Automating my laptop system setup - Ansible

As I always say, I like to avoid manual boring work, and manual repetitive work is always boring for me! So I used to automate my system I use on my laptop with most of stuff I used to use.

Although I'm not big fan of changing my main system too much. And as I'm the author of

Continue Reading »



Powered by Blogger.

Hello, my name is Ahmed AbouZaid and this is my "lite" technical blog!

I'm a passionate DevOps, Linux system engineer, CKA, AWS SysOps/Solutions Architect, RHCE, Free/Open source geek, author, interested in environment, calligraphy, and I believe that “Details Matter”!

Automation, data, and metrics are my preferred areas. I have a built-in monitoring chip, and too lazy to do anything manually :D

Popular Posts