Structure unlocks talent
My first experience working in a UK startup began a couple of years ago. The engineering, design and product team at the time was very small, and with an increasingly popular mobile app you would expect tons of features being constantly delivered.
In fact the exact opposite was happening.
Several were the reasons, but it was immediately clear to me that one of the main problems was that everyday the team was experiencing a new adventure.
Although this might sound like fun the reality is that on any given day you could expect either a new user story to jump in the current sprint, or an (apparently) urgent backlog grooming session, or a new project kickoff, or a new technology being introduced, or a change in the development process (!!!).
Trust me, it wasn’t fun. The result was constant loss of focus, low productivity, high frustration.
I knew the team needed some structure but how do you keep creativity, excitement and that sense of adventure with something boring like a structure?
Well the answer is very simple: structure is not boring at all!
The opposite in fact. With the right structure and processes in place people don’t have to spend time wondering what should happen and when or whether they are doing the right thing at the right time. They can instead plan their work and activities effectively, they can focus on what they do best and ultimately they will feel “safe” in the work environment.
This is where an Agile methodology like Scrum for example can be incredibly successful (if done right!). In fact one of the main pillars of Scrum is the cadence of key appointments: no need to wonder when it will be the right time to…
- …discuss upcoming work and prioritise the backlog, there’s a recurring backlog grooming session for that
- …plan the next iteration, there’s a recurring sprint planning session for that
- …share with the rest of the team the progress made in the last iteration, there’s a recurring sprint review for that
- …discuss areas of improvements with the rest of the team, there’s a recurring retrospective for that
- …update the rest of the team on progress and discuss the plan for the day, there’s a daily standup for that
Can you see it? In a typical 2-week sprint setup out of 80 working hours, 75 hours or so (yes, planning sessions can be done in 1 hour!) are for coding, prototyping, user experience and architecture design, tech spikes, etc.
I’m not advocating Scrum as the methodology to use, it’s just an example. There are many other ways to do software development which can be just as effective, but they all have their own structure because structure is needed to unlock talent!
Unfortunately at first not everyone in the team understands it. They may see structure and processes as unnecessary and ultimately as blockers rather than enablers. I believe this either comes from inexperience or fear of falling into scenarios where structure is no longer in place to solve problems, like it tends to happen when companies become “too big”.
Luckily the key to prevent or change this mindset happens to be also the only way any structure or process can be effective: make sure people understand the why behind it.
The last thing you want is your team to adhere to a framework just because they are told to do so. This may have a hugely negative impact in people’s motivation and passion and in their ability to work together efficiently and effectively.
On the contrary if your team understands the principles behind a certain framework, they are more likely to buy into its value, to make it their own and evolve it to meet their needs.
This is something incredibly hard to achieve, especially because engineers tend to not see processes as “real work” as much as coding (something I will talk about in another post). However it should be the main focus for any tech leader who is trying to build a passionate and efficient team where everyone can express their talent.