As engineers, we partner closely with business stakeholders with the features and projects we work on.

The same engineers who work with Product to refine our product roadmap also work on the technical design (sometimes with guidance), and own implementation through shipping to production and maintaining it afterwards. We also have company-wide panels with both our guest and host populations so that we can understand them better.

When we asked everyone to describe their favorite project, nearly everyone had an answer. Individual engineers have revamped Peerspace’s Admin tools, rewritten and restyled our Manage Listings page, and upgraded our payout platform for our host community. We are still a small team and everyone has outsized impact on not only our product, but also the business.

Through trusting each person on our team to drive and own their work, we’ve been able to accomplish so much. We expanded to 9 major markets in the United States, raised a $16M Series B, established business in many more cities, and have so much in store. We’re proud to have been able to do all of this with a small dev team (>20 engineers), and look forward to bringing on new hires who will continue to push our business forward!

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.

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.

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.

Extreme ownership is very important at Blockstack.

Reliability is one of the most important qualities we look for. The work our engineers are assigned or take on gets done, on time, without exception, and quality is never compromised. We are a small and flat organization, so everyone has an opportunity to share their thoughts with the team and contribute to the direction of the company. At Blockstack, ownership is focused on project inception and follow-through. Engineers are in charge of their feature or upgrade and work both independently and collaboratively to make sure the appropriate work happens with high quality results.

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!

Say “I’ll take care of that” instead of “that’s not my problem.”

We’re outcome oriented and value Engineers who will own outcomes, not technologies, processes, or software. People who own outcomes will fight to find the value in the software they produce and are liable to cross-functionally collaborate outside of their typical remit to get things done. If it’s related to an outcome an Engineer is owning, you’ll almost never hear an Intercom Engineer say "that’s not my problem."

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)

You build it. You own it. We champion it.

With over 1800 employees, Meraki has countless examples of how individuals are encouraged and supported in owning projects every step of the way - from ideation to implementation.

Our software engineers often start with a use case and use it as an opportunity to build a solution. An example of this is seen in the development of the Motion Search software for our Meraki MV Smart Cameras. The use case, in this instance, was a customer needing to pinpoint the exact moment of an incident within hours and hours of video footage, with minimal information.

After reviewing the few known details - a bike gone missing, between the hours of 8pm and 9am - a group on the Meraki engineering team got together to brainstorm a variety of possible solutions. Eventually, one of the engineers built a solution - a customer simply has to draw a box in the camera view around a region of interest, and in a fraction of a second they get back a list of timestamps when motion was detected within that part of the frame.

In order to produce this advanced and impressive solution, the engineer had to understand the entire video pipeline that needed to be built, in parallel and real time, with an index of where motion occurs in each frame. The engineer was then able to build the backend components to retrieve, store, and query that index, along with a simple, intuitive interface. This solution, built by a single engineer, not only impressed customers but has since evolved to an even more intelligent version of itself.

Ultimately, we want to enable and empower all employees to run with their ideas, by giving them the tools, resources, support, and buy-in to bring their vision to life. Engineers are trusted and given the freedom to produce and own impactful work across mobile, back end, front end, testing, deployment, and monitoring.

Cross team collaboration in action. Engineers playing team trivia at a department offsite of Ojai, California.

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!

We like to work with folks who are excited about making and carrying out their decisions, whether in the code they write or the partnerships they strike.

Someday, Vanta will need strict departments and handoff points between owners/teams. We don’t have – and don’t want – those things today.

To date, our product helps companies to check their security settings, but we will eventually build out the ability for Vanta to also prevent vulnerabilities. For example, in addition to checking the settings on your laptop and alerting you – do you know if everyone at your company has encrypted their laptop’s hard drive? – we also want to make it easy for you to fix or change settings. Security related to email, laptop, VPNs, and SSH keys may seem like standalone products, but they’re really part of the security-in-a-box solution that we are building for technology companies so that they can focus on their products. As a result, there is a tremendous amount of room for engineers to fully own projects.

From initial client interviews to the first production bug, you’ll be there!

We start each project with investigation and asking lots of questions. Understanding what the customer needs is key and as a coder, you’ll need to know it! Helping the design team integrate well with the back-end is another phase in this process. Making sure that there’s a good onboarding process for internal staff as well as consumers is a big part of launching a feature that you’ll need to master. Monitoring the feature and ensuring alerts and logging is set up is crucial to its longevity.

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

Right now, we are a small team of 3 engineers. Troy, our CTO, sets long-term milestones and then we work together as a team to decide how that translates into discrete projects. We don’t have product managers and hope to continue bringing on product-minded engineers that will be able to work closely with other departments to handle feature requests, thoughtfully prioritize, and build the product.

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.

Whether you’re an individual contributor or working on a team of 3, 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. Here is an example of what one of our engineers (Rahul Murmuria) designed, implemented, and deployed. 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.)

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.

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!)

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 necessary 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. 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. Please take a look and let us know what you think!

