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.

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 place a high degree of trust in our team members.

As a small startup, everyone at Grouparoo is involved in the entire life-cycle of a feature – from ideation and prioritization, through development, release, monitoring, and bug-fixing. You’ll have the latitude to choose the best tools and frameworks for the job and not be locked into legacy tools or decisions.

We are a team of generalists switching from topic to topic and are looking for engineers who are excited to explore the whole stack (frontend, backend, devops, etc.) rather than experts who specialize in just one part. This way, everyone can own the whole feature, not just the UI or API layer. We place a greater value on holistic knowledge of the architecture and the ability to learn rather than existing expertise in any single part of the stack.

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.

If you want to write the playbook, good – we want you to!

As a small team, every engineer has a lot of opportunity to run with an idea and see it out to fruition. As one example, Sebastian built our payroll calculator, which helps estimate the appropriate cost by state that employers need to match. He’s also responsible for maintaining this calculator, updating it every time a state rolls out a new guideline or regulation impacting paid leave. Engineers can steer projects that aren’t engineering-specific, too. Before becoming a software engineer, Priya studied law. When she noticed how much time we were spending updating employers’ leave policies, she decided to work with compliance to develop a template and start automating that process. With Priya’s help, we can now provide a company that employs people in Washington, New York, and California with a policy that is compliant in all of the relevant states. This is a crucial tool for companies as more and more employers transition to remote work.

At the end of the day, engineers have a large say in the product development process. Things typically start with our Sales or Customer Operations teams because they’re interfacing directly with our customers all day every day, but issues are then shared with engineers. We then get to ideate around fixes or new features to address those issues. Engineers will write a spec, which will go to Deborah (CEO), and then based on the time estimate and priority level, it will be prioritized into the product roadmap accordingly. We’re looking for people who are leaders in their field and can really write the playbook from start to finish, while still making sure to include others and ask for feedback.

Engineers are involved in the entire product development process from ideation to design, launch, and beyond.

We believe in a close relationship between product and engineering. Within our larger engineering team, we are organized into smaller product/engineering teams that are comprised of a product manager along with a number of engineers (and sometimes a UI/UX designer as needed). These smaller teams mean that engineers and product work very closely with each other throughout the whole product development lifecycle. Engineers are involved in the process from the point of ideation through product design, technical design, scoping, phasing, and launch.

We don’t have a separate QA team – engineers and product managers work together to build a testing and rollout plan for each launch. That plan often includes a combination of unit and integration testing along with phased launches, feature flags, and proactive alerting to reduce risk during deployment and give us easy ways to roll back if necessary.

Following a launch, features and products continue to be owned by the same team. The team is responsible for monitoring the health of that product, establishing and tracking relevant success metrics, and rolling out fixes and improvements over time.

When we sat down as a team to brainstorm our key values, nearly all engineers highlighted Start-to-Finish Ownership.

At Curai, engineers hit the ground running starting on day one, and are involved in everything from brainstorming a feature, to maintaining it once it’s been shipped. Most of our engineers enjoy working across the stack and diving into all the details necessary to spec, code, test, QA, and ship a new feature for our patients or doctors.

On the first day at Curai, every new team member is assigned a mentor and a starter task to get familiar with the developer workflow and our code base. After that, their first project begins! Dan Stone joined our team this year, and his first big project was integrating automated ID verification into our user sign-up flow. Over the course of his first quarter, he gathered requirements and presented his tech spec at our weekly design review meeting. Dan brought with him a lot of frontend experience from his prior role at Amazon, but React Native was relatively new to him, so he collaborated with teammates while he coded to learn the quirks of mobile development in React Native. After the new feature launched Dan said, “I felt more excited about this than any feature I launched at Amazon.”

For new engineers on the team, owning a feature end-to-end is a quintessential part of their first quarter on the team. Curai engineers enjoy diving into the details all the way from feature ideation to following feature success metrics and fine-tuning their features for long-term success. Engineers are also encouraged to grab and own focus areas within the codebase as they learn and grow.

Our engineers don’t just write code – they’re key players in our strategy.

