Our responsibilities don’t begin with a ticket or end with a deploy - our ideal team member is someone who identifies what we should work on, figures out how best to tackle it, and then isn’t satisfied until it’s done right.

We value a person’s ability to identify opportunities and drive projects from ideation to production, often collaborating with multiple people along the way. They shouldn’t need anyone to hand them a specced out project, or babysit the project while they’re working on it. We think deeply about this quality, and consider these three scenarios for any member of our team, the last of which we always optimize for:

Bad scenario: They only work on exactly what they're told to, and if someone isn't watching closely or delivering specs in great detail, then the project is likely left unfinished or shipped in a way that doesn't make customers say "wow".

Good scenario: They aren’t satisfied until a job is done right. Nobody ever says "I wonder how that project is going - I haven't checked in in a while" or "I hope they thought through these 5 subtle details."

Great scenario: In addition to the “good scenario”, they actively contribute to our product roadmap. They identify what to work on, consider trade-offs between different tasks and implementations, and drive us to amazing solutions to problems we didn't fully realize we had. Everyone on the team looks up to them and intuitively thinks of them as a real owner.

It’s your company too.

We encourage everyone to speak up and say when things are not working. You can only start making improvements as a team once you’ve identified that there is something to work on. We do this because everyone has ownership in what we’re building and more importantly, ownership in how we’re building it. It’s common for teams to do weekly brainstorming sessions where engineers, product and designers come together to make decisions. You don’t just own what you’re working on, you see how what you’re building connects to the entire company.

We are an end-to-end product partner, which means we work with companies to research, validate, design, build, and launch digital products.

At Connected, we don’t just imagine—we build. From research and ideation to final product delivery, our engineers are involved every step of the way. Our “Connected” approach integrates engineering, design, and strategy from the very beginning to the very end. That means no broken telephones—only well-rounded teams, projects, and outcomes.

Engineering is responsible for all aspects of shipping a product.

Everything from ideation, gathering requirements, design, and implementation, to QA, releasing, gathering customer feedback, analyzing key metrics, and iteration. You will work closely with our designers, user researchers, and data analysts to bring products to life and you will be responsible for defining what success is, and ensuring that it's achieved.

Example products:

• Automatically pay monthly bills (1 engineer, 1 designer, 1 data analyst, 1 user researcher)
• Automatically save for a rainy day (1 engineer, 1 product manager)
• Automatically get out of credit card debt (1 engineer, 1 user researcher, 1 designer, 1 data analyst)
• Making Digit more conversational (swapping out the NLP aspect) (1 engineer, 1 product manager)
• a/b testing the signup flow to maximize conversion (1 engineer, 1 data analyst)
• Facebook Messenger App (1 engineer, 1 product manager)

We encourage the entrepreneurial spirit within our software team, just as we do for the founders in each batch.

Startup School is a great example of what one engineer can build at YC (good work, Finbarr). Startup School required close work with YC’s President, Sam Altman and Steven Pham (who works on special projects) to spec out the software, define what a YC MOOC should look like, and structure the program using software. For those who aren’t familiar with Startup School, it is a collaboration with Stanford University that combines lectures and hands-on office hours to teach founders about launching startups. Companies are invited to apply to participate in the MOOC. Companies that are accepted are split into groups and assigned a YC alumni to advise them as they learn from the course material and submit weekly metrics about their companies. At the end of the class, just like YC, they have a Demo Day. But unlike YC’s, MOOC Demo Day is virtual since these founders are working from all over the world.

Project ownership is more than code development. As you can imagine, developing Startup School involved collaborating with others to design course material, build software from scratch to run the course, and participation in the course to support the enrolled founders; sometimes offering technical advice for their startups and other times providing technical support and building new features.

The entrepreneurial spirit at YC extends to its internal engineering team. The possibilities are endless and creativity and experimentation are encouraged. While you aren’t required to invent new projects yourself, we will support the ideas you develop. One of our engineers, for example, put together a series of conversations for the YC blog called Ask A Female Engineer where female engineers answer questions posed to them by readers.

Get in touch if you want to know more!

Ownership is one of our key criteria when evaluating performance.

Everyone in Instacart’s engineering organization is expected to take ownership of their work. Ownership covers all of the ingredients – how you scope, plan, ship, communicate cross-functionally, and maintain your work. We value ownership so much that it is one of the main categories by which individual contributors and engineering managers assess performance.

We value engineers who can truly “own” their projects and communicate with design, product, comms, and other adjacent teams. As the company grows, it becomes increasingly important for individuals to possess both the EQ and IQ to manage a project from beginning to end. Ownership grows as you grow within the company, too. Over time, engineers will take on bigger projects that range across your team, the engineering org, or even the whole company.

