Have you ever had trouble explaining what your job is to someone? Whilst struggling to explain your role outside work may provide some social awkwardness, when the same situation arises with work colleagues it can be more of a problem. If those colleagues interact with you directly and have a very different expectation of what you should do than you, it becomes a genuine concern.
One thing that has characterised the roles that I've held since I first became involved in setting up and leading teams is the need to establish an understanding amongst others of what I and my teams do. When I was focused solely on testing this was typically due to the need to correct a restricted and out of date view over what testing involved. When running technical support it was more around establishing an understanding of what support could and should be doing for others and the appropriate ways to interact with the support team. More recently, as I've overseen the introduction of Product Owners into River, I've seen it in relation to understanding what a Product Owner does and how they work.
I've tried various ways to communicate out what's involved in different roles.
- Presentations to talk people through the processes and activities undertaken by the team
- Group sessions on how to work together
- Taking each new starters through individually to discuss what we do
- I've even created graphic user journeys in prezi showing people might interact with the team
All of these have worked well to some extent. There is, however, one approach that I've found consistently communicates am understanding of what a role entails better than any other. That is by focusing on doing a great job.
Not as easy as it sounds
It sounds simple, however this isn't always the case. If within your company there are those who misunderstand your job, responsibilities or approach then it is likely that they will make demands of you that are inconsistent with what you know will deliver value from your role.
I've had many situations in my work in software testing where the expectations of others differed greatly from my own opinion of good work
- Being asked to test a piece of software where the only reference point for target behaviour is the software itself ('can you just find the bugs?')
- The perception of testing as a process of creating test scripts and running them
- Testers being expected to ignore the risky architectural concerns in a piece of software and focus on trivial bug finding in the user interface
- The perception of a lack of need for testing other than creating automated unit tests and running them
...and the same is true of other areas that I've worked in
- Product owners being expected to deliver an already defined list of features simply by 'turning them into user stories' and assigning them to sprints
- Product owners expected to predict which features will be delivered in which exact sprints to strict timescales throughout a lengthy development
- Support staff being expected to repeatedly deal with the same issues in flawed software without raising their concerns and recommendations for improvement with the product team
In all of these cases, the situation that the individuals or teams can find themselves is a frustrating one. There is expectation, often associated with a certain level of pressure, to perform a role that is fundamentally different to the one that you should be, or want to be, doing.
Turning in around
As I said in my post 'Knuckling down' - I believe in putting in your best effort to resolve problem situations rather than being too quick to walk away based on a role not meeting your expectations. Clearly if your organisation shows no sign of changing despite all efforts to improve then the door is an option, but I'd always strive to try to turn this around first. But how to do this?
I suggest to start with, ask yourself why the mis-perception exists. Do you believe that what you see as the role will genuinely deliver more value than simply delivering the work in the way that is anticipated?
Presumably the answer is yes. Therefore by changing your behaviour to deliver in the way that you envisage you should deliver more value to the stakeholders in the process than they were hoping for. The problem here can be that, making major changes can impact an existing flow of work. The last thing you want is for your 'improvements' to be associated with a big disruption. Instead I've found that a more incremental approach, focusing on introducing small changes and steering the pipeline of future work rather than what is currently in progress, is much more easily digested.
- Do some small elements of the work your way 'guerilla' fashion and then demonstrate the value from those small pieces - nothing demonstrates the value of exploratory testing more than a shed load of risks and problems exposed that wouldn't have been discovered by your test scripts.
- Know when to bend and when to push back - if people ask you to deliver tasks that aren't appropriate, potentially agree to it this time to avoid disruption but state clearly that on the next occasion you will be tackling it in a different way
- As you deliver, go 'above and beyond' on the work, but make sure any extra effort clearly demonstrates the value of your preferred approach
- Use what you have done to provide information on status or risk that would not have been available previously
- Avoid a backlog of inappropriate work building up - take the opportunity when discussing new work to introduce new ideas at that point and establish a change in expectation for future programmes
The what, not the how
You inevitably need a level of stubbornness here. No matter how much you believe in what you should be doing, if you consistently acquiesce to others demands then attempting to steer a role away from their misguided expectations of it is going to be a challenge. One of my greatest failings in the past has been too easily assuming that the approaches taken by others are appropriate without questioning and asserting my own ideas on a process. Over time I've found what really helps to reinforce stubbornness is passion. The more passionate I am about something the more likely I am to research it, discuss it, reinforce my beliefs around it and belligerently strive to deliver value by doing it, even in the face of conflicting expectations.
If you find yourself in such a situation the most important thing to remember here is that other people ultimately aren't really interested in how you do your job so if you persist you are more likely to win through. Others are probably not that excited by discussions around why your approach is better so trying to present people with explanations of theory is going to have limited success. What people do care about its achieving success in their own roles, so focus on how you can help them with that. The most effective way of convincing anyone of the value of a different approach is by showing what it can do for them, and the best way of achieving this is by doing it. Really damn well.
Image https://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Bristol_MMB_43_SS_Great_Britain.jpg/1200px-Bristol_MMB_43_SS_Great_Britain.jpg - there are many who believed that a metal ship would be too heavy to float, or that a screw propellor would not work as well as a paddle. Brunel proved them all wrong when he built the SS Great Britain.
Post a Comment