Engineering Team at Airtable

Our mission is to democratize software creation by enabling anyone to build the tools that meet their needs.

We believe software is the most important innovation of the past century, but that its potency as a medium for economic value creation and creative expression remains inaccessible to most. (People typically experience a finished software product rather than software as a medium.) We believe customer success isn’t the responsibility of a single team: instead, we all own this. In everything we do, we start with the customer and work backwards. When our customers succeed, we succeed. As engineers, we know how empowering it can be to create software, and we intend to bring this power to everyone.

Instead of designing features for narrow use cases, we create fundamental building blocks that can be assembled to model any workflow. With our next-generation app platform, teams easily develop and deploy flexible and engaging apps that power critical workflows for teams. Our users can build powerful apps using our App designer, without requiring any special technical skills. Our platform makes it effortless to create an easy to use UI, powerful workflows, and scalable data structures. We strive to make complexity as accessible as possible, sweating the details of our user interface and creating the best possible experience even when it means more work up front.

This combination of flexibility and accessibility has enabled people from all walks of life – from magazine editors and TV producers to architects and cattle ranchers – to find value in Airtable. Our users love what we’ve built; they praise us on social media and publish amazing templates on Airtable Universe. Working on a product with such a broad, deep, and positive impact is motivating.

As ambitious as our current product is, we know our mission demands far more. In Niklaus Wirth's classic formulation, Algorithms + Data Structures = Programs. Airtable starts users with a rich, highly accessible canvas to describe their data and then layers powerful tools to add functionality (algorithms) over that data. Our Interface Designer allows our users to define customized interfaces for the programs they construct – a powerful tool when combined with Automations, Sync, and our investment in incorporating AI capabilities into the product. By scaling these dimensions – further enriching data, tools, and interfaces – we have a unique opportunity to teach users to build fully-realized applications gradually.

Building that general-purpose toolkit has a unique set of complex engineering and design problems. Whether it’s finding the right level of complexity and expressiveness for a new feature, or thinking through how it might intersect with the product's existing dimensions and building blocks, the opportunities and challenges embodied in these problems inspire us to do our best work.

We're enthusiastic users of Airtable! Many of our internal processes run on Airtable, including our issue tracker, employee directory, and product roadmap. Ask us about our personal bases for our travel plans, parenting responsibilities, and books we're reading! This passion for our own product unifies our team and ensures we're all invested in continually improving it.

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 software engineer develops an intimate understanding of both the underlying technical architecture and the ideal user experience.

We foster this mindset 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 thoughtfully scope our problems for a period of time before we start building. This preempts issues that may come up in the future and informs the sequencing of new features in a complementary fashion.

Airtable takes a long-term view.

We intend to build a company that will last decades. Our product, funding, and market position make a long-term orientation for our engineering team not only possible but also necessary. For one thing, our product has enough fundamental complexity. Adding incidental complexity by taking on too much technical debt would cripple our velocity sooner than a company with a more straightforward, boilerplate product. Our focus on code quality grows from deep roots in the nature of our business; it’s not just a pet preoccupation of some engineers on our team.

To this end, we embrace the usual repertoire of quality software development practices: code review, linting and static type checking, unit and integration testing, continuous integration, manual and automated QA, deployment automation, issue tracking, and a thorough style guide that focuses on practices that improve code clarity without too much bikeshedding. These practices aren't set in stone; we're always discussing how to improve, and ideas can be raised by anyone from our newest hire to our CTO.

At a higher level, we have a culture of circulating ideas in design documents well before implementing them. We do what’s best for Airtable: we’re one team working towards one mission. We’re collaborative and share our work openly. We’re invested in each other’s success. When done right, a design review process does not slow down development. Good teams are perpetually bursting with ideas. If people are encouraged to share those ideas early, then features or changes can be proposed, discussed, and refined long before the team has the bandwidth to implement them. Reflecting on design or implementation approaches as a team leads to greater simplicity and clarity. Building the simpler, clearer thing nearly always leads to greater development velocity, even in the short-term.