Our engineers love working on projects from inception to completion.

At Gusto, we have an ownership mentality: every employee has the power to make our company better. Our engineers own projects from end-to-end by influencing initial feature specs, building backend APIs (Rails), writing frontend code (React), and overseeing ongoing improvements for deployed features.

Check out Flexible Pay, an exciting project our team recently launched. With Flexible Pay, people have access to the money they’ve earned when they need it — plain and simple! If you’re interested in building elegant software with far-reaching effects in our modern economy, join us!

Product development is not dictated by one or two people.

Engineers, designers, and other stakeholders work together at the beginning of every new project. We discuss what should be built in the first iteration of the product, what we want to measure to determine success, and perhaps more importantly, what shouldn’t be built in the MVP. We aim to have a collaborative culture where our collective best idea wins - product development is not dictated by one or two people.

Afterwards, engineers work cross-departmentally to build and ship the product. In many cases, we have to balance the needs of the company with the needs of our customers, and engineers play an integral role in making sure those needs are met across the board.

Once an MVP of a product is built, we like to demo it at our weekly all-hands, celebrate the win, and gather feedback to make it the best it can be. From there, we continue to have a tight feedback loop between our teammates and our customers, using data to iterate on what we have built.

In small teams, the most effective way to work is for people to have ownership over projects and features instead of over a certain part of the stack.

Everyone in Peergrade participates in ideation for new features, managing projects internally, building full features out from idea to production and on maintaining that feature continuously. Development projects have a project owner from the development team. That project owner is responsible for getting the project out and can pull on other people like designers, the CTO, marketing etc. for all the help they need.

Our last project in Peergrade was a complete overhaul for how institutions use Peergrade including new interfaces for administrators, sharing of content between teachers in institutions, purchasing of institutional plans and automatic setup of integrations with learning management systems. Felipe (one of our full-stack developers) was responsible for managing the project and took it from ideas and sketches to production within 4 weeks. Simon (co-founder and designer) helped design the new interfaces, Malthe (co-founder and CTO) helped ensure that all parts of the technical implementation were up to par and Jamie (another of our full-stack developers) took care of the payment part of the project.

We practice bottom-up ownership and are empowered to own the problem, not the solution space.

Amplitude is organized into four pillars: Adoption, Data Management, Analytics, and Growth. Pillars reflect the company’s strategic objectives, cater to a specific persona, and each one is led by PM, designer, and an engineer. Together, this trifecta identifies the strategy, develops a roadmap, and creates smaller pods to focus on smaller problem areas for 3-6 months.

Pillars and pods are set up to be cross-functional, and as a result, can work autonomously. Product roadmaps are never handed down by leadership. Instead, we practice bottom-up ownership, which means the individuals who make up a given pod or pillar are fully responsible for owning their entire problem space.

Bottom-up ownership also means that teams/pods have the ability to say “no” to customers. When negotiating deals, potential customers sometimes ask us to build specific solutions for them. It is up to individual teams to identify the underlying problem, decide whether those feature requests are in fact the best solution for that problem, and outline appropriate next steps.

Teams continue to iterate to keep delivering the best experience for our customers.

Every engineer is expected to own the full lifecycle of their product: to ask questions of users, design the product, build it, test it, incorporate feedback, ship it, and maintain it over time.

We cultivate a strong “owner mentality” throughout the company. As one of many examples, one of our engineers has a background in mathematics and analytics, and just volunteered to own analytics for the organization. She considered it a rare opportunity to get to own an entire engineering function for a high-growth company. To succeed in her chosen assignment, she'll talk to stakeholders across departments, triage their needs and opportunities, and design a program for data-informed decision-making throughout the company. She will ensure that each of her stakeholders gets the data they need in a format they can use. She’ll continuously incorporate feedback, fix what's broken, and plan for future expansion.

Though we expect product ownership, you’ll never have to go it alone. We're extremely collaborative and helpful to one another, and we strive to ensure that no one team member is ever stuck as the only knowledge holder on a given piece of code. And of course, we want you to thrive: Wherever possible, we encourage people to volunteer for assignments where they believe they can contribute the most value.

From inception to ideation, prototyping, and completion — we fully own our projects.

At a startup, there are a lot of different hats to wear and a lot of gaps to fill, and at STORD, we regularly practice start-to-finish ownership across the company. We are strong believers in having an internal locus of control, or in other words, a high-degree of responsibility for what affects your life, and we look for people who share those same traits. Having a sense of ownership shows up throughout our work process: Julian Pegues (software engineer) stepped in to help augment our product process with a new feature build-out and Nikhita Sagar (data scientists) built a new operational process to improve our data flow across the company.

