Engineering teams that are heavily team oriented

Autonomous teams with product ownership

Angaza has four product development teams: three in San Francisco and one in Nairobi. Each team has a high degree of autonomy, works closely together, and owns most of their internal processes. The typical team has several engineers, a product manager, and an engineering manager. Together they own a broad area of functionality. Our "IoT Solutions" team develops everything from embedded firmware to time-series analytics, for example, while our "Network Partnerships" team builds payment functionality across an ever-growing range of digital currency services. Meanwhile, cross-team projects bring together engineers across the company to solve common challenges and address shared concerns.

“Team is our Unfair Advantage” is one of our core company values.

At Repeat, we’re building software that makes it effortless for consumers to reorder the products they love. To do so successfully requires a culture that emphasizes cumulative, shared ownership. A critical part of our interview process is discovering collaboration style – we intentionally hire folks that share their ideas in an empathetic and collaborative manner.

Every member of the team takes pride in empowering others, which allows us to celebrate everything we ship together, as a team. While some of us may have more experience in certain parts of the stack, we’re always willing to jump in, learn new skills, and help out where we can. For instance, while Diego has a ton of backend experience, he has recently discovered a love for React, and is now a full-stack engineer! Similarly, pairing is a big part of our culture (you’ll likely work with every engineer on the team at some point) and it happens organically. Not only do we learn more by touching each other’s code, but it also enables us to strengthen relationships and hand off in-flight work across time zones. Inter-team mentorship is important to us and all engineers will have the chance to lead a project. Ultimately, our cross-functional approach increases the quality and reliability of our work.

Sibi is extremely collaborative and we have teammates of all skill levels.

We’re transforming the way technology enables smart buying and smarter supply chain logistics for the real estate industry. As a new hire, you’ll be joining both team Sibi and a domain team composed of a mix of engineers, one lead engineer, and one lead product manager. At other companies, you might have experienced how one team can take over the culture of the entire office or company simply because they’re a bit louder – but you won’t find that here. We have a high degree of respect and trust among each other and strive to cultivate an open environment where everyone can ask questions, and more importantly, question decisions.

One of our core values is “design together.” We place a huge emphasis on designing and exploring solutions together, and then breaking out into smaller groups to execute. You’ll always find someone willing to pair with you (if that’s something you enjoy), since we believe touching each other’s code helps us learn and improve. Prefer to have heads-down time to execute? That’s fine too. We want to help all at Sibi succeed and believe the best way to do so is to work with folks who not only have different perspectives and expertise, but who are also eager to share knowledge and problem-solve together.

We often think of ourselves as an elite sports team. It's always we, never me.

Let’s Do This is a collection of seriously impressive individuals, but we thrive as a unit and are willing to make personal sacrifices on behalf of our team members. Our team-first mentality stems from our shared love of exercise and the product we’re building, and a mutual understanding of fun. Everyone has a voice in big product decisions and when we’re not working, we go to the gym together, go on runs during lunch together, and enter races together, too.

Perhaps one of the best examples of how team orientated we are is our willingness to move across the world with each other. During Y Combinator, eight of us moved from London, UK to Palo Alto to make the most of the 3-month batch. We raised a seed round after YC, and four team members moved to San Francisco together to open the office. In the summer of 2019, we took the whole team (everyone from both London and San Francisco) to Cambridge, UK for an intense “training camp” where we more than doubled all of our top-line metrics in six weeks in the run up to our Series A. None of this would have been possible without a team that believed in each other, put each other first, and was willing to make personal sacrifices, like moving their lives across the world in pursuit of a shared dream.

Even as a distributed company on two continents, we maintain cohesion. We keep open communications and everyone feels like it is easy to reach out to anyone else in the company, regardless of their role or location. Early in 2019, we helped relocate a U.S. engineer, Connor, to London and also moved a UK engineer, Tom, to San Francisco. Our hope is that every engineer spends at least one week each year working out of their non-home office, and so far, many of us have spent up to six weeks doing so. Doing so helps us stay close to one another and feel comfortable making quick FaceTime calls to discuss cross-office issues when we’re not in the same city (a much better alternative than potentially misinterpreting written Slack messages anyway).

If you ask anyone at Let’s Do This why they work here, what they love most about working here, or which value represents LDT the most, the clear winner is always “the team.”

We’re not individual superheroes – it’s a team effort.

At New Relic, we believe everyone has things to teach and to learn, regardless of seniority. While there are some engineering teams that work in silos, our Data OS team (DOS) is happiest when we’re collaborating. If we’re crunched for time during a sprint, everyone will pause what they’re doing to help their teammates get across the line. Even though we’re distributed (with team members in the Bay Area, Phoenix, and Portland), we find joy in supporting one another. You’ll see this from the start, since part of onboarding and ramping up includes pairing and shadowing existing teammates.

