Depth vs Breadth

At my last few employers I used to blog regularly and encourage other executives to blog. I will be reproducing slightly modified versions of some of those blog posts here. This one, on the subject of when and how to expand skills and knowledge, was first published in early 2019.

Depth vs Breadth?

In this article I would like to share some thoughts about professional development, especially whether and when one should focus on increasing one’s depth of knowledge or breadth of knowledge.

Disclaimer: This is not anyone’s official policy. It’s a set of personal opinions that have guided me in my career, and that I’ve given as advice to people I’ve mentored from time to time. Consider it just that: advice from a mentor, for your consideration. Take it or leave it as you wish.

Career advice

I’ve written that I think mentoring others is an important responsibility of senior managers; and, indeed, of everyone. In a mentoring role, I often end up discussing career paths and personal development plans with people – often technical people, but not always.

One common topic is the kind of training or continuing education to take, or the kind of on-the-job learning to seek in job assignments. Should I work to deepen (or update) my skills in a given specialty, or put effort into learning a new one?

First, you should certainly do one or both of those things. The worst choice would be to do neither – to just stagnate, neither getting better at what you do nor learning something new. Don’t do that.

We need skilled experts, and whatever your field of expertise, you need to remain up to date. And when you are at the beginning of a career, you probably need to get better at your field before you start worrying about learning something new.

Nevertheless, I still feel that people tend to under-value breadth. We need specialists. But we don’t need everyone to be one.

To an Olympic Silver athlete, getting to Gold probably seems like the most important thing in life. I, on the other hand, would hire anyone who made the Olympic team to coach me in that sport in a heartbeat. They’re already so much better than me that I don’t need to hire a medalist, little less the Gold – and probably can’t afford them. In fact they’re probably too good to coach me – they may be out of touch with how bad someone can be at something, or they may find it frustrating to lower themselves to my level.

Outside elite sports, if you’re among the best in the world at doing something, for many purposes that’s probably good enough. With your remaining learning time, moving higher among the best is probably not worthwhile.

On the other hand, one problem we face all the time is change: something will happen that means the thing we’re good at is suddenly less relevant, and something else is suddenly important. For example, I’m an expert in a number of computer programming languages that haven’t been used for decades. Becoming even more expert in those would be a waste of time and energy.

(This reminds me of a time I was recruiting at a university campus for software development jobs.  I asked an applicant, “which programming languages are you familiar with?” and they responded, rather indignantly, “both of them!”  I didn’t ask what they thought the two programming languages in the world were, and we didn’t go much farther.)

Suppose you’re an expert in some field, and you can routinely score 97% on a skills evaluation. Further suppose that you have a training budget and some time to take training. Should you use that training budget and time to study more in your field, to move from scoring 97% to 98%? Or should you use that training time to learn something entirely new?

I think generally the latter. Be 97% in something and 70% (and rising) in another thing – that’s much more valuable (to society, to your employer, and to you) than being 98% in one thing.

We need experts in many fields. But in a world where change is so rapid and continuous, we need people with a wide range of skills. We need, even more, people who can learn new things quickly, and quickly become quite good at them.

In my mind, this is the real value of formal education: not just what you learned, but that you developed the skill of learning. Whatever you learned might well become obsolete – in the technology field it will definitely become obsolete. But the ability to learn new things will always be valuable.

Being really good at only one thing is:

  • Not only a waste – missing all the other things you could be good at;
  • It can also be an actual problem. If you’re only good at one thing, you might resist change, because change is a threat. I watched people who were really good at ATM networking protocol resist the move to IP, which was a threat, not being their field of expertise. Their expertise became obsolete, rather quickly. Those who adapted are now successful in a new field. Those who resisted to the end are not.

What’s in a name?

Gartner Consulting, a few years ago, offered a label for this concept that I found interesting. They suggested not using the word “generalist”, because that has come to mean (according to them) a person who can do many different things, but is not an expert in any of them. Instead, they coined the term “Versatilist”, defining this as “someone who is a specialist in a particular discipline, but can change to another role and become an expert there with ease” – someone who is, or can be, an expert in many fields, and can adopt to change. I think I like that concept.

