The Not So Invisible Software Developer Support Structure
Software developers enjoy ‘invisible’ structure. Where they feel they are in charge of their own destiny. Can take ownership. But somehow magically all the other stuff that needs to happen, happens.
What is all this (not always so) invisible stuff? We’re talking about things like good facilitation, great process, tight interactions, devops, live system support, dealing with “what’s the next best thing to develop” prioritisation, UX thinking, UX delivery, graphic design, keeping the coffee stocked...
Part of the need for a good support structure for developers is they are most effective once they have established focus and flow. The inevitable noise resulting from delivering software that is used in the real world needs to be kept at bay in order to create an environment where a particular challenge can be the centre of someone’s universe until it is solved.
The other part is the reason the structure needs to be invisible. Developers don’t always understand the need for their support structure. It can be taken for granted and they like to feel like they’ve got it all covered. There is ego there. Useful ego. We want to create a space that results in ownership of a particular project / piece of work / task.
I write this after evaluating the situation at Tranzact and it feels like we have the potential for some meaningful change. Our process often bubbles up out of the unconscious — and with no evil intent — often breaking flow. Developers need to track down someone to review their work. They need to track down testers to demo their work. They need to submit their changes for a live release.
I think it’s ok for a developer to be responsible for moving a task through a predefined process. It’s not completely invisible but ‘push my code to the main branch’ isn’t particularly flow breaking in itself. Even getting a code review may be pretty innocuous if the developer can move straight from ‘dev complete’ to review without losing their train of thought. Juggling with a single ball is pretty easy.
In these examples one of the first flow-breaking characteristics is a need for coordination. Even with the best facilitator, coordination is inherently asynchronous. People aren’t always available at the very moment you need them. This results in context switching. A developer now finds themselves switching to the next task on the backlog while they wait for a code review, tester, UAT, live release.
Flow suffers, but so does ownership. At the point our developer switches to the next task, so does their deep thinking and their problem solving drive. At Tranzact we compound this with a sense that our manual testing step actually switches ownership. Even though the piece of work is still supposed to be driven by the same person there is a sense that the manual tester has this covered now and they will give a shout if anything needs to change. Repeat this sentiment again with UAT signoff.
The side effect of a loss of ownership is that by the time a piece of functionality makes it to the live environment the associated sense of responsibility is diluted. The side effect of the loss of flow is that once we get feedback from live there is a large re-investment to regain the context of the new feature. Loss of ownership and flow results in other undesirable side effects like lack of purpose, motivation, clarity of role etc.
The Big Hairy Audacious Goal is to create an environment / system where a developer can safely and without distraction take a piece of work all the way to a live environment without needing to context switch or transfer ownership.
The technically minded of us may correctly jump to software development practises like test driven development that provide good feedback and don’t break ownership or flow. Our team is not at a point where we feel we can rely solely on automated test feedback and I’m not sure even the most finely tuned one piece flow teams have eliminated pre-release human feedback or context switching. I think there is a need to incorporate the very necessary “human provided” feedback from role players like testers and the product owner. We want to do this in a way that breaks flow and ownership the least. We want to develop a heightened sense of responsibility in our developers and provide them the invisible structure they need to make the new demands realistic.
This article is about exploring awareness around process and the behaviours we want to encourage in our team and team members. I would love to hear about your lessons and solutions in this space. I hope to write about some of the solutions we adopt in the near future.