This is a draft extract from a chapter in my forthcoming book for digital leaders. I’m keen to have any feedback.
How to communicate with senior execs who don’t understand
One of the easy mistakes to make when discussing digital technology with people in the CSuite is to confuse them with the technical language they don’t understand.
If you are lucky they may have technical experience and understand, but that’s not an excuse to use jargon. There is a chance that they may be impressed with technical language and think “wow this person is much smarter than me, they must know what they are doing”. However, this is not in your interest and will likely only get you so far.
Your job is to explain to them why digital technology is better for the company and the customer. Your aim should be able to do this using simple non-technical language.
One way to do this is to tell stories. Bring to life for them the customer or employees “day in the life”, explain how this product or initiative solves a problem for them. Use plain English, use imagery, why not even bring a user along with you for them to tell the story themselves.
Managing expectations
You will come across people who have different expectations of you, your teams and the wider environment. These will be in a number of areas including team capacity, time, customer appetite, the speed of adoption, quality, design… the list goes on.
Your challenge will be how to manage these various expectations. One of the most common is time and we’ll look at this in more detail in the next section.
The best way to manage expectations is to communicate and be transparent. I know this probably sounds obvious, but you may be tempted to bunker down and think, “they just don’t understand my world, they have no idea how complex this is” and shut others out.
This may work in the short term but will likely see you and the team become isolated and even distrusted over time.
Use your ways of working (see chapter 4 if you’ve jumped to this chapter) to get stakeholders involved, show them the value the team is delivering on a regular basis and communicate the successes as well as the failures.
No estimates
Ahh, here we go. Opening a can of worms now…
“How long will it take?”
This has to be the question I get asked the most. My answer?
“Days/months/years, that’s the best estimate I can give you, and by the way, I could be 100% wrong”.
I get it. People are paying for you and the team to deliver value. It provides a kind of sense of security and control if you know the likely timescales.
The problem is in the digital space, you are often creating something new, something you haven’t done before. Also, if you are an effective digital team you will be learning from user responses to your products meaning you won’t be able to predict how the product will evolve and you will want to pivot and adapt as opportunities arise.
In my view, this makes time estimations impossible. It is leftover from the industrial age when work was repetitive and predictable. We don’t live in that age any more.
Of course, it’s hard to tell your superiors you don’t know how long something will take, but still, ask them for money and to trust you.
As before, the only way to get them on side is to get them bought into the iterative way of working with appropriate gateways where they can see progress (value delivery) and if they want to, release money at stages. Caution, they also need to be bought into the experimental way of working and not cut you off at the knees if an idea doesn’t work. They are saving money from large scale projects running months and years with fixed requirements that are much more likely to fail.
So here’s a more positive response to the question of how long will it take.
I really don’t know, this is new territory. However, we will release value to the customer and business frequently which I will report to you. In the digital space it’s important we focus on short term iterative steps, so we can learn our customers’ needs to deliver low risk, high-value work.
A milestone in my career was when I presented my first business case for a big product development that had no timescales. I didn’t get shot down by the board either.
The backlog is not a commitment
I once had an item in the backlog from a colleague who requested it prior to leaving the organisation for about a year. During the time they were away, there were much higher priority items to be delivered and new opportunities that came in. These all delivered a higher value to the customer and the organisation in my opinion and from the evidence I saw.
However, when they came back, they weren’t happy that the work hadn’t been done.
From their perspective, it was the most important thing, however from mine, with oversight of all the possible opportunities and data it wasn’t.
A slightly snotty email was produced by this colleague copying in various senior people saying that the team were not supporting them, and work had been requested ages ago.
The one thing they didn’t understand was work was being prioritised on the highest value, not who has been waiting for the longest.
In this case, if the work had been that important I would have expected other members of their team to be banging on my door saying that they couldn’t function effectively unless we delivered this functionality as soon as possible. They didn’t.
This was an extract from a chapter in my forthcoming new book for digital leaders.
Follow me on Linkedin to stay up to date on progress and let me have your feedback.
Posted in: Agile , Leadership