We also regularly encourage people to have a high-degree of ownership by practicing one of our company values, Empowering Others. Our leadership is focused on aligning and setting direction, empowering team members to own their work, then largely working to clear roadblocks. This allows team members to have a high-degree of autonomy in their approaches and start-to-finish ownership over the projects they take on.

STORD is growing quickly, but we are just at the beginning of the impact we can have on the supply chain. Do you want to join a team that is tackling real-world challenges and solving massive inefficiencies affecting economies? If so, check out our open roles and reach out!

Whether you’re an individual contributor or working on a team of three, your product is basically like an independent business.

From ideation to execution to QA to maintenance to marketing, engineers really own the entire process end to end. Full ownership not only enables us to ship quickly (because you won't need to wait on code reviews or for product to sign off on your work), but it also hits on the best part of engineering: the high of creating, building, and shipping. As one example, Rahul Murmuria designed, implemented, and deployed our Usage Intelligence product. Or take a look at Ad Intelligence below (which Dmitry Filimonov led the team in building!) to provide app developers with insights to the marketing strategies of their competitors.

You can expect to build and ship a product every month or so.

Engineers here are energized by quickly iterating on ideas and then delivering products for our customers to use. As engineers ourselves, we understand that knowing how much impact your feature or product will have on your user(s) is the best motivation, and we want to keep it that way. We don’t enforce deadlines because the desire to help our enterprise customers (like Zynga, SuperCell, or Google) make better, more informed decisions about their next investment is what fuels us. (We're pretty excited when we get press shoutouts too.)

We like to work with folks who are excited about making and carrying out their decisions, and who enjoy working outside of their role.

Engineers at Vanta are full stack; they code and architect both the front- and backend of Vanta. Some engineers get on the phone with customers who have agreed to alpha test a new feature and give feedback, others are drawn to dev-ops and build out our infrastructure and monitoring, while others work closely with support and product to define the requirements of a new feature.

Being multifaceted is incredibly important to us because we work on the highest-priority issues, and the highest-priority thing isn’t restricted to a single part of the tech stack. Having exposure across technologies and departments suits folks who enjoy going broad rather than deep, as well as anyone interested in founding a company someday.

If you’re an engineer curious about sales, you’ll be shadowing sales calls and helping us understand our customers; if you’re an engineer who loves design, we’ve got loads of product surface for you. If you’re interested in building a company, you’ll be on the interview loop (with training!) for a role you’ve never interviewed for before. Everyone contributes to the product and the business, and our goal is to empower everyone at the company to work outside of their job title.

You have control over the direction of your project, and the responsibility to own it end-to-end.

Right now, we are a growing and deeply committed team of ~35 engineers, data scientists, and product designers. Troy, our CTO, sets long-term milestones and then we work together as a team to decide how that translates into distinct projects. We are in the process of hiring inspiring, technical, hands-on Engineering Managers as well as a Product Manager or two. We are building a management team that is committed to empowering their team members through their workstreams, with end-to-end ownership.

If you have an innovative idea that is approved by the team, you’ll be given complete ownership to implement the idea.

For example, an intern was tasked with finding a solution to a problem caused by non-engineers in the company issuing clumsy updates. His solution ultimately became a popular internal tool for the company. That person currently works remotely for the company simply maintaining that tool. Every employee at LoyLap takes pride in they work they do and we as a company nurture our employees by providing the best possible support and resources to help them succeed in their endeavors.

Every team member has significant ownership.

In order to feel ownership, everyone needs to have as much context as possible so that they can be trusted to make the best decisions possible. We have “Brown Bags” about Security and Compliance topics to turn everyone into a subject matter expert, and we all take turns leading teaching sessions about different areas of our product to help bring other team members up to speed. We avoid siloing knowledge at all costs and because we are a remote company, we always make sure that information is both documented and easily shareable to all team members.

When it comes to specific work-to-be-done, individual engineers start with either broad requirements (for big projects) or a specific User Story to solve. In both cases, we’re responsible for designing a plan of attack, getting input from other team members, and seeing the work through to completion. For example, David was the engineering lead for our move to a task and notification-based set of features (a massive undertaking). Armed with just a set of user stories and aspirational designs, David collaborated with other engineers, the product lead, and the design team to propose an architectural plan. After getting the team’s input, David then turned around and implemented those plans. He even sat in on calls with beta-testers to see how the feature was actually solving user’s needs.

Individuals who are proactive and who ask for help when needed flourish in this environment, and it leads to more coherent product development. The benefit of this start-to-finish ownership is there is never a dull day at Aptible. Folks who work here tend to love crossing boundaries into other product areas – ideating, interviewing customers, UX/UI design, testing prototypes, architectural design – to get the additional context they need to take ownership over their deliverable.

We provide autonomy so long as the visibility and reporting is available.

The two things we’d like to see from every task are ownership and estimated completion date. We do our best to leverage tools to ensure that everyone is aligned across teams, projects, and locations. Each of our teams use the tools that work best for them too – Lahore uses Trello while Barcelona uses Pivotal. We're a bit agnostic so long as everything is organized and tracked. :) We then coordinate between our three offices during our 15-minute daily standups.

On the individual level, we provide a tremendous amount of autonomy, which means everyone is responsible for owning their work start-to-end. We define quarterly engineering goals. In Barcelona, we operate with 2-week sprints (scrum), in Pakistan we have 1-month sprints. In San Francisco, Matt is currently a one-man show and chooses his own schedule. (Though we’re excited for this to evolve as we bring on new engineering team members in SF!)

At Airtable, engineers are involved in the entire product development process, including ideation, implementation, instrumentation, and iteration.

Working closely with our customer-facing teams to understand user needs, engineers write specs for new features, conduct “spikes” (timeboxed investigations to explore potential designs), and create UI mockups or prototypes. For a product like Airtable – a horizontal toolkit for software creation – having this hybrid product and engineering mindset is critical to designing building blocks that are simple and usable, yet powerful and flexible.

One way we foster this mindset is through a philosophy of thinking from first principles. Rather than creating narrowly-scoped single-purpose features, we constantly try to solve higher-order meta problems that span multiple use cases and industries. For each new feature we build, we consider how it composes with the existing surface area of the product, thinking through newly introduced edge cases or emergent ways to unlock customer value. To this end, we often simmer on problems for weeks or even months before we build it, in order to preempt problems that may come up in the future or inform the sequencing of new features in a complementary fashion.

For each new product feature, the engineering lead is typically paired with a product specialist lead responsible for tasks like analyzing the competitive landscape, writing internal documentation, and conducting user studies and the beta feedback process. Engineers also work with QA to write up a comprehensive test plan, and with our go-to-market teams to develop launch strategies and growth experiments around the feature.

As our engineering team grows, we are putting more structure in place. We’re dividing the organization into subteams, each having their own tech lead and responsibility for setting team goals. Teams that work on directly user-facing product surfaces also have a product architect, who focuses on defining the product roadmap for the team’s areas of responsibility. Both the tech lead and product architect roles are filled by engineers, who must have an intimate understanding of both the underlying technical architecture and the ideal user experience of their respective domains. By design, Airtable's product development methodology is highly collaborative, with engineers deeply involved in and owning key elements of this entire process from start to finish.

You’ll start with product brainstorming with cross-functional team members, eventually deploy your work to prod, and do everything in between.

Engineers not only get the opportunity to fully own our work, but also are expected to. We value engineers who want ownership and step up, no matter how small or large the task. Many projects are cross-functional in nature (with stakeholders in legal & compliance, biz dev, and/or customer success), so engineers need to be proactive in facilitating discussions so that our projects succeed.

One great example of start-to-finish ownership is Annie spearheading our Admin Dashboard. She started from scratch, studied mocks for dashboards from Dribbble, worked with Product to design initial features, and built the full stack. Throughout the project, other team members helped with brainstorming, knowledge sharing, code reviews, and QA. Annie also hosted a team-wide “bug bash” on her own initiative to ensure releasing the best product.

Another example is our NovaConnect widget, screenshotted below. In 2018, we completely re-designed the widget linked below and this project required start-to-finish ownership led by Ian. Since it was such a noticeable consumer-facing change, all team members were involved in getting this overhaul deployed at varying phases. Let us know what you think!

We believe in making an impact from day one.

For us, ownership goes far beyond just what you’re working on. It’s about seeing how what you’re building connects and adds value to the organization and product as a whole. When new engineers join, they hit the ground running, such as Gary Luo who dove head first into a new data infrastructure initiative the company was piloting. From talking to users to onboarding data and implementing changes, Gary spearheaded a critical project for Enigma—all during their first six months at the company.

Ownership and autonomy are central to how our team members engage internally. Everyone is expected to help own and shape company culture. We’ve had engineers join the company and immediately kick off task groups, jumpstart important product discussions, and make improvements to internal processes. Recent initiatives have included optimizing our interviewing framework, organizing open source flash mob events, and putting together company hackathons.

We want you to leave your mark on the product.

At Jane, we’re looking for a certain type of person – someone who feels ownership in what they do and takes the initiative to get things done. One great example of this is when Andy (a software engineer at the time and now a product manager) got fed up with how often we had issues with our deployments. Andy wasn’t sure if our tests were actually failing or if there was an issue with Capybara. He decided to explore Cypress on his own time, build it out, and developed tests that were more accurate. It’s this kind of ability to raise your hand and commit to delivering something you’re proud of that we’re looking for in every hire.

Similarly, when Cody (one of our newest engineers) joined the team, he wasn’t afraid to take ownership. When he was ramping up, we assigned him several bugs and small features, which he paired with other team members on to get a full understanding of the issues we were facing. He spoke up about certain use cases and acceptance criteria not being what he was used to. But instead of saying, “I wish there was more structure here”, and then asking the PM to handle all project scoping, he took it upon himself to build a process that worked for him. He then met with the PM to collaboratively establish a workflow that met his needs and expectations. His proactivity led to systemic changes in how features are scoped and built.

If you’re the type of person who doesn’t wait to be told, but rather takes initiative to solve problems and develop features you’re proud of, we’d love to meet you!

Our ownership mentality is best demonstrated by how we do OKRs.

Every engineer at Labelbox owns a single OKR. They are responsible for everything related to their OKR – design, customer success, development – and after six weeks, we come together to switch up OKRs for the next six weeks.

Everyone is involved in our product roadmap. Features tend to come together from multiple people on the team, each person contributing their insight, input, and ideas. We are currently ~15 engineers which means that everyone has the space to reach and stretch.

Our image segmentation feature is a great example of how features come together: the project was divided into smaller parts and each engineer was able to own the development process. That process included talking to customers, making case files, designing, and then implementing this feature. The end result of this effort is a product that allows customers to label every pixel of an image. Think Photoshop for the browser.

We believe that having ownership means having agency over your schedule, too. Labelbox is 50% remote and we have engineers on multiple continents. Everyone is fairly autonomous. You can roll in at 8am or 10am in your local timezone, go to the gym in the middle of the day, and structure your schedule in whatever way makes you productive and happy.

When you’re given a task or a feature to complete, it’s yours until you deploy to production.

We’re a small team which means that everyone doesn’t just get to be an owner, everyone has to be one. One task may consist of touching both the backend and frontend, implementing designs, writing database migrations, and updating server configs. Once your work is deployed though, the entire team is then responsible for maintaining it.

Engineers on our team have been able to drive and own large projects on their own. In the recent past, Sean built out our entire enterprise product (meeting with our sales team, gathering requirements, designing the UI, and coding everything) and Marc worked with our designers to completely redesign ReadMe’s homepage.

Engineers are not only responsible for the code they ship, but also the data that their code produces.

At New Relic, project leads own projects start-to-finish. This includes collaborating on ideation, creating specs and tickets and ensuring the project is delivered on schedule, with adequate monitoring, tests, and documentation. What they’re not responsible for is writing code. They may write some code, but that’s not the expectation as a lead. Tickets within projects can be completed by any engineer on the team, but the project leads ensure the integrity and success of the overarching project. When working on a ticket, engineers are not only responsible for the code they ship, but also the data that it produces. Data quality is an integral part of our acceptance criteria.

We’re lucky to have many teams at New Relic to support our individual team. For example, there’s an entire team dedicated to helping other teams at New Relic with their processes: establishing charters, beliefs, and doing retros. We also have a reliability team that supports other teams, making sure we’re following the best practices with derisking. All of this is built in so that we can pay full attention to our work and not worry about other things like devops. Leads can then focus on what they know best: taking ideas to stories and executing everything on time.

Our side-project DNA compels us to work from front to back, marketing to making.

As a team of generalists, we naturally gravitate toward being inspired and working on problems holistically. Design, frontend, backend, marketing, and support all blend into one as we take on these roles throughout the development of a feature.

Ownership at Monograph means taking a stance and supporting it with prototyping, user conversations, or data. Being a startup, there are often challenging problems with no clear precedent which implores us to get creative and go with our convictions.

Ownership may also mean answering emails from customers, finding bugs, creating documentation, extending a function, or updating a design. Having optimistic, supportive teammates really helps to get projects from start to finish.

Engineers are always included during the ideation stages of a project.

Everyone starts on the same page if everyone is involved in identifying a project’s objectives and scope. As an engineer, you’ll have a seat at the table and have a voice in how problems are solved, what features to build to solve those problems, and how those features are built. Some projects are large and require a team effort, while others are small and a single engineer can prove that being full-stack is not just a myth.

One large project that our team took on was rebuilding the user activity feed from the ground up. We had a meeting to discuss the objectives of the project for the company and review wireframes with design team. Our conversations within the engineering team led us to add a huge feature: a global version of the activity feed showing players’ commits and videos within their whole sport. The team organized into backend and frontend teams, and communicated closely to produce a product that was rolled out in a controlled and bug-free way.

Engineers sometimes take on smaller projects, too. Don built a way to generate one time login links and for users to request one from the login page as an alternative to entering their password. The project was such a hit that we know embed one of these “magic” login links into every email and SMS notification we send so that nobody has to be worried about logging in.

It doesn’t matter if you’re working independently or on a team, you’ll always be involved from beginning to end.

We recognize that everyone wants autonomy, mastery, and purpose, and we make sure everyone gets all three.

The best way to describe what this looks like at Range is by letting Sean, one of our engineering/product/design generalists, share his experiences:

“I worked on a new weekly summary email feature, which surfaces interesting content that our users may have missed throughout the week. I was involved from the start, helping to identify, frame, and prioritize the problem based on existing customer research. From there, I designed the email content using an existing design system from Braden as a foundation, and I solicited feedback from the team. Next, I made a quick technical plan for assembling modular email content and then implemented the new email using Go and a templating system that my teammate Steph had set up. Finally, I tested the email by sending it to our own team, incorporated feedback, and then launched it to all of our users. Since shipping it, I’ve checked in on metrics to see how it’s performing. I’ve also made improvements based on customer feedback I received directly through Intercom and issues coming in through Sentry.”

Micromanagement doesn’t scale.

“Run through walls.” This is one of our company's core values and means no one should wait for someone else to handle a problem or remove a blocker, and everyone should have creative agency in doing what it takes to get the job done. We hire the best, and we lean on our people to shepherd experiences and projects end to end. Our engineering team is still small, which means everyone is familiar with the majority of our codebase and can jump in to fix almost any bug. If there’s an outage or our site goes down, someone always volunteers to spearhead the fix and lead the situation (or war) room as we call it, while someone else takes minutes.

Our engineering team holds hackathons and bug bashes, and more importantly, encourages one another to creatively try new technologies and build out ideas that they’re curious about! Matt Doan learned how to use AWS video transcription and built out a text dataset from all of our Cameo videos, which we’re now using in production! No matter who you are, it’s pretty cool knowing that Snoop Dogg and Gilbert Gottfried are using features you’ve built.

Everyone at Webflow is encouraged to embody a founder mentality of ownership.

At Webflow, we instill a culture of ownership in all of our team members. We encourage everyone to think about what’s best for the customer, our fellow employees, and the company in their day-to-day work.

Engineers work closely with Design and Product from ideation through release and are encouraged to participate in every phase of development. They steward and share in our customers’ success for the work they deliver. Any engineer at Webflow can also propose a change to the way we code or work via an internal Request For Comments (RFC) process. This process allows for healthy debates and collaborative decision making, stimulating a broad range of ideas, and allowing everyone to have a significant impact.

Individual teams have a lot of autonomy to optimize their working practices. Our Education Team – responsible for our Webflow University curriculum – owns the article and video creation process from pre-production through post-production and launch. While they do work closely with teams like Product & Marketing on occasion, they also have independent objectives and the autonomy to design incredible educational materials for web developers with their own voice.

Across the company, employees contribute ideas and feedback that help shape our product and processes. Our 10% time projects are often collaborations with coworkers from different departments and allow Webflowers to experiment with new concepts and technologies. Some of the best 10% ideas make it all the way to customers, such as our popular quick find and After Effects & Lottie features. We are highly collaborative and understand that all viewpoints are valuable. We have a strong distaste for knowledge silos and expect our team members to share in all directions.

One of the best things about working at an early stage company is being able to see your work through from idea to completion!

Since we’re a developer-facing product, team members balance Dark’s core vision, external developers’ needs, and their own perspective, often helping to define product requirements. We’ve had people take on everything from better architectural views, to adding user defined types and hosting static assets.

Developers come up with a technical design, get feedback, and build with regular check-ins (which could include pairing, intermediate reviews, etc.). Owning your work means making sure it’s ready to go, writing some supporting information, and sometimes showing a customer before shipping. We don’t have a formal “focus group” process yet, so developers might ask in our user support channel, or reach out to specific individuals that have asked for the feature before.

We try to move people around to different areas of the codebase, too. While we want everyone to have some familiarity across the codebase, everyone will also have their specialities.

We believe to have a fulfilling job as an engineer, you should be involved in a project from its earliest days, if not its conception, to the rollout and support amongst our users. We’ve adopted processes that encourage this at every step of the way:

1. Ideation and discovery: On the product team, you’ll work with the academic and business development teams to understand how software can support new curricular and pedagogical developments as well as secure and support partnerships. Everyone on the product team can submit proposals into our planning process, and is involved in the prioritization discussion at the beginning of each 15-week episode.
2. Full ownership over the implementation path: You’ll work on architecture, implementation, automated testing, code review, all the way through to shipping to production, which we do several times per week.
3. QA and operation: If it isn’t right, it isn’t complete — we own QA for our own features, and we’ll reach out for review or verification from our stakeholders when that’s helpful. We also run our deployment and monitoring infrastructure, and are responsible for whether our systems are working or not.

Students, faculty, and staff at a Minerva Schools year-end celebration.

We want our employees to be active owners of the business.

There is so much to do at EyeLevel.ai that we need every one of our team members to be an active owner. Whether this means taking ownership of our frontend, or some aspect of the backend, we want people to view their responsibilities as being more than just lines of code. We are hiring the future leaders of our company, individuals who will grow with the company as it scales, and we all recognize that the decisions we make today will have a deep impact on everyone that joins us later.

When you’re at a startup, there’s more things to do than there are people. We look for the type of person who solves problems on their own and brings others in when appropriate. Resourcefulness is key but you should also be comfortable asking for help.

Ownership is more than completing tickets.

At NerdWallet, ownership is about designing and implementing the right technology for the right problem and that requires engineers to be involved throughout the entire process. Engineers are typically aligned to a product or feature in order to help them build domain expertise around the issues that face their team and participate at all levels of product development. They watch user research videos to understand how our users think about the problems facing them, and work on requirements with PMs and designers to make sure that we’re solving the most important problems first.

Engineers also sit in on design reviews to give feedback to designers and understand how they have approached the problem, and review metrics with PMs to understand how well the feature actually solves user problems. They advocate for new features during sprint planning and then start the whole process over again, because ownership means caring about the work you did and continually making it better.

Engineers own their work from ideation to release.

We have a bold vision; transforming that vision into reality will require significant innovation and invention to solve problems along the way. To this end, we welcome ideas from everyone. Our engineers partner with our product managers to understand the “what,” and then spin off to figure out the “how.”

Engineers demonstrate ownership by thinking through and leading the design, implementation, testing, deployment and operation of their solutions. With this responsibility, an engineer gets autonomy to martial people and resources and to own critical decisions. For example, one of our devops engineers currently owns defining and implementing the chatops-driven, cloud-based development environment, including all measures of success and documentation.

Once work is released, developers are also accountable for the quality of their work. While we do have test engineers, they are accountable for the automation framework such that a developer can actually own the feature they are producing (and also receive immediate feedback). Long-term maintenance of a project is handled by our SREs (once the SRE team formally accepts the feature of course), and feature developers can focus on building new features.

Engineers are in charge of deploying the right solution for the right problem – from the start.

Ownership at Wealthfront is about prioritizing, designing, and deploying the right solution for a given problem. This requires engineers to be involved from start to finish. As one of our data engineers, Megan Dare says, “Unlike at previous jobs, at Wealthfront I am able to own my projects from the design phase all the way to deployment in production.” What’s more, this starts with prioritization – you can’t do everything and there will always be other factors to consider like business goals, code maintenance, and requests from other teams, so engineers constantly have to prioritize their tasks. “At Wealthfront, I have the opportunity to be much more involved in the process of evaluating trade-offs of working on one task or project versus another, and I’ve learned a lot about the importance of being able to prioritize effectively,” adds Megan.

As a smaller ~15-person team, we place an extremely large amount of trust in one another and empower everyone to be relatively autonomous in their work.

That means a majority of features and bug fixes have a single person as the primary point of contact, from ideation and architecture to implementation and documentation. Documenting and educating one another about our work is the primary way in which we reduce our SPOF surfaces across our codebase. For example, in our earliest days of developing the Hatch Card, our lead designer, Michelle, went above and beyond her role as a designer and took it on themselves to manage the product development process from concept to launch.

Similarly, our engineers take on multiple roles (i.e. infrastructure, data, and front-end) as truly full-stack engineers when the need arises, then specialize as the team grows. At Hatch, we believe tough challenges are never “someone else’s problem” and empower our team members to take ownership whenever they can.

Engineers are part of the product ideation, implementation, QA, and final rollout.

At Handshake, engineers touch all parts of the process. It's a highly collaborative environment, and engineers work closely with product and design. This ensures that the final product we're building is both feasible for engineering and aligned with our overall product vision.

Technical skill is not the only factor that determines who our best engineers are. They are the ones that demonstrate complete ownership of the product and their feature areas by going beyond simply building what they're told.

Engineers are expected to question product and design decisions while providing possible solutions to "Focus on Impact" and "Move Quickly But Don't Rush." There is strong collaboration among the three different disciplines (Design, Product, and Engineering).

Some of our most impactful features have been thought up by engineers. Job role exploration pages, integrations with applicant tracking systems, and a new UI for job searches are some examples of things that engineers brought to life in hackathons and worked with product and design to polish and release.

You are allowed to do what you think it's right for the product you are building.

You are responsible for what you are doing, and you have the doors open to involve yourself in any area that permeates a product since this will bring you a wider vision of people that will be affected by your work.

We know that people have strength to do this, but we also know sometimes they have bad managers and this might be a huge barrier for motivation, so we not only encourage people to speak up to any problem, we make it everyone's duty to do so. If you don’t like what you see you should raise the flag and talk about it to any person in the company.

Our “squads” are committed and accountable for end-to-end roadmapping and feature delivery.

Engineering teams are solely focused and accountable for the end-to-end roadmapping and feature delivery in a dedicated functional scope. Teams are split into “squads” made up of a Product Manager, Engineering Lead, 3-6 Engineers, and a Designer. All squad members have a voice in ideation, design, and QA. Teams are committed to and accountable for both product delivery and parts of the Engineering architecture.

Everyone is expected to be the CEO of their projects.

CoinTracker employees take end-to-end ownership on tasks big and small.

In Alexey's second week at CoinTracker, he started tackling scaling. Our performance was terrible at the time and page load times for “whale” accounts (>10K transactions) were ~15 seconds. Within two weeks he implemented summary tables supported by triggers, database replication, in-memory caching, and more performant cost basis algorithms. His work resulted in a 10X improvement in performance (1.5 seconds load time) and allowed us to support even larger accounts (>250K transactions)! Alexey took complete ownership of the objective, including adding the necessary instrumentation to fully understand root causes, defining a prioritized list of issues, implementing changes, shipping them, reconciling metrics, and talking to users.

Engineers at CareGuide are the focal point for getting new features to our users.

Our squad model organizes our engineering team into groups who are focussed on a specific area of our product. It provides space for ideation, execution, and follow-up. This means you’ll work with key stakeholders in a cross-functional team to spec out, develop, and deploy features across a continuum in a user’s journey. It’s common to collaborate with customer success, marketing, and design teams, while leading the way with your good judgement. For example, our growth engineer Nick shipped a major refactor of our user sign-up flow, from ideation to production, working with design and product. Now he’s tweaking the flow given the analytics he’s collected to reduce bounce rates.

See what you build in the hands of our customers, and get user feedback immediately.

We have a tight feedback loop between makers and end users. What you design, code, and/or build is yours from beginning to end. Our customers are warehouse operators who can’t easily pop on or off updates or new models we deploy. They have to wait for a maintenance window, which means we may only have 30 minutes to drop in an update and make the decision whether to roll back or not. From early design stages to being on-call for production code, we are responsible for the success of our work through and through.

Our sense of ownership is amplified because of how closely we monitor the performance of our deployed systems. We know our solutions are responsible for time sensitive shipments, and downtime is not acceptable. We live stream analytics to track regressions and proactively identify problems before they can cause downtime. To catch unexpected issues, we keep an open dialogue with our customers who can surface questions and alert us when the unforeseen arises. By having tight feedback loops, we never lose sight of who we’re building for and get the deep satisfaction of seeing our work being used by real people in the wild.

You might even end up trying something you never envisioned. For example, Josh Mouledoux, a Mechanical Engineer, became our resident camera expert. As lead software engineer Andrew Vaziri can attest, “When I first joined Covariant, I set up the project management suite, which didn’t exist before. Now, I also run the patent process and help people communicate with lawyers. It’s something I never formally imagined when I was interviewing.” If you’re passionate about something, there’s room for you to put on another hat and try it.

We aren’t hiring managers. We want individual contributors.

You should expect to have freedom in every direction when you join us. If you have ambitions to found a company of your own someday, working at Precious as one of the first employees is a great stepping stone. You should want to ship fast (think days and maybe weeks, never months) and be eager for results. Like a founder, you’ll also need to have breadth. You can be an expert in one or two domains, but you also need to be excited and interested in broadening your skill set. For example, an iOS tech specialist with a growth mindset and interest in dabbling in computer vision. (By the way, if that describes you, you should absolutely reach out to us!)