Quotes that inspired me

I had this philosophy about professional development – about breadth vs depth – for many years before I even realized that it was a philosophy at all.

Then various quotes from literature caught my attention. Here are two: one short one long.

  • Miyamoto MusashiFrom Miyamoto Musashi: one of the greatest Samurai – who were, in turn, among the greatest warriors in history:

    A Samurai should cultivate a wide interest in the arts. Become acquainted with every art.

  • From Lazarus Long, a fictional hero in Time Enough for Love, by Robert Heinlein:"Time Enough for Love" book cover

    A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

    Maybe that is a little harsh, but Heinlein was famously a very prickly character,

Career path for a typical specialty worker

What’s this mean in practice? This is what I think is a pretty good career path for a typical worker with a specialty skill:

  • Start by being good at your field. Become skilled enough to be more than qualified at entry-­level, and then spend time increasing your depth.
    • Get better than “good enough”, get really good.
  • But then switch strategies.
    • Dedicate some effort to maintaining your current skill; and
    • Dedicate some effort to developing a new skill, quite different.
      • Not learning version 2 of a product where you’re already an expert in version 1.
      • Pick a new field, then develop depth again.
  • Repeat. Discover new capabilities and interests.
  • Most important:  learn something, frequently.  If it has been more than a couple of years since you took a challenging course or read a new manual or otherwise learned something new, you probably have a problem that should concern you.

This develops valuable breadth while retaining your expertise, and it hones your ability to handle world-shaking paradigm changes. Some of the things you know will be useful no matter what happens; and, more important, you are keeping alive your skills as a learner.

As an employer, I know I can hand you a new problem and you will figure it out. You’ll even enjoy it.

Blogging about Blogging

At my last few employers I used to blog regularly and encourage other executives to blog. I will be reproducing slightly modified versions of some of those blog posts here. This one, on the subject of executives blogging, was first published in 2014 and re-published in 2018.

Original Blog Post

To kick off my contribution to our blogging culture, I’m going to re-publish slightly modified versions of some of my old prototype blog posts. Here is the first.

Let’s Promote Internal Blogging

This is a blog post about blog posts. A meta-blogI never meta blog I didn’t like, if you will.

I’m going to (try to) publish some general personal and professional thoughts, in blog format, on a semi-regular basis.

Why am I doing this?

First, to experiment with and promote the use of various Social Software tools for informal communication, and to test their role in management communication. Although we have a Wiki (thriving in a restricted community), we don’t have an internal blogging culture, and I think we should. I’ve recently come from another department where, after some growing pains, blogging became a regular way that staff at all levels – from working level up to the Deputy Minister – shared their thoughts and opinions, and it enriched the organization in many ways.

Second, to exercise blogging tools, and identify technology and policy gaps. I believe social software is going to become an important communication tool for managers. (I understand it is already an important tool for technical and personal matters with many people; it takes time for technology to migrate up the seniority chain). I want first-hand experience with the various possible services and communications vehicles, and I want, when possible, to discover their inadequacies before our clients do.

In the case of blogging, for example, do we need a dedicated blogging tool, or is the web-publishing capability of the Wiki (which we need anyway) good enough? My previous experience leads me to believe that the Wiki alone isn’t enough – we need publication, aggregation, and subscription management capabilities that are specifically designed for blogs.

Some of the concepts I would like to explore include:

  • Is there value in having personal “what’s this person all about” commentary from senior management? Does it help staff relate, understand, and interact?
  • How does an executive share ideas, opinions, and experiences with a team in a way that is taken as just that – ideas and experiences from someone who has worked in a field for a long time – but is not taken as orders “from the boss”?

Why I Like Blogging

I write blog posts for the same reason I take notes that I will probably never read: It helps me organize my thoughts. I blog at home and occasionally write in a paper journal too. I’m not really doing either of those things with the expectation that anyone – even me – will ever read it; it just organizes and focuses the thought process. And I think that writing down thoughts that someone might read forces an internal quality-control process to start up, generating somewhat better thoughts.

As another reason, I’m a big fan of influence techniques. I would much rather plant thoughts, suggestions, and ideas that prompt people to discover their own solutions than simply give orders.