Everyone on our team thinks of Branch as their company.

We’re not building this alone, and the only way we’ll succeed in our mission is if we all maintain a sense of ownership over everything we do. Micro-management doesn’t exist at Branch - everyone is empowered to make things happen.

Your job is not your job.

While it is important to be effective as an engineer, we expect everyone at BetterUp to think deeply about the problems being solved beyond just implementation. Your job is doing what it takes for BetterUp to achieve its mission.

Our product development process is highly collaborative and we expect engineers to make suggestions that improve features and the design. This also means making suggestions that will allow us to more effectively use our time. For example, if you see an opportunity for a design adjustment that will allow for more rapid development, it is your responsibility to bring this to the team's attention and iterate with design. You are being an owner, because you recognize spending your time less effectively reduces the velocity at which we can deliver value to customers, which puts our mission at risk.

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.

Caviar operates like a startup inside a larger company—Square.

This means people can have an outsized impact on the product, sometimes entirely owning new features. A perfect example of this: one of the engineers on the team, Nick, led the release of “Cash Instant Payouts to Couriers” with the support of other engineers—leading to the work being featured on The Verge!

Larger projects at Caviar are generally owned from design through execution with checkpoints for support and feedback. Engineers are organized into full-stack teams focused on different audiences (e.g. diners, restaurants, couriers), with each team having dedicated product managers and designers.

Of course, ownership isn’t limited to the code you write. Regardless of your role, you’ll still have a lot of ownership of various projects and roadmaps, and will have opportunities to be responsible for seeing initiatives through from beginning to end. We enthusiastically support both individual contributor and manager tracks at Caviar.

As a small and growing company, engineers have great flexibility to choose what they work on and are given the space to see them through completion.

When we asked our engineers about the autonomy at Plastiq, Marie Cuddy recalled how she was able to build a marketing application that can email hundreds of thousands of customers within minutes and decides which customers receive which campaign based on live data, all from scratch. This is just one of many examples of the type of end-to-end ownership engineers have at Plastiq.

There is a tremendous amount of variety in the projects and responsibilities we have, and it is common for engineers to change roles and focuses every few months. We believe this enables people to have both depth and breadth as they learn new technologies and build new parts to our system. Engineers often suggest projects that they believe will move the company forward and more often than not, they’re given the opportunity to own them to completion. The leadership at Plastiq is extremely open to team members taking on new tasks, and trusting them to learn as they go if they aren't subject matter experts in those new areas.

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.

Engineers do everything.

We don’t have a DevOps or QA team yet, nor do we plan to for quite some time. In fact, we don’t even have a Product or Design team. We outsource and automate a lot, but beyond that we expect engineers to be willing and able to take a feature from idea all the way through to deployment, documentation, and customer support. Engineers are almost always involved in the Design process, too. At a minimum they participate in design reviews and are asked to provide feedback. All of our tickets are created by engineers.

Given how team-oriented we are, there’s no such thing as “your project.” Start-to-finish ownership means, above all, that people are responsible for getting their work done. If you need someone to review code so that it can be merged, you’re responsible for finding a reviewer. If you are blocked by someone else, you are responsible for following up with them to get them unblocked.

While everyone is responsible for the maintenance of the code they ship, we consider it a failure if someone ships a feature that no one else can maintain. The expectation is that everyone is responsible. We have users in our Discord channel at all hours of the night, so whoever is online will jump in to help when issues arise.

We trust you to do great work but hold you accountable to that standard.

We hire people that we trust to have the technical skills and judgement to get the job done. In turn, that means we give you full project ownership. If you’re the person closest to the problem, you’re the best person to make the right call and shouldn’t have to ask for permission.

Recently, one of our engineers noticed that our internal admin tools were outdated and could use a UX and design facelift. He took it upon himself to create a fantastic new dashboard that would make the lives of our operations team easier. Once he showed the product team a revamped interface, the company got behind the effort and asked him to lead a project with a designer, another engineer, and a product manager to take the new admin dashboard to the finish line. The new dashboard is a critical (and beautiful) operations tool that our operations team uses day-to-day to meet our growth and revenue goals.

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

Micromanagement doesn’t scale.

“Run through walls.” This is one of our company’s core values and means we aren't afraid to fail or do whatever 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! Similarly, Matt Rastovac, single-handedly rebuilt our entire backend (data ETL pipelines) using AirFlow when he was an intern. (He has since joined us full-time!) No matter who you are, it’s pretty cool knowing that Snoop Dogg and Gilbert Gottfried are using features you’ve built.

If you do a job more than 3 times, automate it.

We are a small team who owns a large global product. We all share responsibility for the site’s uptime, and we don’t point fingers. We favor a rigorous test suite over a QA team. We favor self-healing infrastructure over an operations team. We are happy to choose (and pay for) the right tool for the job to be as successful as we can be. If you find yourself repeating the same job, we encourage you to automate it.

