Listening to others

As lead developer part of my role is to ‘know’ the answer to things and to identify solutions to problems. Also part of my role is mentoring other developers on my team, to nurture them and help them grow as developers. Sometimes the two sides of my role would seem to be at odds with each other, on the one hand I’m expected to be the authority and on the other I need to step out of the way to allow others to shine. I have to say that I don’t see it this way, yes I do need to know the answers but I also need to listen to others their answers may well be better than mine.

Yesterday a problem with one of our websites was reported to us – it was to do with a new access role that had just been added to the system, people in this role were getting access to part of the site but then being unceremoniously blocked when they tried to access the restricted section. I say unceremoniously, what I mean is they got a nasty error (but that’s another issue). I discussed the problem and agreed a solution, then went to discuss the solution with a member of my team. I began explaining the situation and my solution but this developer had already become aware of the issue and had thought of a different solution to the problem.

We chatted about the different approaches; neither of which was a clear winner, both solving the problem but from a different angle. I left the decision as to which approach to use up to the developer and was a little surprised to be asked whether that was ok! I trust the decision. The developer was able to sum up the pros and cons of both approaches but favoured their own approach – that’s fine by me, I’m not precious about my code if there’s a better way of doing something then I’m open to hearing about it and trying it out. This shows others on my team that they can make their own decisions and choices on how to do things and that I’ll support them and help them when they do. My role is to support them and their learning and that means handing control over to them.