What would happen if a manager dissolved several teams, put all those employees into one room, and asked them to group themselves into new teams, based on upcoming business objectives? And to further complicate matters, what if some of those employees had never worked together before? Would they be able to self-organize into happier, more productive, and more efficient teams? Brian Schmitz, NewsCred’s VP of Technology, sought to find out when he asked his engineering squads to self-organize. Here’s what he learned.
At NewsCred, our engineering team is designed to work accordingly. We have 25 people organized in small, cross-functional squads of five to 10. Each includes a Product Owner, Coach, and Developers.
Because there are so few people, we can’t afford to assign developers specific roles. Squads own all aspects of their problems and solutions, from beginning to end. They’re responsible for identifying and prioritizing issues, coming up with potential solutions, and working directly with customers to address problems. Squads figure out how to best attack an issue by leveraging their collective experiences and skills. There is no hierarchy within agile squads – an intern has equal standing to a 10-year veteran.
Despite the collaborative nature of our work, we still faced a recurring issue: Every few months, personnel, business needs, and customer problems changed. To set ourselves up for success, we’d have to rethink and readjust our organization. Sometimes those changes were as small as moving a person from one squad to another to get the right skills balance. In extreme cases, some squads were dissolved and new squads formed.
No matter how minor or obviously necessary the change, it was always labeled the dreaded “reorg.” Morale took a hit. Team dynamics suffered.
As agilists, we strive to embrace change. But these changes were just too disruptive.
I racked my brain for solutions and found the answer right in front of me: Self-organization.
I didn’t need to tell the developers how many teams we needed or who should be in what group. They knew better than I did.
My thoughts swung between exhilarated and nervous:
“One hundred percent buy-in to a reorg!”
“What if the org they come up with is bad?”
“Motivation and morale should be great!”
“What if cliques form or junior or less vocal people feel ostracized?”
“I definitely shouldn’t be in the room when they decide.”
“I must be in the room to make sure it doesn’t go off the rails.”
I realized I had a problem if I, the agile advocate, was questioning my own proposed solution. Upon hearing my plan to let the squads self-organize, the executive team would be even more nervous, and try to convince me that I was crazy or radical.
I talked through my concerns with a peer who pointed out that my worry signaled a lack of trust in my team. Through our conversation, I absolved my fears and solidified my conviction to the point where I could defend my decision and guarantee to the execs that the outcome would be successful. I also determined that I would facilitate the self-organizing discussion, so I could stop worrying that things would go berserk.
We have since gone through three self-organization meetings, approximately one per quarter. It’s been a great success and we’ve uncovered many learnings along the way.
The First Self-Organizing Meeting
I kept the the first meeting’s agenda a secret. My group had a two-hour all-hands scheduled to discuss the upcoming quarter, and I planned to make the big announcement there.
We started with an exercise where everyone brainstormed their skills and interests. Then we reviewed the near-term business needs and product roadmap, clustering the problems we would tackle into three themes, and outlined the skills needed to successfully do so.
After that, I revealed the true objective of the rest of the meeting: For everyone to self-organize and walk out the door with new squads decided.
Here are my key learnings – many that feel obvious after the fact:
Self-organizing takes time. I grossly underestimated the amount of time needed for 25 people to self-organize without preparation. The meeting went on for nearly four exhausting hours.
Transparency is the best policy. The secrecy was of no benefit and prolonged the meeting. Team members who are more comfortable thinking through problems and who certainly didn’t appreciate being rushed into such an important decision were particularly aggravated.
Be aware of unintentional anchoring. While useful, my long-winded setup took about an hour, which was excessive, given my real agenda. The theme-clustering exercise ended up anchoring the discussion to existing squads that corresponded with the themes, as opposed to opening a meaningful discourse on what the new squads should be.
A collaborative meeting of that size is nearly impossible. It was hugely challenging to give all 25 people a chance to voice their opinions.
In the end, all but one person agreed with the collaborative proposal. When asked what he would suggest instead, the clearly shaken dissenter agreed to move forward with the plan.
Following up with me privately afterwards, he confided that he didn’t know how to voice his objection without offending his peers. His main concern was that the team he was to be on was under-resourced without enough experienced developers.
And with that, another learning:
Set communication expectations and coach participants on honesty and respect prior to the meeting. This would help create an environment where everyone feels comfortable speaking up.
Our Next Attempts
Three months later, I used the learnings from the first meeting to prepare for the second. There were no surprises – participants knew the agenda before the meeting. To address the facilitation issue and try to ensure everyone had a voice, we broke into multiple groups to come up with their own proposals.
However, without a clear facilitator for each group, the breakout sessions took longer than expected. When we reassembled, teams presented their ideas, all of which were fairly similar. The discussions resumed to try to reach a consensus, and we ended up with another marathon meeting that eventually ended in a stalemate. I had to synthesize their proposals and communicate the final decisions after the meeting.
Before our third and most recent attempt at self-organizing, I pulled a few natural leaders into a room and asked them to come up with proposals in advance. Effectively, I wanted them to work with their peers to arrive at the real decision before the meeting.
Over the course of the week, they held many small group discussions. When we finally had the meeting, a single proposal was raised, and everyone quickly ratified it.
In the end, not everyone liked the self-organizing process – there are some who would prefer that there were no changes, or that decisions were still made from the top-down. But I found that while self-organizing doesn’t please everyone, it gives people choices, creates greater transparency and motivation, and ultimately is preferred even by those who are averse to change.
For anyone looking to attempt self-organization at their companies, I have two final words of advice:
- Don’t expect success after a single meeting. Self-organization takes time to eventually become an organic process. The ideal outcome is for everyone to feel they had a say in the final decision. You’ll need several attempts at self-organizing to figure out the right system for your teams, and to ensure everyone feels comfortable voicing their opinions.
- Give your team your full trust. Self-organizing is about letting your employees reach their own consensus – it’s helpful to remember that when you’re fighting the urge to intervene in their decision-making. With that in mind, trust that they’ll come up with an optimal outcome, and offer your support and direction to facilitate healthy negotiation and debate, to get them to that place.
Originally published on Sep 26, 2016 10:00 AM