I have worked on a few teams over the past few years, and I can definitely confirm the well-quoted adage:
“Managing developers is like herding cats”
holds true about myself, and most of my colleagues. I have observed my own response to different management styles with fascination, and it could help Project Managers a lot if they understood this, often counter-intuitive, behaviour.
1. You can allow me to be frustrated but by no means let me get bored
One of the most satisfying projects I ever worked on was my first BI data warehouse project, and I still hold every team member from that time in very high regard. We worked long hours under a lot of pressure and client scrutiny and I still consider the final data warehouse the best I have worked on in my career.
I recall telling my Project Manager Mylo that he should know that I am bored when I start googling crochet patterns. He took it to heart.
Why did I love working so much overtime and under so much pressure?
- The team had a high sense of cohesion. We trusted each other and felt like we belonged
- The work was focused, correctly prioritised and communicated well on a daily basis
- Every person on the team understood the value and need for what we were working towards and believed that we were adding value
- I was learning daily
- It was hard, very, very hard
I also recalled a really tough period on my current project where I was working a lot of overtime, became sick, and could not take sick leave for a few weeks. After the third week I ground to a halt and pushed back, and jumped into bed. At about 3PM I got a call from my client in New York about urgent work that they were just not getting right. I won’t acknowledge this to my Project Manager, but I have never been so relieved in my life. I think five hours sick in bed is my threshold before bed-depression kicks in.
2. I need to know my work delivers meaning
There is nothing as demoralising as churning out code, deploying it, and never hearing about it again. Account Managers, Project Managers and Business Analysts usually get more client facing time than the developers, and naturally starts behaving as a buffer between clients jumping up and down and the rest of us. This is good, this prevents distraction. Unfortunately, this also means that we don’t hear the client’s thank you’s either. We often don’t see the difference our work makes. We need to know that our work alleviated pain.
We need a positive feedback loop where we hear the stories from users about our work. It is a great motivator.
4. I can time manage, stop micro-managing me
Good Project Managers are usually ‘listy’ concrete kind of people. They like spreadsheets with numbers and dates tallying up. It makes them sleep soundly at night, it allows them to give clients concrete answers. Unfortunately, they like to respond to pressure and uncertainty by adding more details to their lists in their spreadsheets. They break tasks out into finer grained sub tasks. They refine their gantt charts into abstract art resembling deforestation in the Amazon. This is not good for developers. Asking me how I am progressing every half an hour instead of every two hours is not going to make me work faster. It is going to break my train of thought, pull me out of my ‘zone’ and make me mute my IM.
There is also the classic, frantic, ‘reallocation salsa’ where a dev is perpetually pulled off high priority items to put out other urgent fires. You are just going to end up with one sad, emotionally drained, confused developer with a long list of half completed urgent tasks.
On the other hand, a good Project Manager acts as a buffer, keeping track of my prioritisation list and effort estimates and has an open line of communication with me throughout the day. I believe this relationship is one of the sancrosanct requirements of a healthy dev team.
5. I need a community of critics, not cheerleaders
In my current role I don’t work with a large development group, rather I work as a developer in close collation with my DBA and Project Manager, sometimes roping in an additional QA. I miss having a close team working in the same headspace as I am. I feed off people, I learn from them and they hold me accountable. Team members should debate best practice with you over coffee. Team members should have a score board of build breaks where the person with the most points does coffee rounds for a week. Working in teams, especially with frustrating, complex, sticky people is like having siblings. They keep kicking you on the back seat of the car, but they teach you resilience and force you to learn.
6. I need to see the big picture
I need to know where we aim to be in six month’s time with a project. I need to know where I aim to be in a year’s time in my career, even though it will probably change. I need to see a big picture within which to slot the work I engage with today. If I don’t have that, I lack vision, I lose momentum. Momentum and belief in a bigger picture is one of the core motivators without which I will start considering moving on.
7. I need work that I don’t know how to do
If I find myself looking back over six months and can’t identify ways in which I have grown professionally or technically, I am in dire straits. Rather throw work at me and see me fail than give me the same job I know how to do over and over again. Life is too short to do things you are already comfortable doing.
In essence, all of these points can be summarised as, challenge me and make me as uncomfortable as possible and see me claw my way out. I think managing a balance between this sentiment and actually providing me with the support and infrastructure I need to deliver is the elusive tightrope walk we call ‘cat herding’.