“Give as few orders as possible… once you have given orders on a subject, you must always give orders on that subject.”
           – Leto Atreides

I’ve always found it better to create the conditions, and provide clues and guidance, where people will make their own decisions, close enough to what I had in mind, and more motivating for those who did the creative work. I’m thinking the less formally structured, more personal nature of blogging might be conducive to this kind of guiding, shared-experience communication.

Finally, I find blogging to be a great tool for advice & mentoring: it’s a non-threatening way to provide coaching and advice to an anonymous audience. I can share thoughts and experiences such as “here is a process or approach that has worked well for me”, and others are free to think, “I’m going to try that” or, “what an idiot”, without embarrassment.

Why I Think Managers and Executives Should Blog

See the above. We all know (or should) that communication is critically important. Different people are best reached in different ways, and managers should use all the communication vehicles open to them.

It’s especially important when we consider demographics. Many senior managers and executives are “persons of an age”, while many new recruits are one or more generations younger.

We’re now hiring and leading people who

  • have had online threaded discussion capabilities their entire lives;
  • have never subscribed to a newspaper;
  • expect all web pages to have a “reader comments ” section;
  • don’t have a fixed, landline telephone;
  • elect politicians based on comments in FaceBook and Twitter.

Social media is how a growing segment of the population, especially the kind of workforce we are trying to attract and retain, communicates. Senior management needs to learn to use those tools.

Issues Needing Attention

There are, of course, some concerns and issues that need attention. I consider these just that – issues that need attention, not reasons why we should not do this. I’ll ask various policy centres to look into these. Some examples include:

  • What is the official records status of blogged communications such as this entry? Is what I’m typing right now an official record? (I think not) An official communiqué? Is saying something in a blog post an official decision? (No.) Guidelines are needed on the things for which blogging is or is not an appropriate communication vehicle.
  • What kind of information management is appropriate? Is this post subject to ATIP? Should it be in the records management system? Classified how?
  • How do Official Language requirements apply? Can people blog in the language of their choice, and can commenters reply in the language of their choice? (Yes to both.) Do blog posts have to be in both official languages? (I don’t know but that is the practice we are establishing.) Do people who want to comment on blog posts have to do so in both official languages? (l hope not – it would reduce the spontaneity of comments.)
  • How do we handle Security and Need-to-Know concerns? There are certainly people – possibly a lot of people – who should not be blogging about what they do, even on an internal secure forum. But I can’t accept the notion that, because of those legitimate cases, no one should blog about anything.

There’s nothing like a real test case to help work through some of these important issues.

I applaud my colleagues who have started blogging, and I encourage others to do so.

– Richard


Thoughts on Mentors and Mentoring

At my last few employers I used to blog regularly and encourage other executives to blog. I will be reproducing slightly modified versions of some of those blog posts here. This one, on the subject of Mentoring, was first published in 2014 and re-published in 2018.

Original post follows

I thought I’d share some thoughts on a topic that has been the subject of several conversations recently: Mentors.

Most people would benefit from having a mentor, and many people would benefit from being one.

What follows are my thoughts on what I think is an important part of management, not specifically on the department’s mentoring program.

… which makes me think it’s worth taking a moment to define what I mean by the term mentor, because I don’t mean just specific processes that may exist for formally having a mentor as part of a professional development program, although those programs are an important part of mentoring.

Graphic showing various aspects of coaching

When I use the term “Mentor”, I mean any process of establishing a trusted confidant relationship with someone with whom you can discuss career and life issues and from whom you can receive feedback or advice. The mentor is usually assumed to be senior to you (in age, rank, or experience) but that’s not at all necessary – all that’s necessary is that they have some experience, skill, knowledge, or perspective that you lack, and that they’ re willing to discuss it. I do think, however, that it’s best that your mentor not be in the chain-of-command above you, otherwise the line between giving advice and giving direction gets blurred and confusing.

I sometimes encounter people with the concern that, “so-and-so would be a great mentor except for this one aspect of their personality that I dislike.”

This is one of the key things about making good use of a mentor: realizing that it is not about copying the person in question, and most certainly not about copying everything about them. Learn their perspective or habits on things, then take what you like and ignore what you don’t.

