Engineering teams that value start-to-finish ownership

Ownership is one of our company’s three core values, and we take that to an extreme.

We’re on a mission to make planning air travel and flying seamless. While the airline industry was one of the first big industries to digitize in the 1960s, the technology hasn’t kept up with the times. This legacy infrastructure means that travelers are experiencing unnecessary hurdles and companies are losing out on revenue opportunities. Previously, if you wanted to book a flight on Expedia or Hopper, for example, you could see flight information, but couldn’t add a bag or select your seat. Instead, you’d have to visit the airline separately after booking a flight and select these add-ons. This is just one of countless examples we’re solving for by building software that makes it easy to retrieve, book, change, and control your journey all in one place.

It’s fair to say that the airline industry is tied in knots – and we love a good challenge. In fact, that’s why we named our company Gordian, in homage to the Greek legend of the Gordian Knot, where a problem that was thought to be unsolvable was conquered by creative and bold thinking. In order to untie the proverbial Gordian knot of the airline industry, we believe in a culture that is defined by ownership.

Every team member is given a great amount of trust and responsibility to tackle large, important objectives independently. Unlike at other companies, at Gordian there’s only one person at the steering wheel for each project. This allows us to spread out and accomplish as much as we can as a team, by working on many important projects at once. This level of responsibility can be scary. In fact, one of our team members wrote a brilliant post about following his fear at Gordian. We have a supportive environment so that people can stretch themselves into owning larger and broader projects to drive the biggest impact for our business and our customers’ experience.

There are no limits to ownership at Gordian. You won’t ever be waiting around for a PM to assign you a task. From day one, you’ll be given access to every system and empowered to decide which features to build to solve high-level business goals. Everything touching your project is yours to manage. From inception to attainment, and across the full functional spectrum, be it legal contracts, billing and payments, marketing or operations, we own our goals – with support from the rest of the team, of course. For instance, Jonathan, one of our software engineers, owned our launch with Hopper. He went above and beyond to ensure the design matched their style, especially when it came to helping end users book options for traveling with their infants (e.g., in lap or in a seat). This included using custom logos and animations, as well as adding new theming functionality specifically for Hopper.

We place a premium on autonomy.

At Reduct, we’re on a mission to make video editing as simple as editing text, so everyone from user researchers to public defenders can communicate effectively with video. As a small team, engineers have a large amount of autonomy and responsibility to own projects and care for the whole of the product end-to-end. We look for folks who are excited about taking the initiative to bring features to life. For example, our intern Jerry started with the vague idea of tag organization. He had conversations with several of our users, created sketches, led the discussion, and oversaw everything through implementation, user feedback, and launch – collaborating with different colleagues along the way. Similarly, we all feel a sense of responsibility for the parts of the codebase we know are ours and getting to know the parts that aren’t. Engineers run the support line and share responsibility for on-call: it’s a high-trust environment where we all depend on each other to run a product and service at the highest possible level.

Ownership is one of our key criteria when evaluating performance.

Everyone in Instacart’s engineering organization is expected to take ownership of their work – regardless of where you or your team members physically work from (thanks to our new office, flex, remote policy). 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 take on bigger projects that range across their team, the engineering org, or even the whole company.

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

Engineers collaborate closely with Samarth, our CTO, on the product planning process. We develop our roadmap by incorporating ideas and feedback from all sources, including engineering team members, our external users, and folks from the Leave Specialists and Sales teams.

Engineers also participate closely in fleshing out plans for specific product initiatives from start to finish. 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.

Every team member has significant ownership.

In order to feel ownership, everyone needs to have as much context as possible so they can be trusted to make the best decisions possible. As one of many examples of how we work together, we measure commitments through company-wide OKRs that are then translated into OKRs at the team level. Those team level OKRs are then divided into week-long sprint goals, which are decided on by project teams in collaboration with our CEO and COO. We hold each other accountable by having daily syncs, and as part of the larger Aptible organization, during our bi-weekly all-hands meetings where we discuss how each team and the company are tracking toward our goals.

We value getting together, whether it’s for a brainstorming session, planning conversation, or deep dive into a previous quarter’s results. Leadership is transparent about what their goals are for the company and they welcome all types of questions at all-hands. 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. One great example of this is our compliance visibility project, which entailed creating a dashboard that would show customers exactly what we were doing to help them deploy secure and compliant applications and databases and what they could change if needed. While we had a general idea of what we wanted to build, it was really Ann Guilinger, one of our engineers, who led the project from start to finish. She was responsible for enlisting a couple other engineers and working with our product and design teams to build the dashboard, get it to our first set of customers, and expand it from there.

