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.

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.

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!

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)

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 emphasize ownership even beyond engineering. One team member was in charge of our Blockstack Summit in summer 2017. He took full responsibility to make it happen, and took 3 months to complete. The rest of the team saw what he had built when they showed up to the event.

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!

You’ll own you work from the initial project scoping all the way to marketing your final product.

At the onset of a project, you’ll work with product managers and customer success to conduct customer interviews. As an engineer, you too need to understand what the customer needs are. You’ll then work closely with design to figure out the best UI. Implementation and execution are fully yours to own and once you’re delivered your project, you’ll work with sales, marketing, and customer success to get your product out into the world. Project ownership doesn’t just mean owning the work that was given to you at DataFox. Full ownership to us means seeing a product through from the earliest stages of inception to supporting our customers that use it.

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.

You own a project but aren’t on an island.

The development and code review process allows for multiple eyes on code and multiple minds thinking about the optimal solution. You set the deadlines, you set the pace, you make decisions and own the outcome.

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 (Tony Mai) designed, implemented, and deployed. Or take a look at Ad Intelligence below, which Dmitry Filimonov and Gavin Dinubilo built 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 know 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 NBC) to 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.

Everyone at Armory is empowered to make decisions and help guide the culture of the company.

We would rather you ask for forgiveness than permission. Part of having a culture that is built on trust means that you know your co-workers well and can trust their decisions. This enables people to own projects, and helps us to move quickly as a company.

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.

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.

We have a culture of autonomy and transparency.

People are not micromanaged here at Rainforest. If people sign up for a project or are assigned a project, it’s really their project. They identify themselves as the leader. While there are expectations, deadlines, and check-ins with managers, the main responsibility your manager has is to remove roadblocks for you.

We have four engineering teams: backend, frontend, data science, and professional services team, with ~5 people on each team.

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. Carlos single-handedly made it possible for users to indicate when they had committed to a college program. Previously, student athletes would have to email us when they committed, and we would manually update our database. Carlos worked with our designer to make a view for how this should look, implemented autocomplete search, included college logos, and adapted the feature to our newest way of writing code using an Ember.js app and a Laravel API endpoint.

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

Our micro-service approach to architecting systems provides end-to-end ownership to individual teams and engineers.

Not too long ago, we had a monolithic Django stack which meant that everyone worked on a single codebase. Everything was so intermeshed and it didn’t scale very well. Since then, we’ve taken the logical pieces and built them into their own self-sufficient systems. This network of different systems talking to one another has given engineering teams (or in some cases, individual engineers) a lot of control over a single system which they can own from end to end.

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.

Taking full ownership of projects is encouraged and even expected from our team members.

We don’t believe in micromanaging. Instead, we believe that the most efficient way to work together is to allow individuals to have independent control over the projects that they are responsible for. This way, our team members are allowed to grow faster professionally and also develop product-area expertise. You’ll never be handed a problem with instructions on how to solve it, and if you do need this type of management, you probably won’t enjoy working at Kite. Instead, we like to be open-ended in the problems we give.

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 everyone in every department at Rover to take ownership of their work and push the boundaries of their skills.

One way that we empower everyone to do this is through data literacy. When a program manager has to wait on an analyst to fetch data for them, it disempowers both the manager and the analyst. Neither party has autonomy over both the data and the decisions it’s driving and overall speed of decision-making is hindered. It’s a no-win situation. This is why we’ve created an environment where everyone has the tools and skills they need to explore the questions on their mind, and can immediately deep dive.

One of our Data Engineering team’s main priorities is propagating this culture that’s steeped in data literacy. We’ve been training up more people with a basic analytics skill set (including knowledge of basic data and statistical methods, writing SQL queries, and using spreadsheets and reporting tools to make pivot tables and charts). You can read more about how Rover does Big Data to empower individuals at the company so that they can own projects end to end.

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.

Part of maturing as an engineer is learning how to be successful when there is more ambiguity.

As an engineer at Good Eggs, you’ll never work alone and always work on a small team. Project identification is a process that is led by your team lead or product manager and includes the input of the entire team. At that point, you’ll be expected to own your work end-to-end. Taking ownership is not simply doing a job or working on a project. It means making it your mission to see it through.

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

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.

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. From a product perspective, 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. From an engineering perspective, this means there is less legacy code to deal with and more freedom to build with the latest and greatest tech.

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

Developers at Braze own the product lifecycle end-to-end.

We collaborate with product, success, and design during the design, implementation, and go-to-market phases of projects. Engineers are encouraged to work across boundaries and find places to have impact. Many aspects of our product have been brought from idea to execution and release by engineers. As our product continues to advance it’s intelligence and scale it’s increasingly critical that engineers are key stakeholders at the ideation stage of our product.

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.

Engineers own features from the first line of code to deployment.

We encourage and support our team to be involved with every feature starting from the first idea. We often work in pairs with one person working on the backend API, and the other implementing the react components or new swift code for our iPad point of sale. During the process, we work closely together to support each other's needs and make changes. For example, we just deployed multi-location real-time inventory tracking. While developing all the frontend capabilities, multiple problems were solved by having an open communication dialogue and modifying the API portion to better support the clients.