A Fictitious Letter

in old times, kings relied on court jesters to point out inconvenient truths and give an unmasked account of what was going on in their kingdom.

You are not king of your company (and would probably feel distinctly uncomfortable striding through the office in a purple robe) but you are the person at the top, the one who wields most power and who carries most responsibility. And so – brushing aside the finer differences between ancient nobility and modern business life – let me be your court jester for just a few moments. For there are one or two things you need to know about the most mysterious and impenetrable part of your company.

What part am I talking about? Well, it is a part that gobbles up millions of your budget but constantly clamours for more resources. It is a part that produces statistics quite effortlessly but leaves you helpless as to what the numbers actually mean – sometimes even unsure whether an upward trend is good or bad. It is the part that you are struggling to understand the internals of – despite your decades of experience and your MBA, despite the fact that you are a highly respected and successful manager, despite your honest efforts to connect to people everywhere in your company.

It is also the part that, if it did not exist, would make your company unable to operate. I am, of course, talking about your IT department.

I know you are unhappy with your IT department. Not desperately unhappy – after all, it all sort of works – but you have that nagging feeling that things are not going nearly as well as they could do. Within IT, there is stubbornly high staff turnover with key knowledge walking out of the door every time. Your non-IT managers complain that project deadlines slip because IT are late. That they lost large amounts of money because crucial systems were down when they needed them most. That it seems to take forever to get anything done at all, and, that if IT delivers, it never seems to deliver quite the right thing. Your fellow board members argue that IT is the department with the poorest visibility of projects, and that half of these projects are probably unneccessary anyway.

Meanwhile, IT outsourcers are knocking on your door claiming to solve all these problems for you at virtually no cost (well, strictly speaking it is a small fortune but they have proof-by-powerpoint that it will all pay for itself by Q2/2012), and leave you scratching your head whether you would not be better off handing over your problems and sleeping easy with a nice IT Service Level Agreement under your pillow.

You are the boss – and hence no-one can can take the ultimate judgements and decisions off you, not even your CTO or Head Of Technology since he might be part of the problem as well as part of the solution. I know you are ambitious and tough and that you usually relish any challenge coming your way. But I see a hint of resignation in you, a grudging assumption that your IT department will simply never be quite like you want it to be.

Don’t give up just yet.

Can I ask a slightly stupid question? What exactly does your ideal world IT department look like? Or, in more practical terms, suppose you found an IT-savvy Genie in the Bottle, what would be your wish? Let me guess the conversation:

“Master, I shall grant you three wishes. May wisdom be with you.”

“Excellent! Remarkable! Can you make my IT department perfect?”

“Master, my power knows no bounds and is at your service. But do tell me: What is ‘perfect’ for you?”

“Well, I would like IT to deliver on budget, on time, every time.”

“Master – ”

“Sorry to interrupt. I would also like to see IT cost reduced by 30% next year, have all operational risks quantified and mitigated, helpdesk response times halved. Let’s have thorough visibility of projects and resources, and the ability to implement the IT aspects of any new business initiative within, say, one week. All decisions should fit into a consistent long-term strategy, and I want my board to participate in all major decisions. It would be good to be able to run the whole company from employees’ homes in case we have a terror scare. Oh, and I want IT to have everything in place to pass any audit with flying colours. Maybe we should become ISO 9001 cert… “

“Master?”

“What is it?”

“My humblest apologies. I have not granted wishes in a long time and have become rusty. Can I warm up with a simpler wish?”

“Like what?”

“May I suggest I make World Peace?”

Dear CEO, your goals are the right ones, and your demand for excellence in your company is a noble one. Yet, as much as you hate settling for second best in some respects, you must make it clear where your priorities are. Otherwise, your IT department becomes a Jack Of All Trades but Master Of None.

Put yourself in the shoes of an IT team lead somewhere in the department. He needs to make priority decisions every day. Should his team work –

on rebuilding the Head of Sales’ laptop ahead of his client visit, – or on producing a better version of Legal’s document capture software?

on rolling out more powerful software testing tools, – or on fixing the latest set of bugs your Finance department are held back by?

on producing project updates ahead of that all-important full board meeting tomorrow morning, – or on answering questions from your biggest client conducting a due diligence review?

