Skip to main content

Are You SURE You’re Actually Helping?

A bizarre thing happened to me earlier today. I was standing by the side of a busy street waiting to cross, when a driver slowed down and beckoned me to cross.  Initially, I thought this was a really nice thing for them to do… however they hadn’t noticed that there was fast moving traffic in the adjacent lane. While they were trying to help me out they were actually just beckoning me into an adjacent stream of fast moving traffic!


I signaled to them that I was fine waiting, and the driver wound down their window clearly angry that they had offered “help” that I did not take. Somewhat taken aback, I continued waiting until there was a gap in the traffic in both lanes and then carried on with my day.  However, it struck me that patterns like this occur in organizations all the time, and sometimes as BAs we might inadvertently beckon our stakeholders into dangerous situations…


For example, as BAs we are often the first to pick up the slack when there is a lack of resource elsewhere.  Has somebody forgotten to plan out who will support the solution when it goes live? No worry, we can jump in and help… after all, we specified it so we know how it works!  Before you know it you’re running a helpdesk alongside your day job, and it ends up running so well that you end up carrying out support duties for the rest of your career… Before you know it you’re managing a full-on support operation too and spend your day prioritizing service requests.


OK, so that’s a bit of an extreme example but you get the picture.  Of course, there are times when it makes sense to step in and help, and there are times when it makes sense for BAs to help with ongoing production support. Delivering change is a team effort, and BAs absolutely need to be team players.  Yet, it’s also important to recognize our own strengths and weaknesses as practitioners.  As an example, I’ve certainly helped out with testing in the past—but, I recognize I’m absolutely not a trained or professional tester!  I can help fill temporary gaps in resource to help execute tests, but I wouldn’t be the best person to write an entire QA strategy for a program. If I tried, I’d probably do it badly, and while this would fill an immediate gap (as a deliverable is produced) it would hurt the program in the long run (as the QA strategy would probably be full of holes).



The danger is that in an admirable attempt to be helpful, we can inadvertently hurt our stakeholders. If we step in, take on more work, working later each night there is a danger we are shielding the fact that there’s been inadequate planning. The person or group that did not plan properly doesn’t have to deal with the consequences (and might not even recognize that a mistake has been made). This robs them of the opportunity to learn and adapt. If they make a mistake in future it might be much bigger and more consequential—to draw parallels with the analogy I used earlier, we have just ‘beckoned them into traffic’ while trying to be helpful!


Think About Consequences & Ensure Feedback Flows

As I mentioned earlier, I’m absolutely not suggesting that we should become fixated on our role boundaries, nor that we should refuse to help out. However, we’ve probably all been in situations where we’ve felt ‘leant on’ or pressured by stakeholders to make problems go away or do things that are outside of our areas of expertise. Sometimes the only way this is achieved is by working late (i.e. sacrificing our own personal/family time), and in the short term that might be OK.  However, we should also ask “why did this happen?”, “am I the only/right person to do this?” and “how can we ensure that this doesn’t happen again?”.


In essence this is about ensuring that feedback flows freely around the organization. If someone planned badly, they need to know this so that suitable adaptations can be made to the schedule and so that they have the opportunity to adapt the way they plan in the future. While it’s well intentioned, quietly shielding others from feedback is actually just a recipe for repetition of the same mistakes.  It’s important to speak up, and give (and be receptive to) ongoing feedback, to adapt and pivot as necessary.  After all, change is hard, and we’re always learning as we go along.  Much as others help us learn, we can help others learn too.

Adrian Reed

Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. He is a Past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’ You can read Adrian’s blog at and follow him on Twitter at