Transcripts
1. Intro: Hey everyone, I'm Andre. And today I want to talk
to you about numbers. Specifically, how
do we use numbers to communicate and
present persuasively? What numbers to use,
how to use them. I have 20 years of experience
in software manager. I've lead business units
of multiple hundreds. And for the past seven years, I've ran my own leadership and soft skills consultancy for the IT industry in
many industries in many jobs will use numbers
to explain things, to present things,
to ask for things. But despite what
people sometimes say, the numbers do not always
speak for themselves, there's a way to use the relevant numbers
to make them more compelling and make
our presentations and pitches more persuasive. This course is about that. So if you're a
professional who uses numbers to communicate
things in your job. This course is for you. The course has four
chapters and it includes several examples which I
built from the basic nuts. So effective way
of using numbers. And I incrementally improve them to their best
possible version, explaining at every
step why and what I do. I'm also going to give you a four questions framework
for you to use when you decide what numbers to communicate and how
to communicate them. For the project associated
with this training, I'm going to give you a couple
of options to choose from. You need to write a
short essay about deciding what numbers to use and how to use them according to the lessons I'm going to
teach you in the classes. I'm very happy to have you
here and I hope you're going to go through my
course in its entirety. Because I'm convinced
it can bring a massive positive impact in
our ability to be effective, to use the skills we have, to use the knowledge we
have to communicate in such a way that we can make other people understand
what we mean. And to increase our influence
and overall impact. Let's go.
2. 3.6 - Not Great, not Terrible: Everyone who's watched
the mini-series, Chernobyl remembers
the number 3.6. Not great, not terrible. And they will remember the
scene where general piccolo comes back from the plant
and says, not through long. 15,003 point 6.15002 numbers that to the technical expert, tell the entire story, but not to everyone else. We to use numbers all the
time to explain things. Ask for things, present things. Engineering, sales,
marketing, management. Everybody uses numbers. Thing is though, numbers don't always speak for themselves. So the challenge is
how do we convey the full meaning
and importance of a number such that our
audience understands its impact and understands
what needs to be done. I mean, we all know what 3.6 and 15,000 mean because the show, I told a great story about it. But when we present our numbers, we're not going to have
HBO doing it for us. We have to tell a great story. Let's get back to
the show and follow the guts of our expert as he has to explain and present these numbers over
and over again. He's having to explain 3.6
of the Political Bureau. Not only how dangerous
3.6 really is, but it's particular meaning, what it could represent and
why it shouldn't be trusted. It's a suspicious
number, 3.6 Rontgen, which by the way is not the equivalent of
one chest x-ray, but rather 400 chest X-rays. That number has
been bothering me for a different reason though. It's also the maximum reading
low limit to submitters. They gave us the
number they had. I think the true number is
much much higher if I'm right, is fireman was holding
the equivalent of 4 million chest x-rays and
it's the legacy of this. He's than having to
explain what 15,000 the number of general
piccolo just told means. In fact, Boris outright asks him, What does
that number mean. Thanks Boris. This is
one of the clearest. Tell me the story behind the number requests
I've ever seen. You're doing my job for me. And legacy of obliges, he is telling them
what its implications are in terms of
damage of gravity. So this is the core, is open. Means the fire were watching
with our own eyes is giving off Danny twice the radiation released by the
bombing hiroshima. Every single hour,
hour after hour, 20 h since the explosion. So 40 bombs worth by now, 48 more tomorrow will
not stop the week or the month for burn and
spread its poison until the entire
continent is dead. And his indirectly telling them that the plant
managers have been lying through their
teeth scored cameras. But carnival some in to the local party
headquarters. Service. Excuse. Like many experts, frustrated by the ignorance and the political games
of management, his frustrated that the
obvious problems that he sees are minimized and
ignored by those in power. He's angry that the
self-evident must be explained. And yet he moves beyond
his frustration and he does explain it
elegantly, vividly. He tells the relevant stories that bring these
numbers to live. And that's what makes
them effective, is not enough for him to know. He has to make the
relevant others know what needs to be done. Gets done. Your conditions are
almost certainly not as bad as like ASOS. I hope you too will have to explain what is obvious to you, but not obvious to
others, others you need. U2 must move beyond
frustration and find the stories that give meaning
to the critical numbers. Because frequently, numbers
do not speak for themselves. This course is about the four questions you
need to ask yourself when you present numbers and the techniques you can
use to give them meaning. We'll look at a few examples, analyse them, see what
works and what doesn't. Let's go.
3. The 4 Questions Framework: Let's assume a lead
the team and you want to increase unit test
coverage by 20%. What do you need to do
to give this number, meaning we're not
going to discuss the merits of such a
decision if it's good, if it's bad, this
isn't the point. Also the numbers I'm going
to use are just examples. I'm not giving
technical advice here. It's a plausible scenario, but it's just an example. The point is, assuming
you've made this decision, how should you craft the right
story around this number in order to gather support for it and therefore
be able to do it. Start by answering
these four questions. One, what is the
benefit of this number? What do we win by achieving it? The more specific and
immediate the benefit is, the better abstract
long-term benefits are the least convincing. What is the cost of this number? What do we have to do
in order to achieve it? Three, does the benefit
outweigh the cost? Why, how and by how much for what is the relevance of this number in
the big picture, any analogies or comparisons you can make with other
well-established numbers. With this in mind, let's
create a series of increasingly better stories
around the 20% number. We'll start from the
least effective story and gradually improve it. Let's increase our
unit test coverage by 20 per cent is the
least meaningful. It doesn't tell you pretty
much anything about it. Let's increase our unit
test coverage from 50% to 70% by 20% is better, but still quite basic. Let's increase our unit
test coverage from 50% to 70% is that's
according to best practices, is better still, because
it gets into motivation. Why should we do it? But it's a weak motivation
as abstract adherence the best practices is less compelling than other
types of needs. Let's increase our unit
test coverage from 50% to 70 per cent. We will need to use 20 per
cent of our capacity for this. But it would allow
us to adhere to best practices which
require 70% or above. This is better because
it also includes cost, but it's still a long
way from perfect. Let's increase unit test
coverage from 50% to 70%. We will need to use 20 per
cent of our capacity for this for three months to
retrofit the existing code. But it will allow
us to adhere to best practices which
require 70% or above. In this version, we've added
an essential detail that clarifies the difference
between the initial cost, the initial investment, and
the ongoing maintenance cost. This is much better. We have an idea of
relative proportions. We're going from 50% to 70%. That's an increase of
40%, a major jump. Well now we're going
to 70 per cent, which is the minimum range
of the best practices. We know it will take
us three months to retrofit existing code. And after that,
we'll need to budget ten per cent of our
capacity to maintain it. We know more about the cost, the initial investment,
the maintainers, all Liz has given a
lot of meaning to the 20% number we started from. The weakest part is
still the benefit. But here's the best practices is a weak motivation because
it's vague and diffuse. Let's improve it. 70% coverage should
reduce the number of bugs per sprint by 50 per
cent compared to today. Now that's already way more interesting and way
more compelling. 70% coverage should
reduce the number of bugs per sprint by 50 per
cent compared to today. Saving about a day
of work per sprint, which will compensate for the
10% of capacity we need to allocate for it as an
ongoing basis, therefore, paying for itself, this is
already very good because it shows how the benefit will
compensate for the cost. But we need to go even further. We need to show not only that
we recover the investment, but then we also gain
something extra. Furthermore, this
should allow us to shorten our release
cycle from six months to three months as
the software would be in a much better
state at all times, the pre-release testing
should be much faster. This is an example
of a net gain. Now this is a good story
because it gives a lot of meaning to the 20%
number we started from N. It answers all the four
questions for clarity, I'm not saying you
should always add more and more information and
more detail to your story. More is not necessarily better. The best stories are simple, but like Einstein said, make things as simple as
possible but not simpler. So make your story as
simple as you can, but not too simple. So simple that it's
incomplete and ineffective. A story that is too complicated
is not going to work, but a story that is too simple
is also not going to work. However, most of
the times people over-complicate stories more
than they oversimplify them. On a practical note, you should be more careful
about putting too much in your story rather than putting
too little in your story. But how do you know exactly how much to put in your story? And what is necessary detail and what is excessive detail? Well, that's easy. Follow the framework of the four questions
answered each of them in the simplest possible way that will work in
your situation. And that is the right
amount of detail. All these numbers, 10%, 20%, three months, one day, etc. What do you take
them from anywhere? You can analyze the
historical data to see what you can
extract from it. Do an experiment for a
sprinter to see what happens. Take it from any source
you can do these numbers need to be 100% precise
in some situations, yes, but most of the times
n In our example here, No, they don't need
to be 100% precise. E.g. if you make an experiment
for a sprinter to any invest 20% of your
capacity in unit testing. And at the end of
that experiment, you observe a certain
rate of being able to retrofit existing code
with unit testing. Is this experiment an absolute
guarantee that you will be able to hold that rhythm
forever? No, it's not. But it's good enough to
make a projection and say, give us three months, and we'll retrofit the existing code. All the numbers of use
here are chosen to be as meaningful as possible
for our audience. In this case, I've assumed the audience to be some
type of management. So if you use the numbers that are more important to them, that have meaning to them, the numbers they care about, time release, cycle,
speed, quality, etc. If e.g. were to make the same case to a
group of developers, we will also use
other numbers and other arguments that are
important to that audience. We might mention
how unit testing helps with cleaning code. We might introduce
the possibility of test-driven development, etc. Meaning is relative and it's
dependent on the audience. What do they care about? We create stories for the specific audience we
are trying to convince. Not everybody cares
about the same things.
4. More Examples: Let's take a couple
more examples and work through them with a four
questions framework. And alongside the
four questions, let's remember that
meaning is relative. It depends on the audience
would trying to convince. Example one, you're a freelance videographer
and you want to increase your daily rate
by 15% for new clients, just tell them the new rate. Okay. But how do you approach existing clients to give
meaning to the 15% increase? You can look at
three main sources. The value you provide, what the market is doing, and your own costs. In this order of preference. The best way to explain your 15% increase is by
referring to increase value. By making your services
somehow better, faster includes something new. The idea being that
you're asking for more, but you're also giving more. I'm calling this the best way to explain your price increase
because like we said, meaning is relative what
matters to your audience, in this case, your audience or your client's existing or new. So what does mattered
to them and to them the most important
thing other than price is the value
they're getting. E.g. if you've gained
the capability to deliver edited videos two
days after the event, instead of the five
videos to take you, that's new value that it can
use to give meaning to rate increase final edits now coming
more than twice as fast. Or maybe you can also edit
them in a better way, e.g. giving them different formats of the edited files
already prepared for different social media like vertical videos and shorts. This is also added value. Does the speed benefit and the additional formats outweigh the 15% cost increase
depends on your audience. If you're not sure,
then you can also keep the old price with the old
5-day delivery and then introduce the new price
with the new benefits as a higher tier service
they can upgrade to, if we can't point to
increase value to give meaning to your
15% price increase, maybe you can point to
what the market is doing. If everyone else who provide similar services is more
expensive than you are, then you can say you're aligning
yourself to the market. It's a weaker story
than the story, but it is still a story. The weakest story of
the mall is to justify the price increase
by the increase in your own costs
is the weakest. Not because it's wrong or
doesn't make sense for you. But because remember,
meaning is relative. What does your audience, in this case, your
customers care about? This is the last thing
they care about. This story works better
for a distributor, e.g. as they get products from the manufacturers and add
their percentage on top of it. So if the manufacturer's
increase the prices, the distributor will
automatically reflect that increase and everyone
understands how that works. But that's also why
distributors work with thin margins because they
don't add that much value. You don't want to
work like that. Just add a percentage
on top of your costs. They'll understand
you on a human level, but they'll go
home thinking that the next time they'll
look for alternatives. There's gotta be someone
out there that can manage their costs
better than you can. So even if the
reason to increase your prices is an
increase in costs, that's not the story
you want to tell, but you also don't want
to ally obviously. So what do you do? What story do you tell? Well, you take advantage
of her predicament or increased costs to also improve your services
and increase value and then justify
your price increases with the increased
value and keep the increasing costs as
an internal motivation, then you don't necessarily
communicate to your clients. Let's take one more example. The WIP limit,
work-in-progress limit. The WIP limit is the
maximum number of tasks the team can work on
simultaneously at any given time. If the WIP limit is reached, the no new task can be
started until one is closed. Your team has six people in it. You propose a WIP limit of five. You need to give meaning to
this number and make a story around it to convince your
team That is a good idea. As always, we start from the four questions
as a framework, the benefit of the WIP limit set to five is that each
of us will work one at most one task at any given time and
minimize focus switching. Another benefit is that the
average size of the tasks will reduce from weeks to
days to three at most. Contexts switching, moving
from one task to another, it can require up to 12 min to get fully back up to
speed with the new task, or to get back to the old
one after interruption. So two or three interruptions, even if they're
only seconds long, can affect more than 30
min of productivity. Working with a WIP
limit will drastically reduce the need for
context switching. The WIP limit is five, even though we're six because there will
be collaboration, two or more people
who will occasionally work on the same task. The difficult part, what we
must do to make it work is to reduce feedback
cycles from days to minutes when there is a problem, missing information,
whatever, it must be resolved quickly so tasks
don't need to be put on hold. And others started
while we wait, which is the very problem
we're trying to fix. So we need to be very
quick in helping each other unblock
issues all in all, working in this way will
increase productivity and quality as we focused
on one thing at a time, the things we're working
on will be smaller, more manageable, and less
interdependent with others. And we'll get each of them done fully before
moving to the next. So no more loose ends. And that's how you give
meaning to numbers.
5. Why These Numbers Don't Work: Now let's take a look
at some numbers that at face value they are very
impactful, very important. We all agree they're
important numbers. They create a strong impression, but somehow in practice, they don't generate a
lot of concrete action. Six months of salary. Many of us have heard
this statistic. The replacement cost
for a good employee is 6-9 months of their salary. If we were to take this
number seriously than the following would be inevitable
logical consequences of it. One, it's almost always
more advantageous to give someone a 30% raise
than to lose them. Because losing them
is the equivalent of pain that 30% raise
for about two years. But without having them too, it's almost always better to do whatever it takes to
keep someone good, then let them go and
hire someone new. Three, allocating budgets
to salary increases should, within reason, always
pay for themselves. And yet, in real life, most managers and most
companies do not act like this. Not nearly to the degree
that the number of six to nine months of salary as a replacement cost should, in theory, dictate. Why not? A story has been told. Someone, whoever came up with a six to nine
months of salary as a replacement cost
measurement was very clever because this
is a great analogy. It's visceral. You're imagining John
right there leaving and it's like continuing to pay
him for at least half a year, but he's not there anymore. It's as simple as it gets. It sends a very strong message. So what's the problem? The problem is that the
analogy is overreaching. There's too many
variables under it, even if you believe
in principle that the overall
replacement costs for a good employee is
6.9 months of salary. Not all numbers are the same. That's replacement cost
doesn't show up in any of the accounting
numbers or in any of the typical management
KPIs and budgets. If you want to give John
a 30% raise to keep them, 30% is real money that
you have to start paying. Now, it eats up from a
real budget and you may get questions from your bosses
about this large rates. On the other hand, that
six to nine months of replacement cost
is more diffuse. It doesn't show
up in any budget. It's not on the expenses column. It's an overall statistical
approximation of lost productivity and other
missed opportunities, but it's not a number that shows up in your typical reporting. You will not be questioned
about it in the same way that you would be questioned
about the 30 per cent race. Also, the six to
nine months number is a statistical average. But in your particular case, it might be less, where
you might think it's less. Maybe your people are
billable to clients and John's replacement will
be billable from day one. The replacement may not
be as good as John, but they're billable anyway, so the revenues are the same. So where's that six to
nine months of cost? Now, this number of six to nine months
or replacement cost is an example of
alluded fallacy. While the overall approximation may be correct in some way, trying to use it as a
day-to-day decision-making rule ignores the many other
variables of such a decision. It's just not that simple. And the other
lesson here is that an immediate and precise need, such as the actual
money you're paying, the budget you have to fit in. The KPIs are measured on the questions you're
getting from your bosses. These immediate
concerns almost always outweigh a more distant
and diffuse problem. Even if that distant
problem is larger, that 30% raise is an
immediate concern. That six to nine months of replacement cost is
an approximation of a potential future
problem that will manifest diffusely across time. One is going to occupy your
mind more than the other. This is called
hyperbolic discounting, and it's the tendency to
be more concerned about immediate rewards or risks
than about distant ones, even if the distant
ones are larger. And that's why this number, this estimate over
replacement costs for a good employee being
System nine months of their salary doesn't really work in driving day-to-day
decision-making. It works to send the
general message, but that's about it. That's also why e.g. attrition percentages, the percentage of people
leaving the company is a much more frequently
used management measure in practice because it is
easier to measure, track. It's not debatable, is not
a statistical average. It's a real number, even if arguably is the
less meaningful overall and a less complete number compared to the
replacement cost. But because it's
specific, precise, and immediate, that makes
it more compelling, employee engagement numbers are similarly ineffective in driving day-to-day decision-making
because they suffer from the same problems. There are statistical
approximations. They're fuzzy because they
can be measured in many ways, some more precise or
relevant than others, which makes them debatable. And the impact is not immediate but diffused and
spread across time, which makes it easier to ignore in day-to-day decision-making, even if you in principle agree with the idea of increasing
employee engagement, logic fallacy and
hyperbolic discounting. Again, just to be clear, I'm not stating a position here. I'm not saying you should
ignore replacement costs. I'm not saying you should
ignore employee engagement. Far from that, I'm
just analyzing why some numbers are more compelling and more
convincing than others. So the lessons here are immediate concerns are stronger
than distant concerns. Precise concerns are stronger than statistical
approximations. Immediate and precise concerns
are the most compelling. Someone who write
your stories and give meaning to your numbers. Don't try to justify them
only by talking about the bright and distant
future or that looming problem that might or might not happen
five years from now. You can mention that as
well as an overall context. But the thing that's
most likely to get the audience on your
side and give you the support that you
need are going to be more precise and more
immediate concerns. So do your best to identify some of those as well. So e.g. if you wanted to make a
case that the management in your company about
employee engagement do refer to the overall idea about employee engagement
and the high level macro economical
statistics out there. But that's just the background, that's just the starting point. Try to identify specific
examples, specific numbers, specific anecdotes, specific
stories from your company, from your situation that your audience can
directly relate to, to also give them some
immediate concerns and some immediate benefits
that they can relate to.
Andrei Postolache, Leadership Consultant
