I would like to preface this entire article by stating that I’m about to speak from anecdotal experiences. Not everyone or every company functions in the methods in which are about to be described. But if you’d like to know how to make your developers run for the hills because they can’t stand working with or for you then this article should help provide some ideas.

I will be referencing two different companies that were, by far, the best examples of how to wage this war. Oddly enough, one company ended up being the best company I've ever worked for and I long to go back to that kind of work. I'll let you sort out which one.

Not taking responsibility

Company A had a website where images were rather critical to the user experience.

These images came from another source and the CEO had coded a system that pulled these images into a network mounted folder. These images were usually large in size and sometimes came in large numbers.

The CEO had also coded up a cron script to check when images were no longer necessary and delete them.

That cleanup script was never checked. Assumptions were made before I joined that it was working. It was not. Before long, the network mounted volume maxed out on disk space.

This wreaked havoc on the site. Queue me spending a few sleepless nights trying to fix and recover the system.

I didn't receive any recognition for the time I had to take away from my friends and family because the CEO couldn't be bothered to take ten minutes and check the cleanup script functionality. There was no recognition or acknowledgement of his own mistake. It was just… There and it just happened and it was nothing.

Taking too much responsibility

Remember the images maxing out for Company A? Remember how I worked some sleepless nights to help fix it? Well the CEO came in towards the end and re-did a bunch of work I had done without checking with me. He fixes the problem before I can (because I had to take a nap) and becomes the hero. He caused this huge problem, picks up where we left off last, duplicates my efforts and then takes credit for the fix himself.

At Company B, we had this huge, multi million dollar project and our dev team was way too small. We should have had at least a dozen developers and we had about four to six.

Anyways, I complained for, literally, months about the size of our team and what this would mean for our project. All of a sudden, when our client was getting antsy because our progress was lackluster, one of the managers brought two more devs onboard. He was praised for recognizing the need and bringing them on. I'm not sure where my complaints fell but it feels like they fell on deaf ears. The manager was also months too late. The project was already dead by the time he took action.

Creating silos

At Company A, we had a junior developer who could not perform as well as he might have under different circumstances. The CEO had coded the website we were working on and he was no developer. His code was spaghetti. The cognitive load was crazy. No conventions, at all. There was nothing consistent about it. It was also terrible to read. I would confidently say it's the worst code and structure I've ever seen in my life. I wish it upon nobody. The CEO thought he was hot stuff, though, and our junior developer was closely involved with his tasks so they worked together a lot. As a result, the junior could not grow. All he had to look at was this wasteland of code and structure. He could not excel.

There was a point where our junior developer was considered such a drag to my productivity that they separated us and instructed me never to help him again. I would help this junior on an almost daily basis. I would answer questions and review his code and help him learn and combat the negative crap he was seeing in the code and structures he was working with. However, the answer to the problem wasn't to help this developer out but, rather, to discuss how they would fire him and, eventually, cut him off from me, someone who was genuinely trying to help.

At Company B, even though the company itself had at least twenty or more developers working at any given time, only four to six were ever and always assigned to our understaffed multi million dollar project. Not only did those developers have no idea what their colleagues were working on but it was the other way around too. At a lower level, because we didn't have the resources we needed, the developers on the project ended up being pigeon holed into certain aspects of the code. We were under a tight timeline and had four people for a dozen people sized project, best case scenario. It was faster for the devs to specialize and stay where they were instead of rotating the knowledge. A whole year went by and these poor devs got stuck working on a huge project and learning nothing. Learning nothing over the course of a year can be a death knell for web developers or even developers in general.

Squashing ideas

At Company A, I lost track how many times ideas were outright given a no from the CEO for reasons I can't even explain. The company hired certain experts in certain fields to bring their knowledge in. They would subsequently make recommendations and the CEO would often squash them, sometimes in heated arguments, in public.

The database was as much of a mess as the code was. At one point, I remember, it was so distressed and I recommended we take certain tables (like a CRM we had) that didn't need to be in the same single database and slowly break it apart into more manageable pieces. Instant nope.

This theme was carried on over and over again not just with me but with the other developers, who were often times proven right, and others in the company who had different expertise.

This also brings up a point: blocking learning opportunities. When you keep bringing up ideas that are perfectly reasonable and, more often than not, will help improve a lot of things, but are constantly told no, you're being blocked. Blocked of opportunities to try something new or to exercise existing knowledge and show that you're valuable and have something to contribute.

Overpromising during the sales pitch

At Company A, we had to go and land that multi million dollar project. Well, when the sales team went for it, the client would ask questions like “Do you have X, Y, Z system that we require in order for this project to be successful?” and the sales team said “Yep” and, as you can guess, we didn't.