It reminds me of the theme of a classic set of old Jokes, which go along the lines of

“go meet so-and-so, find out what they would do, and then don’t do that.”

Those are good jokes but probably not useful advice because not doing something is not an action (or not a usefully specific one), and not doing a thing is no guarantee that you will avoid an outcome that happened to someone who did that thing. So, plan to use your mentor to help you work out what you’re going to do, not what you’re going to not do.

Since I’m emphasizing that the relationship doesn’t have to be formalized and bureaucratic, maybe I’m using the wrong word. Maybe I mean muse or role model or inspiration.

In fact, they don’t even have to know they’re your role model – you can observe and learn from someone without their knowledge. That, I think, would be outside any reasonable definition of “mentor”. Maybe the word “mentor” should at least be restricted to the cases where the coach is a knowing and willing participant in the relationship. Anyway, mentor will do.

Use Mentors Well

Two people having an in-person discussion

Of course, just having a mentor won’t actually do much for you. You need to use the mentor. Some thoughts on using your mentor well:

  1. Build a Relationship: Ask the person in question if they’re willing to be your mentor. They’ll probably be flattered, they’ll probably say yes, and they’ll probably help set some expectations about how available they can be and what they may or may not be willing to discuss. As part of this conversation, be prepared to explain “why them?” What are you hoping they can do for you?
  2. Expect confidentiality, and give it in return: It goes without saying that you’re expecting your conversations with your mentor to be confidential – but that means you need to do the same, and not share with others things they share with you unless that’s clearly OK.
  3. Someone being your mentor doesn’t make your career development their problem. Don’t sit back and wait for them to call you with advice – you need to take the initiative to book meetings, bring up topics, and ask for help and advice. (As an exception, they may have agreed to watch for certain types of opportunities for you, but you initiated that and it needs to be clearly understood.)
  4. Have regular meetings and give them advance warning, if possible, of what you’d like to discuss so they have time to prepare thoughts. But expect schedule pressure – frequent rescheduling, etc. Mentoring you is competing with operational pressures for the use of their time. A person with few demands on their time, who is readily available, and whose schedule never changes is probably not the one you want as a mentor.
  5. Don’t necessarily expect advice. Sometimes just having an intelligent person listen attentively, and perhaps ask some clarifying questions, while you describe a situation you’re struggling with is all you need.

Be a Mentor

Mentor/Mentee conversing

On the other side of the coin, I can’t stress enough how valuable it is to be a mentor when you can

  • Managers: it’s your job.
  • Non -managers who are experts at something: it’s your responsibility.
  • And everyone: it’s good for you Ask anyone who teaches or coaches, especially if they teach adults, and they’ll tell you they learn as much or more from the relationships as their students.

Senior and experienced people are probably already mentors and good at it. For people who are new to being a mentor, I offer some thoughts on this role:

  1. Establish ground rules. What can your mentee (is that a word?) expect from you? Promise confidentiality but not concealment – if you learn something that you must deal with, you don’t want to have promised that you won’t.
  2. What you’re initially offering is availability not advice. Your mentee may not need anything more than an audience or a sounding board.
  3. Listen actively. Ask clarifying questions, and ask questions that may lead the mentee to think of their situation in different ways.
  4. Offer advice if asked. If not asked, ask for permission first.
  5. Make it personal. They came to you for a reason. What has happened to you that is relevant, what have you done, what might you do in this situation?
  6. Don’t mess up the chain of command. Don’t let mentoring meetings become out-of-band channels for business decisions. You are offering advice and guidance for employee development, not influence peddling for business decisions. This is why I generally discourage mentors from being in the reporting line above their mentees – it’s too easy for advice to be taken as overriding an intermediate manager’s direction.

Things I’ve Learned from Mentors

I’ve had some good mentors who have made a big difference to my life, more to follow.

Project Risk Analysis

Consulting firm The Right Door Consulting & Solutions occasionally publishes white papers written by their consultants. A couple of white papers I wrote were included in their collection and distributed at a recent government management conference. The following is one of these. (The version distributed at the conference is available here.)

