I was a skeptic. I didn’t believe engineering could be a “collaborative” activity. I got my computer science degree by using my brain, alone, to solve problems. I knew from when I was in diapers that it’s not my job as an engineer to coordinate with my colleagues! That’s some pointy-haired manager’s job! Right?
But no! At Qumulo I’ve become a new kind of engineer—a much more powerful one, because I’ve become much more collaborative. If you take the engineering output of this company and divide it by the number of engineers, my share is more than it has any right to be. And that’s because of teamwork.
We do a lot of things that I think of as radically collaborative. I say radical because it wasn’t too long ago that I would have told you this kind of engineering environment would never work. It’s too open! It’s too heavyweight! People, I would have said, are private; engineers especially so. They want to do their own best work and never be “held back” by others. But at Qumulo, we’re constantly digging into ourselves and each other to get better and to help each other grow. Let me talk about a few of these practices.
Practices for Radically Collaborative Engineering
First of all, we have a completely flat hierarchy: all engineers report to the VP of Engineering (at least for now). That’s dozens of people. Needless to say, that VP doesn’t manage individual people, or assign work at that level. Instead, teams volunteer to pick up big projects from our product roadmap.
Here’s just one example: About year ago, we had put all our engineering resources toward big-ticket, “novel” features, and hadn’t invested in performance for a while. One team said, ‘Screw that, this product needs to be super-fast—we’ll step up to that.’ And they did. It was inspiring to see a set of 4 or 5 engineers, with no manager, spontaneously get up and take ownership for an important part of the product that no one else was working on right then.
They started by quickly building some of the tooling that they needed to measure performance, then designed and implemented a series of performance improvements. Since then we’ve brought down metadata latencies by a factor of 25x, increased write speeds by about 50%, and made a 30% increase in read throughput. That speaks to the way teams take ownership of the product and their careers.
Accountability, Self-actualization, and Support
Every week, teams take responsibility for how successful they are. For example, each team has weekly retrospectives where we talk openly about what’s holding us back. And it’s not just a meeting to sit through: each person shares thoughts about what’s frustrating them, places where they’re getting stuck, or ideas about what will create more leverage in the weeks to come. It’s a self-examination and it requires a little personal vulnerability–the opposite of the old chest-thumping quest for dominance–and it pays off.
Retrospectives are one example where Qumulons show vulnerability and grow from it, but there are loads of others. Many teams use periodic, brief, 1:1 round-robin feedback sessions, or “feedback speed-dating”, which gives us a way to address specific problems (“Seems like you’re pretty harsh on Joe when you do code reviews.”) and encourage one another to pick up the slack (“I’ve noticed you never dive in on bugs from the field; that would be a great place to learn and become a more excellent engineer.”).
We have a system of advisors, which more than half of engineers participate in: the advisor is someone you meet with regularly who is “in your corner,” supporting you in struggles with colleagues and struggles to grow. Between the advisors, the retrospectives, and the round-robin feedback, each person has the chance to be both supported and scrutinized, which helps us all loosen our stiff joints and become willing to grow and adapt.
Collaborative engineering in practice
We do a lot of pair-programming. Like many people, at first I thought this was just going to cut into my time and productivity! But once I tuned into it, I saw the benefits. Pairing is a great way to share what you know and learn, and it’s a great way for people to catch up to the same standards of excellence. If “Sam” thinks there’s a better way of doing testing, let’s say, she can explore that with a pairing partner (Pat) and prove the benefits of it to Pat experientially. Pat will later pair with another engineer (Morgan) who might also see the benefits of that approach first-hand. Partners help us keep up to our own standards and spread new ones around. It’s been terrific to watch the whole Qumulo team slowly progress towards better and better practices over the years, spreading them through pairing osmosis.
Lest all this sound like so much new-age hufflepuff, another basic Qumulo trait is to always check back on whether our processes are helping us achieve our common engineering goal, which (to paraphrase) is to make the greatest data-storage products the world has ever seen. Sometimes we experiment with a new practice and find it just doesn’t accomplish what we want it to, and so we drop it. Having seen the way we’ve shipped some meaty work, like the big performance jumps I mentioned, our novel approaches to snapshots, quotas and replication—and of course the great analytics and customer service that we’re best known for—and with high quality, on a regular cadence—that’s what makes me a believer when it comes to radical collaboration.
