What is Headless Chicken Mode?
Headless Chicken Mode is a state of mind, and can sometimes seem like some sort of highly contagious mental condition that can spread through the office like wildfire. Anybody from architect to junior developer can suffer from this condition, and it is usually brought on by some pressure from the business. The further up the chain of command this condition permiates, the bigger the problem is. Symptoms include a fixed, slightly glazed stare, a sheen of sweat on the forehead, and rapid walking around the office talking to the wrong people about the wrong things at the wrong level, and lots of enthusiastic discussion about completely inappropriate solutions. The business and non-technical managers love this sort of thing. They see people jumping into action, reacting in a positive way to their motivational techniques, lots of activity and enthusiasm.
The Business Idea
The business has this fantiastic idea, and have convinced all the senior managers that this solution would really benefit the company. They build up huge enthusiasm for the idea, get loads of budget, print special T-shirts, have promotional events, put adverts on the big screens. And to be fair, their business outcome they are aiming for makes absolute sense. Then two days before their go-live date, they remember that somebody has to actually enable the systems to support this idea. But how hard can it be?
Top Priority - Process Ignored
They don't need to go through the normal 'propositions' process, so carefully put together by Technology, because the CEO has decreed that this is the priority and will be delivered. Therefore they approach a team leader, and make sure that he is fully aware of the absolute urgency of their request. They usually present a technical solution, rather than a business outcome, and give the absolute deadline of, say, two days. The team leader
You have various controls at your disposal when you are running a project. You can control the scope of the project, so you can choose to deliver more or less features. You can control the quality of the technical solution, but this is a very dangerous control to use. You can control the amount of resource allocated to the project, but you have to be aware that they gain from this isn't linear, and can actually cost you efficiency if you try to ramp up too quickly. You can control the time allocated to deliver the project. Finally you can choose to fulfil the business outcomes with a non-technical solution if that makes sense - and this will usually be invaluable if you have a tight deadline, but over the long term will usually not be the most appropriate solution.
The team leader has just given away scope, time and manual alternatives to the business. He hasn't got time to introduce a big team effectively, so he can't really use resource as a control either. As for quality, he hasn't discussed SLA's (Service Level Agreements), so they default to production quality, 99% uptime. So he now has no control left at all.
Switching to Headless Chicken Mode
This is when Headless Chicken Mode strikes, and he runs round the office in a mild panic, asking random developers if he can use this database to get this bit of information, if they could go direct to the database without having to build a web service, if they could build a web page in a couple of hours this afternoon. He rarely gives context, so nobody has the opportunity to suggest an alternative, or highlight the problems with this approch. Then he tries to find a fast track to live, skipping testing.
The Mythical Next Release
Many people who should know better do this sort of thing, and they always believe that they have no choice, and that its ok to deliver this complete rubbish, because 'the next release' will sort out all of its shortcomings. However, the next release never happens, because the business never spend money on making the technical solution better, they will be investing in their next idea. If the app keeps falling over, it is up to Operations to fix it. If its got bugs in it, then development will provide bug fixes. They see no point in spending any more money when they already have their application in live, no matter that it is costing Operations, Dev and Testing a huge amount to operate, test and maintain. It's not their fault that we can't do our jobs properly. But Technology has now got high operating costs, and their ability to respond to new ideas is compromised.
Avoiding Headless Chicken Moments
So how should we deal with this situation? Well, the key thing to remember is that it should always be a negotiation between technology and the business, neither should be able to dictate things to the other. In addition, the business should never present a technical solution; they should present the business outcomes that they want to achieve, and negotiate with Technology to agree on the most appropriate way fulfil these.
If the deadline is unrealistic, first try and work out what actually needs delivering for that deadline. Usually you only need to deliver a small subset of the solution for that date, and then you can iteratively add features on a 'just-in-time' basis. The next step is to look at what manual solutions you could put into place to deliver the same business outcome while you deliver the automated solution. Could you set up a call centre with people manually entering data? Could you send emails to customers, send a form through the post? Place an advert in a magazine? You don't always need to deliver the technical solution.
Is It Worth It?
Another good discussion point is cost benefit. If you can demonstrate that it will cost X to deliver the automated system, and the predicted benefit isn't several times higher than this, is it worth doing at all? When discussing things with business people, always bring it down to money - then you're talking the same language.
Once you are aware of the Headless Chicken Mode, it is easy to spot. The look of mild panic is the first sign. If you then overhear snippets of conversation, or see an email trail that indicates that ill-conceived solutions are being hacked together for an unrealistic deadline, you've got a 'HCM' problem.You have to put a stop to it, or your technical platform will be corroded to the point that you will spend your time fire-fighting rather than producing inductry-leading solutions that you are proud of.