Too Many Hats

[James Beresford]

I’m coming to the end of a project and contemplating some of the lessons learned during its near 9 month duration. One key one I’ve taken away is that in the middle of the project we had a bit of a resourcing issue and my role was expanded to cover more activities – from pure architect to hybrid architect / project manager / senior developer. Not a problem in itself – as a consultant you expect to wear many hats – technical expert, customer relationship manager, architect, sales guy – it’s all part of the fun of consulting. However I found myself on the hook at one point for a hat too many – and that hat was the easiest for me to wear – the developer hat.

The difference with the developer hat is two-fold. First up, you have hard deliverables. If you are a bit late with a project plan, or your architecture isn’t quite complete – life can usually move on. If your code is late, you start holding up other developers and raising red markers on the project plan. Of course the code you get allocated as a senior guy is not the easy stuff, but the bits where dragons can be found – so the odds on it being late goes up. Which leads to the second aspect – you fall under pressure because your code is late – and under pressure you focus on what you are comfortable with dealing with – coding – and everything else gets left by the wayside.

Consequently the other activities on my plate began to lose focus – notably the project manager related ones (organisation is not my strong point anyway) – and the project began to suffer because soft deliverables can slip… but only so far. Thus the pressure rises and my head stuck itself deeper in the tasks I could deal with and knew I would get called out on.

The tl/dr summary of this is that when doing multiple roles on a project:

• Hard deliverables add significant extra pressure to your role
• It is easy to unintentionally put more effort into the role you are most comfortable with (especially under pressure)

Get More from the original blog...