At the same time, if you're a developer and you see these signs in yourself or your coworkers, today may be a great day to hand in your two weeks' notice and find a proper developer job. You're doing yourself a favor by taking the first step!
The following list are epitomes of an organizational culture which will eventually result in a steaming pile of garbage that is both worthless and expensive rather than software which lets the company flourish. Systems generated in such a culture are parasites - they suck the very life essence out of everyone who has to deal with them, and the longer you let them fester, the bigger the problems will become.
Ten signs you should fire your developers
#1 - Working 9 to 5
Creative work can't be clocked. When developers always start at a fixed time and always drop the pen at the same fixed time, never taking work home, that's a huge red flag. Sometimes, the best ideas happen while jogging, under the shower or even while playing a game. Most work doesn't happen at work - solutions created exclusively on the clock just plain suck.#2 - Copy Paste Solutions
Software development is creating new solutions and optimizing existing solutions. By copying and modifying the same thing all the time, complexity grows over time and simple changes eventually become extremely difficult. This way of working is unsustainable, and by the time this becomes obvious, it may be economically impossible to change course.#3 - Need for supervision
Developers need to think by themselves. When developers only do what they have explicitly been assigned to do, only work when someone is checking on them and outcomes need to be monitored before they can be released, you have a serious problem.#4 - Closed groups
The world is bigger than we think. When developers dig trenches to the business, can't even give you the name of a single user, much less having a professional relationship with any of them - how can they build the right product? A sense of "stranger danger" where developers perceive every new face as a threat means that they have already lost touch with reality.#5 - One Trick Ponies
"If the only tool you know is a hammer, every problem looks like a nail".When developers see technical diversity as a threat, can only work within a single paradigm and start to frame business problems in terms of what they know rather than expanding their knowledge to suit the business domain, you have the wrong people. Combined with a "my way or the highway" attitude, you can be certain that the money you sink into development exceeds the value generated.
#6 - Learning passivity
Knowledge work is all about knowledge. A continuous hunger for new knowledge allows developers to excel in their field. When developers resist new ideas, need to be told when they need to learn something new and shy away from experimenting, they lose their edge - and so does your software!#7 - Limits to responsibility
Great people care for what they do, and want their work to make an impact. Statements like "Works as Designed", "Works as Requested", "Quality is a tester's job" or a pervasive mindset that users are just too stupid to use the software properly imply that developers have locked themselves into an ivory tower and try to shelter themselves from reality.# 8 - Frameworks frame thoughts
If there were a standard framework for your business, someone else would be doing it better and cheaper than you could. Be very suspicious when the answer to every question is, "<this framework> can do it", especially when the solution always looks like the framework says it has to. Once developers have a standard of standards for developing new solutions, you know they're solving the wrong problems.#9 - Enamored with code
Nobody cares what happens "under the hood", as long as the engine runs. When developers esteem good-looking code higher than the business utility of said code, they waste time and money. Combined with an attitude that the code would look much better if it wasn't for constantly changing business demands, you know that eventually, the house of cards will collapse - and your business might tumble down with it.#10 - Caught in the past
The marginal value of every technology is Zero. Yesterday's great solution is often just barely useful today, and last decade's state of art is today's liability. If your newest technology is half a decade old, and the "never change a running system" mindset pervades the organization, you're riding a dead horse already. If on top of that, developers feel emotionally attached to "their baby" and aren't willing to let go, you'll be stuck between a rock and a hard place.Toxic culture
Encouraging and reinforcing the behaviours above creates a devastating culture. If you encourage behaviours that fall into any of the above ten categories, you are creating a culture where high performance isn't even possible. You may likewise inadvertently be shaping culture by not stopping these behaviours, not calling them out or just tagging along with them. As such, it's always a people problem, that is - a problem created by management.You can't close a blind eye to these. You have to call them out, you have stop them, and you have to actively work against them. There's a reason why people do these things - and rarely is the reason that people want to hurt the business or their own career. Explore the root cause, and eliminate it!
Organizations where development works as above are career dead ends. They take the purpose out of the work and make IT as a whole a massive liability. The faster developers leave such a place, the better it is for them. If they no longer have the will to take this step by themselves, do them a favor and help them move towards a better future.
I agree these are not good things. But perhaps the problem is that you are blaming the people for it instead of the work environment. that the root cause may not be the people, but the environment you are putting them in. Removing people who are not performing well instead of looking at the culture that causes that is a toxic culture in and of itself.
ReplyDeleteThis looking at the systems for the common causes that are found was a concept put forth by Edwards Deming in the 40s. It is part of systems thinking. When people have given up on their company the types of behavior you list is the type of behavior you get. We need to do more critical thinking and ask ourselves - why are we getting this behavior? Are we encouraging it by demotivating people?
Al, thank you for commenting.
DeleteThis has nothing to do with blame. The system is made up of people, and people shape the environment. A general problem is that many times, we confuse symptom and cause - when the symptom is no longer visible, we falsely assume that the problem is gone.
For all factors above, the root cause is, as you rightly noted, a dysfunctional organization where such behaviors can flourish.
The point of the article is that as managers, we have a choice: preserve the root cause and lose the talent, or actively deal with the cause.
Revisiting this *years* later - but I agree with the points put forth by Alan: a system where participants aren't incentivized to exhibit exemplary performance will likely result in the behaviors listed in this article.
Delete". If you encourage behaviours that fall into any of the above ten categories, you are creating a culture where high performance isn't even possible. You may likewise inadvertently be shaping culture by not stopping these behaviours, not calling them out or just tagging along with them. As such, it's always a people problem, that is - a problem created by management." -- this statement sounds like we are placing the root of issues at the hands of management simply keeping an eye out (the stick) vs. creating a culture where individuals want to show up at a high level (the carrot).
thanks for making this article Michael! i found it thought provoking on swe team mgmt
These are true and I see these patterns in the best of environments and companies. Can you add a new post on when to fire your leaders? I have transformed large orgs by replacing the leadership with people who knew how to run high-performing teams. You need both good teams and great leaders to make real change.
ReplyDeleteGood comment.
ReplyDeleteThat may definitely be worth an article.
I'd say in short: "When they aren't leaders." ;-)
Lol ye so work overtime for your company to get rich while you get peanuts. No way Josė
ReplyDeleteGot hung up on the 9-5 statement?
DeleteNope. This isn't about doing overtime. In fact, if you think this is about quantity at all, you're getting it wrong. I'd rather work with someone who excuses themselves at 2:30pm "sorry can't think anymore today," than with someone who will sit at their desk until 5pm sharp just because it's the job's requirement.
#1 - OMG, what a bullshit. This is how developer should work. Moreover this is how all employees should work. Why do you think that someone's business would be more valuable that employee's personal time?
ReplyDelete