Qualia engineers are involved throughout the entire product life cycle, from conception to architecture and implementation. Developers at Qualia are empowered as builders and creative thinkers and play key roles in the development of our products. Engineers have the opportunity to explore new potential product or feature solutions for customer pain points, and we’ve had a few releases start as hackathon projects based on customer requests. Our engineers have developed a flexible infrastructure for real estate that not only brings the industry together as a digitally-connected ecosystem, but also enables businesses of all shapes and sizes – from household brand names such as Realtor.com and Redfin to newly-funded proptech companies – to modernize and provide better, more efficient service.

Our engineers feel ownership over the products they’re working on, and have the agency to make key product decisions alongside our product team.

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.

Engineers are in touch with what they’re building at all stages of the pipeline.

At Honor, engineers are involved with the technical design of how their products are going to be built very early on in the process. This means collaborating closely with designers providing input and starting to research different technical paths forward. We value writing out our plan and communicating it with the rest of the team before executing, so we can get broader feedback and ideas. Engineers are empowered to build features, test them, ensure the rollout goes smoothly, and monitor that they continue to work for our users. By learning from others along the way – including senior team members – we’re able to build the best product possible.

Honor is also unique in that we have instantaneous feedback loops with our users on a majority of our products. Much of the product we build is for Honor employees, whether it's the web app for our care operations team or mobile apps for our Care Professionals, who are continuously communicating with us about the tools we’ve built. This helps us avoid product churn and design a roadmap with confidence that we’re prioritizing the top product opportunities.

Every engineer is expected to own the full lifecycle of their product: to ask users questions, 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. In order to succeed, she regularly talks to stakeholders across departments, triages their needs and opportunities, and designs a program for data-informed decision-making throughout the company. She ensures each of her stakeholders gets the data they need in a format they can use. She continuously incorporates feedback, fixes what's broken, and plans 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.

As a fully distributed team with no offices and no managers looking over your shoulder, we trust (and expect) you to work autonomously.

We lean into asynchronous working tools (e.g. Linear, Slack, Notion, GitHub, Figma, etc.) to get our work done, and our company policy is to schedule all meetings within the 9am to 12pm PT time frame whenever possible to give everyone at least half of their day to have uninterrupted work time. All of this helps to create enough time and mental space to hit flow states.

When we bring on new hires, we trust your expertise and want to give you the space to run with big projects and see things through from start to finish. For example, when Eivind joined our team, he had a background from Kraken and spotted some issues with our Kraken integrations. He worked relentlessly – above and beyond the scope of his role – to ensure that every single integration bug with Kraken was resolved. Pavlo offers another great example of taking charge and seeing an initiative through. A few years ago we received an email from him – he was passionate about our product, but noticed we hadn’t built an integration with a particular cryptocurrency exchange (CEX.io) and was excited to code it for us voluntarily. We then asked him to do five more integrations on a consulting basis. He’s now a core senior full-stack engineer on the team.

As long as you’re aligned with our mission and values, we’re excited to give you the space to be creative and take on projects you’re passionate about.

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 users' 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 empower engineers to take full control of their work end-to-end. We trust you to build what is necessary and support you throughout the way.

When we first launched Brex Cash, every single check that a customer uploaded took our Ops Teams four minutes to review. Multiplied by Brex’s scale, this wasn’t sustainable...

David Medina, an engineer on our Cash Team (and now a senior software engineer), took the lead on creating an automated way to process checks. He first shadowed our Ops Teams to understand their current workflow, then investigated multiple potential OCR technologies, prototyping them with a simple Python script to test accuracy. Once he chose one, he led a small team to build a production-ready, scalable automated checks processing system. The result? Check processing time was reduced by 88%. There are countless examples of this type of start-to-finish ownership at Brex. Everyone has the opportunity to really own and have an impact on the work they are doing.

Ownership extends to the team-level, too. We embrace the DevOps philosophy within engineering: each team fully owns their service, from bootstrapping to maintaining and operating. Teams are responsible for ensuring their services perform at the level expected by our customers, and have on-call rotations to address potential incidents.

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 look for folks who have the confidence to try, fail, and learn on their own.