It is standard within New Relic to have performance reviews twice a year, which is coupled with leveling. However, our DOS team does these quarterly. We do these more frequently to give our team members additional opportunities to review key strengths, accomplishments, areas of improvement, goals, and how managers can help. Our Engineering Manager, Teresa Martyny, shares 1-on-1 docs with everyone so that we can add questions, keep track of quarterly goals, and make sure feedback is transparent both ways. We are all growing always!

Teamwork is especially important within DOS, where also use project “squads” composed of folks from different teams (e.g. infra engineering and analytics). This isn’t a typical practice at New Relic, but we find it beneficial for us to prevent knowledge silos and encourage more collaboration. Bringing together experts on different parts of our systems and business ultimately helps deliver greater value. That’s why internal transfers are also fairly common. All new engineering roles on teams are posted in an internal job board, and employees can apply and go through an accelerated interview process. We encourage people to transfer to different teams when it will support their career growth goals. New Relic as a whole considers it a better outcome for someone to transfer to a new team to help grow their skills than to leave the company entirely.

One of our company values is “Tie your neighbor’s shoes.”

Everything we do is a team effort and our culture is centered around collaboration. One great example of this is our Technical Docs process. Before starting a new project, engineers are encouraged to write up their project plan. This includes any required architectural changes, pros/cons of various options, and the rollout strategy. The project plan is then shared across the entire Engineering org to encourage cross-team feedback and knowledge sharing.

We value intellectual humility and acknowledge the limits of our own perspectives, which is why we welcome both positive and constructive feedback with open arms. We host feedback training regularly to provide each employee with the tools to have productive conversations. Because another one of our core values is ‘Challenge Without Ego,’ it's important for us to give feedback to one another in a way that is professional and respectful, keeping team interests top of mind instead of our own.

Finally, we make it a priority to acknowledge and thank people for their contributions and for going above and beyond. Our #thanks Slack channel is very active with shoutouts and we end our weekly all-hands meeting with a few folks giving a “Nova Credit” to someone for demonstrating one of our company values.

Ask us about our spirit weeks.

In the early days of Curai, we were a team who ate lunch together every day. Now that we’re remote-first, our team-oriented camaraderie is expressed through company activities and celebrations (recent events include a Star Wars trivia competition, at-home cheesemaking, and a talent show), jokes during stand up, and kindness toward one another. As engineers, we are quick to hop on a call to pair program and unblock each other, and start each bi-weekly team meeting with a different icebreaker activity to get to know our teammates. Many of us remain good friends outside of work even as we have spread out geographically, and stay connected by hopping on video chats or playing games together.

In terms of decision making, we used to follow a consensus-based model, but have since evolved to go through a formal design review process. This helps us strike a good balance between purely top-down and bottom-up decision making and gives all members of the team a chance to offer their insights and inputs. It also helps to distribute responsibility and ownership throughout the team so that no single person is overloaded, but also so that everyone knows with whom the proverbial buck stops.

There are no solo projects at Lever.

Everything we do is team based. 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. When we’re in the office, our two dedicated pairing rooms (called Pairadise) are often occupied.

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 an 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.

At Upstatement, engineers work as part of small multi-disciplinary teams.

Designers, PMs, and engineers work together closely for the entire duration of a project, from strategy presentations through to final browser bug fixing. Our teams (usually around 4-6 people) kick off each day with a 15-minute standup and check in frequently via Slack, Trello, and GitHub. We also keep up lightweight communication via Slack with clients – engineers are client-facing, so you won’t be playing telephone with account managers.

Each project team functions autonomously. This means that technology decisions don’t come from the top down, but rather they’re made at the project level by the engineers who will actually be accountable for delivering the work. Our process is malleable and can change depending on what works best for the team. Projects typically last 3-6 months, and primary design/engineering team members are fully allocated for the duration of the project. Directors and managers meet every week to discuss scheduling, and do their best to ensure that team assignments are compatible with personal interests and growth goals.

Many of our engineers are also fans of pair and mob programming, making it easy for people new to a technology stack to get on-boarded. That said, we definitely support individual contributors, too. Our skills and performance matrices allow for growth on both maker and manager paths. For IC roles (Engineer, Lead Engineer), people are more or less 100% focused on one project at a time, which leaves a lot of room for solo work on any given day. It’s also worth noting, we’re a fairly introverted group (especially engineers). “It surprised me when I first joined because it was the quietest open office I had ever encountered!,” says Mike.

At the end of the day, we don’t hide people from clients, and while everyone doesn't have to lead every client conversation, a certain amount of comfort with this sort of service relationship is important.

We value knowledge sharing and have roundtable-style sprint planning meetings.

At Leapfin, we try to avoid working in silos. Engineers often pull each other in on stories to collaborate and seek out second and third opinions (from fellow engineers as well as others in the company). We have weekly knowledge sharing group sessions and our sprint planning meetings are roundtable-style to make sure all voices are heard. We also have a bi-weekly company all-hands meeting for cross-functional knowledge sharing and business-as-a-whole insight. New engineers on the team will report directly to Olivier, our VP of Engineering, who leads a team of software, DevSecOps, and data engineers. You can also expect to work closely with Erik (co-founder and CTO), Larry (Director of Product), and Pavneet (Associate Product Manager). Finally, on a case-by-case basis, you’ll likely interface with Craig (VP of Customer Success) and two of our solutions architects to learn about customers’ feedback and help inform product decisions.

