Technical Debit

Running a software company badly is easy. Running it very badly is harder. Generally, you've employed smart people, who can spot the bullshit. To run the company in such a way as failure is guaranteed, you're bound to get noticed. Your smart people, natural-born-problem-solvers, are bound to rock up and tell you what they've noticed - the impossible can't be done, and it's being made impossible by the following factors.

In some ways, the idea that your smart people might prevent you screwing up seems like a good thing. However, what if you've promised someone that you're going to achieve the impossible. To turn around and say you're not even going to try to do it would be very demoralising and would make your promises seem like they were flimsy ill-considered folly. To try very very hard, fail, but get something vaguely pass-off-able, would be better, even though it will make all who touch it shimmer with shame. So, you need to squeeze your development team through the mincer of your decisions, no matter how naive, fallacious or plain reckless they were. This works all the better if you simply refuse to believe that your decisions are anything other than reasonable and achievable. It really helps if you liken your strategy to one which worked in some other situation, under different circumstances, with a different problem, team, technology and desired end-result.

So, how do you stop your team beating you and "pushing back against your decision"? This is where Technical Debt comes in. Technical Debt is where you first push your team to deliver some stuff too quickly to do it properly. You assure them that you'll give them time to tidy up. However, you quickly push them again and again into more dark corners. By the 4th cycle, the work will be a cludgy mass of nonsense. Then you can ask them about Technical Debt. This is the missing tidy-up they were meant to do as they went along. Then, you get them to ask for the time to put it right, as though it's a debt that they owe you.

Then you need to go a step further. From Technical Debt you must achieve a Technical Debit. The idea here is to crush the spirit of your technical team, by pressuring them negatively with demanding schedules for the impossible, a sense of accusation over the technical debt, and, and this is the clever part, no opportunity to research moving technology and move with it. Generally, as technology improves, the ability to make stuff gets easier and your team could get better at their work, which will only improve their ability to focus on the impossible/improbable bits of your strategy. You have to keep them crushed and cornered to avoid them causing you to fail too soon and HAVE to back out of your plan.

So, this is where Technical Debit comes in. A chronic exposure to the impossible and the crushing will cause people's capabilities to reduce, thus debiting their technical proficiency, or, will cause your best people to say "screw this crap, I'm going somewhere better" and leave. You can then get the smaller team to limp along, or even appoint a Problem Absolver to confuse matters further.

Technical Debit is inevitable if you want to keep the team down and, by comparison, yourself up.

Problem Absolving Position

Imagine you have a perennial problem in your company. You have a couple of choices for solving it. You can work on fostering a company culture of group responsibility and empowerment, such that everyone recognises the problem as their own and naturally come to solve it themselves. This, of course, is the most effective and long-term solution to a problem. What's more, the emergent solution probably will create some opportunities for further development of the company's capabilities and the staff involved. However, this approach is very very difficult, because it requires a company culture change, involving the hearts and minds of the employees. Frankly it takes leadership which may well be either too hard, too much effort, or simply beyond the sort of person who blags their way into leadership of a company.

This is where the Agilistamistalentalist consultant first gets an in-road into the company. The management know their a problem, so they just hand the problem on to some other mug. The consultant, who can only continue to work while there's work to do, gets to come along and stir things up, providing illusory and placebo progress results to management, while simultaneously working hard to maintain the core problem in such a way as it's tangible, thus keeping them in work.

There is a further pattern that management may also use. This need not exclude the Agil-sultant. The pattern is to recognise a problem and then create a job description which equates to "suffer this problem on our behalf". The idea is, metaphorically speaking, to appoint a messiah who the company can follow for a while, ultimately nailing them to the cross of the problem and watching them die slowly and horribly. The problem may not go away, but the fact that it has a figurehead gives people the comfort that it's not their problem, and even the chance to point at the person and say that it's all their fault that the problem still exists.

Of course, some job seekers reading this may be worried that they're currently looking at roles that might be of a "problem absolving" nature. Here are some clues to look out for in interviews and job descriptions.

• There's a look of "please help us" in the eyes of the grass-roots staff you meet at interview
• The role has a lot of varied responsibilities, all of which look like management, but are at a low level
• The role has never existed before
• The management ask you how you would solve certain very specific problems at interview, and the examples don't sound like they've been made up
• They ask you how long you might expect to take to restructure something - this is a trick question, always estimate it as 10 cycles
• They ask you to be "flexible" on the job description
• They seem prepared to offer a bit too much money
• They're looking to improve abstract quantities, like "throughput" without quantifying what that means
• There's talk of some possible future, where the role will change, once the initial phase is complete

You can take a problem absolving role if you intend to do it for a few months and leave under a cloud. You can take a problem absolving role if you are, essentially, a lazy person and want to do nothing for a few months; if you can report illusory progress of your own, then nobody will suspect you've really done nothing, since the problem was never going to go away no matter what you did. Don't become a problem absolver if you're looking for an engrossing hands-on satisfying job experience. Life's not like that.