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.

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.

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.

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!

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.

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.

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!

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.

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.

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.

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.

Even if you’re a great engineer, you’ll have to be a good team player too.

We work in a fast-paced, creative environment where everyone is expected to pitch in and solve problems together.

Our management philosophy can be summed up as: one team with each individual having the responsibility and authority to get their job done. That means that if your problem crosses departments, then it’s up to you to get help from the other department.

And of course, the reality is, now were so small, and we have so much to do. We don’t really have departments so much as we have people. Everyone works with everyone else so we can maximize our output.

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.

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

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.

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.

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.

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.

All of our engineering teams do rotations with our Data/DevOps teams who we call the Jindos.

We are a highly collaborative company and have done our best to remove barriers between teams and departments. One of the way we increase cross-pollination between our engineering teams is through a Jindos rotation, when members of each tech team spend two weeks with the Jindos. During the rotation, we participate with the Jindos on their current projects and go to their daily sprint meetings. We’re essentially embedded on the team for 2 weeks. It’s a great experience because it gives us an idea of what the Jindos work on, what their pain points are, and offers a more developer-oriented perspective. Additionally, it gives us the opportunity when we are not wearing our Jindos hats to better support them in case they are short on staff or otherwise require assistance from a developer.

In discussing his experience in Jindos rotation, Albert Hopkins said, “I was able to offer my Python programming and packaging experience to a software project that they use and maintain. At the same time I was exposed to a host of tools and technologies that I was not aware of before, but I can now take with me in my day-to-day activities.”

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.

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.