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.

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

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.

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

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.

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.

Put your team first.

While we all have a great degree of ownership, it’s impossible to work in a silo here. As a healthcare data platform, the technologies we use are inherently intertwined. We’re pulling data from thousands of different sources, so it’s imperative that different products talk to each other, which in turn requires public collaboration and strong communication. Take scheduling for instance. Unlike sites such as Kayak.com, where you can search every flight option, there isn’t one place to search for every bookable doctor (even Zocdoc only offers 0.7% of overall visibility for U.S. doctors). We’re working on an API to aggregate scheduling data and make it possible to accurately see doctors’ availability and make an appointment. This means we need an agreed upon framework for all data aspects and it requires close collaboration with the data acquisitions team. Tech leads have to ensure they’re in sync with other tech leads across the org.

Our pod structure is inherently cross-functional. Pods range in size from 3-8 people and include folks from engineering, data science, and product. Each pod is then responsible for owning a project start-to-finish. Engineers regularly rotate pods every 3-6 months and share best practices between different pods, from code quality (linting, pydantic, architecture) to team ceremonies (sprint planning, retros, docs). Not only will you get exposure to all different parts of the product based on the project, but you’ll get to change up who you work with, too! We find that pairing happens organically and touching each other’s code helps us share knowledge, keep our quality bar high, and execute faster.

Everyone at Ribbon shares a sense of humility and eagerness to help succeed as a team. We iterate on, add to, or create new pods as needed, so there are always exciting challenges to work on. Recently, we held our first hackathon. Over two days, members across all levels of the tech org innovated around external customer-facing needs and internal business priorities. Our CTO joined a team and it was also open to all Ribbonites across the company, with protected time to be able to fully participate. With fun prizes, swag, and an awards ceremony, it was a great opportunity to bond and get creative as a team, and we plan to do it annually!

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!