The Enemy That Comes Back to Defeat You

Let me start with my brother, Leke.

Leke is the one who taught me how to play games. The real ones, the old ones. We would crowd around that computer and he would show me Dangerous Dave, jumping over fire and grabbing trophies, and later he put me on Doom, and I watched him move through those dark hallways like he personally built the place. I was the small one, just trying not to die in the first two minutes. He was patient with me. He taught me how to look around corners, how to save my ammo, and most importantly, he taught me one rule I never forgot. The enemy you ignore does not disappear. It waits.

Because that is the thing about those games. There is always a small enemy somewhere in the early levels. A tiny thing you can run past, slap once for fun, and forget about. Easy. But if you do not deal with it properly, it comes back. Later. When you are tired, when your health is low, when you least expect it. And by then it has armor, it has friends, and worst of all, it remembers everything you did to it.

I think about that a lot now that I lead people, because that is exactly what bad engineering habits do to you when you become a leader.

When you are a solo engineer, your habits only trouble one person. You. You can be messy, you can be quiet, you can take shortcuts, and nobody is coming to arrest you. Cooking instant noodles every night is perfectly fine when you live alone. But the day you have a family to feed, you cannot serve everybody two minute noodles for dinner and expect peace in the house. The habit did not change. The number of people depending on you did. And suddenly all those small enemies you ran past in the early levels come walking back into the room, fully grown, ready to fight, and now they are not just fighting you. They are fighting your whole team.

The enemies hiding in your code

Take the things engineers do with code. When you work alone, your documentation lives in your head. You remember why you wrote that strange function at 2am, you remember which button should never be pressed, and your brain is the manual. The problem is that your brain is not a shared drive. The day a new engineer joins your team and cannot open your head to read your thoughts, they will ask you. Again, and again, and again, until you become that one uncle who knows where every single thing in the house is kept but refuses to tell anyone, so the whole family has to call him just to find the salt. It feels powerful for about a week. Then it just becomes a prison you built yourself.

The same goes for being the hero who fixes everything alone. As a solo engineer, killing a hard bug by yourself at midnight feels amazing. People clap, you feel like a superhero, cape and everything. But when you lead a team and you are still the only person who can fix things, you are no longer a hero. You are a single point of failure with a cape. The whole company waits for you, you travel and everything catches fire, and your team never grows because you never let them try. And the code those teams inherit tells its own story. Skipping tests when you code alone is like not wearing a seatbelt on an empty road at night. Risky, but you might survive. Do the same thing while driving a bus full of passengers and it is a different conversation entirely. When a team inherits code with no tests, every small change becomes a prayer, nobody is sure whether pressing one button will break ten other things, and a scared team is a slow team.

Then there are the temporary hacks, the ones we all swear we will clean up later. We hardcode something, we leave a key somewhere it should not be, we tell ourselves it is just for now. But nothing in life is more permanent than a temporary solution. It is like that temporary generator your neighbour bought during a power cut three years ago. It is still there. It has a name now. The children play around it. When you are alone, your shortcuts are your own headache, but as a leader they become landmines the whole team steps on, usually in production, usually on a Friday evening. I have personally watched a small “we will fix it later” grow into a real security scare, one quietly forgotten secret sitting in the wrong place, costing real money and real sleep. And right next to that lives the habit of not caring about cost. When the money is not yours, you spin up servers like you are ordering suya. One more, one more, one more. Then you become a leader, somebody hands you the bill, and you finally understand that every server has a price and somebody is watching that price. That somebody is now you, sitting in the meeting while the finance team looks at you funny.

The enemies that wear a human face

But here is what surprised me most. The habits that come back hardest to defeat you are not even the technical ones. They are the human ones.

Going quiet, for instance. As a solo engineer, disappearing into your work for two days is fine. You are focused, beautiful. As a leader, silence is loud. When the boss goes quiet, people start writing stories in their heads, and the story they invent is always scarier than the truth. Is something wrong, are we being fired, did I do something. You have to learn to overcommunicate, even when there is nothing exciting to report. In the same way, you have to learn to stop running from hard conversations. Alone, you can avoid conflict forever. As a leader, avoiding a hard talk is like ignoring a small leak in your roof. It looks fine for a while, and then one rainy day the whole ceiling comes down. If someone is underperforming or behaving badly and you keep letting it slide because you do not enjoy awkward talks, you are not being kind, you are just saving a bigger problem for later. I have had to sit in rooms and have firm, uncomfortable conversations I really did not want to have, and that is where I learned that the easy thing and the kind thing are not always the same thing.

You also have to unlearn the idea that everyone thinks like an engineer. We love logic, we love being right, we love saying “well, actually.” But your team has designers and product folks and finance people who do not care about your beautiful database structure. They care about results. Speaking only engineer to non engineers is like reading poetry to a goat. The goat is not impressed. You have to learn to talk human, to explain the savings to the finance person in money and the timeline to the product person in dates. And while you are learning all this, you have to learn the hardest word of all, which is no. Saying yes to everything makes you look helpful and reliable when you are an IC. As a leader it is how you and your team burn out, because you keep selling dreams to five different people and now your team is working weekends to deliver promises they never agreed to. Their energy is a budget too, and you have to spend it wisely. Underneath all of it is the quiet enemy of running on vibes. “We will figure it out” is a lovely sentence and also the reason teams end up doing the same chaotic thing five different ways with nobody sure who is responsible. When you are one person, your process can live in your head. With a team, vibes do not scale. Process is not bureaucracy, it is just writing down the good way to do things so you do not have to reinvent it every Monday.

