It's safe to say that there has been a fair amount going about in the UK news recently about honesty, or lack thereof, surrounding a certain political event that I'm not going to discuss here. I've always been an honest kind of person. Whether driven through a higher moral compass, fear of getting caught out, or simply a lack of imagination that it doesn't really occur to me to fabricate, even to my own advantage, I'm rarely tempted to resort to fiction to resolve an awkward situation. I had a friend at school who was very different. He would tell me stories that, years later in adulthood, I have discovered were complete hogwash. Like the time that he told me that his cat had killed his neighbours parrot while he was at home alone ...
... a story that I later discovered he'd invented to excuse his missing a homework deadline and had told all of his school friends to reinforce his tale to the teacher. I'm still friends with him (I'm not entirely sure why) and even now every so often he reveals to me the truth behind some absolute porker he told me years before.
It's easy for me to say that honesty is always the best policy, but it doesn't always feel like the best option. A situation that occurs frequently in the working environment that can tempt anyone to stretch the truth, is when we're worried about the status or progress of our work. When this happens it is easy to fall into the trap of thinking that giving the impression of being in a better position than we actually are might satisfy those that we report to for a while, and allow us to catch up or fix the issue.
But you rarely do catch up. The fact that you are in a position where you feel the need to fabricate your progress in the first place must have come about because you're progress is not quite where you, or someone else, would have liked it to be. This will have happened for a very good reason, like the work being more challenging than you thought, which you're not going to change overnight.
Let's look at the potential impact of misrepresenting progress to some important people:-
To The Customer
The more distant the third party the easier to be economic with the truth so the customer is a prime candidate for inventive reporting. Of course you don't want the customer to know things are taking longer than expected, why would you? Perhaps you run the risk of exposing that perhaps your up front estimation processes were, actually well, estimates, and the development is taking slightly longer. Or, even worse, it could involve admitting that you are actually doing some work for, gasp, another customer. If the customer is on the other end of an email or phone then the temptation to give a false impression of progress is ever present.
I'd advise against it. Consider some of the disadvantages that can come down the line:-
- If you misrepresent progress on a development, and then hit a technical challenge that requires a rethink, or at least some major decision making on the part of the customer, how are you going to broach that conversation when the customer thought that you were already well past making such fundamental decisions?
- Also if you misrepresent progress then it diminishes your ability to negotiate scope as the development progresses. Better to be open early and often, at least then you can negotiate openly around what you are delivering.
- If you misrepresent the level of rigour in your testing, this can really backfire. I've worked with more than one supplier who has insisted that they were thoroughly testing what was delivered. I therefore focussed my own testing on the integration points and relied heavily on their testing of their own features. On discovering a high number of issues in these features this immediately called into question either their competence, or their honesty. In subsequent developments I actually had to negotiate for the supplier to deliver the software slower to give adequate time for them to test it.
- If you misrepresent the severity of an issue that has been discovered, then it is hard to justify taking time in testing a fix and therefore you place pressure on yourself to push out untested bug fixes. When I was running both support and testing I had to negotiate a reasonable delay on delivering changes to the customer a number of times. This was done on the basis that we had just found an issue and the last thing we wanted to do was rush in a change and introduce more issues, so we needed to take the time to do some thorough testing around the fix. Under-playing the severity of an issue makes such negotiations more difficult.
In the drive for 'responsiveness' to please the customer it's easy to lose sight of the value of honesty, however responsiveness in communication can deliver a huge amount of value without necessarily the need for the same responsiveness in scheduling or delivery. In my experience customers appreciate knowing where they stand, even if it is not necessarily where they want to be. They also find it hard to argue if you are putting effort into ensuring improvements to the quality of the end product you're delivering to them. Even with the awkward subject of other customers, software customers want to be buying from a stable supplier, so your having other customers is something that they should view in a positive light (though not all will). Showing respect for those other customers and being seen to uphold your commitments to them will reinforce your integrity as a supplier. If on the other hand, you are seen to default on your commitments just to please the customer in front of you, they are going to be under no illusions that they'll receive the same treatment once they're not in front of you.
To your colleagues
Misleading your progress to colleagues seems like a strange thing to do, yet I have encountered situations where this has happened when individuals are struggling or making mistakes.
- On one specific occasion I can remember a tester working in an agile team felt that he wasn't keeping up with the user stories he was supposed to be picking up. Instead of admitting this, he misrepresented the level of testing that had been done on the user stories that he was working on, to the extent that I thought they were completed. I then reported to other teams in the business that they could make plans on the basis of that work being completed. On examination I discovered the status of the tests had been misreported and what had been done gave us little or confidence in those features. The result was me having to drop my other work in order to devote time to testing those items so that we could fulfil my commitment to the other teams. Had the tester been honest with me about his status, I wouldn't have misreported our progress and the problem simply wouldn't have occurred.
- Similarly, if an individual has made a mistake then the temptation can be to try to cover it up. One lesson that I personally have had to learn over and over again, is that it is rarely as bad as you think, and getting a mistake out in the open is empowering. Keeping mistakes concealed, conversely, accumulates stress on the individual, and anyone else taking the responsibility to resolve a difficult situation will not appreciate it if those who have made mistakes hide the truth in an attempt to conceal their errors.
Being honest with your colleagues goes beyond operational benefit. In the world of self-managing teams and a move away from strict hierarchical control and micro-managements, creating a community of trust with your colleagues is essential. If you're co-workers feel that they can't trust your status reports in terms of what you have developed or tested, then they will likely resort to committing effort to double checking your work, at the expense of progressing their own, a situation which at best will result in ill-feeling and at worst could blow up into serious confrontation.
Senior managers tend to be more removed from the immediate development and testing work and so often don't have the low level view of the software products to really make a good assessment of status. That's what they rely on you for, particularly the testers. It's therefore relatively easy to give a false impression of progress to senior management, but this can have dire consequences for them, your colleagues or you.
Something I've seen more than once is when a senior developer or architect takes it upon themselves to develop a pet project that they put together as they see value in it for the business and want to impress with their ingenuity. Much of this type of development has gone on outside of the core development processes and has had little or no formal testing. The software is presented to C-level executives as release ready in all but requiring a "rubber stamp" sign off from the testing team ( I have actually had a CEO say to me "now all we have to do is test it - right?" in relation to just such a development ). The result can be a lot of stress placed on colleagues who have to take this work and try to test it or support it to the level expected of them. The sad thing here is that there's no need to keep such projects away from others. The best chance of success of any new endeavour is to bring others on board with it and get them behind it, being honest about what you don't have the time or skills to do, such as the testing. If you are honest about getting others on board and giving them the credit for the contribution they make, they'll be more than happy to report your contribution to senior management and give you the credit that you are looking for.
Another route for misleading management comes from the manner by which we communicate with them. If we're communicating via metrics or aggregated reports and metrics then for some reason it becomes easier to massage the truth. Now I've admitted that that I strive for honesty, however I'm not a saint and admit that I have in the past been tempted to tweaking metrics and measurements to make a situation look better. For some reason the level of guilt around gaming metrics to give a positive spin on things is far greater than it would be doing the equivalent in an open conversation. If ever there was a need for an open and communicative relationship with senior management, this is one. Inevitably the truth will out and no metrics in the world can the reality of the status of development. If you don't realistically appraise management of the status of development then someone else will, and if that person ends up being frustrated customer who is suffering delays or poor quality, then the outcome will be far worse than the awkward conversation you could have had around more realistic metrics.
Honestly, Honesty - it's not that hard
Looking back at some of the most challenging times of my career so far, many of the biggest difficulties have been the direct result of someone not being open an honest as to the status of their work. The problem with taking a misleading line in relation to work is that, once done, it is so easy to escalate and compound your problems by telling more lies. Taking ownership of difficult situations, getting the problem out in to the open and driving through to a conclusion is an empowering activity that actually helps with personal development and builds experience and character. Whether in software development/testing, management or support - there isn't a successful technical leader out there who hasn't at some point had to tackle a late project, missed deadline or simple mistake head on and face the consequences.
Coming into a new organisation, as I have done this year, has been a difficult journey for me given the level of knowledge that I had developed around my team and processes in my former role. I've inevitably made some mistakes as I've worked to understand the culture and processes of a new organisation with a very different technology stack and customer base. Maintaining a level of openness around what I'm doing and any mistakes has hopefully allowed the same openness in communication to me and encouraged others to be honest with me about their work - as honesty is a two-way thing. By being honest with colleagues, management and customers I believe that we not only uphold our own principles but also encourage others to do the same.