Giving team freedom (within limits)

As someone in management I make every attempt for my team work on their own. I will not micromanage, I never like it being done to me and would not want people to feel the way I did when it happened.

Also there are plenty of research out there that shows when leaders take that step back and give them control in their work it will lead to better job satisfaction.

10 factors in job satisfaction

Letting be empowered in what they do and get the work done gives staff the sense of ownership and not driven by specific orders from above.

Now with that said comes the “within limits” part of the title. Read through the link I provided you will see in the control part it discusses that leadership will give direction and not specific orders. That is something I firmly believe in. Barking out orders doesn’t work well in an industry where innovation and “outside the box” thinking helps with ensuring quality products go out to clients. What I use is a basic set of rules, without them it does not end well.

As an example there was one group that I worked for that used an automation tool to complete all the testing for one application. Now it was a good tool at the time and provided what was needed. The unfortunate thing was there were no rules around how the data, scripts and application was to be used by the team. At one point nobody would be able to run a suite of tests and get valid results to validate without doing more investigations and traces within the system to review. In doing so it complete negated the value of the tool that was to do all that for you.

There was a sub project that was created to clean up the data, scripts and provide a clearly define process on how the tool was to be updated. The project took a while, a little longer due to something I did (detailed here Owning up to mistakes) . I can tell you I never repeated a similar mistake like that again.

In the end with the rules and changes we did it proved to be a huge value. Now I know you are saying right now “where is the freedom?” Well the freedom came in the lead up to the stable environment. We created two automation data databases; one with strict control and one that was fair game. This was the perfect set up as people can do what they wanted to test and after go through the process after the project to move the data to the clean database to add to the regression suite.

In the end I understand that most people are happy when they are left to their own devices to get work done. As some of you that know me I am far from being a strict rules follower. While some rules should never be broken there are some that can be bent or should be broken to help with getting work done and also help with innovation.

Testing in difficult situations

Having been doing QA work for close to 25 years now I have come across one or two difficult situations. Whether they are delays in code deployment, resource issues, environment issues or finding one of those Surprise issues late in the game. That is just to name a few difficult situations that a QA team would have to deal with.

The one that seems to cause the most angst is the dreaded “finding a Severity 1 defect late in the game”. This one is the toughest because QA is now potentially the messenger of death for a given project. Finding this issue could delay or even shelve an entire project or program.

The best example I have encountered is two weeks prior to deploying a huge program we discovered that the speed of the system we were about to introduce to replace the existing system was much slower in processing transactions than what is currently being used. This was after almost 2 years of planning, requirements, development and testing. From a non-functional testing standpoint this was really late to be doing such tests, that will be another blog all together, and the team tried to retest as much as we could hoping that it was an issue outside of the system that could be explained.

For a week we stress tested the application with no real change in the results. The next thing to do was let the executives know what was going on. To say they were not happy would be an understatement. A lot of questions came out and the team tried their best to answer them. We had mitigation plans and rescheduled dates to accommodate the work needed to fix the issue. A day later there was an announcement that the program has been shelved indefinitely.  That was the biggest kick in the gut the team could have had. Years worth of work and the last two weeks of trying to find ways to get it to work just done with nothing to show for it for our customers.

Internally there was some benefit as we looked hard at our processes and made changes so something like this could not happen again. That is usually the best thing that can come out of difficult situations; a problem is found and resolution comes out of it for the future.

That was a difficult situation that was based through a team, what happens if it is an individual. We all have something that can happen i our personal lives that could find its way to impact work, or something happened at work that makes things hard to deal with. As a people manager I have to be conscious and considerate of what people are going through and help them as best as I can to get through what they are going through. It is a tightrope act in how to deal with issues that, if personal, people may not want to share with their direct manager. For me, I always tell my team they can approach me about anything and they have my confidence that it would only be between myself and them. If not they should go to an HR representative as they would be able to help out with whatever is needed.

As I write this and remember what was discussed in the QA corner podcast component in SPaMCAST I think I will be writing a continuation of this one to get a little deeper on what I think about this scenario. The one thing I do feel that letting someone know what is going on before it festers is the best thing that can be done. A good manager will not be angry at the messenger, they will focus on rectifying the issue.