We hire people who are not only proactive, but are also comfortable asking for help when they need it. Folks who work here love crossing domain knowledge boundaries and getting their hands in all aspects of product development: ideating, interviewing customers, UX/UI design, testing prototypes, architecture design, DevOps, and everything in between. In other words, if you’re resourceful and like taking the initiative, you will thrive at Aptible.

We empower engineers to see ideas from initial proposal to execution and improvement.

Everyone on the Propel team is invited to write proposals and share ideas for new features and improvements that align with company goals. For example, Jeff, one of our software engineers, proposed moving to a new architecture that would improve how low-income families see their EBT balance in real time, which helps them purchase food.

Zack, one of our newer engineers, took this project on and recently pushed massive code to production within the first month on the job. 👏 He continues to work with the team on monitoring and refactoring it to optimize the process. It was a big success as our customers' turnaround time for getting EBT balance information dropped significantly.

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.

Team members are given the trust and autonomy to drive solutions end-to-end.

We identify key areas of the product that we’d like to invest in and then empower engineers to own projects all the way from ideation to shipping, monitoring, and extending a feature. While we look for people who are proactive, resourceful, and love taking initiative, it’s equally important that folks we hire aren’t afraid to ask for help when needed. One of our engineering team values is “craft meticulously” and this applies to the entire process of scoping, gathering feedback from stakeholders, and partnering with cross-functional teammates as needed – not just writing excellent code.

One great example is caregiver leave, which one of our engineers, Belinda, owned. She worked with our legal team to figure out what documents to collect, and collaborated with product and design to create a simple flow that determines an employee’s eligibility and shows how much time and pay is available based on state and federal laws, insurance, and company policy. In addition to shipping the feature itself, she also collaborated with marketing and sales on the messaging around the launch, resulting in blog posts like this one sharing real stories from caregivers who handled family crises.

People do their best work when they feel empowered by ownership and the opportunity to make an impact.

Our engineers aren’t just expected to write great code – we challenge them to be product-minded and involved in every aspect of bringing products to market from end-to-end. For example, after speaking with several customers, one of our engineers drove our reporting API feature from start to finish in order to give customers better visibility into their data.

It’s important that engineers approach their work holistically, aspiring to fully understand both the customer and the problem space. To that end, engineers have control over the processes and tools they use to do their job. For example, our data analytics team did a deep dive into multiple data warehouses to determine the best tool that we adopted as a product team. Engineers that thrive at Qualified continuously search for optimal outcomes – challenging assumptions, asking hard questions, and leveraging their creativity – rather than just delivering according to specs.

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.

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.

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.

Engineers are empowered to make decisions and take ownership.

As a new engineer, you’ll join a cross-functional pod that’s a mix of engineers, designers, product managers, and an engineering manager. Each pod is responsible for their own problem domain and we look for engineers who are willing to define what success looks like for their given goals and ensure it’s achieved. For instance, since we’re building a mental health product, one important metric we look at is time to remission – is the user feeling better afterwards and how can we get them there even faster? Engineers who succeed at Big Health encourage others to share their ideas, actively listen, and roll up their sleeves to dig in on a problem, even when it’s not necessarily in their job description. We’ve had backend engineers look into frontend automation testing and other frontend engineers who led projects from start to finish on the backend. Similarly, we like to hire engineering managers who can moderate and facilitate the best ideas cross-functionally. At the end of the day, while we have specific goals, we’re not here to tell you exactly what and how to build things – we want you to feel a strong sense of start-to-finish ownership for solving problems and moving things forward.

Every person who joins – regardless of level – is a project owner.

As a lean team, there’s a unique opportunity for all of our engineers to have a significant impact on the product as we develop. We believe in a very flat organization – we have not introduced any middle management and are not building vertically. This means all employees at all levels meet and work with our co-founders and partners.

Engineers have end-to-end ownership, from discussing and evaluating project requirements to designing, building, and testing the solution, to deploying it to production, and using data to evaluate whether it’s meeting customers’ needs. For example, Nico, one of our software engineers, noticed a user pain point and took the initiative to create a new flow for cashiers at truck stops so they could fix transaction errors without needing to contact customer service. He solicited feedback from stakeholders, communicated regularly with our PM and designer, and made sure to reach out to others if he needed help figuring out parts of the codebase or was going to make a more drastic change. Ultimately, he pushed everything to production, monitored and fixed any bugs, and ensured that the feature went to plan. As he shares, “During the entire process of owning this feature, I felt empowered to dig into legacy code, find edge cases that had not been discussed, and even make changes to the user experience that had been there for a long time. There were a lot of moments where the expected experience wasn’t the one that had evolved over time, or the fix that we thought would work showed us another UX improvement to help our customers (internal and external) throughout the lifecycle of our purchase process.”

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.