I understand this is sometimes part of the sales process and the whole “fake it until you make it” thing. But, in this instance, the system was complex and large and had a lot of moving pieces and legal requirements.

Not only that but this price was paid, ultimately, by the developers who had to jump onto an understaffed project with high complexity and then see it all fall apart and fail.

Understaffing a project

At Company A, we were managing a rather large website with a lot of moving parts. There were three of us. A junior, an intermediate and a senior. We needed more. Even a few more juniors would have been a huge help. Instead, the CEO forced HR to put posts out for a magical senior developer unicorn who could do backend, frontend, full stack, UI, SEO, UX, and more. Anybody who didn't meet that criteria was instantly thrown out.

At Company B, I've already talked about this at length, so I won't say much more. But this cost me (and a few others) 100 hours a week of work to try and keep up to the workload we had in the timeline we were given. Doing that for eight months or so, non stop, was not sustainable. But that's the price we paid for not having enough developers to help us and management ignoring the issue.

Backstabbing

At Company A, the network mounted drive got full (a second time because the CEO didn't do a good enough job fixing it the first time, his code wasn't working correctly, again) so images were no longer showing. Once again, I had to fix it.

However, later on, I heard that the CEO was telling people, including in HR for some reason, that the images were broken because I had apparently run some errant query on the DB. Not only could he not provide proof of this claim but I never received any feedback from him or my direct manager about it. Instead of coming to me directly with issues so they can be sorted out, they were happier to spread my faults around (true or not) to everyone else in the company. This ties directly into…

Talking behind their backs

Our junior developer at Company A struggled keeping up for a number of reasons. I've already explained most of the reasons but there was more.

Performance reviews were a perfect time to tell him where he was struggling and help him work on it or ask how the company could help him get better. Guess how many times that happened? Zero times. Exactly zero.

Instead, I was personally privied to conversations by management where he was trash talked and, for months, they were eager to fire him. Instead of supporting him and giving him the opportunity to defend himself and to speak up, they simply NEVER listened to him and jumped at the chance to get him out the door.

I kept thinking “If they are ok and happy to talk about him behind his back like this, I wonder what's being said of me?”

Judging performance incorrectly

At Company A, our performance was measured by how many contacts inquired of our service. It was also measured against how much of our development time was focused on bringing those leads in. It doesn't make sense.

Developers can't solely be judged by the success of what really falls under the domain of a product owner and user experience. If you are asked to build a feature that seems perfectly reasonable but doesn't have the desired effect in terms of user interaction, the developer cannot be held responsible for that. At least not entirely. There were others who were involved that decision.

Taking away bonuses or assigning blame to developers for fulfilling their superiors request but having the effects of that request fail is a failure in itself.

What developers SHOULD be judged on can be saved for another time.

Be socially inept

At Company A, I can't count the number of times the CEO showed a complete disregard for basic social structure. He thought he was above everyone else.

One time we went out for an overdue lunch because I had created a system that saved the company thousands of dollars a month. The other devs supported me so we all benefited from a pricey steak lunch. It was a great opportunity to bond and get to know each other. Instead, the CEO asks, as we've sat down “Ok, what are your questions?”. The table went quiet. We didn't know what he meant. Me being the senior dev and having been around the block a bit, I realized he thought this was a lunch where we'd ask the all important CEO a bunch of business questions to know how smart and business savvy he was.

We are developers. Not CEOs. Maybe some of us have an interest in that kind of thing but this was not the time or place.

Regardless, he launches into a tangent about business goals and what we need to do on the dev team to build the bottom line. Queue the rest of lunch ruined.

There was a point where I asked my heavily pregnant wife to come to the office and meet the team. I wanted to open the door for people to know me and my family better.

My wife went out of her way to purchase some goodies for the whole office and come in. She's greeted by everyone with welcoming smiles and introductions.

Two seconds after stepping in, what does the CEO do? Puts his headphones on and goes to work, never getting involved with us even after my wife left.

I have a lot more stories that illustrate how the CEO dealt with the devs and, actually, the employees in general. But, suffice to say, building a team spirit and applying social norms was beneath him and he made that clear. Sometimes he would break people's trust and spread private knowledge the devs told him in confidence. Or he would yell and swear and storm out of the building and slam the door when the devs disagreed with him on a technical course.

Conclusion

Waging a cold war with your developers isn't hard and I've been part of it. Company A has since lost all their developers (including me) and Company B lost a multi million dollar project and it hurt their reputation a bit.

Not all jobs are easy. Not all jobs are fun. Not everyone gets along. But there are some basic and fundamental things that anybody can follow and apply to help make things better.

In another article, I will go over how developers could wage cold war with their employers (or clients). I've done my share of screwing up. It's only fair that I be honest about that too.