How does he make those decisions? He cannot get the answers from you. He also cannot wait for an opinion from your CTO – the CTO should be working on strategic plans, after all, on negotiating major 3rd party agreements, on programme management, on IT organisational development, … . At the same time, whichever way this team lead jumps, he has a fundamental impact on the business.

You help him by making your overall priorities clear, by communicating what you care particularly deeply about, and, just as importantly, where you are prepared to settle for second best.

I know you put a lot of effort into working out the strategic direction of your company – which markets to go for and which ones to ignore, which customer relationships to invest in and which ones to leave as they are, whether to take the risks of aggressive expansion or to play it safe. Since virtually every aspect of your company depends on IT, your IT department reflects these decisions. Think of IT as a microcosm of the whole company. Without a foundation of clear and realistic priorities, it will drift aimlessly and unproductively. The one thing you do not need to worry about is translating business into technical priorities – that’s your CTO’s job.

I could leave you in peace now and let you mull over what I whispered into your ear. But a court jester would not be a court jester without carrying on a bit further, just enough to become a tad annoying.

It is a bit old-fashioned to talk about it in this way but – let’s face it, one of your jobs as head of the company is to build and enforce a Chain of Command. This is how you stamp your authority on the whole organisation.

You are more than familiar with the Chain of Command – issues of delegation, empowerment, allocating responsibility, choosing appropriate hierarchy levels and team sizes at each level. I do not have anything to add to this. What I do want to introduce you to, though, is a complementary concept: the Chain of Trust. The issues it addresses are not exclusive to your IT department but they are particularly burning there.

Let’s look at the hands-on end of the Chain of Trust: Suppose the senior database specialist in your company checks system messages one murky morning and realises that blocks within 45xxcompPass.log files for real-time transactional push replication to remote recovery instances are subtly compromised due to rwx permissions errors as a result of a backRTPacinGE.sh script failure. The guy knows two things: (a) the company could get into serious trouble over this (the risk of loosing live databases is distinctly unfunny ), and (b) no-one except him understands what exactly is going wrong on a technical level.

And so he talks to his direct boss, likely to be some infrastructure team lead with only superficial knowledge of the innards of an enterprise-level database system. Does our database specialist explain the issue to her in terms of 45xxcompPass.log and backRTPacinGE.sh? Of course not. He gives her a rough overview of the technical problem and then he and the team lead discuss how serious the issue is and how to control the business impact: What are the immediate risks, what is the resource impact of immediate measures as well as of fixing the underlying issues, what needs to be done to prevent similar problems occuring again, etc.

Can the team lead verify what her database specialist is telling her? Unless she has a spare database specialist in her bottom drawer – no, she cannot! Beyond a few plausibility checks (assuming she has the time) she essentially just has to trust the engineer.

Ok, let’s climb up the hierarchy. Our infrastructure team lead concludes that the database problem is serious enough to get the CTO involved (I assume that yours is not a vast corporation with another three hierarchy levels in between). Does she explain the issue to the CTO in terms of 45xxcompPass.log and backRTPacinGE.sh? Of course not – she does not even know these gory technical details. Does she explain the problem in terms of failed integrity checks and corrupt replication as it was relayed to her by her database specialist? Again, no. The CTO’s hands-on knowledge of databases is both slim and 20 years out of date. Instead, the infrastructure team lead explains which systems are at risk, which business processes they support, what action she recommends and what the impact on project deadlines is going to be.

Can the CTO verify that his infrastructure team lead is not telling complete porkies? In many cases he cannot – he essentially just has to trust her.

And if the CTO concludes that the issue is so serious it threatens the operation of the whole company he will pull you, the CEO, out of your sales call with the fateful words “We have a problem. I need to talk to you for a minute.”

Needless to say, you as CEO need to trust your CTO and hence the infrastructure team lead and ultimately the senior database specialist.

This is what I mean by Chain of Trust. No amount of organisational structure, processes, checks, monitoring, management information systems, etc. can replace the Chain of Trust. If it is broken anywhere you are like an aircraft pilot flying blind – unable to rely on what the tower tells you about the runway being clear.

