Back

So basically

Over the past few months I have been paying particular attention to improving my skills as a leader. I've decided to start writing about my leadership experience as i've found writing has really helped my technical skills.

I work in a small team of 5 people. We are small enough not to need a dedicated project manager, so it's something I've been taking on. Each day I'm usually on the phone directly with the customers or at least in contact via email, essentially acting as the conduit between our team and the developers.

One large benefit of the project manager/developer hybrid role is that it's really easy to play the So Basically... game and translate client requirements into technical requirements. Why do I call it this? Well it's because developers need concrete requirements, something that isn't all that common when working with clients who aren't tech savvy. In my experience, most developers love when they receive a descriptive requirement and even a sketch of what the end product should look like. Without a solid requirement, developers need to context switch into project architect mode which is not necessarily their specialty.

There was a period where I experimented and took a back seat in project management - seeing how developers would work with raw requirements directly from the clients. When I did this something really stood out to me. I noticed that the developers would constantly try to simplify the requirement down to it's base level and usually follow up and ask something like 'So basically the user wants to be able to change this and that'. Lots of development time was spent just analysing requirements and converting them into technical ones, sometimes incorrectly, especially with those that had context with other requirements. But it was interesting to me that the why wasn't all that important, or maybe it was, but just not at that specific time. In the end less was achieved, mostly because developers had to constantly switch between development and designing.

As I write this it sounds so obvious, but for me, it really challenged a previous belief that developers should be super close to the client. Don't get me wrong - I think it's still really important to give developers a good idea of how their ticket fits into the rest of the project. This is one way we can easily foster intrinsic motivation by giving our team Purpose. But I also think it's really important to have a dedicated someone who can create detailed, contextual technical requirements that can be easily understood by the development team.