As creators of opinionated software for operating better teams, we take collaboration seriously.

Our teams have a clear purpose, and people work together toward shared objectives. We are not a culture of individual achievers, even though individual accountabilities are clear. Objectives are set on a three-month cadence where the full team weighs in. Each month, we conduct a retrospective process that serves as an opportunity to clarify roles and improve the way we work together. Each week, we use our own software to prioritize against planned objectives and emergent opportunities. We’re a small team that works closely with one another -- get to know us!

We all succeed or fail together.

Teams jointly commit to deliverables and help each other achieve those goals. Since we offer so many products and services, coordination and cohesion among teams is crucial. We rely on good teamwork and synchronization to ensure we're not duplicating work or changing things that will have upstream or downstream impacts on other processes or products.

We utilize scrum meetings and quick daily stand-ups with team leads to sync up with relevant teams. Product and UX work across teams so all parties understand their role in the overall vision and stay aligned. We use Aha! for roadmapping and strategic product views and Jira for sprinting and executing on those initiatives. These products are “open” in that there is a common view and understanding to manage natural complexities.

Everyone on our engineering team, regardless of level, is expected to make decisions or contribute to them. Some decisions are routinely made at the team level (design patterns, open-source libraries, etc.) while others need to be made with more insight into cross-team or cross-product strategies, company goals, or industry trends and may be made by engineering leadership with input from relevant teams. For certain products, there are bi-weekly architecture meetings open to anyone who is interested. Not all decisions are democratic, but all team members have a say in how their solutions are built.

Billtrust promotes a "we all succeed or fail together" culture. People ask for help when they need it and generally everyone is willing to help, whether it be through code reviews, pair programming, mob programming, sharing lessons learned, or bouncing ideas off each other. The dynamic is different on each team, but getting to done is culturally and objectively a team effort. Since we have development teams in New Jersey, Colorado, and India, we use tools like Slack, Google Meet/Hangouts and Zoom to connect with one another. Our engineering teams work in “agile pods,” which have their own screen that can be connected to a Google Meet allowing remote teammates to join at any moment and have pseudo face time with everyone.

We work very collaboratively and pair-programming is a vital part of our culture.

Somewhere between 80% and 90% of our work is done while pairing. We pair program regardless of location, so whether you’re physically side by side at the office or on your own in the comfort of your own home, we’ll likely pair. We tried tools like tmate and saros for collaborative editing, but have also found that simple video calls with screen sharing work. The drivers share their screen and the co-drivers do their best to not interfere except for talking. If anything, remote pairing has helped us become more disciplined when pairing! 😀

We enjoy being a cohesive team, even when we’re not physically coding. We eat lunch together, do a team breakfast each month, and regularly get drinks together after work. Our engineering team is also close to the other teams at the company. Every month, we do an information exchange and also meeting to touch base on what our company values are and discuss our company’s culture. Once a year, we also have team days where we visit a new European city.

Loosely coupled, tightly knit collectives

Angaza’s collectives are small groups of 2 to 4 engineers, some with a product manager additionally attached, focused on a single set of engineering concerns. For example, one collective is dedicated to straight ahead roadmap features, while another focuses on devops issues.

Each collective has a high degree of autonomy, physically sits together, and owns their internal lightweight processes. This means that each collective determines what time they’ll have daily standups and how they manage their own workloads and deliverables. Across collectives, there is a high degree of communication to coordinate cross-cutting concerns or dependencies, where one collective’s deliverable may affect another’s operations, e.g.

Every quarter, engineers choose their own adventure, rotating onto the collective of their choice (within business constraints, of course). This structure allows for a few interesting features:

• Engineers choose “new” colleagues every quarter, strengthening relationships and learning to work with a diverse set of styles.
• Early-career engineers gain broad exposure not only to our entire platform, but also the different flavors of specializations within the larger tech industry, while senior engineers get opportunities to lead projects that are either entirely in their wheelhouse… or a stretch.

Overall, our collective system is working well for our engineering team, but we’re not dogmatic about it. If and when we need to iterate on our internal organization, we’ll happily do it again.

We celebrate team successes.

