Teams do it better.

Whenever we bring someone new onto our team, we rethink our seating plan. We want people to sit alongside the group they’ll be working with most. For the most part, product, engineering, sales, and customer success sit with others in their department, but while you might be sitting with other engineers, you may also be sitting across from a designer. We do this to facilitate easy communication and collaboration and encourage engineers to be involved at all stages of the development cycle.

As an engineer, you’ll work closely with folks from every other department. We are all about team players and we are careful not to hire anyone who prefers working in a silo by themselves. We said it before and we’ll say it again: teams do it better.

New hires will absolutely get the opportunity to work closely with experts in other fields/departments.

Depending on your interests, expertise, and general fit, you might join a focused team that is comprised of members from various departments. Right now, for instance, we are working to getting video content on reddit. There will be a few mobile app developers that will be dedicated to this team and work very closely with designers and product managers.

Dev.xyz services several different businesses under one roof.

Dev.xyz is the development company within our family of tech companies. We provide the engineering and development services for our other entities which means that our development team works in a variety of industries and we work with different coworkers depending on the project at hand. Regardless of the project, engineers engage and collaborate with peers in sales, biz dev, legal/compliance, and marketing throughout the course of the project. We all share one open room (no cubicles or offices), and we have a shared kitchen and communal areas where we often get to interact with members of other departments, even if we’re not currently working with them on a project.

We value cross-functional teams that bring together key stakeholders from across the company to accomplish a shared goal.

Not only does working collaboratively allow us to build connections, but it also strengthens our understanding of our users. Product Managers and Engineers get to work with stakeholders in legal, operations, finance, sales, etc., to help design and build systems serving their individual needs. Whether this is building better compliance and auditing tools for legal, better sales forecasting frameworks for the sales team, or more efficient processes for our operation teams, everyone benefits. The amount of collaboration depends on the team. You don’t have to work directly with stakeholders all the time, but it is a big part of our culture!

Each of our product teams is staffed with experts from various domains.

We are organized into various teams, each working on a particular initiative (either one product or part of the platform). Our teams are comprised of combinations of product managers, designers, oncologists/clinical professionals, and engineers. All of our teams are fully staffed to operate independently, which means that engineers do more than read and write code. Engineers are constantly working side by side with the people on their teams. We take customer feedback into account as we translate our vision into tangible roadmaps that we can then execute. The ability for the team to deliver relies on collaboration between each team member’s skill set.

LabGenius aims to bring together the best of synthetic biology and software engineering to create something new.

As a result, we need to collaborate both within the tech team as well as with our scientists – you can’t automate something you don’t understand! We designed our office with this collaboration in mind. Not only do we all sit together in the same shared space (science and tech team members are intermingled), but our protein-engineering laboratory is built into our office. This not only makes it easy to dive in and out of the lab, but it constantly opens up opportunities for collaboration and encourages knowledge sharing.

Many aspects of our day-to-day work require working really closely with the science team, whether that's optimising an experimental protocol, automating a liquid-handling procedure, or analysing the results of a DNA-sequencing run.

We are also big fans of knowledge sharing, and have a weekly tech-talk slot for someone on either the science or tech side to discuss some of their work, pitched at a general audience. This is both a great way for us all to gain knowledge in new areas, as well as to gain fresh appreciation for the work we all do each day.

We might have offices in different cities but we are always collaborating.

At Algolia, tech and non-tech profiles are on the same boat and show respect for and interest in one other. The engineers care about the business and the customers. They are all working on the support alternately. Marketing and Sales are trained to have a deep understanding of the product and contribute to engineering feature specs giving constructive feedback. We take full advantage of Slack, shared documents, and video calls to work collaboratively. We also encourage everyone at the company to travel at least once a year to visit and work from a different office. For example, as an engineer in Paris, you might work face-to-face with your peers in the San Francisco office for a few weeks. Traveling and working from a different space with different people offers inspiration and a tremendous amount of perspective. Plus, it’s always really fun to get to know your colleagues in different cities!

Our collaborative culture is part of what makes Stitch Fix unique.

In addition to building software used by Stitch Fix customers, we build many internal tools used by Stitch Fix employees. Most engineers here work directly with the people using the software they write. Engineers work together with non-technical people in other departments to solve business problems. That means the engineers supporting Merchandising work directly with buyers and planners to build the tools Merchandising needs to do their jobs. Engineers supporting Operations work directly with teams in the warehouse. We place a high value on partnership here. It's how we work everyday, and how we build great things together.

