Archive for the ‘management’ Category
Star performers
I am pleasantly surprised with the vast array of books that are now available to our RA library. Never knew they own that many books.
I’ve read parts of this interesting book: 201 Ways to Turn Any Employee Into a Star Performer by Casey Fitts Hawley
Some stuffs that I get out of the book (things that I can relate to).
Casey suggested that companies should have a (long term) development plan for employees. However there are some factors (myth) why business might shy away from this
- Once developed, the employee will leave. Casey says, the good ones will leave anyway. But if possible moves this person to another role/position IN the company.
- Development takes a lot of time from the manager. Casey says managers will spend a lot of time in fixing the problems anyway if there’s little development taking place. It’s better to spend time in positive management tasks she argues.
Some of the problems of great employees:
- Move out to another job opportunity faster (higher turnover rate)
- Burn out more easily
Managing Great Employees’ Turnover
Spending time and attention to your great employees will have better ROI than spending time with the problematic ones. The cost of losing great employees is astronomical. It’s a highly likely that your great employees are being constantly approached by headhunters, family, friends etc for job opportunities.
Nicholas Stern says:
Create a culture of exclusivity so people will see working for a competitor as a step down.
Managing Great Employees’ Burnout
Great employees are dependable and high performing, they continue to push and push to meet the goals set for them and their own goals. But often they do this at a cost of their personal life and health.
By the end of the year, the burn out employees will look for another position since a failure (incompentence, which might occur due to their burnout) or a half hearted effort is just not good enough for them. The problem with these star performers is sometimes they can’t bring themselves to cut back or ask help from management, hence starting afresh elsewhere is more tempting proposition.
Possible remedies:
- Ask the great employees to think balance first, make it their responsibility to achieve this balance. Ensure employees that you are committed for them to achieve this balance. Recognize them as total person not just an employee.
- Offer self improvement opportunities, these people are usually life long learners, they will be frustrated if they are not given opportunities to learn.
- Offer variety or even job rotation if possible.
- Simply ask them to design their ideal job and learn from the answer. You might be surprised of the mismatch between management perceptions and employees perceptions of what constitute ideal.
To sum up:
Invest in the great employees will offer the greatest payback in productivity, innovation and contributions.
How would you rally a wounded troop
If I were in charge of a team/company, how would I rally your troop in the wake of people leaving?
What do I need to do to contain the damage? Not only damage to the business but more importantly the damage to the team’s morale.
How would I dispel the compounded negativity? How would I prevent other to follow suit?
I need to address the team with the following:
- Honestly admit that there is something wrong
- Quickly do a survey on what people are feeling, it has to be anonymous otherwise the quite ones won’t speak up their mind
- Hold a meeting with the team to address the issues from the survey and work it out from there
- Ask what sort of environment or working condition that the team would be comfortable and happy with. If this is not aligned with business expectations, then something got to give, perhaps adjusting business expectations is less costly than employee leaving.
I need to retrospect what is it that my company can offer that other companies can’t? And nowadays in the candidate tight market, attractive renumeration alone is not enough.
I also need to do research on who will poach the talents from my pool and what do they offer that I don’t at the moment?
After the dust settled, I would need to inject some positivity, I probably suggest a team building activity, but not just a once off, it needs to be regular. At my old workplace, weekly soccer and daily coffee breaks helped people bound very well. I would have more non work related conversations more with the team, I need my team to be comfortable talking to me about their concerns. I need to be able to read the signs of someone looking to leave and do something about it and not to be caught off guard.
It’s really tough, but this is dangerous situation, it needs to be managed not ignored.
Just thinking out loud and shaping myself to simply not just only being able to identify problems but to provide solutions. Anyone can find problems, but not many want to find solutions.
Who dunnit
When things go wrong within a project, I often find people start pointing finger to other people. I guess it’s human nature to always find scapegoat rather than owning up.
From developers point of view, management is the usual target to blame. We tend to think management is not competent, not able to stand up to the clients, not able to cut the loses short (borrowing share market term here), not able to mediate developers and clients, always put up with clients because of the “potentials” (some call it second stage of the project, some aptly called it a mythical creature 
). Management (and developers) will then point the finger to the client, as the client is usually fickle, changes their mind every single minute, is slow in signing off but wanting quick results.
Oh and I haven’t even brought the designers into the equation!
I personally think that we can do better by actually looking at ourselves, introspecting, thinking ways to improve ourselves before blaming the others. It might be true that they are to blame, but I would like to think if a project goes wrong, everyone is at fault. We as developers should improve, we probably can code a bit faster, improve code quality, produce less bugs, not coding too rigidly to the spec (which will cause a nightmare when client changes his mind).
I admit that clients do make me frustated a lot of times, but I now realize this fact: Clients WILL CHANGE their mind and their decisions. They are human, human change. Also it’s worth to note, if you are dealing with bigger clients, the people who are involved in the project might change over the time. It’s the easiest to blame the client, but that doesn’t get us anywhere, we can’t possibly demand clients to not have a change of mind AT ALL (it would be ideal from development point of view, but might not good from marketing point of view). I have some thoughts on how as developers we can do better with requirements change, but that’s going to be another post.
And frankly, I am also quite tired, hearing developers blaming the management. Project managing is hard work, project manager has to satisfy both clients and developers (and bosses), so cut him some slack. Sometimes developers think they can do better job as project managers, can they really?
I just got tired of this blaming game I guess. My principal is don’t blame anyone for your project failure, look at yourselves, is there anything that you can improve/learn from this failed project? Before starting to blame someone look at yourselves, could it be that it’s you who sabotage the project?
WHo dunnit? WHo killed the project? You know what, it might be you.
Rules to better team members
I stumbled across SSW’s rules to better team members and rules to better project.
I haven’t read much of the later, but I read most of the points of the first one. There are good points there, although most of them are just common sense. Having said that, common sense is not common, is it?
I would want to see whether the points preached are also practiced there, but at least having those points compiled and put up for everyone to see is a good start. I would like to see lists like this for our company and that people are actually working towards better work environment and process.
These are points of interest:
- Point 13 turning free work to billable hours. On my terms, this means do not be too lenient to our clients (ie doing lots of free work) and do not over estimate your capabilities to deliver, eg if you promised to do something in x hours of time but turned out that it actually takes x+y hours, then of course you have to work the additional y hours for free.
- Point 8, persistence when you think some things need to be done and create a list somewhere to store your thoughts on these things. I think this is an excellent point, I have done this for previous company, I created a list of things that they can improve on, but I somehow I just didn’t give the list to them when I left and I can’t remember exactly why. I probably should start my list and give it to my boss (before I leave).
- Point 38, knowledge sharing. I am a huge fan of knowledge sharing, I set up a Wiki at my old workplace (which unfortunatelly hasn’t been updated since I left) and tried to put up some of my knowledge and experience in my current workplace’s wiki and chase up the Chief Architect to put up his as well.
Some points that I think are questionable (and a bit silly):
- Point 74, always carry a thumb drive.
- Point 34, don’t listen to music at work. I actually can understand this point, but I personally think listening to music helps me a lot in tasks that require undivided attention.
- Point 52, speak correct Egnlish. What happen if you are not a native english speaker? Surely you can forgive someone having grammatical or pronounciation errors at times, as long as he can communicate well.
All in all, it is a good guide to read up and to reflect, kudos to the SSW to put it up on the net so that others can benefit.