It’s a reflection of how humble we are and what motivates us day-to-day. Team members will go out of their way to help each other, even if it means that their personal tasks will fall behind, so long as it is in the interest of the greater good.

We emphasize this by aligning the entire team around a common team goal and being fully transparent on how we progress towards that goal. And when we meet those goals, we celebrate as a team! Recently we took the entire team on a 3-day retreat to Whistler and went white water rafting. We have monthly social events where significant others are always welcome.

Another example is how we do our year-end bonuses, which are tied transparently to team objectives, rather than individual ones. In that way, either the entire team wins or the entire team loses!

Individual contributor != I work alone.

We think about productivity at a team level, and not as much as individuals. People have different strengths, and we want to take advantage of that while investing in our weaknesses to make the team more versatile and robust over the long term. A huge part of why we all love working at Sparkswap is that we get to come to work everyday and collaborate with one another. We (Brad, Martine, Danny, and Trey) feel lucky to have found our tribe and we think this is by far our biggest (and most unfair) advantage. Our tribe is collaborative, we genuinely like and care about one another, and we’re all passionate about doing really great work.

We truly work better as a team than we do as individuals. It is common for people to “check in with the team” at various points on a project to get feedback and bring everyone up to speed. We frequently work in teams of 2 instead of the whole group. For particularly thorny issues during design or code review, we all think through the problem together. (We literally sit together around a whiteboard to solve it together.)

We are co-located in part because we think the high bandwidth communication (both intellectual and emotional) that comes with in-person working is worth the trade-off of losing some (many) candidates. It’s incredibly important to us that all new hires consider themselves to be a mentor, a good teammate, and an enthusiastic learner.

Everyone is involved in the decision making.

As founders, we go out of our way to collect everyone’s feedback through monthly one-on-one meetings, surveys, and voting on Trello/excel, this includes office location, off-site activities, as well general company process improvements. We are open to hiring individuals who prefer to work alone. At the end of the day, it's about getting the work done, and finding joy and meaning in the work that you do, regardless of the personalities around you. I want to attract candidates who want to take on a lot of responsibility at a growth stage company, is emotionally mature, and wants to work in a drama free environment.

We are a flat organization with no managers.

We’re currently too small of a team to worry about titles. In the not too distant future, we’ll have more clearly defined roles and a hierarchy that fits our company culture, but for now, we are one team. We have deliverables and company goals that we all work towards together. The way we plan and operate is heavily collaborative. In the rare cases where we don't have a consensus, we operate under a "first among equals" style where the CEO acts as final arbiter.

Meet our team:

• Ryan (Cofounder)
• Ben (Cofounder and CEO)
• Jason (Software Engineer)
• Eric (Director of Engineering)
• Stephanie (Cofounder, Product and UX Design)
• Mike (Cofounder, President)

You can also learn more about who we are on our team page.

There are no solo projects at Lever.

Everything we do is team based. We have two pairing rooms (called Pairadise), which are always occupied. We focus on aligning around team goals throughout projects, which means we’re incentivized to give and receive help (pairing, mentoring, whiteboarding, unblocking tickets, etc.) over focusing on solo hero work.

Collaboration also prevents us from creating silos of knowledge. It facilitates information sharing and there are many “game-changing” instances where one person’s good habits or use of a awesome tool gets shared across the team to everyone’s benefit.

Above all, we are big believers of succeeding and failing together as a team. We celebrate feature launches with a physical trophy ceremony where the team presents who built what and why. They then place a small token that represents the project in a glass case with white gloves, music playing, and all the pomp and circumstance a feature release deserves.

Each team works together to determine what their team values are.

A lot of what we do at Box is team-centric. For one, even though we’re becoming a large company (~300 engineers), we still hire into individual teams rather than hiring into the greater organization and then later placing people on teams that need more resources. Once you’ve joined your team, you’ll likely do team building activities to help you and your teammates assess how the overall team is doing. We have different work experiences, perspectives, and working styles and no two teams have the same dynamic. It’s important that we draw from our past experiences and share ideas, practices, and processes to elevate the team while also making sure to learn from what didn’t work. We are incredibly team oriented in this regard. Engineering managers also work together to share knowledge and help one another build engaging, cohesive team cultures. What is the best team you’ve ever been a part of and why? We want to know.

