maciej łebkowski Maciej Łebkowski

I was doing a horrible job and then I realised it wasn‘t me

in Personal

I have hit a bit of a roadblock on my path lately. I was unsatisfied with my work. I was struggling. I actually lost confidence in my value and impact on the company. There was no other logical explanation for me other that I wasn’t doing a good job. In hindsight, maybe I didn’t. But at the time it never occurred to me that I might not be responsible for the root cause.

It all started with me engaging in new project. It was different in many ways than the previous one. It required a lot of attention and different skills. I needed to combine the manager’s and the maker’s schedule. One thing led to another and after a few months I identified my burnout and my poor performance — I couldn’t lock myself for a week to finish a bundle of code without being summoned for a meeting or something; on the other hand I wasn’t able to react promptly for ad hoc tasks, because I was trying to zone-out at least for an hour or two to finish some code.

I went to a couple of people, my manager included, and relied my observations. „Dude, just think of a thing that’d get you rolling again and we’ll see if we can shift your angle in the company” — it seemed like the best response we could come up with at the time. You’re unhappy? No problem, drop what you’re doing, start something new and exciting. For me — and for a time — it worked. But nobody anticipated the impact on the project.

New start

I returned to work after over two weeks of vacation. Fresh mind and fresh start. My new objectives were to oversee others while they were implementing the project I’ve abandoned and to work with the team on the code quality. This wasn’t an uncharted territory for me; I was silently in charge of this ever since I got around the project.

In the meantime, our company’s core project went under the wings of the most junior developer we had. If that’s not enough, the junior started to build his team with the most inadequate engineer I’ve met. The project went for a few weeks like that. The only senior input was my occasional supervisory and a friend’s module — but apparently without any business introduction, because it mostly went to shit. And of course there was a deadline, so in the end nobody cared for quality or edge cases.

None of us really noticed what was going on until it was too late. A few weeks after production deploy the bugs were still pouring in, the code was a mess and there still was no time to take care of them. To make matters worse, the product team became more alienated from the more senior developers because the constant stream of comments to improve the code. The project was lacking a solid mainstay. We gathered for a crisis meeting later and actually found a solution, but more on that in the next chapter.

The first point I’m trying to make: you can’t let your employees just do whatever they wish — even the senior ones that you put trust in. In this case, moving me away from the product in time of one of the greatest rewrites in it’s history was — to say it lightly — a bad move.

Let’s just talk about it

We began to talk about what’s happening. We tried to isolate the root cause of the problem. And we had some ideas, but we somehow couldn’t get through to the management. I was fighting my fight for a month. I needed to get involved more in the projects quality. I needed the team’s uninterrupted time for refactoring; to explain their mistakes to them; to teach them to make more reliable code. This was my focus after all, my new job.

I expected approval, but I hit the wall. There were only obstacles, and more obstacles after them. I was startled. So my CTO wanted me to improve people’s skills, but I couldn’t get the means to do it. Instead of something along the lines „ok, let’s figure out how to move some projects to find time for this” I was receiving more of a „let have the juniors decide if they like their code or do they need to improve”. It’s easy to demand results from someone and turn a blind eye to all the obstacles. Unfortunately it doesn’t create a magic bubble that resolves all of the problems.

So it was the whole team’s effort and finally, after another couple of weeks we all agreed that unit testing was an inseparable part of any project (in theory at least). But the damage was done. There are now months of shitty, untested, undocumented and mangled spaghetti code in our core product. Somehow we managed to put our worst quality into our crown jewel.

Now the team is incapable (in the most of the team’s opinion) of creating a quality product. It desperately needs guidance and an on-deck help from a senior engineer, but frankly no one want’s to work with them now. And since the management still doesn’t see this as a big deal, the guy will still be working on the project despite that he can’t handle it.

My takeaway from this: the manager can’t put a junior developer on an important task without oversight and expect good results. It’s your job as a manager to put people to best suited positions — both for them and for the company. And to evaluate beforehand if someone will manage to pull off the task.

I just wanted to dance

In the end we decided that we have to undo my shift in responsibilities and get me back to coding again. This was about the time I started to realise that in the current situation my skills aren’t used to the full extent. I’ve heard from all over me that I should be involved in more projects or that I’m not coding enough. It was somewhat flattering, but it also meant that I’m most valued as a coding monkey.

I felt like I was the girl Sir Ken Robinson talked about (seriously, if you haven’t seen his talk about school’s impact on creativity I strongly urge you too). I was evaluated by a standard template. I was supposed to be a coder, nothing more. If I tried to sway from this path, I was perceived ineffective. Even by myself. The thing is — I just wanted to dance — and no one expected me to.

It was a kind of an „Eureka” moment when I came to conclusion that in fact I shouldn’t be judged that way. I should find my best perks and go to a place where they’d be put into good use.

But isn’t that kind of a managers job to figure out? It’s the managers sole responsibility to remove obstacles and let people work without distractions. From my current point of view: management is the most difficult job. Not only do you have to satisfy business requirements, but also you have to make good with all the various people that rely on you. And you need to be exceptional, because they are and they expect nothing less from you.

Last tip: as a manager you have to actively engage in daily work and everyones issues. It’s not just about responding to problems. If you fail to act, to think about two or three next steps, your team will eventually stumble into chaos or fail to excel… and be miserable and won’t perform and leave. Because „people don’t leave startups because they’re failing, they leave because they’re mismanaged, which is often why they’re failing”.

What’s next?

So it’s time to burst the bubble. I am not primarily a coder. I am a people’s person (paradoxically), I am a good teacher, a decent leader and I know a shitload of stuff. I can tell how to make the most efficient code given a business situation, but I wouldn’t be the first person to sit by the keyboard and do it. I mentioned it earlier in the „how to write a job offer” piece — you sometimes need a brilliant mind to push your limits forward and sometimes it’s just a soldier with a steady pace and reliability.

I decided to abandon my current job because it’s not a good place for me — I won’t thrive here. It’s time for me to find my own way and pursue my new professional goal: a kind of consulting company, focusing on my best skills. Although not without regret, I am entering the new year with a whole new set of challenges and opportunities.

Creative Commons License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License . This means that you may use it for commercial purposes, adapt upon it, but you need to release it under the same license. In any case you must give credit to the original author of the work (Maciej Łebkowski), including a URI to the work.