Don’t Miss Out on a Valuable Management Tool

If you fill out a “project risk register” only because it is required by some governance process, you’re missing a powerful investment analysis and planning tool and missing the chance to

  • Choose among different project approaches with different risk profiles;
  • See at a glance which risks you should be most worried about;
  • Choose what to do about risks, and calculate the ROI of alternative mitigations;
  • Invest in readiness to react effectively if things do go wrong.

Make a list of risks to your project and estimate the probability and impact of each. In your risk analysis, pay attention to these points:

  • Be sure you analyse probability and impact independently. Impact, especially if lives are affected, can be so emotive that it tends to affect assessment of probability. I’ve seen risks that are very unlikely, but would result in death, listed as “medium” or “high” probability. Yes, if the thing happens, it would be really bad. But that should not change your assessment of its probability, or you will overreact and poorly distribute resources.
  • Quantify your probability and impact ratings using historical data and research. This avoids subjective debates and allows you to budget and calculate ROI on mitigations.
    • E.g. A risk with $1M impact and 20% probability has an expected cost of $1M x 20% = $200K. Compare the cost and effect of proposed mitigations to the expected cost of the mitigated risk. Is the mitigation worth it?

Analysing possible mitigations is an important part of the risk analysis process — indeed it’s the point of the process. Consider:

  • Many mitigation plans I have seen focus only on reducing the probability of risks, and often miss addressing impact. Seek mitigations for both.
    • For example, consider protecting a building from fire. Using fireproof materials would mitigate the probability of a fire, while using sprinklers would mitigate the impact. Some things, such as early smoke detection equipment, could be argued to do both.
  • Re-chart what your risks would look like if the proposed mitigations were applied. Make sure that every table and chart is clearly labeled “unmitigated” or “mitigated”.
  • Good mitigation is rarely free. Fund it — risk mitigation is part of the cost of the project.
    • In the above example, fireproof building materials are probably much more expensive than sprinklers. But sprinklers don’t trigger until there is a fire, so choosing them is a decision to accept a certain amount of damage, which will also have a cost. Include all these costs in your analysis.
  • Mitigation will probably not reduce risk to zero. What remains, “residual risk”, should be accepted by an authorized person as part of deciding on that risk management plan.

If there are several project implementation options, risk-analyse and compare the costs and residual risks of each alternative. This information will help you choose the best approach.

Identify and analysis multiple possible mitigations to each risk. Choose those that give a positive return by costing less than the reduction in residual risk cost they generate.

For example, imagine we’re considering implementing an AI-backed Chatbot to interact with clients on our web site. We might identify the following risks.

 RiskUnmitigated ProbabilityUnmitigated Impact
1Lack of skilled resourcesMediumHigh
2Lost opportunities to redirect or upsellMediumLow
3Client upset when they learn they’re talking to AIMediumMedium
4Chatbot gives wrong or embarrassing repliesLowHigh

These can be clearly compared on a “heat map” chart. Simple coloured cells in a 3×3 or 5×5 matrix are usually good enough for our purposes. What to worry about (and what not to) stands out clearly.

In this example, we clearly need to address Risk #1, and can ignore Risk #2. Risks #3 and #4 need analysis and consideration, and you might or might not choose to address them depending on time and resources.

Next, identify how we could reduce the selected risks and what the resulting mitigated risks would look like.

1MedHiSet up contracting supply arrangementLowHi
2MedLowProgram chatbot to collect follow-up contact infoLowLow
3MedMedChatbot clearly self-identifies, offers humanMedLow
4LowHi5-second delay, human review in “probation period”LowerHi

This kind of risk analysis is relatively simple yet is a powerful management and communication tool. Do it because it helps you, not merely to comply with some rule.

IT Funding Models

Consulting firm The Right Door Consulting & Solutions occasionally publishes white papers written by their consultants. A couple of white papers I wrote were included in their collection and distributed at a recent government management conference. The following is the long version of one of these. (The formatted versions are available here: the short version that was handed out, and the longer version reproduced below.)

Use the right mix of funding options for your IT organization

