How We Work

 

Our goal here is to provide a job that is fulfilling, challenging, not stressful, not hostile, and pushes you to reach new skill levels you didn’t know you have in you, all while hopefully not pissing you off. How do we accomplish this?

• Organization. We try to organize folks into full stack groups around products. We run about 60ish products. We’re understaffed in all of them, but we hire about 20 people a month and hope to catch up someday.
• Compensation. We compensate people based on their contributions and outcomes, not output. We kind of copy Google Levels but with like 1/1000th of the structure. So, if you’re a writer producing amazing outcomes, you might be an L9 or L13 making $150,000 a year. Or you might be an L1 or L2 writer making $60,000 a year if that’s where you’re happy. The same thing goes for all roles, from engineers to designers. We want to provide a career path that compensates you in a way that you feel supported and rewarded for your contributions. Our hope is that your pay is NOT fair relative to others, but it is such that you’re happy and feel we’re doing our part to show you our gratitude for your time here doing good work for us.
• Quarterly Alignments. We don’t use levels day to day, but once a quarter we try to re-align and create the freedom to reward and compensate people according to where they want to go here. Titles can get in the way of this, so we aren’t too big into titles like Director, VP or Sr VP. We want to make sure people aren’t feeling pressure to climb the ladder or take on some weird title they will ultimately Peter Principle out on just because they want more money.
• Employee Pride. We call people employees. There’s no goofy names. To us, employing people is a sense of pride. To be able to provide a job that elevates people’s financial situations and supports their personal lives is something to be proud of, and we don’t have to come up with weird names for people that work here. If calling someone an employee or saying they work for us makes someone cringe, we’re doing a bad job and need to get our act together. That’s our overall stance.
• No Analysis Paralysis. We move fast and embrace making wrong decisions. If you’re not making wrong decisions and screwing stuff up, you’re not moving fast enough. Analysis Paralysis and fear of getting yelled at is a real thing at all companies of size. When you take too long to do something or make something happen, it further develops a culture of fear. We try like heck to fight this by just doing stuff. Making forward progress and being okay if we make mistakes along the way.
• Product Ownership. Our goal with products is that each person on that product really gets a chance to own the product. If you’re always beholden to “stakeholders,” you’re always only checking to-do boxes off a list. We want to give you the space, freedom, and support to try stuff and push your product beyond what any stakeholder could lay out for you. The most important thing is having an open dialogue and trying to do what is best for the users in the products we make and maintain.

---

How We Manage Hot Fixes, Bugs, and Quality of Life Improvements

We have 3 “operations” groups: Marketing, IT, and Engineering. This is where all people, regardless of their experience, start. These three groups meet up daily and fight fires live and hot. This is our way of getting people as wide a range of experience as possible.

People can stay in the operations groups indefinitely if they prefer quick and rapid resolutions. Or, when someone is ready and finds something here they can be passionate about, they choose a product group to be a part of. It might be VoIP phone service, domain names, automation, security, networking 55 offices together, accounting and billing, APIs, dev ops—whatever really.

For operations, we use Kanban. For products, we use Scrum. Both are frameworks based on Agile principles.

Agile

Like many modern tech companies, we use Agile. Not familiar with Agile? It’s the fancy name for a collection of project management principles that have had a lot of success in the tech world.

One important idea within Agile is that teams should be self-organizing and cross-functional. There’s also an understanding that our products, projects, goals, and priorities will go through lots of changes during development, and our job is to adapt along the way. If you’re familiar with Agile, you’ll know that it’s a concept and it has to be melded to the people you have and your culture. There is no perfect form of Agile. We’re always working at making it flex with the people on a project or product to work best for them.

So how do we actually incorporate Agile into our work here at 2B? We mainly use two Agile frameworks: Kanban and Scrum.

Kanban

In operations, tickets from our customer service and internal employees come in and are turned into a project (or routed to a product team if they’ll be better served there). Because every project has many small parts that require different people, it can be difficult to see exactly where we are on a project at any given time. Kanban helps solve this problem by representing our workflow in a visual way.

We use online Kanban boards (mostly Jira) where we list our individual tasks in categories like In Progress, In Review or Done. We move our tasks from one category to the next as we complete work so that the current state of projects can be seen at a glance.

Our goal with our operations groups is to have a fun, engaging, and welcoming place to learn about our business and how we do stuff. It’s also a place to work with other people getting used to our company and meet some new great co-workers.

Scrum

Scrum? Doesn’t that sound like something we should scrape off our shoes? Some hipsters came up with Scrum to translate Agile principles into actions, but it’s really kind of just common sense branded for tech people to feel cool.

Scrum is a bit more structured than Kanban and more easily supports running full teams for products. Scrum breaks down projects into one or two-week chunks called “sprint cycles.” Each sprint begins with a planning session. And we follow up with regular retrospectives (reflections on what worked and what didn’t).

And in order to help our teams adapt to constant changes, Scrum is big into communication. Really big. For example, we have “stand ups,” which are quick (usually daily) meetings. In a stand up, we briefly share what we’re working on and any obstacles keeping us from moving forward.

---