Recognition – Make it a habit

Image: psdgraphics.com

The company introduced a new recognition system some time back where by people can send a recognition card based on the company values. It was, and to some extent, avoided by some, distrusted by others, and completely unknown to the rest. The initial thought by many was this was yet another HR initiative that we'll all be forced to use and no one will get any benefit from it.

The company introduced a new recognition system some time back where by people can send a recognition card based on the company values. It was, and to some extent, avoided by some, distrusted by others, and completely unknown to the rest. The initial thought by many was this was yet another HR initiative that we'll all be forced to use and no one will get any benefit from it.

That is of course, until people started getting them.

I had one developer come up and tell me, “You know, I thought this whole idea of this system was lame, but when I actually got a couple sent to me, it actually made me feel good”. Bingo, that little centre of the brain fired up and triggered the dopamine associated with reward. It doesn't take much thought as a manager to find ways of rewarding people on our team, but it’s not a habit for many people and it does take a little time.  The net effect is that it has the chance to makes someone’s day. I can’t think why we wouldn't want to do this as managers.

Furthermore, people can reward each other. Initially there was a review process in place where the manager had to “approve” the recognition, but we challenged this approach as people should be able to raise recognition for anyone else without having a manager put a dampener on things by forgetting to approve or worse yet, rejecting the proposal. Seriously, who would even do that?

Cynics of this of course take it to the extreme (as they often do to prove the point) saying that people will “game” the system and raise countless recognitions for each other. But honestly, who is going to sit there at work and collaborate on raising a reward card for someone just so they can get one in return.

The fact that anyone can raise a card on anyone is totally awesome, especially in a development group. Developers are experts in finding mistakes, looking for problems, finding defects, but being good at those activities also makes them occasionally blind to the positive aspects of the work place. This gives people the opportunity to recognise the positive aspects of their work environment.

Doing a little research on the topic, I found a few things. People who receive praise feel appreciated, respected, more motivated, and more engaged in their work as a result. The increased dopamine levels also lead that person to want to experience that same feeling again which helps cement good working habits and behaviour. What stood out however was that research shows that the person giving the feedback often gets as much, if not, more value out of giving as the person does receiving. So, in essence, each “applause” card has the chance to make 2 peoples day, with all the positive effects associated. Who wouldn't want to encourage that?

Last year, I set myself a personal goal to recognise at least one person per sprint. It doesn't seem like much now, but it was an achievable goal I could build on. To help build the habit, I set up a quick survey as part of each sprint where people could give points out to the person who helped them out the most. This gave everyone an opportunity to contribute to giving as well as a chance to receive one of these coveted MVP awards. Most people really appreciated it and to be honest, it was an excellent source of data when it came to performance reviews at the end of the year. At the risk of getting into a discussion on objectives in an agile software team, I found this to be a great way of providing concrete feedback on people who are regularly being recognised by their peers for helping. I didn’t only enter recognition based on the survey, I also found myself looking for opportunities once I got the hang of it.

The great thing was that I was able to get a few nominations pushed forward for monthly recognition, and another even got elevated as a successful annual award. It felt good to see one of my guys up there getting recognised for the hard work that I know he put in, and I'll admit it, I felt good too.

So, if you’re not in the habit of recognising your peers, or people on your team, what’s holding you back? 

When Not to Ask For Advice

Golden Rule: Don’t ask people what they want if the decision has been made

I guess this seems like common sense in hindsight, but the impacts that I've witnessed for ignoring this rule have been significant impacts on any team or individual involved. This year, I've been on both sides of this mistake, and in both cases, the results were not pretty. 

What I am talking about is the scenario where decisions are predetermined regardless of the wishes and desires of an individual or team. This might be for any number of reasons. It might be that process is changing to accommodate interactions with other groups, new tools are being adopted, a management or organisational change might be happening, a new idea is being discussed, or maybe we're just asking someone if they “want” to do something. Whatever it is, if you give people even a “hint” that they have a say, then that comes with an implied level of responsibility for you to respect their recommendation, whatever it is (within reason). I'm sure this would be compounded over time if the team is used to being run by committee and they somehow get the impression that the decision is optional.

The concept of not asking if the decision is predetermined is not all that different to dealing with kids. While kids aren't technical experts, they do have thoughts and opinions of their own. If you ask a child what they want to wear to the shops, most parents will know that they are in store for a super-hero costume or fairy costume or the like. Going back from that is like trying to un-break an egg, and equally as messy. If instead you suggest they can wear the red dress or the blue shirt, in most cases you'll get one of the two options. If you need them to wear the red dress, then just tell them that they need to wear the red dress that day and be done with it.

For technical people such as in Software Development, one of the key things that people value is respect. People like to feel like they are the expert in their field, that they are the “go to guy” (or girl), that their ideas are valuable. In general, that their opinions, recommendations and advice is treated with the respect that their expertise deserves.

