I had the great pleasure of attending a webinar presented by Judith Umlas called the “Power of Acknowledgement” (http://www.iil.com/poa/about.asp). In addition to being gracious and attentive to each member of her audience, Judith’s message is extremely important for not only general management but project and disaster recovery managers.
What does the impact of acknowledgement have on participants in technology programs and projects? By the responses in the webinar and my own experience, it can make or break the project. We are all human and we all have bad days. But making the attempt to really understand each individual in the project and disaster team helps us to better understand how people will react when an incident occurs or during the critical aspects of a project. It is savings in the bank during those bad days or critical moments.
There are many ways to acknowledge what each member of the team brings to the table: 1) Writing thank you notes to their management and their management (for annual staff reviews); 2) Understanding their schedule and responsibilities to their primary technology team before setting deliverables - especially those in the critical path; 3) Working with their manager to take personal lives into consideration; 4) Giving them the opportunity to present to the team; 5) acknowledging team members’ approach to their deliverable or to the overall deliverable; 6) identifying when team members go beyond the call of duty or think of solutions “outside-of-the-box” and 7) not passing on Management pressures to members of the team.
Everyone has something they love about their work. Acknowledging this to them through direct communication or to the team through these various means, makes the difference.
Understand that you may not be appreciated by your management for recognizing the team or individuals in the team. In some corporate cultures, it is frowned upon - for whatever reason. However, a simple query before hiring or upon starting the engagement will tell you whether management approves of team/staff acknowledgement or how they prefer to handle this. But, either way, I will never understand how acknowledging members of the team could be taken as a negative action. So be forewarned, and ask whether providing acknowledgement to the team/participants is permitted and how acknowledgment is made - and if the answer is “That is not done here,” you may want to re-think your engagement.
Another important aspect of providing acknowledgement to individuals is that it is clear that you live by, “Giving credit where credit is due.” Someone once told me that they are acknowledged by their management and peers - by how talented they are as a result of the team and individuals working for them. Part of that is not taking credit for the good work that is performed by members of staff, the team or project. It is clear, anyway, what your capabilities are and it will not take too many thought cycles for people to realize what you can or cannot provide by the way of technical, engineering solutions. So, be honest right away - and acknowledge the source of the great idea.
I learned about team and individual acknowledgement during 9/11 - while managing the rebuild of back office operations of an impacted financial institution. Acknowledgement is particularly important during and after disaster incidents - as this may be the only life-line you have to maintain staff loyalty and presence. After an incident, no matter how catastrophic, if people do not feel accepted through acknowledgement, they will leave - so fed-up with the stress of the incident, that sometimes they cannot deal with going back to a company so that so ill treated them. Staff retention is one of the biggest risks after an incident. Staff acknowledgement can mitigate this risk.
Remember that acknowledgement is free and takes little effort. Good people show you who they are by their existence. Change your world and take the risk of opening yourself up to something that feels good for both you and your team — and that yields results in ways that you cannot imagine.