As software testers, we work in a world that is both business-focused and creative. Business-focused because there is usually a financial consideration attached. Creative because someone (or many someones) design/build/release a software-based product that requires blood, sweat and maybe a few tears to bring it to life.
In my opinion, central to this dichotomy is the question of ownership of the product or outcome. The majority of contracts today state that the intellectual property (a major component of ownership), associated with the product under development, resides with the benefactor or employer. Therefore, unless we are party to a contract that does not stipulate this, neither the software designer nor the developer retains ownership and therefore a somewhat nebulous state exists. Unfortunately, this nebulous state generally leads to various parties assuming ownership throughout the various phases of the SDLC. And here lies, for me, the real challenge. How to navigate this maelstrom of creativity. How to negotiate an acceptable outcome for all parties. How to balance time, quality and risk – the usual suspects.
Giving (and receiving) feedback is a crucial function within the SDLC and can become a minefield for those of us who fail to approach it with respect and candour. Respect for the creators and candour in achieving the most pragmatic outcomes.
Over the years I’ve noticed that when feedback comes into the picture ego is lurking somewhere close by and, depending on the maturity and gender of the individuals, positions taken can vary anywhere from openness to negotiation and collective acceptance to outright denial and/or blatant hostility.
No matter what form the feedback takes it needs to be given and taken both professionally and without prejudice. We’ve all been subjected to at least one of the myriad of reality TV shows, where some poor schlep has just poured heart and soul into their chosen art form (music, dance, food etc.) only to be told they suck big time. Most shows employ the good cop/bad cop approach where at least one expert judge provides meaningless platitudes. While most of the audience tune in to hear the bad cop routine, can you imagine taking your newly crafted software into a peer review and some Simon Cowell wannabe arcs up and says “that was shite, don’t give up your day job” – unfortunately, this is your day job… Thank goodness for Context, my friends.
My view on giving feedback is this – if your job description includes the provision of feedback, give it. If you give feedback, consider the context and the audience. My approach (in the majority of cases) is to act as if I am dealing with my kids. I consider how important the outcome is to them personally. I consider how important the outcome is to those around them. I consider whether my feedback will have implications on their long term development. I also consider where and when I will provide the feedback; sometimes feedback should be given privately and other times publicly (especially if it’s positive).
I have encouraged my kids to push boundaries and aspire to lofty goals and ideals and therefore my expectation is that they will sometimes fall short. This is a time for encouragement, not constructive criticism. This is a time to focus on the big picture, not a single goal.
If a software designer or developer is pushing boundaries (technically, creatively or both) we need to use different language than if they are reworking a long-standing feature or function. Creativity requires ego. Ego is fragile in most of us. The majority of folk haven’t learnt how to leave their ego at the front door when they enter the building. Therefore, consideration for others feelings is an important skill in the workplace. I’m not talking about molly-coddling or pampering, I’m talking about respect and consideration for your fellow workers. A junior developer needs guidance and understanding, a 20-year software veteran can take it on the chin – most days.
Relationships are a crucial part in giving feedback. The stronger the relationship, the better position you are in to provide difficult feedback. There will be times when your feedback needs to address poor decisions or outcomes and this is where empathy and flexibility are needed in spades. As a 35-year veteran of the software industry, I’ve undertaken pretty much every role within the SDLC and I can therefore empathise with the challenges of the majority of software professionals.
Experience is a great teacher and I’ve been fortunate to work on some amazing projects alongside some incredibly gifted people, which gives me perspective and confidence in dealing with the majority of software challenges. I still make mistakes, but I recognise them earlier than I used to. I still get frustrated with anything less than perfection, but I am more cognisant of other people’s perspectives.
I have developed a toolkit, from my many experiences, that I draw on every day in order to achieve the best possible outcomes. Here are a few that I think are pertinent to this story:-
1) Most outcomes will not be perfect.
2) Most outcomes require compromise (yours and theirs).
3) Context must determine how you deal with each feedback opportunity.
4) Feedback must never focus on the individual, it must focus on the challenge at hand and the eventual outcome.
5) Feedback must focus on specifics, not generalisations.
6) Feedback must be incisive and decisive, not wishy-washy.
7) Feedback must be balanced and fair.
8) Feedback must be timely and appropriate.
9) Feedback is a two-way stretch, make sure you understand the other person’s perspective.
10) Feedback should not be rushed; make the time, find the right environment and create the right energy.
Finally, points 9 and 10 above highlight a key component of giving feedback – listening. Listening to other folks ideas. Listening to other folks reasoning. Listening to other folks constraints and dependencies. Listening to other folks hopes and aspirations. We all come to creative endeavours with different skills and experiences. When you have learned how to truly listen, your ability to provide your own feedback will improve exponentially.
As Phil Collins once said – “We always need to hear both sides to the story”.
Dateline: Monday December 1, 2014