Depending on how it's delivered, asking a technical person their opinion can imply that you are not only interested in their opinion, but you are prepared to make a decision based on their expert advice. If that is not the case up front, then just don't ask. That might seem harsh on the surface, but really, it's not. There are many things that people are just fine to go along with if that is what is required by the company, even if they don't agree with it. Most people realise that being in employment means they are there to serve the needs of the organisation even if it's not what they “want” to do. 

When we seek someone's opinion in the situation where a specific outcome is required, there are really only two outcomes; they either come up with the option that matches the desired outcome, or they don't. It's awesome in the first case as now they feel like they have control of what is happening (be careful not to let that bite you later if you get caught), but if they don't come up with the option that you need, well, you've created a problem for yourself. You can take their recommendation into account and change the desired outcome which might not be an option, or you disregard the advice and show that you are deliberately disrespecting their recommendation. For any professional person, that's hard to swallow.

Even though a decision may have been made, the team or individuals impacted may need to be consulted to work through any challenges and issues that might arise. If you aren't the only one directly communicating the decision, it's important to be very clear with them that the decision has been made and what is needed is to to work on the details of what needs to be done in order to implement the decision. If they aren't totally clear (because you gave them the impression that the options were still in negotiation), there is a good chance that that will come through in how they deliver the message. As I said before, even the hint that a decision is not  final, is where the problem creeps in.

Summary

Another way to put this is that the use of a collaborative style of leadership when a more directive or even an autocratic style is required, can really backfire.

2012 Reflections - Multiple Hats = Delegation

2012 Reflections - Multiple Hats = Delegation

2012 was a hectic year for me. Probably the most challenging so far, even more so than the "Felix" year, but I might post on that another time.

Early in 2012, I was asked to help out with some product management tasks as the existing Product Manager had been taking time off due to an operation. Of course I accepted, who wouldn't?  After over a decade in software development, I was more than interested to get some exposure to different roles, and I get to do it from the relative safety of my current role.

Shortly after, it became a full time appointment by default as the Product Manager of the release, as the previous Product Manager left with short notice. It was a short term assignment until they filled the role with a permanent Product Manager. No problem, the project was already in full swing and wasn't due till later in the year. I still had my existing roles and responsibilities as a Technical Manager, but now I also had essentially a marketing position as well. Right time and place I guess.

The difficult part was that I was totally new to the role, so I didn't know what I didn't know. The state of “Unconscious Incompetence” came to mind. There was no hand over and no one assigned to help out. At the same time, we're transitioning the product to another group overseas, which introduced a host of other challenges. The Product Management role required tasks to be completed that I had never previously had experience with before including business cases, product definitions, licensing changes, EULA revisions, sales presentations, price increases, reviewing marketing documentation, supporting collateral, a host of internal tools and documentation requirements etc. Fortunately, there were some areas that overlapped, for example, I was responsible as a Product Manager for defining requirements for new features, and from a Technical Manager's point of view, overseeing the architecture, design and implementation. It was these overlaps which I found the most rewarding as I could leverage my previous skills in both roles. I'm sure by the end of my tenure, I climbed up the ladder as far as "Conscious Competence" in most areas, and I'm sure I still remain blissfully unaware in "Unconscious Incompetence".

I was conscious throughout this period of a pod-cast from “Manager Tools” that covers a topic called the Juggling Koan. Basically this describes that there are big balls and little balls (responsibilities or tasks) and it is your responsibility as a manager make sure that you focus your time on the big balls, and that means dropping some of the smaller ones. In the case where I'm responsible for 2 separate full time positions, that's a lot of big balls and even more small ones.

Staying back, working harder, faster and more efficiently, are the first things that are ticked off, but at the end of each week, there are just more things to do than anyone has time to work through. I think the art to this is try not to drop the balls, but to find other ways of getting them done, and that invariably involves relying on other people, sometimes other people who you aren't on your team.

Fortunately, I had a few good people who I could rely on to do some of the tasks that I just didn't have time for, either from the Technical Manager role or from the Product Manager role. I tried my hardest to ensure that as many balls were done as possible in any way possible, and some I was fortunate to be able to cut corners on or even cut out completely due to the overlap between the two roles. At one point, I was filling in for the Project Manager while he was away, fulfilling the duties of the Technical Product Manager, as well as the other two roles I had. I was able to get through quite a bit given the massive overlap between those roles, but I'm sure that there are still many things that I didn't do that I probably should have.

Some of those balls that drop to the floor just disappear as they might have a limited time or just weren't important enough, but others just pile up, and there is a part of me that still can't stand things being left undone. Looking back, of course there were some things I could have done better, but in general, there wasn't too much more I could have done. 

It was a totally awesome experience getting exposure to the business side of software development, but it also challenged me in more ways than I could imagine. I don’t regret any of it, but I'm glad it's over.