People who thrive at Leapfin are self-directed and able to learn on their own. This “ownership mindset” is one of our core principles, meaning we’re always acting on behalf of the entire company, not just our teams or ourselves. Engineers are involved in everything from ideation, to messaging for the sales/marketing team, and long-term maintenance. For example, Miroojin (one of our full-stack engineers) has been focused on building features for and improving different parts of our financial data platform. He writes technical specifications for product features, designs systems to automate manual work and decrease operational overhead, and makes improvements to the platform's infrastructure and architecture. In order to be successful, Miroojin regularly dialogues with the product team to better understand customer needs and then uses that insight to make the product even better. He actively works to understand any pain points the team is facing and ideates around new ways to streamline internal processes. One of his biggest accomplishments was helping design and build a scalable data platform that can handle large volumes of data.

We’ll toss you into the deep end and give you the autonomy to try, fail, and learn for yourself. If that doesn’t excite you and you’re looking for more structured mentorship, this might not be the best fit. This isn’t to say that we don’t want junior engineers (we do!), but we’re looking for folks who have a problem-solving mindset and don’t rely on a manager to give them the greenlight. This is true for everyone, since there is no real hierarchy here.

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.

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.

Not only do engineers drive our internship program (see above!), but so much of Seesaw’s product comes from individual engineers, too.

Engineers at Seesaw have a tremendous amount of agency: we own features from ideation to launch and are involved at the top of the funnel of our product roadmap. Every week in our product check-ins with our Co-founder and CPO, Carl Sjogreen, we make product decisions with the entire team in the room. This gives everyone on the team full context and visibility to understand key choices as well as the opportunity to contribute their thoughts or opinions.

In 2020, our Product & Engineering team had its first hackathon and eight of the 15 projects are live in production today! In most cases, each project that launched was led by the hackathon project lead who worked with a product manager and designer to make it production-ready.

Hackathons are not the only way an engineer can be involved in the product roadmap; sometimes a simple lunch conversation will do. During lunch, Darren (IC3) and Jennie (IC2 at the time) pitched an idea to Carl to build a feature that allowed students to save their work as a draft and allow teachers to be able to send back student work for editing purposes. Carl loved the idea and encouraged us to prototype it. Three months later, the feature was launched and is currently one of our most used features by teachers!

COVID-19 really challenged us to become a do-it-all education tool overnight and we’re proud of how quickly our team rose to the occasion. Now more than ever, remote learning solutions are essential. With the coronavirus pandemic, we now have 15% of all K-5 teachers in the U.S. active on Seesaw daily, and many other teachers using Seesaw around the world. If any of the above excites you, we hope you’ll get in touch soon!

Own the impact from day 1.

Our first core team principle, we expect every team member to “own the impact” and give them the respect and freedom to do so. Ownership at 3Box Labs is not just about executing against a task or project; it’s about responsibility for making sure that work realizes its full potential impact. Engineers drive much of our product thinking and prioritization, and no part of a project lifecycle – from ideation to testing to marketing – is off-limits. We don’t have toes to step on.

We each are responsible for changing priorities, rethinking scope, involving others on the team or community, soliciting help, or whatever else is needed to realize the impact of our work. This relies on strong trust across the team, which is built on constant attention to quality and intentional communication.

We have one Directly Responsible Individual (DRI) for every project.

The most effective way to achieve our mission is allowing every team member to propose and contribute to initiatives. While this doesn’t mean anyone can execute anything of their choosing, it empowers people to influence strategy and direction across the organization, allowing any team member to push projects and objectives forward.

The underlying concept is that good things happen when individual people are directly responsible. This is why we don’t have an explicit Project Management team at DuckDuckGo. Instead, we have one Directly Responsible Individual (or DRI) for every objective, project, or task. We’ve documented DRI expectations for every role and built-in advisory roles at the personal, project, and objective level. Along with members of their Functional and Objective Teams, DRI’s have ongoing support from Career Advisors, Project Advisors, and others.

Every quarter we hold three (day-long) Hack Days, during which we work on anything we choose. If you can utilize data to craft a compelling case for a new product or feature, we'll implement it.

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 VP of Product) 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, built 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 senior software engineers) first 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 asking the PM to handle all project scoping, he took it upon himself to build a process that worked for him. He 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!

