Having a team of motivated individuals with high morale will not only make working at your company more enjoyable, but also keeps everyone more resilient to burnout and stress. Jaco Prinsloo, Vice President of Custom Development at EPI-USE Labs, shares how he fosters and elevates team morale and individual purpose on a daily basis.
Jaco sees software development as intrinsically not a cookie-cutter industry: “It requires people to apply themselves and their minds, take ownership, and think things through for themselves.” Because of this, he makes sure every person feels like they’re driving the company mission with everything they do.
However, being people-centric doesn’t only mean caring about how well you can manage people; it’s also important to be able to understand what the intrinsic motivators are for the people in your team: “You wouldn’t micro-manage an artist,” Jaco explains, “because no-one considers them formula-driven. I think a lot of people still need to realise that the tech industry is a lot less formula-driven than they think.”
In his experience, micro-managing people and getting them to ‘do the work’ is actually pretty easy - but Jaco says it destroys motivation. More often than not, it removes ownership and makes a developer’s responsibility really unclear - which, for a lot of developers, is incredibly important for motivation.
For example, if an unforeseen issue, bug or error comes up, that wasn’t on the task list you were assigned, whose problem is it to fix? Jaco acknowledges this point, that good software requires creative problem-solving.
What has worked really well for him to mitigate this drop in motivation is to transfer ownership to the team and individuals. He does this by letting his teams choose their own methodologies for each project, and making sure he maintains a flat company structure.
Letting tech teams choose their own methodologies
As a team gets together to work on a project, Jaco says they are able to weigh different methodologies against each other and decide which they think will suit the project best. “For bigger projects,” he says, “where reaching a consensus can be hard, we have a bigger discussion and sometimes break into smaller teams.”
To make this effective, Jaco approaches this by adapting the methodology to the project, rather than the other way around, because it lets teams problem-solve for various things before starting a project. As a result, they take a lot more ownership for the decisions they make.
This automatically makes each person more invested in their project from the start, and Jaco has seen a direct impact on how well they are able to solve problems and challenges as they arise.
This process might look a little like this:
- A team gets assigned/chooses a new project to pursue.
- As a team, they look at what needs to get done, and how they could achieve it.
- The team then picks the methodologies and frameworks they think suit their specs and their strengths.
- Once a consensus is reached, they move to development and begin on the project.
- If a consensus is not reached, they seek advice from a lead or an architect, which may or may not be moved to a larger group discussion if consensus still cannot be reached.
Maintaining a ‘flat’ company structure
In Jaco’s experience, explicit hierarchies or ‘levels’ by seniority and experience don’t help people feel like they have agency, or like they are actively driving the company’s mission as an individual.
That said, “just flattening any hierarchy might remove it explicitly,” Jaco explains, “but it isn’t enough to remove the risk of any implicit hierarchy.” For example, even without formalised ‘team leads’, the loudest voices still tend to take charge and lead the way.
To avoid this implicit hierarchy, Jaco’s teams structure their daily operations to make any implicit hierarchy easy to spot:
- Rotating project responsibilities from person to person, project to project: Someone will be responsible for doing X now, and for doing Y on the next project. Jaco says his teams get better at the things they might not normally do, and share knowledge and experience across the team, irrespective of seniority or experience.
- ‘Flatter’ code review process: Any team member reviews code on rotation, regardless of their level of experience: “Everyone can learn from someone else’s code,” he says. “It doesn’t matter how much you think you know; reviewing code is an important skill for anyone to keep up.”
In terms of morale and motivation, flattening company structure in these ways helps individuals feel like they themselves play an important role – no matter how much experience of seniority they hold. There’s more ownership and motivation to do well, and Jaco has seen more productivity in his teams.
Over-and-above all of this, lies a core value that Jaco says is held by all of his team members: Trust.
If you show your team that you trust them to be the high-quality developers they were hired to be, Jaco says, each person automatically feels way more invested in doing their best work – even if it’s only to you and your trust in them. That’s enough to start building and developing a holistic motivation across the board.