Many years ago, I inherited an IT organization with a funding problem: they were coming to the end of a multi-year, but temporary, allocation of funding. Unfortunately, this temporary funding had been used to enter into ongoing liabilities, such as enterprise software licensing and hiring indeterminate staff. (Hint: don’t do this.) This prompted us to consider the various ways that mandatory and optional services could be funded in an organization, and how to allocate available funding in the most effective and justifiable way.

It is worth thinking about how your IT organization is funded. There are probably options you haven’t considered, and a mix of funding models can improve your financial stability, your client satisfaction, and the quality of your portfolio management.


Most IT organizations have a dedicated budget – a fixed portion of their organization’s overall permanent budget. This is a form of internal taxation: allocating a department’s budget is a zero-sum game, so the “tax” is funding that the organization allocated to the IT group instead of to other branches. It would be the same as if the IT group had no budget of its own, but then all the other branches in the department had a mandatory tax clawed out of their budgets and given to the IT group.

Thinking about a dedicated branch budget as a tax is useful, as it prompts us to ask how the tax is allocated (i.e. who didn’t get the funding that went to IT). Was it allocated according to the number of staff in the other branches, their budget size, or some measure of their IT consumption? Chances are that no such analysis took place – the department simply allocated “the funding IT needs” then allocated the rest to the other branches.

Taxation is a suitable way to fund certain things. First among these is what economics calls “public goods” – services that benefit everyone in a community, not just certain individuals. The classic example is street lighting, which benefits everyone, not just drivers. Many IT services are public goods – email, the telephone system, and cross-enterprise applications such as finance and payroll. All the hidden infrastructure that makes these things possible (e.g. the data centre) is also in this class.

Taxation is a good way to pay for mandatory programs, especially those that are unpopular or invisible, and is an appropriate way to pass on costs that you are receiving, from suppliers, as tax – for example, enterprise-wide software licensing.

However, there are disadvantages to a taxation model. The most obvious is that tax is unfair to non-beneficiaries. If an IT system is built and operated for the exclusive benefit of one branch in a department, making all the branches share in the cost will seem unfair.

Tax also discourages resource conservation, promoting waste. We have all known (or been), an apartment dweller who said, “Why turn the lights off? Power is included in the rent.” If IT clients pay a fixed amount for a service, whether they use it or not, there is no incentive to be thoughtful about what resources they consume. Frivolous and wasteful network usage is a common symptom of this problem. “If I pay a fixed amount for the network, whether I use it or not, why not stream ‘Dancing with the Stars’?”

Tax is also not very agile. Because it is hard to quickly add funding and the staff to spend it if additional services are urgently needed, and hard to quickly release funding if there is surplus, taxation promotes large, long-term enterprise projects. Not that that is a bad thing – but it doesn’t encourage or facilitate short-term quick wins.

Finally, a tax-funded organization should be prepared for intense scrutiny from their taxed base. Clients will want to know where their money is going and that they are getting good value. A tax-funded organization needs good bookkeeping, reporting, and transparency.


Cost-recovery is the other extreme on the scale. For example, look at the IT Consulting industry: you pay a well-defined rate for consultants, who will do exactly what you pay for and nothing more. You don’t get work you didn’t pay for, and you don’t pay for work you didn’t get.

This model can be applied to an internal IT organization. In its pure form, the IT organization would have no base budget, and would bill client branches for the total cost of all the work they do. Clients would pay the total cost of new projects done for their benefit and would pay a share of the cost of consumable services (e.g. network) based on usage.

The advantage of cost recovery is that it promotes better-informed business decisions. Client branches get what they are willing to pay for, and they are fully aware of the price of their decisions1I heard an IT group say, “if we charge the client the full cost of the service, including the ongoing operating cost, they might decide it’s too expensive and not go ahead”. To which I would respond, “Good! If they can’t afford it, they shouldn’t go ahead. If you can’t afford the car insurance, you can’t afford the car.”. Cost recovery also encourages conservation, since clients will use only what they are willing to pay for, which usually translates into using only what brings positive value.

