I’ve been working on a document for the last twenty years, consolidating my notes from presentations that I thought were especially good or bad into a set of advice on presenting well. This has become my own approach to making presentations, and it works well for me. I’m making the document available publicly here, in case it can help anyone with an idea or two to improve their own presentation skills.
The document is free for personal use, with some restrictions. Here is an excerpt from the “usage rights” page:
Use and Distribution Rights
This document may be used (unmodified), copied, and distributed free under the following conditions:
You may make personal, non-commercial use only.
You are granted the right to use, no right to modify.
Author retains all ownership rights.
You may not sell this document, distribute it through a service that charges access fees, or use it in a course or service that charges fees.
The file must be distributed in its entirety with no changes or subsetting.
This rights paragraph must be included in the file.
Contact me to arrange licensing for any commercial uses including
For-profit resale or inclusion in collections;
Distribution via any aggregation system that requires a membership fee;
Use in any course or service that charges a fee;
Right to modify;
Right to subset or create derivative works.
Click here to download the current version of this document in PDF format.
“Elevator Speeches” are an important tool in management. By chance, you find yourself in an elevator with a senior decision maker for 30 seconds. Can you do something useful with that time? You should have an “elevator speech” ready, or be capable of generating one instantly, for several topics, such as:
Who are you?
What do you do?
What are you working on?
How’s it going?
Anything you’d like me to know?
Do you think we could problem-or-concept-you’ve-never-heard-of-before-this-moment? What would it take?
This post talks about an important “elevator response” skill – quickly estimating costs by using rules-of-thumb worked out in advance. It uses Information Technology investment as the working example, but the concepts apply equally well to other fields, although you may need to recalculate some of the rules-of-thumb used.
You can develop estimates that are accurate within a certain range, and that are better than guesses, in a few seconds if you remember some rules of thumb, and if you practice and refine your technique.
Detailed cost analysis and proposal-writing is important, and takes time, and there is definitely a place for it. But fast estimates are used to make high-level strategic decisions more often than you might realize. You should develop this skill.
If this hasn’t happened to you, it will.
You follow another person onto the elevator and, as the doors close, you realize the other person is your Deputy Minister (private sector: company President), on their way up to the board room on the top floor.
The deputy says hello and you introduce yourself. Then,
So, what do you do?
… Oh, you’re the leader of the IT development organization? Great. I’m on my way to a meeting right now, and it just occurred to me that it might come up that we need a system to do requirement-you’ve-never-heard-of-before. What would that cost?
I can send a business analyst to get your requirements right away, and have an estimate for you by end of week.
No, I’m meeting the Minister now. What’s your best estimate, now?
What often happens next
A number of reactions to this high-pressure situation are rather common, including, “No response”, “Rote inflated response”, and “Poorly informed lowball response”. Here’s how those typically go:
You can think of all kinds of things that you don’t know right now. You don’t want to be anything but exact and perfect. So, you respond, “Sorry, Deputy, there’s no way to give you an estimate without going through our requirements and analysis process; we have to make sure we don’t miss anything.”
The Deputy says, “OK, thanks anyway”. When the opportunity arises later in the day, they remain silent, and the opportunity is lost. The Deputy remembers that you were unable or unwilling to do a fast estimate.
Rote inflated response
You can think of all kinds of things that you don’t know right now. You’re terrified that you’ll be held to an estimate that is too low and not have the time or funds to succeed; but “no one was ever fired for having money left over”. So, you “take a conservative guess then double it”. Essentially, you’re going to ask for as much as you think you can get away with. You can return whatever is left over at year-end, or use it for something else.
Most small systems probably cost $150K so you say, “It might be $300,000, and $100,000 per year ongoing? Maybe more.” The inflection at the end of the sentence implies the “question mark”, re-enforcing that you’re really not sure.
The Deputy responds, “Really? Wow. OK.” Again, they don’t take the idea forward – it’s more money than they’re willing to invest – and the opportunity is lost. Or, even worse, they propose the idea, and are not believed. Your group’s reputation for inflated estimates increases.
Poorly-informed Lowball response
You can think of all kinds of things that you don’t know right now, but you hate to pass up an opportunity to get new work. You’re terrified that if you don’t get awarded this project, it might go to someone else and you’ll lose control. You know they sell a software package that does something like this at Best Buy for about $350 so it must cost something like that to buy or build. You’d need a computer ($3000 at Best Buy) and a couple of days to install it.
So, you respond, “Maybe $5000?”. (Again the spoken question mark.)
And the deputy responds, “Fantastic, thanks! Assume we’re a ‘go’ on this.”
Half a year later, a note written by the Deputy on a returned briefing note says, “You need another $50K and to hire another person? You said $5K!” By the way, it’s performance review season.
What your response could be
You think for a few seconds while the elevator floor indicator ticks by: 3… 4… 5. Then, taking a deep breath, you say,
This is only an estimate – about $65K one time – that’s $35K salary and $30k capital – then $20K expense ongoing starting in year 2 for as long as the system is in use. There’d also be a small cost – around $10K – to decommission it at end-of-life. I’d need to get back to you on what current project would be sidelined to do this with existing staff. We could avoid that by using a consultant instead, for about $30K more. Don’t forget that the users might require training, and there would be an opportunity cost to take them off their jobs for that.
I could explain where those estimates came from if you like, or could get back to you with a more detailed analysis in a couple of days.
Looking thoughtful, the Deputy responds, “Thanks, that’s enough detail for now. I’ll get back to you if I need to follow up.” The project gets approved, and the actual costs come in within about 15% of this estimate. You’ve built up some trust in your estimating skills.
Where did those numbers come from?
Those figures were not fiction and they were not a guess. They were an estimate based on sound and defendable reasoning.
The labour estimate assumed this simple system would take one developer 3 months. The 3 months came from your experience with small systems. (Know how many months small, medium, and large systems usually take.) $500 per day for 60 days gave us the $30,000. (See below for where the $500/day figure came from.)
The capital cost assumed that we need to run this system on a server costing $10K. (Know your standard server costs!). We’d need 3 – development, production, and testing.
The ongoing expense assumed 1 day every 2 weeks from an employee (which is 10% of a $100K person, for $10K), and assumed 20% of the server cost annually for renewal, for an extra $6K. We rounded the $16K up to $20K. (20% of purchase cost is a standard rule-of-thumb for annual maintenance costs of IT equipment.)
10% of purchase cost is a good rule-of-thumb estimate for the decommissioning of a system at end-of-life.
Do the homework for your domain
You can do estimates like that in a few seconds if you already know the various rule-of-thumb estimation values involved. These might be different for your field – but you can work them out, and you should.
For labour, know how long typical tasks take, and know roughly what your staff costs are.
In this example, we’re talking about technically-skilled professional staff (CS or ENG). CS salaries range from $66K to $124K – but it’s a bell-curve since most of your staff are in the middle of this range. (i.e. you may have a few CS-01s and a few CS-05s, but most of your staff are probably mid-range, like CS-03.) If we do some kind of weighted average, we get an average salary of $93K. Add the 25% “benefits tax” that our finance group usually includes in calculating salary budgets, and we get about $117K as the annual loaded labour rate for a CS.
Do some simple math and it turns out that there are about 112,000 minutes in a standard work-year. That’s really close to the 117,000 dollars above, so the loaded labour rate for your average technical person is $1.04 per minute, or “a dollar a minute” to a pretty good approximation. That’s about $60 per hour, and just under $500 per day. Double that if you are using contractors – you are paying extra for their profit margin, their administration costs, and for not making a lifelong employment commitment.
$1 per minute for professional staff is a useful rule-of-thumb estimator for many purposes. Use $2 per minute for Executive staff.
As an added benefit, this is useful to help you keep an eye on how long some decisions take. If 5 technical people spend an hour deliberating, that’s 5 x 60 = $300 in labour costs. 5 executives: $600. Was that $600 spent making a $200 decision?
If your projects make heavy use of staff in a very different salary range, repeat the calculations above and know your per-minute, hourly, and daily cost for average staff.
If you are an IT manager, it’s important you know your average server cost; and don’t forget to allow for more than one if you need a development environment or spares.
If you are virtualized, or using Cloud, know the average cost to add an application, instead of pricing servers. If you are cloud-based, your cost will be expense instead of capital, and there won’t be separate “ongoing” maintenance or decommissioning costs – those are included in the Cloud service fee and are, in fact, a big part of the reason for using the cloud.
If you are not in the IT field, know what other equipment costs are often associated with your work. Office space? Vehicles? Specialized equipment? You might even have no standard equipment costs.
Grow your estimating skills using feedback
Do an estimate like this at the start of every project, even if you are not being cornered in an elevator. Do it yourself, with little or no research, before your experts do detailed costing and planning and fill your head with distracting details.
Then, after every project, compare what actually happened to your estimate. Of course it was wrong – it would be surprising if it wasn’t. But was it spectacularly or dangerously wrong? If so, why? What did you forget or estimate incorrectly? Learn and improve.
Important strategic direction-setting decisions are made with very coarse estimates all the time. Learn to use this process to your advantage by feeding it with good data.
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 was intended to be a little “tongue-in-cheek” because I had a bit of a reputation as a nerd. It discusses leadership lessons we can learn from watching Star Trek. To my surprise, it turned out to be, by far, the most popular blog post I wrote, and received, by far, the most comments.
Science Fiction Confession
I have a confession: I’m kind of a science-fiction nerd. I certainly have that reputation among my colleagues and get good-natured jokes and ribbing. Sometimes I re-enforce this by “stepping in it”. But, come on, when someone misidentifies a Jawa as an Ewok, or incorrectly mixes Star Trek and Star Wars metaphors, what is a person supposed to do?
Among the Sci-Fi I like, I like Star Trek. I used to rush home from school to catch the new episodes of the original series, and I was thrilled when the series rebooted years later.
I like STNG
My favourite Star Trek series was The Next Generation – known to fans as STNG. I liked it best, and I’m going to discuss some of the aspects I liked that I think are relevant to our work here. I’ll leave the pure fiction fandom for social conversation times.
First, for people familiar with the Star Trek franchise and the STNG series, when I say, “I like STNG”, I mean the “real” episodes. Not the first season, except for how happy I was that anything returned at all. (It’s amazing that there was a second season considering how bad the first was.) And not the silly episodes like the holodeck adventures – I always assumed that those were fillers during creative lapses and during the writers’ strike, although the holodeck episodes in the Deep Space Nine series were worse.
Second, for everyone else: yes, I know it’s fiction. That doesn’t bother me. We can appreciate good writing and can learn from and admire behaviours exemplified in good fiction. And I think the best STNG episodes were good fiction.
I like the world view Star Trek, especially STNG, presented, but my current comments will be limited to ways that world view applies to leadership and technology.
The senior leaders in the series demonstrate a variety of leadership characteristics – some good, some bad. We can learn from all of them – but I’ll highlight a few of the good characteristics here.
One of the guiding principles for the lead characters is to have a clear set of values, and to stay true to them. Their employer, The Federation, itself has a simple value statement – the “prime directive” which, interestingly, guides some episodes but is deliberately set aside in other episodes in favour of the personal values of the leaders. Captain Picard seems to have two personal values that override all other concerns.
One is “truth” – in several episodes he emphasizes that nothing is more important than seeking and revealing the truth, and he forgives serious transgressions when staff are open and truthful about them. An episode providing good example of this is “the Pegasus”, which ends with Picard saying to his first officer (while releasing him from confinement),
“When the moment came to make a decision, you made the right one. You chose to tell the truth and face the consequences. So long as you can still do that, then you deserve to wear that uniform. And I will still be proud to have you as my First Officer”.
Another good example is “The First Duty”, with
“The first duty of every Starfleet officer is to the truth… it is the guiding principle on which Starfleet is based.”
(It’s hard for me to recommend that episode as I didn’t like the Wesley Crusher character, but it is a good story. Here’s the scene.)
The other is the fair and ethical treatment of people. While this is shown in many episodes, I particularly like a couple that involve Commander Data. I like “the Offspring”, where Picard disobeys an order, stating,
“Order a man to hand his child over to the state? Not while I’m his Captain”.
In “The Measure of a Man” Guinan guides Picard to realize that the Federation’s attempt to define Commander Data (a sentient machine) as “property” has deeper implications:
“. . . Whole generations of disposable people.”
“You’re talking about slavery.”
“I think that’s a little harsh.”
“I don’t think that’s a little harsh, I think that’s the truth.”
Strategy vs implementation
The leaders in the series do a good job of separating strategy formulation from implementation. The hard part, and where their attention goes, is in deciding what to do in a given situation. Actually doing it, once the decision is made, is only work, and is facilitated by their technology.
Roles and the chain of command
The Canadian public service has the unofficial slogan, “Fearless Advice, Loyal Implementation”. Many STNG episodes demonstrate these two roles: when options are being sought, provide advice, and argue for your point of view; once a decision is made, execute that decision.
While there are many episodes where this is demonstrated as a matter of routine procedure, the episode “Gambit, Part II” addresses it directly, when Acting Captain Data reprimands Worf. It’s also a great example of a manager dealing with a performance problem immediately, firmly, clearly, and in private.
Communicate in the audience’s language
The series contains many examples of the importance of communication, especially of adapting it to the circumstances and of speaking to each audience in language they will understand. One is firm – even threatening – with bullies and Klingons, and one quotes regulations to hyper-bureaucrats. The best example of this is the episode “Darmok”, where the entire episode is based on the concept of a species whose language uses a completely unfamiliar structure, and learning to communicate with them.
Finally, a technology leader can hardly talk about Star Trek without talking about their technology. Some of their technology (e.g. teleportation and faster-than-light travel) is forbidden by the laws of physics as we presently understand them. Most science fiction writing has this problem – there would be no aliens or interstellar travel in stories without some way to violate these laws. While the series depends on these “forbidden” technologies, I like that the writing acknowledges this dilemma in subtle ways.
For example, a physical rule called the Heisenberg Uncertainty Principle prohibits macro-scale matter teleportation such as the Star Trek “transporters”. Clearly the writers are aware of this, because several episodes make passing reference to a system component called “the Heisenberg Compensators”, which presumably addresses this. I like that gesture.
However, a lot of their technology is not impossible in that sense – it’s only hard, or expensive, or something we don’t know how to do yet, but that they have figured out. The underlying premise is that they have a vast, almost unlimited energy source available. What could you do with nearly unlimited quantities of energy? Quite a lot.
Their technology, and its extreme adaptability, is enabled by highly effective system architecture. A real-time graphic display shows the operation of systems, at any level of detail. Interfaces between systems and components are standardized, so you can implement new interactions between systems merely by sketching what you want on the interactive display. “Let’s route the output of this system through this processor, then feed it into this system over here”. There are no concerns about how to do that – you draw the desired flow of energy or information and it just happens.
When I first watched these shows, this kind of flexible system interaction seemed like a distant future vision, probably fiction. Now, however, Cloud computing is close to making this a reality.
The series also contains numerous important nods to security. The ease of accessibility and connectivity of systems also presents a security vulnerability, and this vulnerability is the basis of some episodes. Hacking, viruses, authentication, encryption, and privilege management are all key to various stories. This is a good reminder to get the security right.
STNG is replaying on a variety of networks – Netflix, Crave, etc. Skip the first season (except as the basis for certain drinking games) but have a look at some of the episodes mentioned above. Even if you don’t become a fan, there are good lessons to be found.
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.
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 on 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.
From 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:
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.
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.
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.
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
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:
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?
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.
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.)
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.
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
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:
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.
What you’re initially offering is availability not advice. Your mentee may not need anything more than an audience or a sounding board.
Listen actively. Ask clarifying questions, and ask questions that may lead the mentee to think of their situation in different ways.
Offer advice if asked. If not asked, ask for permission first.
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?
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.