Just say no
(things I’ve learnt becoming Lead Developer at LGSS Digital)
We’ve all been there. Someone walks up and has a problem that needs fixing there and then. It’s crazy urgent and if it’s not fixed in the next 5 minutes, it will be the end of the world. Different people from different areas are all running around, panicking.
But in actual fact, once the dust has settled we all realise that wasn’t really the case. There’s just been a little blip caused by something out of our control and it’s been resolved by the service provider. No one actually needed to do anything. Think of all the time and energy wasted on that “problem”.
Don’t get me wrong, there are times when the only course of action is to roll your sleeves up, put on your most serious face and get right on the case of solving a serious problem. Nothing else matters, even blinking seems to take a back seat. But these times are rare.
Learn to prioritise
One thing I need to get better at is learning which scenario is playing out in front of me, and what needs my immediate attention. There are times when the best course of action is to take a step back and see what is actually going on, who is working on the issue, and what the possible outcomes are.
I’ve also started to look at who the problem is affecting. If 1 person has a problem when there are over 3,000 active users, it’s not a big deal. That is, of course, unless that 1 person is the big Kahuna.
So yes, there are exceptions, but we all know who the VIPs are. The names that need to be taken seriously, no matter what the request. Again, these are the exceptions to the rule.
The majority of problems come from user error. Someone does something by mistake and now something isn’t looking or sounding or smelling right. They are adamant that they only pressed the big green button, but after spending the best part of an hour investigating, we can see they must have pressed the big red button.
We can implement the best systems in the world, but there will always be user error. It’s knowing when a problem is a problem, that is key.
I’ve lost track of the number of times where the users have simply gone away because I wasn’t able to look at an issue there and then. They often figure it out themselves and don’t let us know.
We can be too helpful. If someone knows you’re at the end of the phone and will look at every issue – no matter how small or large – they will choose the path of least resistance. Instead of reading the documentation, they will just pick up the phone instead.
“I’ve lost track of the number of times where the users have simply gone away because I wasn’t able to look at an issue there and then. They often figure it out themselves and don’t let us know.”
Saying no can be hard
We all want to be helpful. We all want to be the star and make a difference. But be warned, helping every Tom, Dick and Harry whenever they ask, ultimately leads you down a dark and perilous path… one that is very difficult to find your way back from.
Sure it gets you noticed initially, but it’s scary how much time it takes up, answering every call, investigating every issue. Working in this way can cause people to work in silos, without the bigger picture being considered.
Get back on the right path
In our team, we’ve all been hired because we have a unique set of skills that help LGSS Digital deliver great products and services. We need to work in the most efficient way possible, and we can do this best by filtering out requests, prioritising and planning if, how and when these things are delivered.
The customer journey should remain top of the list. There should be no doubt on timescales and who is responsible for what and when things will be delivered.
There’s a process to make sure this happens!
- A project pipeline for knowing what work is needed
- A helpdesk system for logging, managing and reporting on calls
- Time recording and forecasting tools for allowing us to see who’s working on what and how much time/money is left on a project.
Even with this process in place, sometimes asking users to wait a bit can help determine how big an issue really is, and how it should be prioritised.
Consider these things when pondering whether no is the right word:
- How many people is the issue affecting? Is it 1 out of 10,000 or 1 of 5 users?
- What’s the reason for the short deadline? Is it a real deadline? What happens if it’s not delivered at that time?
- Is it likely to be user error? Have they read the manual/asked other people to test it? Have we seen this before? Document user errors and publish this for the rest of the team.
- How important is the person asking you? This shouldn’t matter, but it does.
- How important is the request in relation to the thing you’re meant to be working on?
- Is it a support issue or a new request? New requests can be given to the design team to follow up, whereas bugs and fixes can be ticketed for the support team or, if not-urgent, consolidated for the next iteration.
- Are known bugs visible, if so, they have already been captured and not need to be reported.