We kicked off 2022 with our 3rd annual hackathon, which saw extensive collaboration (and hacking) between Product, Design, and Engineering teams. The previous hackathons have been a source for real production ideas and features that have shipped (including 8 out of 15 from our first ever hackathon!) and we’re excited to see ideas from this year come to fruition as well.

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. We’re currently in 35 of the top 100 school districts and serving more than 10 million monthly active K-12 students. If any of the above excites you, we hope you’ll get in touch soon!

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. Ted is a great example – he dove into product analytics and worked closely with our Data Engineering team (among many others) to integrate the new Eventing Platform into our products and to make sure it met our analytics requirements. Today, he’s known as the go-to for product analytics thanks to his hard work.

Similarly, when Cameron first started, he worked on a tight-knit team owning the design, build, and roll out of an entirely new application that we call “Ellis” aka the consumer dashboard. Ellis allows immigrants to view their credit history from their home countries, get credit and financial product recommendations, and more.

From implementing design specs to spinning up a new database and organizing a bug bash before rollout, Cameron worked closely with our legal, QA, and customer success team to ensure this huge project was a success. If you’re willing to roll up your sleeves and take ownership to help problem-solve, you’ll fit right in!

We care about start-to-finish ownership for several reasons.

First, we believe developing our engineers to think at a high level is mutually beneficial. Companies exist to solve problems, and doing so effectively requires start-to-finish ownership. It is necessary to look at data that identifies a problem, build a solution, and again use data to determine if this solution solves the problem. If not, we’ll attempt another solution. At Ladder, we want engineers to be problem solvers, not just code writers. This means they’re involved and have the full context throughout the entire process.

Second, we've built our teams around stages of the user journey – and not technology – because we think it's more efficient for one person to build the frontend, backend, and data aspects of a feature instead of coordinating three teams to do this. We also find this diversity of technology and environment is good for a developer’s growth.

Third, we believe that a lot of incidental complexity and rigidity in software comes from establishing the wrong abstractions. We push engineers to think about the end customer result of their changes rather than the code-specific modules and interface changes. We've built a whole testing framework that makes writing these tests fast and deterministic.

In a great example of start-to-finish ownership, an engineer on the team noticed that a large percentage of people didn't accept their offers for coverage because they were too expensive for them to afford. The engineer built a predictive model to simulate the change in the offer acceptance rate if we made offers that were more affordable and quantify how many users solving this problem could impact. They worked with product and design to build several solutions to this problem and ran them in A/B tests. This engineer not only built and ran these A/B tests, but they also analyzed the resulting data to confirm the desired effect happened.

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

Product delivery at Airtable is deeply cross-functional and collaborative. Software engineers work with product managers, designers, UX researchers, customer-facing teams, data insights partners, and quality engineers to understand user needs, propose and implement solutions, and evaluate outcomes. Engineers can be as involved with all aspects of this process as their skills and interests allow.

Here are a few things that our engineers can do as part of product delivery (collaborating with our partners in other roles):

• Analyze user behavior both qualitatively and quantitatively
• Conduct interviews with users
• Write specs and designs for new features
• Conduct “spikes” (timeboxed investigations to explore potential designs)
• Create UI mockups and prototypes
• Engage in detailed design and final production implementation
• Create an automated and manual testing and quality assurance strategy
• Define, implement, and analyze experiments and metrics that measure success
• Conduct blameless retrospectives on process and launch learnings

For a product like Airtable – a horizontal toolkit for software creation – every product decision has nontrivial, combinatorial implications for other related features. Having a hybrid product and engineering mindset is critical to designing building blocks that are simple and usable, yet powerful and flexible. Our ideal product engineer develops an intimate understanding of both the underlying technical architecture and the ideal user experience.

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 sometimes simmer on problems for a period of time before we start building. This preempts problems that may come up in the future and informs the sequencing of new features in a complementary fashion.

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.

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 can count on each other.

As a team, we have a bias for context over control – we develop a shared understanding of the most important problems, and then give team members the autonomy to develop and validate the solutions. We hold each other accountable for outcomes, not hours spent. No one is watching over your shoulder to make sure you’re getting work done. You have the autonomy to figure out a work schedule that makes sense for you.