Many of us are not consumers of our service, which means we have to work extremely close with our care delivery and management teams to understand the end-user and build the best product.

Generally speaking when you work on a social media app, the developers belong to the audience they’re building for. As engineers at Honor, we’re not seniors getting care nor are we caregivers giving care. This means we have to work from a place of extreme humbleness and open-mindedness so that we don’t build the wrong product. When we have questions, we don’t assume we know the answer; we have to ask a lot of questions and work really closely with people who do know the answers. Likewise, if a Care Professional encounters a tech problem, it’s likely that an engineer will jump directly on the phone and walk them through debugging the problem. Without that kind of collaboration, there is no way we’d be able to build a high quality service.

Regardless of what team you’re on, it’s likely that you’ll be doing cross-functional work.

We work collaboratively at Box. Whether it’s with the diverse group of people on your current team or with people from various departments, it’s important that everyone we hire is able to and enjoys working with others. Our interview process has both technical and cultural components and we care less about if you solve the problem and more about how you communicate with someone as you’re working through it.

We have a lot of different pieces in play.

We have a interface for our users that allows them to sign up, tell us who their doctors are, and where they can interact and share their records once we collect them. (Check out our demo!) However, the majority of our work is in structuring the data in the records we receive. We have an extensive internal system for managing the medical record collection process (think calling offices and getting faxing) as well as an interface for processing. We get paper records that need to be transformed into text, and from there, into structured data where individual data elements are recognized. Therefore, each of us works closely with our operations and sales teams.

Working cross-team is one of the most unique aspects of working at Thread.

We’re bringing together stylists, engineers, and data scientists to reshape how retail works. These teams work together every day to develop new tools and approaches. We’re also interested in and actively applying machine learning to other aspects of the business. For instance, we are building tools to help predict what users are going to want to buy rather than relying on archaic merchandising practices.

As a cross-functional company, we also always celebrate our successes together as a whole company. We truly are the sum of our parts, which is why we we take time to thank each other at the end of every week for the help we’ve received from one another. Finally, we also spend time together outside of the office. We budget time to do fun things together, with some recent highlights including axe throwing, an augmented reality treasure hunt, and Thanksgiving dinner.

Each of the 4 business departments at Zeus has a small tech team dedicated to them.

Our mini tech teams are comprised of 3 engineers, a designer, and a PM. Tech teams sit with one another and at minimum, meet once a week with the head of the business department that they work with. As an engineer, you’ll work closely not only with designers and PMs, but also the other members of the biz department who give feedback, report bugs, and ask questions.

Cross-functionality is important for us because much of the software we build are internal tools, which means engineers need to work well with and understand the needs of non-engineers. We also have some deep technical challenges on our data science/engineering team (like collecting, cleaning, and processing millions of points of data and deploying ML models to price homes), and we encourage anyone interested in depth vs. breadth to do so.

As we hire more engineers, we will be fortifying our existing teams (Owners, Residents, Operations, and Data). We may also spin up new teams to focus on finance, marketing, and the physical home product. Exciting things ahead!

We look at the company wholistically and make sure that money in and money out make sense.

Our team is organized into several pods that focus on different products. The Growth team as a whole is involved in pricing, the core feed infrastructure, user acquisition, referrals, and we are responsible for many of the features you see on the Postmates app like Most Popular and Recent Orders. We couple our product engineering work with comms and marketing, and are responsible for spending our multi-million dollar marketing budget wisely. We are involved in a number of projects with touch points across all products and it’s not uncommon for our team to start a project and spit out a team to maintain it once we’ve proven it to be impactful.

We work with many teams to make the best decisions.

We use cross-functional teams to advance our product. A typical engineering workday will have you pairing with other engineers, syncing with product managers, getting feedback from designers, reviewing interaction events to send to analytics, and sitting next to operations/sales to iterate on the UX of a feature.

That’s why we involve other teams in our engineering interviews. When we gather after an interview to discuss an engineering candidate, we actively ask product managers, designers, and other engineers, “Would you want to work with this person?” We consider it a disqualifier if the answer isn’t a resounding “yes”.

Overall, we celebrate our successes as a team, and we discuss our failures as a team. We believe that teams that work well together will outperform teams of highly productive individuals working alone.

We have company-wide initiatives that are driven by cross-disciplined project teams, and project teams are owned by a Directly Responsible Individual (DRI).

