In a well established team, personality traits come into play. Here we group three main types that, when recognised and supported, can help the business and the technology team to thrive.
Have you ever worked with a fellow engineer who doesn’t seem interested in investigating new tools that are available? Have you ever met someone who annoys you because they push untested, proof-of-concept code into production?
These aren’t flaws in our engineering team members, they’re features. And when we properly understand and support them, each can be an asset to the organisation you work for.
I’m going to just add a caveat here: any ideas about how personalities work are just theories. We can’t really understand how people think, only observe the outcome. But having observed these traits in quite a few teams, and having discussed them with other people, I think I’m onto something that might be able to help you.
Personality traits
Each person on the planet has traits. Like being left handed or right handed, these are personal preferences that are deeply ingrained in all of us: although someone might work hard to use their right hand when they’re left handed, they will likely always be conscious that they prefer the alternative.
If you watch the personalities of certain teams in your organisation, you might find certain teams share common traits. For example, I’ve observed that HR teams often have common traits that have steered them towards a career in that field. I’m not saying everyone on the team displays those same traits, but its likely that many will to some degree or another.
And I think it’s likely that you are a leader because of the traits you have.
For simplicity, and to help us understand differences in individuals I’ve observed within a software team, I’m going to group them into three terms: “dreamer”, “builder” and “cultivator”.
I can’t take credit for identifying these groups myself: they were first outlined in this Reddit thread by user j_d_q, which I’m now expanding on.
The Dreamers: thinking big, not small
Dreamers think big. They’re the explorers of our teams. They are constantly enthusing about new technology or new ways of doing things. You’ll find them on Discord channels for Nix and Biome. They’ll use Arch Linux just so they can get the latest release of packages.
They are great at building enthusiasm in a team, and can help everyone keep up to date with new technology … as long as their enthusiasm is tempered (but not smothered) with a dose of caution. Leverage their energy by getting them to build experimental new features. Give them a business problem to solve without specifying a solution. It’s likely everyone on the team will be impressed with what they come up with.
Try to avoid asking these people to implement a simple feature that they can do in their sleep. If you do, they’ll either be asleep as they do it, or the’ll find a way to do it with this obscure new package they found and want to try out.
When they deliver, don’t expect tested, production-ready code. Instead rely on Builders to shore up their creations.
Builders: the glue that guides
Builders are great at, well, building. They’ll take the raw concept that a Dreamer has come up with, adding test coverage, improving type safety and generally making sure other team members can use it easily without it breaking unexpectedly.
Builders aren’t focused on concepts as much as they are execution: it’s more difficult for them to conjure up solutions without any guidance. If you ask them to, they could become stuck in a loop where they can’t decide on which approach to implement. Assist them by encouraging them to shortlist 2 or 3 approaches, then decide with them. This will give them the confidence they need to progress.
Leverage their love of documentation, clean code and automation to refine and protect code that needs attention or that is difficult to work with. Allow them to introduce coding standards and tools that free up cognitive ability for the whole team.
Use builders to solve problems that cultivators cannot because they’re engrossed in delivering on their current workload.
Cultivators: implementors that tend
Cultivators like structure. They see their role as tending to the land that the dreamers and builders have set up.
Have a project with a large bug backlog? Give it to a cultivator and watch them steadily and happily clear it.
They can take a product requirement that has a clear implementation path and be confident to carry it out. Anything well documented that has a lot of clarity, and less room for the unexpected and they will thrive.
Leverage their deep knowledge of the codebase by pairing them with one of the other types. Arrange regular check-ins to make sure they’re on track and don’t feel blocked by something that they deem as outside the requirements of the task.
Try to avoid giving these people a sketchy feature with no description and expect them to fulfil it.
Cultivators are essential to carrying out tasks that builders and dreamers would struggle with.
There are no rules
At the end of the day, nobody’s traits are set in stone; a left-handed person can learn to use their right hand pretty well. And traits are stronger in some people and not in others: there is a portion of the population that are ambidextrous and use both hands with equal aplomb.
As I said at the start, this is just a rough outline that I think can help leaders understand and work with team members who have different strengths and abilities.
We can leverage these abilities for the betterment of the whole team.
If you have the capacity, identifying and grouping different engineers according to project requirements can help you to fulfil them with greater speed and efficiency.
Understanding your team members this way can also help negotiate disagreements: if arguments erupt over different approaches engineers might have, you can point out respective strengths to dissenting team members. You can also work with individuals to balance their traits out a little.
Pushing every engineer to have the exact same set of skills isn’t going work to the best advantage of the team and could lead to some valued members withdrawing from the team or even quitting.
Instead, cultivate a happier and more productive workforce by respecting differences and using them to everyone’s advantage.