You don’t just need an intact Chain of Trust when things go wrong with your IT systems. You need it every day. Project estimates and progress reports travel up the chain in exactly the same way, and so do e.g. assessments of third party products. I’ll say it again – processes, monitoring, organisational structures, audits and the like complement the Chain of Trust but cannot replace it. Not unless you want your IT department to turn into a bloated mess with engineers who only work there because they were not good enough to get a job elsewhere.

You would not be where you are without already asking the obvious question: How do you build (and maintain) the Chain of Trust in IT?

Well, it is rather old-fashioned and it is, I am sure, what your instinct tells you anyway: Trust grows between people. It needs to be built, earned, nurtured. It comes as part of a strong relationship. Hence, maybe surprisingly for an area in which technical skills are traditionally seen as more important than social competence, you need to insist that every link in the chain builds relationships based on mutual trust.

Actually, “mutual” is a crucial word. Trust cuts both ways. I gave you an upwards example but the downwards aspect is just as important: E.g. your CTO must be able to trust you to lead the business into the right strategic direction. The IT team leads must be able to trust the CTO that his technology vision will work out, that there is a career perspective for them, and that he is their advocate at board level and across the company. Another level down, individual engineers must be able to trust their team lead that their skills and effort are not wasted, that all those extra weekend hours will be rewarded, and that their excitement and pride in their work is shared.

If I was in the fortunate position of having a Genie at my command – I would wish for trust in IT at all levels and in both directions. It is not an easy wish (and the Genie might still try to wiggle out by mumbling something about world peace) but it is achievable, not least by putting the right people in the right places.

And once you have a Chain of Trust in place in your IT department, everything else becomes a lot easier. Yes, there will still be a lot of work to do maintaining optimum organisational structures and processes, weighing priorities in the face of limited resources, making sure people stay sharp rather than drifting into complacency – but success becomes achievable rather than a dream.

Well, I am afraid of overstaying my welcome, so I’ll stop here even though there is more I could whisper to you. Thanks for lending me your ear. Let me leave you with a recap of what I have been suggesting to you – it is really just two things:

Make your priorities clear
(this includes saying where you accept second best)

in old times, kings relied on court jesters to point out inconvenient truths and give an unmasked account of what was going on in their kingdom.

You are not king of your company (and would probably feel distinctly uncomfortable striding through the office in a purple robe) but you are the person at the top, the one who wields most power and who carries most responsibility. And so – brushing aside the finer differences between ancient nobility and modern business life – let me be your court jester for just a few moments. For there are one or two things you need to know about the most mysterious and impenetrable part of your company.

What part am I talking about? Well, it is a part that gobbles up millions of your budget but constantly clamours for more resources. It is a part that produces statistics quite effortlessly but leaves you helpless as to what the numbers actually mean – sometimes even unsure whether an upward trend is good or bad. It is the part that you are struggling to understand the internals of – despite your decades of experience and your MBA, despite the fact that you are a highly respected and successful manager, despite your honest efforts to connect to people everywhere in your company.

It is also the part that, if it did not exist, would make your company unable to operate. I am, of course, talking about your IT department.

I know you are unhappy with your IT department. Not desperately unhappy – after all, it all sort of works – but you have that nagging feeling that things are not going nearly as well as they could do. Within IT, there is stubbornly high staff turnover with key knowledge walking out of the door every time. Your non-IT managers complain that project deadlines slip because IT are late. That they lost large amounts of money because crucial systems were down when they needed them most. That it seems to take forever to get anything done at all, and, that if IT delivers, it never seems to deliver quite the right thing. Your fellow board members argue that IT is the department with the poorest visibility of projects, and that half of these projects are probably unneccessary anyway.

Meanwhile, IT outsourcers are knocking on your door claiming to solve all these problems for you at virtually no cost (well, strictly speaking it is a small fortune but they have proof-by-powerpoint that it will all pay for itself by Q2/2012), and leave you scratching your head whether you would not be better off handing over your problems and sleeping easy with a nice IT Service Level Agreement under your pillow.

You are the boss – and hence no-one can can take the ultimate judgements and decisions off you, not even your CTO or Head Of Technology since he might be part of the problem as well as part of the solution. I know you are ambitious and tough and that you usually relish any challenge coming your way. But I see a hint of resignation in you, a grudging assumption that your IT department will simply never be quite like you want it to be.