Becoming a manager is not a promotion

Now, the part nobody warns you about properly. Becoming a manager is not a promotion. It is a career change. You are not getting a better version of your old job, you are getting a completely different job that happens to share a similar title. A chef who buys a restaurant is not “a better chef,” he is now doing something else entirely, and if he spends all day in the kitchen, the restaurant suffers. The mistakes here are almost always the same. People keep trying to be the best coder in the room when their job is no longer addition but multiplication, because helping ten people each get a little better creates far more value than anything you could ship alone. People grab tasks themselves because they can do it faster today, not realising they are robbing a junior of the chance to grow and borrowing time from the future at a painful interest rate. People hire smart engineers and then hover over their shoulders telling them which spoon to use. And almost everyone forgets that their mood is now the weather. When you were an IC, your bad day was your own. Now your bad mood becomes the whole room’s bad mood, because people read your face before they read your words.

And the road runs the other way too

It goes the other way as well, which nobody talks about. Sometimes a manager goes back to being an engineer, and that is completely fine. Some of the happiest, most valuable people I know chose to step back into the code on purpose. The traps there are just different. Ego will whisper that you are going backwards, and you have to ignore it, because being a brilliant builder is not a consolation prize. You will probably be rusty, since the tools moved on while you sat in meetings, and going back means being humble enough to learn again, sometimes from people younger than you. And you will catch yourself still trying to manage everyone, reviewing pull requests like performance reviews, when nobody asked. You are a peer now. Sit down. Code.

The boring rules that quietly save you

There is a bigger lesson hiding inside all of this, and it is meant for company owners, not just engineers. It is the boring phrase nobody wants to hear, corporate governance. Rules, policies, who can access what, who approves what, who is responsible when things go wrong. People treat it like annoying paperwork. But governance is just the rules of the road. Traffic lights are boring, speed limits are annoying, lane markings feel pointless on an empty street, right up until there is a crash, and then everyone suddenly understands why the rules existed. In a small company you can run on trust, because everyone knows everyone and one person holding all the passwords is fine when it is just three of you. But as you grow, “trust me” stops being a strategy. You need to know who holds the keys to what, you need to be sure that when someone leaves they cannot still open the front door, and you need a trail so that when something breaks you can find out what happened instead of pointing fingers in the dark. Companies that keep saying they will sort governance out “when we are bigger” usually learn the hard way, through the leak, the lost data, the angry regulator, the money that vanished because nobody was watching the right door. It is not about distrust. It is about protecting the company from small mistakes before they grow into disasters. Set the rules early while it is cheap and easy, not after the crash.

Product people and product operations are not twins

One last thing, and it confuses more companies than almost anything else, which is the difference between product operations and actual product people. In a lot of places there is someone “doing product.” They are busy, they update the boards, they organise the meetings, they chase engineers for updates, they keep the spreadsheets neat, and everyone calls them a product manager. They are working very hard. But the question nobody asks is whether they are deciding what to build and why, or simply keeping the trains running on time, because those are two different jobs. Real product people answer the hard questions. What problem are we solving, for who, and why would anyone care, what do we build next and what do we bravely ignore. They hold the map, they talk to customers, they say no to good ideas to protect great ones, and they own the why. Product operations keeps the machine running, managing the process and the tools and the reporting, making sure information flows and nothing falls through the cracks, and they own the how smoothly. Both matter, both are needed, but they are not the same. It is a restaurant again. The chef decides the menu, tastes the food, and owns whether the meal is actually good. The waiter makes sure that food reaches the right table on time with a smile. You need both, but if your waiter is designing the menu, do not be shocked when the food is confusing. When a company dresses up a coordinator as a product strategist and then wonders why the product has no direction, that is the reason. The person was given the “keep it organised” job, and organising chaos is simply not the same as deciding where to go.

Back to Leke

So here is where I land, and it takes me right back to Leke and those dark Doom hallways. Your habits are seeds. The small things you do today, alone, with nobody watching, are quietly growing into the leader you will become tomorrow. The enemy you ignored in the early levels is coming back either way. That part is not up to you. The only choice you have is whether you trained it to fight for you or against you. The engineer who learned to write things down, to talk to people, to share what he knows, to care about cost and about the humans around him, that engineer becomes a leader whose old habits show up later as superpowers instead of boss fights.

So start now. Write the doc. Have the awkward talk. Say no sometimes. Speak human. Set the rules. Build the habit while it is still small and gentle and easy to shape. Because one day you will level up, and when that small enemy walks back into the room, fully grown, you want it to look at you, nod with respect, and say, I have been waiting for this moment too. Let’s go to work.

Thanks, Leke

.