We build teams to have strong ownership and accountability.

Our engineering department is split into four distinct teams: Product, Platform, TechOps, and Customers. The Product Team owns customer facing features like adding API endpoints, new protocol support, and our developer dashboards. The Platform Team develops and maintains robust, scalable, and easy-to-use abstractions in support of the Product Team. Our TechOps team creates, manages, and ensures the smooth and secure operation of our technical infrastructure. Finally, Our Customers Team owns the issues that don’t seem to fit anywhere else, but are important to our customers.

Each team has a team lead who both decides on its process and how to empower each team member to have an active voice on important engineering and product decisions. The teams hold regular retrospectives to reflect on what is and is not working well.

Being at the heart of Dublin City, our team has a multi-cultural mix with employees with different areas of expertise.

One of our strengths is having an open and clear communication channel between different teams. The Technical and the Business teams are both just a stone's throw away from each other. We try to eat lunch together, and also have monthly team dinners so that we can bond with one another. While we do provide the facility of working remotely, we prefer working together as a team.

Our teams are organized by personas, which reflect the many hats we (and our customers) may wear.

At LightStep, we have collaborative, cross-functional teams comprised of designers, product managers, and engineers. These teams are grouped by customer persona, aka the “hats” that LightStep customers may wear at some point during their work. As of March 2019, we have four persona teams:

• Application: Application engineers care about adding instrumentation to their application with minimal amount of effort: either via configuration of a framework they’re using or via instrumentation libraries themselves. They want to move fast to develop their application, so it’s important they have a tight feedback loop to know if the product is working.
• Observability: Observability engineers want to standardize and encourage platform/infrastructure best practices. They build in-house observability systems, operate 3rd-party ones, and encourage SLOs to be applied to all services.
• On-call: On-call engineers want to keep their service or product up and running, and meet all SLAs. They want to resolve the 2 a.m. page as quickly as possible and be paged as infrequently as possible.
• Performance: Performance engineers define and improve the baseline (i.e. SLO) of performance and reliability including throughput, cost, latency, errors, memory etc. They proactively make long-term system performance, scalability, and reliability improvements.

In addition to persona-based work, any engineer can propose a new project, which goes through a selection process. All projects typically start with a conversation with the product manager (PM) on your team, followed by a collaborative drafting of a 1-2 page brief that outlines the problem space, potential impact, and engineering effort level required to complete a solution. Briefs are then grouped together, reviewed, and further vetted by the entire team, including the PM, EM, engineers, and designers. During this process, we have both verbal and written mediums for anyone to provide feedback. Ultimately, the teams make a collective decision to work on the highest impact projects.

Even our interview process reflects how collaborative we are. Every engineering candidate meets with panels of two team members who focus on productivity and teamwork. Having a pair of interviewers lead each onsite panel helps reduce bias in the hiring process and more accurately assess a candidate’s ability to collaborate and work with diverse perspectives. Using the feedback from both interviewers, we can continuously reflect on and improve our interview practices. We’ve heard from candidates that they also appreciate this setup, since more people in the room adds greater perspective and generally yields more interesting conversations.

There is no I in team. But there is a “me.” We celebrate individuals and their unique strengths, but also recognize that collaboration makes our teams more innovative.

We encourage collaboration among our teams in San Francisco, Melbourne, and Berlin to work on solving problems together by bringing their unique experiences and thoughts to the table. We believe that by working together we find the best solution and produce a greater quality of work. Our track record over the last 12 years can speak for itself. Teamwork also enables our Bubblers to feel a sense of belonging, togetherness, and a deep commitment to one another and their team goals. Whether it’s through inter-office travel, slack, or a trusty Google Meet, you will certainly get to know your teammates well.

Everyone is involved in decision making and we have a ‘no question is off the limits’ policy.

We value transparency and every team member is welcome to challenge anyone else’s assumptions. Our engineers constantly challenge Daria, the CEO, on any decision from how we run our 1:1’s to our annual planning process. One of our three team values is challenge everyone’s opinion and think for yourself.