In return, we expect our teammates to own their work and deliver what they promise. Engineers keep the bar high on quality, security, and end-to-end customer experience, not just executing the tasks they are assigned. People who thrive here are able to remove their own roadblocks without waiting to be told what to do.

As a company, we want to empower people to do their best work and give everyone the tools, support, and resources necessary to achieve their goals. We strive to create an environment that removes as many distractions as possible, and an important part of that philosophy is making sure our team can come to work, focus on what they do best, and not worry about non-work-related concerns.

To help reduce anxiety around questions like, “Am I getting paid enough?” or “How much will my family’s medical bills cost?”, we pay top of market compensation for cash and equity, and we pay 100% of premiums for best-in-class healthcare for all employees and dependents. In our offer process, we are transparent and share the benchmark data we use to create offers so that we can try to minimize bias and help candidates and employees feel good about working here.

Everyone on the team also has a $500 monthly outsourcing budget to find creative ways to offload tasks that are not a good use of their time, like manually testing our “Snapshot” system on different business apps or getting new icons drawn for our web app. Our primary goal is to find people who are great at what they do and create a work environment where they can focus on what they do best.

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 responsible for breaking down complex ideas into achievable tasks and then rigorously executing.

We are currently a small 15-person company, which means everyone has a tremendous amount of ownership. As we grow, we want our team 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. For example, Rebecca is leading the charge on our product redesign and Ruud built out our integrations engine, which is one of our largest growth drivers. Ownership – and a high degree of trust that comes with it – will always be a core part of Doppler’s culture.

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.

Every engineer is an owner.

For us, ownership is everything from ideation to impact. Through hands-on research with guests or collaboration with our kitchen teams, you may uncover an insight that leads directly to a new feature on the roadmap. As an engineer, you’ll have a seat at the table with product and design from the very beginning. You may even design a feature yourself, coordinate the marketing launch, and write the announcement copy!

In December, Michael Parlato, the lead for the guest experience team began working on our mobile ordering app. The project gave him the opportunity to learn a new framework, run a beta test in which he received direct feedback from dozens of enthusiastic end users, and push the limits for fast-paced, agile development. “Through phone interviews with guests, I was able to refine our definition of launch-ready, narrow the scope to the absolute essentials, and move the App Store launch up by three weeks.”

You’ll work on projects from inception to completion – and beyond.

We have an ownership mentality and engineers have a lot of room to innovate and see ideas to fruition. It’s everybody’s job to understand customer needs and deliver on them. That’s why you’ll get to have your hand in everything from discovery and ideation to design and QA. For us, finished doesn't just end at “shipped” – engineers are responsible for fixing bugs, extending features, and iterating based on customer feedback. Whenever possible, we love to have engineers present their work to customers directly in our design partner meetings. Not only are they the ones closest to the work, but it also enables engineers to get live feedback and see firsthand the impact they’re making. That said, we’re strategic about the features we build and aren’t afraid to find ways to push back on customer feedback if needed. There’s a lot of exciting things we’re working on and new hires might work on building anything from developer experience tooling to new features in the app to different integrations. If this sounds exciting to you, let us know!

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 comprised mostly of engineers grouped into six different teams. The support team provides our customers with hands-on engineering help and expertise. Infrastructure is responsible for building and scaling Render’s platform for security and reliability. Security focuses on all aspects of resilience and protection of sensitive data, as well as adhering to international security, privacy, and compliance standards. Datastores owns our managed Postgres and Redis products and other customer-facing data products. Services owns the core of setting up and running user Services, signup/in, first run experience, billing, and much of the Dashboard. Last but not least, environments allows larger and more sophisticated users to configure complex combinations of Services via Environments, Blueprints, and Projects.

Check out our blog to see what we’ve been working on!

Engineers drive projects from inception to completion.

Whether it’s a project that takes weeks or just a few days, engineers have a large amount of responsibility and ownership. One great example of this is how we built an intake app for COVID-19 testing. In March of 2020, we quickly mobilized our diagnostic genetics testing infrastructure to respond to the COVID-19 pandemic. Testing hundreds of people a day required us to rethink our manual intake process. Five engineers built our digital intake app in just one week by starting with a detailed design document, working in tight pull requests to keep the code as up to date as possible, and keeping open lines of communication with the entire team. At the end of the day, we look for folks who are excited about finding the simplest solution to a problem that will make the biggest difference for our users.

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 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, which lets Orbit users identify and merge duplicate community members. 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!

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.

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.

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.