The typical visitor to the BigDoor office, often comments on one of two things: The eerie silence or their inability to distinguish between developers, executives and anyone else. It’s true, the BigDoor office is one big buzzing space of activity, with every employee moving around from desk to desk, or tapping away at their keyboard furiously with a look of concentration. We all wear T-shirts, drink copious amounts of diet coke or red bull and argue over who gets the conference room, the comfy couches or the bar stools in the kitchen for their meeting. That fluidity of employees is one of the truly unique things about working for a start-up and we continue to see employees grow and learn in truly awe-inspiring ways. CTO and Co-Founder Jeff Malek took some time to talk about how BigDoor is organizationally structured and what that means for employees who work here.
One of our rockstars here at the company had questions about our organizational structure, trying to determine who was in each of our departments. He’d listed what he thought those department “labels” were (Bizdev, Development, etc) and who he thought belonged in each of those branches of our company. He’s recently been asked to improve our process and communication during customer on-boarding, largely because he’s very detail-oriented, organized, and process-driven. To get this done, he’ll need to be interfaced with other folks in the company that he hasn’t before, so asking about who does what and where in the company is totally understandable, expected and part of his diligence.
This approach and thinking around a company’s organizational structure is age-old, and for good reason. But it’s Org v1.0.
It’s human nature to try and departmentalize, categorize, bucket, silo, label, simplify or otherwise narrow down anything in life. In this case the context is “who does what and in what group”, an attempt to establish who falls into what departments at our company, and there were two (somewhat) flawed assumptions:
- we have departments that contain people
- person x belongs in department y
What we actually strive to have at BigDoor and will continue to work towards as long as we possibly can, is a team of people who wear one or more hats, and we call those hats “roles”. The internet has taught us that tagging is a much more flexible, powerful and realistic way to associate attributes with anything, more so than creating hierarchical taxonomies. For the database-minded, it’s the difference between a many-to-many entity relationship and a one-to-one.
A tag can be associated with many different things, and a thing can be associated with many different tags. In the same way, engineers who operate in many different roles (e.g. production developer, test developer, project manager, UAT tester, etc) grant both the company and themselves much more power and benefit than if we were to create a Quality Assurance department and put specific people in it, and only in it.
Once you create departments and put people in them, there’s no going back. The company is limited to asking Joe in the Foo department to fulfill Foo tasks. All or most Foo tasks go into the Foo department, agility and flexibility go out the window, and a manager ends up with being “accountable” for department Foo and tasks of type Foo. Department Foo is one tier on the multi-waterfall path toward the “done” that never gets done, and it will wind up being the managers fault, so they start getting cycled in and out of the company, along with the teams. Barf. I want to fight the Foo just thinking about it.
Once someone starts thinking in terms of belonging to the Foo department, it’s totally natural to become closed off to doing anything but Foo work.
Now, if I don’t live in a department, but I’m on the team that is supposed to take care of end-users, that’s a different way of looking at things. My team doesn’t “do QA” or “do Product Management”, it takes care of customers, which is what we all should be thinking about as a P0 (highest priority). That’s a great reason to have a group of people working together.
So we have a Player team, “player” being a euphemism for end-users. The purpose of that team is to meet the needs of our end-user customers. The Player team is cross-functional, it does it all: it determines what the next highest priority is for the customer, works out how to meet their needs, builds it, tests it and deploys it. Everyone required to meet the needs of the customer is on the team, whether it be someone to fix a problem with our build system, stand up a new server, design a new graphical interface, deploy an API performance optimization, or change the backend database schema. The team pushes to continuously improve and learn, on all fronts.
This non-departmental approach raises valid concerns for folks, around topics like accountability, ownership (“if everyone owns it, no one owns it”), and scaleability. But clearly, even without a Project Management department, someone can still own a publisher on-boarding project management role, for example. More about scaleability with regard to the organization here.
It’s true there are tradeoffs to this approach, but it’s better for the company and for our employees to leverage the multiple skills and talents buried deep throughout our awesome team.
All that said, we all can’t do everything, and it’s necessary to create categories at least at a high level for various reasons. It’s also true that some external customers may be more impressed with us if we talk about our QA Department, while others may be more drawn in by an agile approach to org structure.
So ultimately, I encouraged the engineer to avoid thinking along the lines of departments and silos as much as possible, and just question whether certain terms or departmentalizations are needed to begin with. Focus more on identifying the individuals you’ll be thinking of as stakeholders, and get to know what they’re specializing in.
Titles are another story altogether, and at BigDoor they’re much more valued and needed outside than within the company. We’re all engineers and salespeople to varying degrees, having additional strengths and attributes.
Strengths, attributes, tags, descriptors…too bad there wasn’t some way to quickly visualize these, and convey someone’s strengths and achievements better than with just a “title”. Like a badge. Kidding – of course we do that. Here are some of the badges that we put on the back of our engineer’s business cards, each of which are only attainable when specific criteria are met:
Full-stack employees are like gold, and we try hard to cultivate them here. But it takes a rare breed, someone with fire, adaptability, agility, ability, a clear communicator. If you think you’ve got what it takes, and all of this sounds fun to you, please get in touch with me directly – we’re always looking for good people to join our team. We don’t just look for people when we have an opening, that’s very “recruitment v1.0″.
(title is me tipping my hat with much respect to the Foo Fighters, the best makers of music, ever).