Be the 1 to Put Skin in the Game
Few things in life are both rewarding and terrifying as working at a small company. There are 17 of us, that’s it. A seasoned and proven firm by now, Analyst1 is far from being a startup, but the team is small. And the rewards of being part of such a lithe and nimble organization are many—feeling valued, camaraderie, ownership in the wins, opportunities to shine, and more—but the price each person must pay for this is skin in the game.
It was this responsibility that I sought out in leaving a much, MUCH larger company when I came to Analyst1. I wanted to feel the excitement and weight of knowing that my contributions truly mattered, that if I didn’t carry my weight, the whole team would suffer, and that when we succeeded, I had played a meaningful role in that success. I wanted a chance to learn from the best (because a company this small must surely hire the best to survive), and I wanted to be pushed beyond my limits (because each person’s work might be the difference between success and failure).
In joining this team, I have found all of these things and so much more. I found a culture that takes the initiative, swarms on the problems, shares knowledge, and owns the results.
Taking the Initiative
At my last job, I was one of more than 70,000 employees worldwide. I was another cog in a machine that had forgotten how many cogs it had and, possibly, even that it was made of cogs. Before that job, I worked as a civil servant for the federal government. Employees at either of these places can find ways to hide for an entire career carrying little to no personal responsibility. While this may be comfortable for some people, for me, it was largely unfulfilling. Sure, occasional projects with tight deadlines forced everyone to jump into action, but these were the exceptions. I remember loving those times because I did not have to actively seek out work, whereas I usually annoyed my supervisors with frequent requests for more tasks.
In a small organization, there is no room for those who cannot or will not take the initiative. There is no room for those who would rather wait for the assignment to come to them than seek it out. At Analyst1, the team takes the initiative. Each person is responsible for choosing their next task from the To-Do list, which, true to Agile, is groomed, estimated, and selected with the team’s input. Personal initiative is required of every individual for the company’s success, from the beginning to the end. There are no silos for people to pigeonhole themselves in. Indeed, every member has a nominal role they fill most of the time. Still, our Customer Success team has jumped in to help the engineers, our operations people have joined calls with the sales team, our engineers have provided support alongside Customer Success, and this wheel keeps turning moving the company forward.
There are no excuses; there are no cop-outs. Everyone must take the initiative.
Swarming the Problem
The software industry, like few others, has acquired a sizable portfolio of stereotypes. Many are holdovers from days gone by (e.g., intellectuals adorned with pocket protectors, socially inept introverts staring at their shoes, etc.), but one that still seems to plague projects is the “lone warrior” mentality. This person usually presents as the individual developer who disappears for days at a time to work on a problem in solitary. Even the daily stand-up or scrum does little to combat the issue.
Another stereotype that goes hand-in-hand with the “lone warrior” is the “wizard.” This is the developer to whom everyone runs for answers. Some revel in the importance conveyed by being that wizard but, regardless of the wizard’s feelings about that status, this constant interruption takes a considerable toll on that person’s productivity and inhibits building the team’s skill level.
Analyst1 has turned the tables on both of these issues with a practice known as “swarming the problem.” You have likely encountered this term if you have any experience with Scrum, but, at Analyst1, we expand the generally accepted definition a little. When most people talk of swarming the problem, they mean tasking as many people as possible to a specific ticket, user story, or other documented task. On this team, swarming takes place any time a team member hits a roadblock.
I had never experienced the process of swarming before joining Analyst1. I remember my first taste of it occurred early on when I had difficulty setting up the development environment on my shiny new laptop. I posted a question to the #develop channel in Slack (where the development team does most of its communication). A few seconds later (literally), I received a Slack call and responses from no less than four people offering to help me solve the problem.
My short anecdote demonstrates so many things the team got right that I’m not sure I can cover them all. First, encouraging members to post a Slack message, send an IM, video call someone, or simply speak up when a problem occurs starts counteracting the lone warrior. This may not be enough to bring those introverts out of their shells, so it is also common for members on our team to proactively reach out and offer help if someone appears to be struggling. This practice keeps our velocity high, keeps our morale high, and builds trust between the developers. The action of a team swarming around their co-worker to remove a roadblock speaks louder than a million motivational posters ever could.
Swarming also combats all the issues related to the wizard. At my last job, I was that guy, and I despised it. As soon as I got “in the zone,” I’d receive a guest at my cubicle looking for help, or an IM asking about a Java compiler error, or some other disruption because I was the wizard. With Analyst1’s approach, the whole team is the wizard. No one person bears the brunt of this responsibility, and everyone gets to learn from the experience.
More on how swarming is facilitated by how we share information in the next installment.