For a recent new product idea, we wanted to get to a demoable MVP ready in 4-6 weeks, which we had never done before. We brought together 2 product designers, 2 business team members, and 1 engineer into one war room for 6 hours a day, 5 days a week for the first 2 weeks. We invited a design partner from our of our VCs to help lead our initial design sprints, and after we had some low fidelity prototypes, we had our business team reach out to super users at our client sites to set up feedback sessions where everyone involved sat in. Through quick feedback, prioritized iterations, and close teamwork, that project team was able to prove out a market that could result in a new line of revenue for the company. Without the business team, the team would not have had the relationships with clients to get useful feedback in a short window. Without the designers, there wouldn’t have been prototypes to show or user research to build from. Without the engineer, there wouldn’t have been a demo built. At the end, the engineer noted this was his favorite project because the depth of the additional context he had from the business side allowed him to make better decisions on the development side.

No team is effective in a silo.

There’s a high degree of information sharing and collaboration among engineering teams and between engineering, marketing, sales, and support. We all build tools that are relied on by one another. It’s not uncommon for engineers to participate in other teams’ standups so we maximize cross-pollination of ideas. Many engineers have made pull requests in at least half a dozen repos across the organizations, and engineers are always welcome to contribute to another team. Engineers are also encouraged to take ownership of their features and work side-by-side with business owners even in the ideation phase of a feature. So you’ll often find engineers not only advising on technical feasibility, but also working directly with the product team to improve design and user flows.

Information sharing across teams is so important to us that for the past two years, we have flown our entire team to one location for our offsite. In 2016 it was in Greece, and in 2017 it was in Spain. One of the highlights from our 2017 offsite was a blindfolded walk in the woods where we had to lean on other team members to find our way. It’s a good metaphor for the amount of trust we have in one another and the degree to which we are comfortable relying on one another.

Take a look at our yearbook from last year.

Our seating reflects how much each department collaborates with one another.

Engineers, analysts, product, and interns all sit together and are interspersed. Our product requires expertise in multiple fields and it’s really at the intersection where we build. Teams are constantly working together and making use of the various whiteboards we have around the office, stationed in open spaces for all to see. It’s apparent when you walk into the office that information flows naturally and teams don’t feel segregated from one another. Similarly, there’s no sign of hierarchy as our leadership works alongside their team members.

A sense of teamwork and collaboration are a must for Relay team members.

We’ve cultivated a sense of open, effective communication between the engineering team and all other parts of the company. Because of our flat organizational structure, getting something done here doesn’t require crazy levels of approval and back and forth. Stuff gets done because we give employees young and old a large amount of autonomy and focus on working with and for each other.

We have this venn diagram of developers, designers, and product-focused leaders to create our balanced team.

We really push hard within Carbon Five, as well as with our clients, to have diversity across skills. We also look for people that have low ego; strong opinions are welcome if they are loosely held. Almost every one of our developers want to know that the thing they’re building is being used. Even if it’s not specific to product or design, they like understanding the value of what it is they’re building and having input on it.

Our desk arrangements are unstructured, with people often sitting with others outside of their specific discipline.

Why? Because this allows for a higher degree of ambient knowledge sharing. It is typical for engineers to work with stakeholders outside of the engineering organization, even if the problems they are solving seem purely technical. For example, trust is fundamental to our marketplace. Engineers recently built scam detection tools to ward off bad actors. They collaborated with the customer success team who deals with users who may have been affected to best understand the types of scams. This unlocked a whole series of ideas and approaches informing further iterations.

At the Connected office, our executives work side-by-side with our engineers, who work side-by-side with our designers, who work side-by-side with...you get it.

By bringing together engineers, designers, and strategists, the opportunity to unblock a problem or brainstorm a new idea is always possible. It takes many perspectives to make a great digital product.

On a more fun note, we recently incorporated a House System whereby Connected team members are divided across departments into official “houses,” which compete against each other in various company-wide activities, with prizes (and glory) to be won. Previous events have included a scavenger hunt, a trivia night, and a spelling bee. These team-building activities help create an atmosphere of collaboration by bringing the entire team together and breaking down barriers between departments.

You’ll know everyone by name whether they’re in sales or marketing or customer success.

As an engineer, your work spans far beyond just pushing code. We are a customer-focused group of engineers which means everyone hops on at least one sales of customer call every month to garner empathy for both our customers and coworkers. Every team plays a critical role in the company, and the best way to celebrate our successes is knowing how we each contribute to them. That’s why we do an “Empathy Day” every quarter where everyone shadows another co-worker to learn more about their jobs, or we act as one of our customers to understand how they use our product. Empathy, one of our company core values, is baked into collaborative work and we practice it daily with one another as well as with our customers. You’ll never feel disconnected from the end user either, as we have a weekly “Customer Feedback” meeting where we hear raw, honest feedback from our users.