Our pod structure is core to our success.

When you join the team, you’ll be matched with a pod of six or seven people (think a mix of engineers, product managers, and product designers). Each pod covers a certain domain, such as our Donor Experience Pod or our Organization Experience Pod, which builds and supports customer-facing software. While each pod functions independently, all code is reviewed in a very collaborative process and you’ll get dev manager feedback for all pull requests.

Our product roadmap conversations always involve input from the engineering team and we encourage people to reach out if they have a question or to mentor others, regardless of role or pod. It’s an exciting time to join the team as leadership is very receptive and open to creating new pods as needed – which we’re definitely doing!

We believe strong teams are greater than individual “heroes.”

At CircleCI, we place an emphasis on collaboration and helping each other out. Each team has around 6-8 engineers (sometimes more when growing) and an engineering manager. Product engineering teams also have a product manager, data analyst, and designer. It’s important that everyone can participate and have their voice heard when making decisions. We aim for long-running teams, with relatively stable members and areas of ownership.

Since we’re distributed, part of building a strong culture is with regular team meetings, where we get to know each other, build relationships, align and calibrate ourselves, collaborate, and strategize face-to-face (virtually). Those who stand out at CircleCI are willing to exchange ideas, information, and knowledge whenever possible to help any and all team members, not just those on their direct team.

Because we’re growing rapidly, we highly value engineers who can help us scale our human systems. We expect engineers at all levels to be effective mentors and sponsors, to continually improve our onboarding, to eliminate knowledge silos, to make implicit knowledge explicit, and to actively prevent the tyranny of structurelessness. Pair programming and mobbing are regular practices.

While focus time is important, if you’re someone who wants to do their own thing all the time, this is probably not the best fit.

Teams are how we organize: Our work. Our communication. Our meetups. Our Impact.

When our founder and CEO Matt Mullenweg talks about the Future of Work (as he does in his podcast, Distributed, and in a recently published TED talk) he shares his belief that distributed teams are a big part of that future. And we know, from years of hiring and from our recent user research study on hiring, that talented and diverse candidates might be just as interested in pursuing a role with a specific team, versus simply pursuing a specific role.

We go to great lengths to help each team in our company continuously iterate, share feedback, and meet goals. All full-time Automatticians are members of a certain team, and work as closely with their teammates as possible on all tasks. All teams have areas of responsibility, but can choose to go outside them. Teams have names that aren’t descriptive, because teams aren’t limited in the ways they can influence any part of the company.

Automattic teams also have their own unique rituals, from how they hold standups in Slack with Geekbot or take turns writing biweekly updates for other teams, to how they kick off projects and celebrate successes.

Teams are so central to how we work that our Team Leads are less managers than leaders. They help employees cultivate opportunities for impact and growth, while staying on top of the vision and goals for their team and all of Automattic. Developer Team Leads spend time with extra coaching sessions, biweekly leads roundtables, and get-togethers at relevant lead dev events.

In fact, we’re so constantly iterating on the tools that help our teams perform well together that in 2019 we launched Happy Tools, a suite of products for handling scheduling, customer support, and other things that help distributed teams navigate the future of work.

We love what we’re building, but we love who we’re building it with even more.

We embody teamwork in so many different ways that it’s difficult to make a comprehensive list! We do company-wide offsites twice a year where we take multiple days/nights away from work – really, we don’t do anything work-related – and spend time bonding as a team. We do a full or half-day offsite as a company once a quarter, too, and sub-teams will do quarterly offsites in smaller groups as well. But to us, being a team is even more than these offsites.

At our office, we have a Creative Corner where people can take what we like to call “brain breaks.” We bring the supplies and you get to take 5-20-minute breathers in the middle of your day to unwind. Remotely, feel free to take a walk around the block. Throughout the year, we’ll have small events in the middle of the workday to make wreaths, Valentine’s Day cards, or do meditative yoga (we have even continued these types of events virtually.) More regularly, we have a coffee bot that randomly selects a colleague for you to get coffee with (or remotely, connect over a 30-minute video call).

While these are all things that we do, they’re more of an expression of who we are. We’re all here at Seesaw to better engage kids at school, build trust between parents and teachers, and improve learning outcomes, and we apply the same principles within our team. We know we have different learning and working styles, so we have multiple avenues for people to create, converse, clear their heads, or just play.

Our success is in large part thanks to our pod structure.

We believe that throughput comes from fostering team autonomy. An essential component of this is to provide the teams with the knowledge and skill sets they need to deliver value to our users. That is why our cross functional teams (aka pods) have members from all functions (Clinical, Engineering, Product, Design, Creative, Regulatory) and their ability to work together is what allows us to win. If this sounds good to you, we encourage you to apply!