We make space for technical tasks in our backlog, and we never let our dependencies get more than a few months out of date. The engineering team always has the responsibility to add technical stories to improve their own efficiency and happiness.

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

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.

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.

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 nginx server configs. Once your work is deployed though, the entire team is then responsible for maintaining it.

A few examples of how much ownership each team member has:

• Sean built out our enterprise product. He met with sales, completed calls with clients, gathered requirements, designed the UI, and coded everything. He’s also never afraid to take on the big challenges in some of the older parts of our codebase: single handedly rewriting our whole routing layer in ~3 weeks.
• Kanad revamped the key functionality on the user-facing part of our developer sites. He made suggested edits iterative and more like GitHub pull requests. He owned all of the development, wrote the database migration, deployed and ran the migration, and was there to firefight when an issue occurred.
• Marc redesigned our homepage. He met with designers, discussed feedback with them, built the whole frontend, and refactored it so our homepage code is deployed separately from our app code. He was also responsible for creating the Heroku servers, updating DNS records, and switching to a Cloudflare backend.
• Dom rewrote the first version of our new API Explorer (which is open source). He took it from an untested garble of spaghetti code to an open source React component. It took a little over a year from start to finish: refactoring, removing cruft and turning on for some customers via feature flags until the major issues were ironed out. It is now much faster, easier to work on and supports much more complex Swagger/OAS files.

An Alto Engineer built our entire patient dashboard from scratch in 3 months.

Another Engineer built our prior authorization system that touches all facets of our platform from our admin tools system, the patient dashboard, the app, to the provider dashboard. These are examples of the depth and breadth of projects that our engineers take on, and what you can expect for yourselves when you join. In terms of ideation, we project plan as an entire engineering team so everyone has a say on what they work on. Additionally, engineers are expected to spend time doing research and shadowing during the initial phases of their projects in order to help set project goals, influence design, and plan the project timeline. We have a clear mission at hand, with defined short and long-term goals. If you are looking for an opportunity to own a significant project that you can call yours, now is the right time to join our team.

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

We try to have everyone in every function ask themselves the question, “What is best for Webflow?” while keeping in mind our three stakeholders: (1) customers, (2) employees, and (3) company. Our engineers work closely with design and product at the beginning of each project and continue to get support and help along the way. We also assign an engineering manager to every engineer so that everyone has the support they need to do their best work. Your code will always be reviewed by peers and you’ll always have opportunities to participate in other code reviews.

Pick a feature, build it, and ship it.

There's a reason we call our developers “product engineers.” Engineering is core to all decisions from product prioritization to feature design. We believe that when you work on what excites you, you also bring your best work. Engineers at Hipcamp are involved at the very beginning of the process helping define what we build and how we build it. We create goals collaboratively, and engineers work with the rest of the company to take projects from ideation to production.

As a startup, there is so much that we're building that's fresh territory. This means designs are not restricted to solving challenges and points of friction but are instead creative and free to offer new opportunities for campers and hosts.

We want owners, we want people who act as if it was their company, people who realize that, actually, it is their company.

As mentioned before, our engineering team is organized into smaller squads of 3-4 people. This gives everyone the ability to sit at the table and own their product. As one person on a small team, your opinion and ideas drive the direction of your product and you give you responsibility over a significant portion while also having the support of a few others who are equally invested in the success of your work. “We want owners, we want people who act as if it was their company, people who realize that, actually, it is their company.”

Developers work on projects from start-to-finish, and they can also see how the company operates end-to-end.

As a developer, you’ll be encouraged to join in early with project ideation and defining requirements. You’ll then work with stakeholders throughout development, and continue supporting your code after it’s released into production. Additionally, the developers at G Adventures also work closely with the Learning team in producing documentation and training modules for our products.

We also believe in company ownership, not just project ownership. Developers are encouraged to shadow others in the organization, even if that area doesn’t fall under your purview. This allows us to become familiar with other parts of the organization and understand how the company works as a whole. Yes, you own the code you merge, but you should also view yourself as an owner of the company.

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.

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.

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.

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.

Everyone who joins has such a tremendous impact to the company, and brings something that doesn’t exist yet here.

This is a startup. If you need a super structured world, this isn’t the right place for you. The people we have attracted understand the impact of our product and have ideas about how to push it further. At Nylas, we ask for forgiveness, not for permission.

If you have a question about design or marketing, you should speak directly to a designer or someone on the marketing team. We’re not a huge company, which means you will have full ownership of your project. While we avoid 1-person projects as much as possible, project teams can have as few as two engineers, giving each person a tremendous amount of freedom and responsibility. Everyone touches all parts of the codebase. Everyone is a full-stack engineer.

Additionally, all Nylas engineers participate in a customer focused rotation where we work exclusively on the most critical customer facing issues. This allows each engineer to work directly on what customers have highlighted as their biggest issues. These may include really complex ActiveSync authentication situations, Unicode parsing issues, data duplication, and more. Each engineer spends two weeks of their choosing every two months to empathize with our customers.

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.

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!)