An entrepreneurial spirit is required to join the HumanFirst team.

We look for individuals who have an entrepreneurial spirit and not only feel comfortable with a wide breadth of responsibility and autonomy, but also need it. To empower each person on our team, we use asynchronous tools like Notion and Google Docs to ensure that you have the necessary context and support to run with your ideas/project, regardless of your time zone.

We are committed to a hypothesis-driven approach at HumanFirst. For instance:

• When faced with a problem, we ask everyone to state their hypotheses and assumptions explicitly. For example, “The story I am telling myself is that when our customer asks for X they really want Y, and so I think we should run the following test to see if that assumption is correct.” That person will then prototype a solution to test with the rest of the team.
• During your first week at HumanFirst, you’ll draft your ‘user guide,’ outlining how you best collaborate with teammates – check out our CEO’s ‘user guide.’

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. For instance, Eileen on the frontend team took on the rebuild of our timesheets: she met with several customers, shipped the initial scope, fixed the few bugs that came up over the ensuing months, and took it upon herself to add keyboard shortcuts and delightful wayfinding animations based on her customer interactions.

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 get projects from start to finish.

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.

We ask that you take a personal stake in the outcome of every project.

From the first spark of an idea all the way to completion, engineers are empowered to own projects. If you like to wear your product hat, your design hat, enjoy talking to users and getting involved in multiple different areas, you’ll fit in well here. For example Casey, one of our engineers, proposed the creation of a timeline feature to help our customers track the progress of their experiments. This ended up being one of our biggest and most impactful projects for the quarter, and he worked on it from idea through launch.

Our aim is to give you the autonomy to go forth and build great things within the context of company and team goals. But autonomy isn’t just coming up with the idea and putting something into production (aka the launch), you also have to own the final piece (the landing). This could involve writing training docs, talking to people, iterating, or even changing the type of thing you were building. What’s important is whether a user cares about what you built – even if they may complain about it, that’s a sign they care about it, then we can make it better.

Ultimately, after all of the tasks, story points, metrics, sprints, OKRs, KPIs, and things we use for process, we want to make sure what we’re building brings value to a customer or teammate and makes their lives better.

Whether it’s spearheading a feature or helping with hiring initiatives, you’ll own every project you take on.

We're a small company of mostly full-stack engineers. We review all major code changes through pull requests and are always pushing ourselves to do better. Since we iterate quickly and deploy to production several times a day, we have complete, end-to-end ownership for every project and expect the same from you. Here are a few of the exciting projects you might work on:

• Create fun open source projects and documentation in multiple languages and frameworks to demo Render's features.
• Enable Render's Kubernetes clusters to run on other clouds (they currently run on Google Cloud Platform and AWS) and eventually in our own data-centers. You will also allow our users to connect Render resources with their private networks in AWS/GCP.
• Create an effortless functions-as-a-service abstraction on Render and enable per-request billing for containerized resources.
• Build managed Object Storage, MySQL, and Redis for Render users.
• Contribute to hiring initiatives such as the development or new iterations of interview processes, conducting interviews (with training), or attending recruiting events.
• Attend conferences or partner meetings where you will present your work. Check out our engineer, Sean Doughty, demo at the RedwoodJS Meetup!

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

Engineers are responsible for breaking down complex ideas into achievable tasks and then rigorously executing.

We are currently a small 5-person company, which means everyone has a tremendous amount of ownership. As we grow, we want engineers to continue weighing in at every stage, from ideation to design. We get feedback from customers often and if we hear the same thing from multiple users in a short period of time, someone typically takes it on and runs with it. One to two weeks later, that feature will be live! Ownership will always be a core part of Doppler’s culture, with a deep affinity towards prioritizing features users deeply need.

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.

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

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

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.

We’re building something new.

As of now, we speak directly with customers to hear their pain points and it’s a collaboration internally to distill the product change. We don’t currently have a PM and it is very possible we won’t until well into 2021, which means every engineer who joins our team should not expect every component of the task to be defined by someone else. You won’t have to act as a PM, but you should be ready to act like a tech lead in your area, understanding the bigger context and how what you build will impact other systems, dependencies and customers. You’ll also be able to point to specific, high-impact things that did not exist until you helped create them.