Don’t give up just yet.

Can I ask a slightly stupid question? What exactly does your ideal world IT department look like? Or, in more practical terms, suppose you found an IT-savvy Genie in the Bottle, what would be your wish? Let me guess the conversation:

“Master, I shall grant you three wishes. May wisdom be with you.”

“Excellent! Remarkable! Can you make my IT department perfect?”

“Master, my power knows no bounds and is at your service. But do tell me: What is ‘perfect’ for you?”

“Well, I would like IT to deliver on budget, on time, every time.”

“Master – ”

“Sorry to interrupt. I would also like to see IT cost reduced by 30% next year, have all operational risks quantified and mitigated, helpdesk response times halved. Let’s have thorough visibility of projects and resources, and the ability to implement the IT aspects of any new business initiative within, say, one week. All decisions should fit into a consistent long-term strategy, and I want my board to participate in all major decisions. It would be good to be able to run the whole company from employees’ homes in case we have a terror scare. Oh, and I want IT to have everything in place to pass any audit with flying colours. Maybe we should become ISO 9001 cert… “

“Master?”

“What is it?”

“My humblest apologies. I have not granted wishes in a long time and have become rusty. Can I warm up with a simpler wish?”

“Like what?”

“May I suggest I make World Peace?”

Dear CEO, your goals are the right ones, and your demand for excellence in your company is a noble one. Yet, as much as you hate settling for second best in some respects, you must make it clear where your priorities are. Otherwise, your IT department becomes a Jack Of All Trades but Master Of None.

Put yourself in the shoes of an IT team lead somewhere in the department. He needs to make priority decisions every day. Should his team work –

on rebuilding the Head of Sales’ laptop ahead of his client visit, – or on producing a better version of Legal’s document capture software?

on rolling out more powerful software testing tools, – or on fixing the latest set of bugs your Finance department are held back by?

on producing project updates ahead of that all-important full board meeting tomorrow morning, – or on answering questions from your biggest client conducting a due diligence review?

How does he make those decisions? He cannot get the answers from you. He also cannot wait for an opinion from your CTO – the CTO should be working on strategic plans, after all, on negotiating major 3rd party agreements, on programme management, on IT organisational development, … . At the same time, whichever way this team lead jumps, he has a fundamental impact on the business.

You help him by making your overall priorities clear, by communicating what you care particularly deeply about, and, just as importantly, where you are prepared to settle for second best.

I know you put a lot of effort into working out the strategic direction of your company – which markets to go for and which ones to ignore, which customer relationships to invest in and which ones to leave as they are, whether to take the risks of aggressive expansion or to play it safe. Since virtually every aspect of your company depends on IT, your IT department reflects these decisions. Think of IT as a microcosm of the whole company. Without a foundation of clear and realistic priorities, it will drift aimlessly and unproductively. The one thing you do not need to worry about is translating business into technical priorities – that’s your CTO’s job.

I could leave you in peace now and let you mull over what I whispered into your ear. But a court jester would not be a court jester without carrying on a bit further, just enough to become a tad annoying.

It is a bit old-fashioned to talk about it in this way but – let’s face it, one of your jobs as head of the company is to build and enforce a Chain of Command. This is how you stamp your authority on the whole organisation.

You are more than familiar with the Chain of Command – issues of delegation, empowerment, allocating responsibility, choosing appropriate hierarchy levels and team sizes at each level. I do not have anything to add to this. What I do want to introduce you to, though, is a complementary concept: the Chain of Trust. The issues it addresses are not exclusive to your IT department but they are particularly burning there.

Let’s look at the hands-on end of the Chain of Trust: Suppose the senior database specialist in your company checks system messages one murky morning and realises that blocks within 45xxcompPass.log files for real-time transactional push replication to remote recovery instances are subtly compromised due to rwx permissions errors as a result of a backRTPacinGE.sh script failure. The guy knows two things: (a) the company could get into serious trouble over this (the risk of loosing live databases is distinctly unfunny ), and (b) no-one except him understands what exactly is going wrong on a technical level.

