Understanding Developers and Timeprofessional developmentteam interactionproject management
Project managers (and clients) view time very differently from developers. It's not just in the way we structure our thinking in order to work, but in order to plan and decide too. On 2 occasions recently I have been able to manage expectations better in order to allow both managers and developers the space to complete their respective tasks.
I was surprised how these two events happened in such quick succession of each other; yet belie a lack of understanding between the two parties which is a strong argument in my mind for manager - developers.
On the first occasion, a developer working on a key project refused to answer the account managers' calls. With a fast-approaching deadline the account manager understandably began to worry, and therefore became more persistent in their pursuit of a reply from the developer.
On the second occasion, a friend asked me to get in touch with his web developer for him, as she had seemingly disappeared. After three weeks he had seen no results for a project that he had been told was almost finished.
Deadlines As Guidelines
A deadline is, to a developer, a guideline. If it was not, then we would not have the thinking space necessary in order to complete our work.
This was brought to my mind recently when a database developer friend of mine said that his manager was persistently stressing the urgency of some work that needed to be done, but the developer was calmly working away. It may have seemed very neglectful behaviour to the manager. But then the developer told me about the potential consequences.
"One wrong keystroke and I could have messed up the entire database. If I hadn't taken appropriate care, the 1 hour job could have turned into a couple of weeks."
This is part of the reason we have a comparatively high hourly rate too: making database changes is easy; doing it whilst taking the appropriate cautionary measures (and not messing it up with a wrong keystroke) is where it really counts.
Also, in order to be a successful developer, one must be able to focus on the task at hand. That means that social media, office chit-chat and even lunch breaks and finishing times might be changed significantly in order to concentrate on the workload.
So in our first situation, I knew that we could have confidence in the developer. And if we expressed our need in a calmer, more undemanding manner, we would be more likely to get a reply that we needed.
Sure enough, once we'd asked him in that way, the answer came and the site was ready in good time.
Three Weeks isn't a Long Time
On my second example, after talking the situation through with my friend, I found out that he had asked her to provide an ecommerce solution in addition to the website she had built. This wasn't part of the original brief.
Straight away I knew what had probably happened: once ecommerce was added on to the project, she was faced with a huge amount of scope creep which she didn't verbalise (from either lack of confidence or not knowing how to explain it, which is a big problem in our line of work).
In order to be a successful developer, one must be able to focus on the task at hand.
Whatever reason it was, I suspect hearing the words "adding a shopping cart is easy, isn't it?" is enough to send a timid developer scurrying.
Once I knew that's what happened, just saying the words "three weeks isn't a long time" was accepted; a brief explanation that "adding a shopping cart" wasn't a small job and that he shouldn't lose confidence in her, was enough to ease the situation.
Developers As Managers
It's been argued before (and I wish I'd saved the link so I could share it with you) that developers should be encouraged more often to take up the role of management.
Having a Project Manager who is also a developer means that communication flows much more easily and problems can better be forseen and avoided. Management expectations can be dealt with in a much better way, and developers can have the appropriate space to discuss their concerns and better verbalise where there are problems.