No Surprises!

This is what I aim for in my teams - no surprises. That means my team members do their best to not surprise me and I also aim to not surprise them. Surprises are great when it comes to birthdays at home with family and friends. But in corporate life, there's just no room for surprises. Even something like filling my office floor-to-ceiling with balloons while on vacation can be a nice surprise at first until the balloons slowly melt on the equipment under my desk and drift down the hall into other offices. J

So what does it look like to work without surprises? For a test engineer, this means that as you are testing a feature, if you think the quality is at risk, not meeting customer requirements, or that the schedule is slipping, you need to communicate this with your manager and project team. The way to think about this is that you should never keep your manager/project lead in the dark in such a way that when that manager attends meetings, they are surprised by something happening within their team or projects that they didn't know about, but everyone else did. Granted, managers have some responsibility to keep abreast of the latest issues, but individual engineers who are in the midst of all of these issues need to communicate them out. Also, as a test engineer, you need to enter all the defects you find and you need to communicate with project team members on these issues. You should exhibit this attitude of "no surprises" in everything that you do.

This can also extend to process improvement. Nobody likes surprises when shipping products. There needs to be enough unit-testing in place so that engineers aren't surprised by a bad build. Some form of beta or user testing needs to exist so that the project team isn't surprised by unexpected reactions from the customers after a release. Engineers need to develop good estimation skills and consider all risks in a project in order to come up with accurate schedules, so as not to surprise anyone by a slip in the schedule. I typically hear the phrase “our schedules didn’t account for all the surprises”. Remember how I mentioned that I "aim" for no surprises? It doesn't mean that I don't see surprises. And project cycles without much planning and definition are the best ones in which you’ll see these surprises - and they are the most difficult to move towards the no-surprises goal. Realistically, you can only aim for this and not require it. To continue to minimize those surprises, hold retrospectives or post-mortem meetings to determine where the surprises came from and how to eliminate them for the next project.

For managers, aiming for no surprises is a bit different. First and foremost, managers should never surprise people during review time with feedback that they hadn't heard previously and had a chance to improve on. Be upfront with your engineers and discuss all the feedback at length in previous one-on-one meetings with your reports so that stepping through review feedback becomes straight-forward and uneventful. Managers also need to know when to communicate issues and changes to the team to keep them up-to-date on new team strategies and on what higher level managers are thinking before they hear it from somewhere else and are surprised. The challenge there is to know what information should be communicated and what should not be (did you read my previous blog post on playing interference?).

“No surprises” is a good motto for everyone to try and follow. And if everyone in your organization can approach their work with this in mind, it can change behaviors, open up communication channels, and get the whole team to understand expectations in any circumstance.

Comments

• Anonymous
  January 19, 2011
  very educational as usual :)
• Anonymous
  January 19, 2011
  very educational as usual :)
• Anonymous
  January 20, 2011
  Thanks Rami!
• Anonymous
  January 20, 2011
  Excellent post! I guess this is part of the "Gray" half of "Colorful and Gray"... :-)
• Anonymous
  January 21, 2011
  Awesome post. Very well written, enjoyed reading it..
• Anonymous
  January 24, 2011
  Thank you.  My hope is that I can write down all the great things I've learned through my own experiences to help others get better at what they do and how they approach engineering work.