That said, we recognize that there are times when fast turnaround is imperative. Sometimes a defect that affects users must be fixed urgently, and the fix is clear, and in such cases, we prioritize appropriately. We prioritize progress over perfection and operate with urgency. We move fast to deliver ambitious goals but know that sometimes getting the right results demands more time. And sometimes, the best way to deliver quality in the long-term is to put early iterations of a feature in contact with users so we can learn from their feedback. In these cases, we strategically deploy well-contained technical debt. (One tactic for containing debt in these situations is to ensure that decisions made in this mode are highly reversible. For example, exposing a feature behind a flag to a small audience constrains future development much less than a public UI or API in the core product.)

That said, we recognize that there are times when fast turnaround is imperative. Sometimes a defect that affects users must be fixed urgently, and the fix is clear, and in such cases we prioritize appropriately. And sometimes the best way to deliver quality in the long term is to put early iterations of a feature in contact with users so we can learn from their feedback. In these cases, we strategically deploy well-contained technical debt. (One tactic for containing debt in these situations is to ensure that decisions made in this mode are highly reversible. For example, exposing a feature behind a flag to a small audience constrains future development much less than a public UI or API in the core product.)

We think of diversity and inclusion in terms of 3 P's: Presence, Participation, and Progress.

Presence: The first step to inclusion is simply including diverse people in your company. We actively discuss improving and diversifying the culture in our #diversity-equity-inclusion Slack channel, ERGs, DEI working groups, and other forums. To reduce bias in engineering hiring, we've introduced standardized rubrics and assessment metrics for our interview process. We're continually investigating methods for improving the diversity of our candidate pool. Our executive team leadership unambiguously supports devoting significant resources to this end.

Participation: Once you get people in the door, you must ensure everyone is involved in meaningful decisions. Our employees come from all walks of life: some are parents to newborn children, some are empty nesters, and others are part of the younger workforce. Companies should mold themselves to accommodate their employees’ work styles. Most of our communication is asynchronously accessible. Company-wide celebrations happen at all hours of the day, not just after work, and include activities, food, and beverages compatible with various lifestyles.

Progress: We want all employees to create the biggest impact possible. We've instituted a program of training managers in coaching skills to maximize every report's chance of success. Majority-identifying, as well as minority-identifying engineering leaders lead our DEI working groups. We support formal communities (ERGs) and organic communities (such as our Women in Eng group) that have developed within our organization – ask us about these!

The best decisions are made by proactively communicating with everyone who might thereby receive or add value.

This nearly always means capturing it in written form, whether that’s project specs, meeting notes, retrospectives, market opportunity analyses, or other documents. We’ve all got a lot to learn and know there’s always room for improvement. We’re aware of our shortcomings and welcome feedback on how we can do better. If we fail, we learn fast and move on. We approach our work with humility. We’re open to new ways of thinking and are never arrogant or entitled.

Furthermore, we strive to establish a social context in which people have the right expectations about authoring proposals or commenting on them. First, we encourage people to share as much information as possible: not only proposed actions and decisions but also the context and motivations that prompted them. This allows readers who do not already have that context to engage more effectively. Second, we practice empathetic communication and discourage excessive pride of authorship. Ideas can only be shared early and often if people feel secure that their half-baked or highly speculative ideas will be welcomed as a starting point rather than criticized for their imperfections. On the other hand, iterating and refining proposals can't work if people start out too attached to (or personally identified with) particular versions of an idea. Without these critical values, no software tool can create a culture of open communication.

Like many other companies, we use Slack for real-time communication. However, we also recognize the many limits of chat-style communication and strongly bias toward capturing discussions wherever reasonable in documents, tickets, and other durable media (including Airtable bases). The best decisions are often made with ample time, discussion, and thought, which are best supported by asynchronous collaboration.

(A powerfully written and asynchronous communication culture has other benefits, too. It's better for work done outside our main offices, or on time-shifted schedules. Also, it enables a more significant proportion of focused “maker time” compared to a culture where everyone feels obligated to actively monitor chats for fear of missing out on meaningful conversations. Of course, there are plenty of times when real-time chats or meetings really are the best way to communicate, and we embrace those situations. But we try to deploy these communication modes thoughtfully.)