Saturday, 20 March 2010
Would you like fries with that?
One in ten.
That's how many managers I have worked with who have made me better at my job just by working for them. There were three things about them that made me a better employee...
They are direct
If they wanted something from me then they asked me clearly and explained the reasons why. That could include doing things to gain brownie points with clients; for political reasons inside an organisation; for urgency; or for winning or losing a battle that needed to be won or lost.
Most developers are not political animals. In fact, trying to make us that works the other way. We don't have the same drives as the fox in the work place. Gaining power and status doesn't attract us to the work we do. Developers who like that usually end up as managers or start calling themselves Architects. No, software engineers chose to work in this profession because creating something from nothing is what we enjoy doing. Bringing order to chaos. Finding patterns in a mess of requirements. Deconstructing an unfathomable problem domain and rebuilding it in technology.
Don't get me wrong, we aren't stupid or disconnected from the games played in the workplace. Most of us would rather be but we are aware the these dynamics exist and that no matter how illogical it is, we are affected by them. We often see them as an necessary evil that must be dealt with to get stuff out of our way so that real stuff can be achieved.
With that in mind, when the political manoeuvrings draw us in we would rather you just tell us what you need us to do to make them go away. I have had many a management type ask me what it is ok to tell the team. My answer is almost always the same: tell them the truth.
Manipulation to get us to do what you want is only going to come across as condescending and kinda stupid (on the part of the manager). We are grown ups. Be straight up with why and how and unless it's illegal or completely immoral then you will find that we are on your side and do want to help make things happen.
They remove blockers
What I do well, is build things. In my world it involves talking to a framework on top of an operating system, running on hardware in a controlled little utopia that (in the best case) helps someone do their job better or be serviced at a higher level. People talk of efficiency and cost-benefit and rapid delivery and usability. That's a lot of blah blah blah to me most of the time. I want what I produce to make a positive difference in the world. When I walk off this client site, it should be in a better state than when I arrived. Be that for the workers internally or customers and external agents. Whoever uses the system should be benefiting from the man(a) hours I put in to it.
Those hours are the hours I bill the client that add up to the how much the project costs and how long it takes. I'm a cog in a complex system of other cogs including other software developers, managers, analysts, business people, users, testers, and dozens of others who care about getting the project out the door. What I need from a manager is to not know what all the other cogs are going through, except in summary. I need to work with a person who can hear me when I identify something that is slowing my progress and use whatever means they have to remove that blocker.
The best managers I have every worked with removed those blockers systematically and efficiently. They heard the pain points we were experiencing and took them seriously. They did not pacify with promises of actions but instead did all they could to get us moving again or at least explain what was holding us up. Information will set you free. Keeping information flowing in to a team and out of it, then on to whoever else needs it or can use it to keep us moving forward is the key to being a good manager or leader of a team.
People who pacify the team and cushion the message to the client are only prolonging the moment until the truth bites and the pain bubbles up to the surface. It's just like patting someone with a dislocated shoulder on the head and saying "I know it hurts. I'll get something for that right away" and then walking in to the next room and telling the doctor that all the screaming is just the person in the other room, having a pillow fight with a bunch of teenage girls. It doesn't help anyone do their job.
Solve the problem by removing the blocker and keeping the lines of communication open.
They are part of the team
This is the controversial one. The one that I have argued with many technical leads and managers about. They say that to lead, you can not be part of the group. That leading means living outside the organism that follows you on the leash. It means appearing infallible to those above and those below.
A very respected project manager at a recent company I worked at gave me feedback at the end of a project that summed up to this: You can not lead a team and be part of that team because no one will do what you say. She was on her way to becoming a big manager in that company. Management loved her because she was one of them. Of course, she wasn't one of us. One of the consultants that went out there and did the actual work. Nobody trusted her. We all liked her and said she was very organised and did her job well but we didn't want to follow her anywhere. She knew how to be a good project manager but she was never a leader.
A leader doesn't need the authority of another person to lead a group, they need the authority of the group. I did tell her this and she scoffed at it. Interestingly enough, within a month of getting a good promotion she was out drinking with the troops and doing all she could to become one of them. Why? Because bossing someone around only gets you so far. People have to know you understand them and have their best interests at heart or they won't follow you anywhere.
The big thing a manager needs is to be part of the team. Not necessarily mates who go out boozing it up together but someone who suffers their pain and celebrates their triumphs. Someone who knows what coffees they drink or that they don't drink coffee at all. Of course they have to be organised and structured and good with clients but people always forget how important it is to be good with your team as well.
In the end, most of this can be summarised by one important skill... communication.
Tell your team what you want in a clear and direct way with the real reasons behind the request. Listen to the team about what is causing them to slow down and remove those blockers or talk to someone else who can. Get to know your team and let them get to know you. You have to spend a lot of your time with these people so they might as well know why your least favourite alcohol is tequila or that the client drives you nuts too.
Apple started a user experience trend many iOSes ago when it accepted Settings changes and did not ask for confirmation. Once the chang...
Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having...
After posting a quick how-to about Ruby-LDAP , I received a couple of very helpful comments that pointed me towards ruby-net-ldap . This is ...
It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of ...