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.
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.
0 Comments:
Post a Comment
<< Home