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.

Our team culture is centered around collaboration, kindness, and appreciation for different perspectives.

Home care is inherently complicated and nuanced, which requires an empathetic and collaborative approach. Engineers interface daily with Design, PM and Data Science (often multiple times per day). We depend on each other to observe different nuances and bring a variety of different expertise and knowledge to the table. Working cross-functionally gives us a more well-rounded view of our challenges and enables us to move quickly toward solutions by avoiding communication silos.

As a team, we’ve honed our ability to solve ambiguous problems quickly by staying flexible in our approach and adapting quickly to change. If you’re the first person to hear about a problem, we expect you to dive in, regardless of whether it’s in your job description. For example, maybe there’s an issue where an operations teammate is in our tool and can’t find a piece of critical information for a client. They might Slack an engineer, who can be on the first line of defense and find the answer in the code. Engineers are empowered to “own the outcome” by reaching out to others, gathering the information they need, and continually moving things forward. In addition to cross-department collaboration, we’re constantly helping one another in our day to day product work as well.

There’s no shortage of people willing to drop what they’re doing to talk through a sticky problem or brainstorm with you. While we steer away from the ‘lone wolf’ persona, we keep a healthy balance of having heads down time to code too. We simply expect engineers to use good judgement to determine when they should step out of the code to collaborate for greater project success. At the end of the day, surrounding ourselves with people who have different areas of expertise and different perspectives, and an eagerness to share and communicate, allows us to make the best decisions for our users and our business.

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.

Teams are empowered to solve problems as needed.

Our goal is never to tell engineers what features to build, but rather give them the tools they need to solve whatever problem they’re facing. Instead of following a roadmap that’s decided on in advance, we have a list of prioritized business problems that business owners weigh in on. For example, let’s say we notice it’s taking too long for providers to refill medications. We don’t know why or what the solution is, but we might say, “It currently takes an average of 36 hours and we need to get it down to 12, go!” Teams then work cross-functionally with users, providers, designers, and business analysts to create hypotheses and test them using software.

Scrum teams working on Chirp are made up of 3-4 engineers, a product manager, a product designer, and a representative from the market the team is serving. This is usually a provider who has a high level of insight into the day-to-day operations of the primary care clinic. Teams are typically set for about 1-2 years before we mix them up, and most of our teammates (we currently have around 20 on the team) have all worked with each other at some point.

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.

All of our product teams are formed around a ‘triad’: a PM, lead engineer, and designer.

We follow the Inspired model from Marty Cagan to create cross-functional teams centered around specific business objectives. Every triad has at least three people (and their supporting casts behind them) and all stakeholders are equally valued and included from ideation to product maintenance. By having these three perspectives represented across all stages of the product life cycle, we’re able to build better products, faster. We also place an emphasis on testing and failing quickly, which enables us to move through multiple iterations with speed: once we find something that works and verify it by data (we A/B test, do small rollouts to subsets of users, and use Pendo to track events), we build it to scale.

Our triad model is wonderful because it also guarantees a tremendous amount of exposure to every team member: product managers understand technical challenges, engineers learn design processes, and designers can watch how user needs translate during problem solving.

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 have a strong founding team and recognize the importance of collective experience and skill sets.

Together, we have a wealth of knowledge in cybersecurity and it is our cumulative experience that gives us an unfair advantage as we take on this massive market. Managed Security Service Providers (MSSPs) already represent ~20% of total global security spend and the global Managed Security Services market is projected to quadruple to $101B by 2026.

Learn more about who we are and please reach out if you’d like to help us build a first-of-its-kind AI platform to manage cybersecurity holistically!

• Dr. Sameer Bhalotra (Co-Founder and CEO): Sameer previously worked as Co-founder/ CEO of StackRox, as a cybersecurity executive at Google, as COO at Impermium (acquired by Google), and as a board member for numerous security startups. He has served in various roles in government including Senior Director for Cybersecurity on the National Security Council staff at the White House and Cybersecurity & Technology Lead for the Senate Select Committee on Intelligence.
• Ed Gardner (Co-Founder and Head of Product): Ed was previously a Senior Program Manager for Enterprise Protection and Detection at Microsoft, and Senior Technical Program Manager for Consumer Data Protection at Amazon working on a content classification and data loss prevention service. He spent nearly 10 years at Akamai Technologies, working in various roles including Senior Service Architect for Platform and Security, Service Architect for Cloud Security Solutions, and Senior Program Manager.
• John Nurczynski (Co-Founder and Head of Strategic Operations & Business Planning): John was previously team lead for Customer Success at Arceo Analytics and Operations Manager at StackRox, two rising security startups in Silicon Valley. He was Senior Analyst within the Investment Banking Division at AGC Partners, specializing in Cybersecurity and Enterprise Software. John is also a former Senior Associate within the Wealth & Asset Management Division at Ernst & Young.
• Jerry Heinz (Head of Engineering): Jerry previously led NVIDIA’s GPU Cloud for AI/ML, Professional Graphics, and Gaming. Jerry is the former Head of Advanced Gaming Technologies for AWS and led Amazon AppStream, Amazon Lumberyard, and operations for Amazon Game Studio. Over his career, Jerry has led engineering at multiple startups in online-dating, e-commerce, member management, education, and mortgage banking.

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. 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. More regularly, we have a coffee bot that randomly selects a colleague for you to get coffee with (or during COVID-times, 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.

Sometimes walking away from your code and doing a jigsaw puzzle (there’s always one being worked on) helps you think through it. Other times, it’s better to think aloud while doing some arts and crafts with a colleague you haven’t talked to in a while. Whether you’re a 5-year-old kid or a 50-year-old working adult, engaging with different parts of our brains throughout the day (and engaging with different people on a regular basis), makes us happier, connect with one another in more meaningful ways, and ultimately, be more productive.