And so he talks to his direct boss, likely to be some infrastructure team lead with only superficial knowledge of the innards of an enterprise-level database system. Does our database specialist explain the issue to her in terms of 45xxcompPass.log and backRTPacinGE.sh? Of course not. He gives her a rough overview of the technical problem and then he and the team lead discuss how serious the issue is and how to control the business impact: What are the immediate risks, what is the resource impact of immediate measures as well as of fixing the underlying issues, what needs to be done to prevent similar problems occuring again, etc.

Can the team lead verify what her database specialist is telling her? Unless she has a spare database specialist in her bottom drawer – no, she cannot! Beyond a few plausibility checks (assuming she has the time) she essentially just has to trust the engineer.

Ok, let’s climb up the hierarchy. Our infrastructure team lead concludes that the database problem is serious enough to get the CTO involved (I assume that yours is not a vast corporation with another three hierarchy levels in between). Does she explain the issue to the CTO in terms of 45xxcompPass.log and backRTPacinGE.sh? Of course not – she does not even know these gory technical details. Does she explain the problem in terms of failed integrity checks and corrupt replication as it was relayed to her by her database specialist? Again, no. The CTO’s hands-on knowledge of databases is both slim and 20 years out of date. Instead, the infrastructure team lead explains which systems are at risk, which business processes they support, what action she recommends and what the impact on project deadlines is going to be.

Can the CTO verify that his infrastructure team lead is not telling complete porkies? In many cases he cannot – he essentially just has to trust her.

And if the CTO concludes that the issue is so serious it threatens the operation of the whole company he will pull you, the CEO, out of your sales call with the fateful words “We have a problem. I need to talk to you for a minute.”

Needless to say, you as CEO need to trust your CTO and hence the infrastructure team lead and ultimately the senior database specialist.

This is what I mean by Chain of Trust. No amount of organisational structure, processes, checks, monitoring, management information systems, etc. can replace the Chain of Trust. If it is broken anywhere you are like an aircraft pilot flying blind – unable to rely on what the tower tells you about the runway being clear.

You don’t just need an intact Chain of Trust when things go wrong with your IT systems. You need it every day. Project estimates and progress reports travel up the chain in exactly the same way, and so do e.g. assessments of third party products. I’ll say it again – processes, monitoring, organisational structures, audits and the like complement the Chain of Trust but cannot replace it. Not unless you want your IT department to turn into a bloated mess with engineers who only work there because they were not good enough to get a job elsewhere.

You would not be where you are without already asking the obvious question: How do you build (and maintain) the Chain of Trust in IT?

Well, it is rather old-fashioned and it is, I am sure, what your instinct tells you anyway: Trust grows between people. It needs to be built, earned, nurtured. It comes as part of a strong relationship. Hence, maybe surprisingly for an area in which technical skills are traditionally seen as more important than social competence, you need to insist that every link in the chain builds relationships based on mutual trust.

Actually, “mutual” is a crucial word. Trust cuts both ways. I gave you an upwards example but the downwards aspect is just as important: E.g. your CTO must be able to trust you to lead the business into the right strategic direction. The IT team leads must be able to trust the CTO that his technology vision will work out, that there is a career perspective for them, and that he is their advocate at board level and across the company. Another level down, individual engineers must be able to trust their team lead that their skills and effort are not wasted, that all those extra weekend hours will be rewarded, and that their excitement and pride in their work is shared.

If I was in the fortunate position of having a Genie at my command – I would wish for trust in IT at all levels and in both directions. It is not an easy wish (and the Genie might still try to wiggle out by mumbling something about world peace) but it is achievable, not least by putting the right people in the right places.

And once you have a Chain of Trust in place in your IT department, everything else becomes a lot easier. Yes, there will still be a lot of work to do maintaining optimum organisational structures and processes, weighing priorities in the face of limited resources, making sure people stay sharp rather than drifting into complacency – but success becomes achievable rather than a dream.

Well, I am afraid of overstaying my welcome, so I’ll stop here even though there is more I could whisper to you. Thanks for lending me your ear. Let me leave you with a recap of what I have been suggesting to you – it is really just two things:

Make your priorities clear
(this includes saying where you accept second best)