We’re constantly talking with each other because Alto's solution depends on collaboration.

Once a week, we have a "Tea Time" meeting to review recent incident reports from our patients. This meeting always includes members from pharmacy, patient care, pharmacy operations, engineering, and design because we believe in a cross-functional approach to resolve the underlying issue(s) for any unhappy patient. Together, we figure out why these problems happened and what we can do to prevent them in the future.

The problem Alto is solving is so complex that it requires the skillsets of a very broad team. Engineers need to work with pharmacists, designers need to work with our operations team, and the people who manage our partnerships with physicians and insurance providers need to be on the same page too. Engineers, pharmacists, and operations sit together, lunch together, and we’re constantly talking.

We rely on everyone contributing their ideas.

Ideas can come from anywhere at Aero, regardless of your title or department. As a company, we sit together and do standups together. As engineers, we probably learn more from our Community Manager and Operations team than they do us. For example, our VP of Engineering Gabe often sits with Greg, who is in Ops, so that he can understand what the actual daily routine is. By understanding what it required in the day-to-day for booking flights, we can then use technology to alleviate those pain points.

Ben also sits with Jamie to learn about Facebook and Google ad campaigns. We put an emphasis on sitting down with the person you want to work with, outlining an objective together, and tackling it as a team. We aren’t dogmatic at all about pairing, but there are certainly times when pairing is appropriate and a helpful practice when it’s needed. It helps us understand how we work.

As another example of how we collaborate, we recently did an exercise where everyone gathered in one room to brainstorm for an entire day. We discussed what the ideal customer experience should be and then voted on one another’s ideas. This helped us determine our product roadmap.

Engineers at YC work directly with founders and YC partners, as well as our legal, finance, outreach, and operations teams.

Our goal is simple: scale YC and continuously get better at funding excellent founders and big ideas. It’s a job that is never finished, and the next software hire will do the same work that we all do. You can expect to sit with the engineering team in our open office in San Francisco, working directly with founders and YC staff.

Every Tuesday and Thursday, all of YC’s partners work with the founders at our Mountain View office doing “Group Office Hours”. Office hours allow founders to meet with partners and talk through problems they’re having. On these evenings, we have dinner and a talk from one of our successful YC founders (think Airbnb, Segment, and PlanGrid founders). Members of the software team are encouraged to get to know the founders, have dinner with them, attend the talks, and occasionally sit in on office hours. As a YC engineer, you also have the opportunity to participate in YC’s interview process (where companies fly in from all over the world to meet with YC partners and potentially join the batch). At the end of each batch, when we have demo day, YC’s software team manages the software and attends the event with the rest of the organization. It’s an exciting and unusual job! Tell us if you think so too.

Instead of centralized teams, we have cross-functional teams at Intercom.

We absolutely have guidelines where it makes sense to do so, for example in picking out and investing in critical technologies, or in ensuring Intercom is available and secure for our customers. We have developed pattern libraries for engineers to reuse as they see fit, but as an engineering organisation that prides itself on autonomy and empowerment of our engineers, we’re more interested in trusting and cultivating good judgment. You’ll more frequently find our engineers collaborating with more tenured teammates, and colleagues from other disciplines like design and product management, than you’ll see them follow a strict, centralised process or be beholden to the limitations of some technical framework.

Silos should not exist between teams.

Our technical and commercial teams work together with the common objective to improve our products. Since we have now evolved into a Fin Tech company with aspects of Customer Transaction Management, it is vital for the Business team to be in absolute sync with the Technical Team. We achieve this by trying to keep everyone on the same page with regular meetings. We have two dev meetings a week, one business meeting each week, and a full team meeting once a month. As an engineer, you will work alongside your engineering peers as well as members in other departments.

Understanding how the business works improves the code we release.

The best way to familiarize yourself with our product is to use it, which is why everyone at the company is entitled to one G Adventures trip per year. Even when you’re not traveling, one thing you’ll often hear is that you don’t have to be coding 100% of the time. In fact, we hope you don’t. How much you interact with other departments depends on your exact role, but you can expect to work closely with other departments on a daily or weekly basis. We do this so that developers can learn how the business works, how we can best serve our users, and have the necessary context to engineer quality solutions for our customers.