Managing people
Belonging
I've talked about hiring in the past, and how each new hire helps redefine the team as a whole. But how to approach that, so all team members find their place in this new context? It all comes to arousing a sense of belonging in every one of them.
A good addition to the team
Adding someone to a team doesn't necessarily mean they belong to the team. There is a vast difference between being part of a team, and belonging to a team. The former merely means that one takes part in various activities with other team members: discussing specifications with business, implementing solutions, reviewing code, debating the respective merits of different algorithms… This describes the motions team members go through, but doesn't say anything about how they relate to the team itself, and how fulfilling this context feels to them. The comply with existing practices, are asked to conform to the culture. This can bring decent results, depending on the expectations, but usually a mundane approach is unlikely to yield anything but mundane rewards to the new hire, the team members, the company and the customers. This also takes away the most important part of hiring: that of seeking meaningfulness. Instead of demanding to confirm, ambition to celebrate the differences, the creative ways people can complete each other. Expect to be surprised, and offer room for the unexpected to blossom.
Team tautologies
How can one achieve this? It can be tempting to look for ready-made methodologies to apply: some high profile companies have applied such and such, and if you want their results, surely you should be adopting their ways. Countless articles and books will tell the same tale: that of an organisation that has, at long last, figured out how to best define the roles of every member of any team. You only need to follow the manual to ripe all the benefits.
Today, this is as simple as getting a copy of the books Team Topologies and The Phoenix Project, reading them cover to cover and and implementing a modern, DevOps team. Before that, you could have put together the ideal Scrum team, as described in Scrum: How to do twice the work in half the time. Even before that, you probably would have found your inspiration in eXtreme Programming Installed. And before that, your model might have been the Joint Application Development. These methodologies span half a century of software history, and each one aims at fixing all the errors of the previous ones in shaping the clockwork-perfect organisation for a team. You can tell where this is going: it won't work. The reasons can include the usual suspects: pushback, misunderstandings, confusion, endless debates, frustrated ambitions. But none of these constitute the real reason such an approach is doomed to fail.
The sense of belonging
A methodology is simply a set of processes, and processes are what connect people to channel their interactions. As we were describing above, if a sense of ownership is what allows people to grow in meaningful ways, then to grow the team, people need to take ownership of it. In other words, to truly belong to the team, the team also needs to belong to its members. This means to have people own their own team, they need to get to work on improving what embodies the dynamics of the team: the processes, the services, the discussion forums, the knowledge management, the onboarding… This requires them to understand the place of each other, to develop mutual understanding, and formulate propositions based on that. Shopping for a methodology on the market, a pre-processed topology will never deliver here anything else than pre-processed results on their part: a short term change that is only the byproduct of a local, time-bound effort to play a role in a play written by someone else.
Like personal growth, growing the team is not something they need to deliver to you, the manager. It’s something they get to deliver to themselves.
← All posts