There are also disadvantages to a pure cost-recovery model. On the other side of the above coin, cost-recovery might discourage experimentation and automation, since the innovator knows they’ll have to pay for the new service. Such concerns are often misinformed, as automation is often cheaper than the manual process it replaces, but the bill for automation is overt, while the cost of manual processes is distributed and hidden, and thus often overlooked and mis-labeled as “free”.

In a cost recovery system, we must prorate shared infrastructure and services. It wouldn’t be fair to bill the cost of a new data centre to the next client whose application request caused us to build one. We need to calculate the cost of the shared foundation and determine a fair way to add a share of it to each client’s bill.

This billing for “total cost” tends to make clients think that our costs are too high. They compare our proposed price for a new application to the number they saw on a software box at Best Buy, or how long their co-op student says it would take to build. They aren’t taking into account the data centre, network, foundation software, help line, power systems, operations staff overtime, etc.

Cost recovery also implies that the services in question are optional. If there is a bill for the service then, surely, I can say “no thanks” and choose not to purchase it. Cost recovery is a poor way to fund mandatory services. “Thanks, but I’ll just take the web application, not the IT Security option.”

Staffing a cost-recovered IT organization is difficult. Clients expect to be able to have anything they are willing to pay for, but this requires that there be staff available to do the work. Does the IT group staff for the demand peaks or the demand lows? How does it pay staff during periods of low demand, or have enough workers available during peaks?

Cost recovery also implies that the IT organization is just a competitive supplier – that the client can “price shop” and go elsewhere for their services. This is probably not allowed – IT is, in fact, a cost-recovering monopoly. Those are usually unpopular.

Finally, there is a cost for cost recovery. We need a billing system, cost transfer transactions, debt collectors, and additional budget planning and complexity. We need to include the cost of cost recovery in the cost we recover, and we need to be careful that we don’t simply transfer the burden of cost recovery to our internal finance group. We must set the system in place in partnership with them, and making sure that the budgeting transaction size and period are set appropriately.


As you might expect, we can get some of the advantages and avoid some of the disadvantages of both models by combining them: pay for foundation and enterprise-wide services with tax, and cost-recover services provided to specific clients.

For example, we could tax-fund the data centre, network, help line, storage, and database and application server layers, as well as enterprise-wide applications such as payroll, finance, and email, and then cost-recover development and operation of services for specific clients.

We can also simulate cost recovery without the burden of financial transactions. Stay with a fully tax-funded IT organization, but don’t allocate all of the funded resources. Set aside a sizeable capability and let clients “purchase” work from that capability by spending “IT Bucks” – some kind of token purchasing power that is corporately-calculated and allocated to the client groups. To have the desired effect on business planning, the “IT Bucks” need to be multi-year and transferable, allowing clients to save, conserve, and barter with them.

Example: Shadow IT and the Gold Standard

Any time resources or funding prevents the IT group from doing everything clients want, “shadow IT” may pop up – clients doing IT themselves because the IT group can’t or won’t. This is often a nightmare for the IT group because of the effect of the non-professionally-done IT on the enterprise environment.

One partner organization that I worked with several years ago took on the issues of shadow IT and IT funding in a single approach. They redefined the IT group’s primary role as to deploy and support application development capability – from the data centre all the way up the stack to the development environment, programming language, workflow engines, and a set of services such as storage, data base, user interface, user management, etc. Those services were well-defined, integrated, managed, secured, and accredited.

The IT group maintained a small cadre of business application developers available, on a cost-recovered basis, to build applications upon those services — not enough for all demand, but a number that was sustainable even in the low-demand seasons. Anyone else — client organizations, students, contractors — was also allowed to develop their own applications as long as they used those services and only those services.

Foundation services were pre-approved architecturally and accredited for security and end-user branches were not allowed to build or use competing foundation or services, or to omit mandatory ones such as security audit. An application built on preapproved services with preapproved tools was automatically approved for operation, including accreditation.

Clients with funds and no people would buy application development from IT, while clients with skilled people might prefer to build their own applications. The foundation was centrally-supported, while client-built applications were supported by the client, or support by IT could be negotiated and purchased in long-term deals.


The process for allocating funding for your IT organization is an important consideration, and can affect how projects are selected and prioritized, and what business decisions clients make. Funding models deserve attention, and even occasional re-consideration.