A big part of making start to finish ownership run smoothly is documentation. On every call with a customer, we’ll get to know what their issues are and take notes, which we then share during all-hands. Tasks are created in JIRA so we have written documentation and engineers will be responsible for moving that task toward a given milestone and completion date. We’ll create a Notion doc and discuss on Slack or Zoom to set expectations clearly and share any roadblocks.

Ownership is a core part of an AngelList engineer’s DNA.

As a startup for startups, AngelList is a bit meta. Naturally, this attracts entrepreneurial engineers, who are interested in working outside the scope of traditional engineering roles. Folks who succeed at AngelList want to be full-stack and involved in more than just coding.

Engineers have the opportunity to drive business strategy and work closely with stakeholders in operations, sales, marketing, and legal. We don’t need to encourage engineers to own projects from start to finish because they actively embrace and seek out ways to do this themselves.

Projects are typically driven by a single engineer collaborating with a product manager and designer. Sometimes the engineer will PM the project themselves and other times they’ll design it themselves as well. It’s expected that this working team is able to drive projects from the inception of an idea all the way through execution and reflection.

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. We recently held a four-day Hackathon, where PD teams created working software, a product opportunity assessment, or a design document. The most recent event focused on ‘Creating More Engaging Relationships on Change.org.’ It led to several great projects including reimagining our petition page for accessible storytelling. We hope to continue this practice on a quarterly basis.

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.

Micromanagement doesn’t scale.

One of our company’s core values is to “Run Through Walls,” which means that we don’t wait for someone else to handle a problem or remove a blocker – we each take the initiative ourselves.

We hire the best, and we lean on our people to shepherd experiences and projects end to end. Our engineering team is still relatively 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.

It’s not done until it’s shared.

Engineers are involved in the entire process, from ideation and design to building and sharing products with the community. As we like to say, “it’s not done until it’s shared.” We’re inspired by the book Shape Up from Basecamp. Every six weeks we have a “shaping week” where we all look at customer feedback and roadmap strategy and decide what goes in the backlog for the next six weeks. We value product-minded engineers who enjoy the added challenge of thinking through the UX and the business case for each feature and work through questions such as How important is it? What’s the priority? Who needs it? Is there a faster/cheaper way to do the same thing?

One great example of start-to-finish ownership is the Merge feature. On the engineering side, Nicolas led the initial research stage to land on the current algorithm used, and sought help from Josh when he was stuck. When it came to feature/UX design, the team discussed Nicolas’ early prototypes both internally and with community members and then iterated based on valuable feedback. Finally, Nicolas kept an eye on rollout and tackled support tickets when needed.

We’re looking for engineers who are comfortable managing their own projects and aren’t afraid to ask questions as they arise!

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.

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.

Each feature has an engineering champion.

At Rune, we've organized ourselves into Durable Teams. Whether you're focused on Patient & Clinician Experience, Analysis, or Core Platform, you're there side-by-side in every standup with champions from the product and neuroscience teams.

There's plenty of tasks that take one engineer a few days or less, but anything bigger or anything that requires cross-stack collaboration puts us in collective gear. During early discovery and ideation, our Product folks bring home the user research and put together user stories decorated with engineering’s final say on feasibility and scope of work. When we're all on board to build a given feature, everyone jumps into a Kickoff meeting to get up to speed on what problem we're trying to solve and for whom. Each feature has an engineering champion that knows the ins and outs of the project, what it means to be "done,” and the technical vision for future iterations.

For example, when we built our mobile integration with the Apple Watch, there was a limit on how much we could unit test in a CI environment. We did our best to design and build against documentation. Our mobile lead got the entire company engaged with our TestFlight build to generate data from different watches while doing different activities, and we discovered a lot of edge cases. As we slowly rolled out the app, we discovered even more anomalies. We knew we needed to bring reliability up to the expectations of our clinical and research users, so we connected our engineering lead with the actual beta testers, and even collaborated directly with the Apple team that had built the Watch kits we were pulling data from. As an engineer, you’ll play an integral role in driving projects forward and make an impact from day one.