This is a report on the experience of building and shipping software today. What we saw, and what’s captured in this report, are a number of opportunities that have the potential to unlock the next wave of speed and agility for the software industry.
It takes a long time to build software. As builders ourselves, we believe it can be done faster, with more joy. Deeper insight into the day-to-day experience of building software will uncover opportunities to bring more joy to builders and more speed and agility to their organizations.
Lots of research. We draw from 18 months of research, including over 50 qualitative interviews and a 301-respondent survey, as well as our own experiences as builders.
The parable we keep coming back to is the blind people and the elephant. We sought to incorporate views from all sides of “the elephant,” including engineers, designers, product managers, researchers, middle management, and executives to fully uncover the Shape of Building.
This report is not about the Future of Work. We aren’t trying to predict what it will look like to be a builder in five or 50 years. We’re firmly anchored in what it means to be a builder today, and how we can improve that experience right now.
We start with a simple question, Why do builders build? The answers we gathered from builders clustered into eight main categories, which we collectively refer to as the Joy of Building and quantify below.
These are the fuel sources that drive builders to keep going. Amplifying them is a durable way to improve any organization’s speed and agility. When there is joy in building, powerful work gets done.
We asked builders,
Here are the most common answers, which we collectively refer to as builders' Joy of Building:
Bringing value to people
Building is an act of giving. It’s about builders using the skills they’ve acquired to add value to people’s lives.
Overcoming a challenge
Building is a way to overcome challenges. The reward is experience that can be used again and again.
Impact on the world
Building is an act of community. Builders have the power and responsibility to create value for millions, if not billions, of people.
Being on a team that is greater than the sum of its parts
Builders team up to deliver something greater than they could on their own.
The success of the business
Once a builder joins a business, they want to cheer on their teammates, see their team win, and celebrate victories together.
The journey keeps life interesting. It’s filled with ups and downs, days of “grinding it out,” and days of pure bliss when things start to click and come together.
Reaching flow state
Flow can exist in any pursuit, but it is particularly powerful for builders. When work becomes focused and energized, time flies.
The tools for building
Like a sharp knife in the hands of a master chef, better tools eliminate distractions and allow for building to happen faster, better, and with less friction.
Many builders start out on their own—a class they take, a blog post they follow, or an annoying task they want to automate.
At some point, builders will consider building as a day job. How does a builder’s joy manifest while building at work? Below, we asked builders what are the best and worst parts of software development at their current company.
What's the best/worst part of software development at your current company?
The best parts of software development are: (1) the relationships with teammates, (2) the technical challenges, and (3) the compensation for their work.
The worst parts of software development are: (1) the time it takes to ship, (2) the software development process, and (3) the tools used for work.
The best and worst parts are largely company-agnostic. No matter which company you join, your relationships with your teammates will most likely be one of the highlights, while the time it takes to ship things will likely be one of the lowlights.
Let's compare a builder's Joy of Building with the ways a builder can find joy at work. Together, these statistics tell a story of sacrifice and tradeoffs that builders must make in order to build in their day jobs.
On the one hand, a builder will get joy out of their relationships with teammates and the technical challenges they own. On the other hand, a builder will have to sacrifice any joy that relates to faster ship times, a stronger development culture, or better tooling.
How might we, as builders, work in ways that are less frustrating and more fulfilling? What tradeoffs are we making when we decide to join a certain company or team, and how can we go into that opportunity with eyes wide open?
We asked people to rate their companies on various dimensions.
Company size has an outsized impact on overall job satisfaction, satisfaction with total compensation, the amount of control builders have over their work, perception of builders’ relationships with managers, and their ratings of software development process and culture.
At bigger companies, builders are less likely to own decisions about business processes, priorities, and hiring. This growing power distance limits builders’ agency to create joy for themselves and their team, as decisions about everything from product priorities to the software development process become increasingly centralized. This is partially offset by an increase in satisfaction with total compensation.
At smaller companies, builders are more likely to own business decisions, priorities and hiring. At the same time, they may not make as much salary (though equity can be one way to balance out a lower base salary).
Building is hard! Thankfully, there are many joys that help builders persevere. As an industry, we can achieve more by anchoring in—and celebrating—what brings us joy while we build. Ultimately, it’s up to each of us to figure out what brings us joy when we are building, and find ways to fulfill that in our work.
It takes too long to ship software. Stereotypically, time pressure comes from management, but we found this stereotype to be untrue. Nearly everyone wants to ship faster—builders, managers, and leaders. The main challenges are development process, culture, and tools. If we can bend our tools and process to better fit the realities of building, we can gain the speed and agility we collectively yearn for.
Every organization has a massive opportunity to improve ship times, builder culture, and tooling. It starts with collective awareness, and asking ourselves some hard-hitting questions: Now that you see it, how long can you live with the status quo before you do something about it? What would it take to improve? What's holding us back?
Most of the time, builders work on teams with people that specialize in a range of trades—all in service of shipping software. In this section, we expound on what teamwork looks like in modern technology companies: Who is on a builder team? Where does each teammate’s time go? What brings out the best in teams? What brings out the worst?
Across the industry, we saw striking similarities in team composition. While there are occasional exceptions, most teams comprise the following trades:
Beyond the team itself, builders are impacted by their relationships with other people, including:
Builders work on teams with a range of trades.
Each person has a unique view of the terrain and plays a key role in the team’s overall success.
We asked builders, "How often do you feel like you are doing the following activities on your primary project?"
It appears that builders feel as though most of their time is spent planning, coordinating, and updating projects—often more so than their own trade work!
Why does this happen? Next, we break down the data by trade—research and data science, design, product management, and engineering—and we supplement with stories from builders.
It’s tempting to view teams as collections of functional specialists, each focused on their specific discipline. Simply put, this is not how work gets done. Across the many teams we spoke to, and throughout our survey data, teams reported high degrees of overlapping responsibility between functions, even, and perhaps especially, on high performing teams.
This overlap is about developing trust, alignment, and chemistry, which pays dividends throughout the course of a team’s time together. Inevitably projects will face adversity: The best laid plans are not always better than a fuzzy sense of the destination. Progress isn’t always linear. Data can mislead.
In these moments, teams with trust cope better than teams without it. They spot “slow moving trainwrecks” earlier. They have tough conversations sooner. They reach solutions that are greater than the sum of their parts.
Our industry is fast-paced, and the task of building is a messy one. While functional specialization plays a huge role in execution, exceptional work requires every specialist to have a clear, shared understanding of the bigger picture. It also requires mutual trust and chemistry with teammates to thrive and adapt together under constant change or adversity. This in turn unlocks the speed and agility builders crave and organizations rely on.
Well-designed tools are powerful sources of leverage. We see tools practically everywhere in the software industry: they help us plan, build, ship, measure, allocate resources, and stay organized.
We set out to understand which tools teams rely on most to stay on top of their projects, and how effective their current tools are at helping them stay fast and agile.
What is the most reliable source of information for your primary responsibility or project?
The three most reliable sources are (1) Myself, (2) Meetings, and (3) Systems of records (or tools).
Relying on yourself and relying on group meetings are the same thing in a way. Group meetings are get-togethers where people who rely on themselves share what they’re doing.
In spite of the broad availability and adoption of software tools, builders turn again and again to themselves, and to meetings as their primary means of staying aligned and informed. Despite poorly run status meetings being one of the most commonly criticized activities of our industry, we still struggle to replace them with software. Why?
And, (as we saw in the previous section) if builders are continually falling back on social processes for coordination, could that be a sign that the systems of record are failing us?
We asked builders to describe the status of their systems of record, for their primary project—designs, documentation, and tickets.
The results are stunning:
Here, we see a vicious cycle: We rely on ourselves and meetings, because our systems of record are stale, and they are stale because we rely on ourselves and meetings.
Why might this be so?
Documenting is work, and hard work! It requires explaining what you’re doing with clarity and empathy for people who have less context than you. This takes time away from your specialized work, and is its own skill that requires more time and attention to develop.
Systems of record are most valuable when teams are moving quickly, yet this is the time when cutting corners on documentation is most tempting. In practice, these systems are disconnected from builders’ everyday work, and painful enough that updating them feels like an optional second job—one that usually falls on a manager or someone in program management, with mixed success.
As individuals customize their systems of record in pursuit of productivity gains, they also create paper cuts for other members of the organization.
An engineering manager may benefit from the customizability of their ticketing system, and in so doing create more paper cuts for builders on other teams.
What happens when one teammate’s tool doesn’t fit the needs of another teammate? They use more tools!
The average builder in our survey reports using two to three tools for project management, two tools for documentation, one for design, and one for source control.
Builders use a lot of tools, but there is much room for improvement: the systems of record require manual updating, which creates new work on top of “real” work. Many tools offer solutions for a specific person on the team, and in so doing create more paper cuts for another member of the team. There are too many tools, which fragment our attention.
The net effect is clear: it’s easy to get lost in all the tools that builders must use to get their work done—and right now, builders rely on meetings to help find a way out of that maze. How might we find our way out of the maze without relying on ourselves or our teammates so much of the time? Herein lies the solution to faster ship times.
Whether our existing tools can get us there is unclear. In talking to builders, and in our own work experience, we’ve seen much vitriol directed at the poor ergonomics, lack of interoperability, and limited visibility provided by the tools available today. If we can improve the interoperability and usability of tools, perhaps we can move them to the center of the building process, reduce our reliance on meetings, and gain the leverage tools are intended to provide.
Everyone we spoke to—builders and leaders alike—believe it takes too long to ship software.
And yet, the pursuit of faster ship times at the organization and team level appear to be at odds. Where the organization needs standards, systems, and alignment, teams need freedom to bend tools and processes to match their needs as they arise. Across our research, we found builders deeply skeptical of whether the status quo is providing the speed and agility we need to move the world forward.
Instead, most builders have stories of times they’ve felt like cogs—powerless and voiceless. Our research uncovered and unpacked many ways powerlessness manifests in a builder’s work life. The overwhelming majority of builders are earnestly trying to move their organization toward its goal as quickly as possible. What holds them back is structure and controls put in place by leaders who, in fact, want the same thing as builders.
What would happen if we moved away from these existing structures and inertial forces? Can we return autonomy and control to the teams of builders doing the actual work, and in doing so, collectively be inspired to build bigger, better, faster? Maybe customers would pay extra to know that more love, care, and local craft went into the products they use. Wouldn’t you like to know that your software was ethically sourced? That the builders were “free range,” rather than boxed in?
We believe the dichotomy between organizational alignment and team-level autonomy can be dissolved, that builders can be empowered to choose process and tools without compromising leadership’s ability to steer the organization and stay informed about progress. It’s time to be the change we want to see in the industry. We’re ready, are you ready?
We gathered qualitative and quantitative data from over 351 people working at the following companies.
We thank our many partners and collaborators on our inaugural Shape of Building report! This includes, but is not limited to:
Everyone who participated in our research and everyone who shaped the narrative, directly or indirectly:
We're driven by three beliefs.
1. Builders move the world forward. Progress comes from the hard work, ingenuity, and adaptability of builders. Without them, we wouldn’t have the Golden Gate Bridge, the Internet, or the Smallpox vaccine. Improving the happiness and productivity of builders improves the lives of everyone.
2. When there is joy in building, powerful work gets done. Creating something truly great takes time, collaboration, change, feedback, and repetition. The process can be draining, the temptation to declare “good enough” irresistible. Builders persevere when they find joy in the process, and it’s in those moments that the breakthroughs happen.
3. Tools can be a source of joy. Like sharp knives in the hands of master chefs, great tools amplify the impact of their wielders. When tools provide focus and leverage, rather than distraction and frustration, they empower builders to do their best work.
We’re building tools for builders. Our first product, Balsa Build, is a project management interface—for the tools you already use. Balsa Build empowers builders to work with their teams’ existing projects and processes, in a lightning fast and intuitive way.
Builders have more tools than ever before. Our goal is to tie these tools together into a single interface, so builders can see their whole workday in one place instead of keeping it all in their head. In doing so, we hope to strip away some of the frustrations of building and infuse more joy into every builder’s day so we can move the world forward faster, together.
The report comprises three primary pieces:
Research participation recruitment came from these sources:
We did not offer incentives or payment for participation in this report. We thank everyone who invested their time, knowing that their primary gain was our gratitude and, we hope, the report itself.
For all our qualitative interviews, we coded for key themes in participants’ answers. Interviews were recorded. Key themes and quotes were tagged in the videos for analysis and reference over the course of the research program.
We took the themes from qualitative interviews and turned them into survey questions, to quantify answers with a larger population of participants, which included builders, managers of builders, and executives of software development teams.
Prior to launching our survey, we ran user sessions with a wide range of builders and non-builders to test the survey questions for comprehension, resonance, and coverage of experiences.
Recognizing that we may not have captured everyone’s answers in the answer options provided, we included options for “This does not apply to me,” “Something else,” “Other,” and “I don’t know” wherever possible. When respondents answered “Something else,” or “Other,” we asked for an open-ended text response to gather additional information.
Our survey was built using the open source software SurveyJS. Data was collected in Google Sheets. Analysis was performed in R.
The first few questions in the survey were open to all respondents, in order to gather information about employment status and what motivates them to build.
The rest of the survey focused on people who are currently working at companies with at least 2 employees; we therefore excluded anyone who did not fulfill this criteria for the rest of the survey analysis.
We included 2 checks to ensure humans took the survey, and were indeed paying attention. Any respondents that failed the checks were removed from analysis.
We chose not to weight the survey data. On a medium-sized dataset of 301 responses, adding weights could lead to misrepresentation of results. Moreover, the publicly available information at the Bureau of Labor Statistics does not provide sufficiently granular statistics on our target population—builders, or the team of people that work together to ship software, including—but not limited to—engineers, designers, product managers, researchers, data scientists, technical program managers. Instead, we share all demographic information we gathered, and speak of insights or perspective only of the population represented in our survey data.
We intend to conduct this research program on the Shape of Building repeatedly over the years. We may weight the data in future years if available data permits.
As an example, if only five engineering executives took the survey, and they were underrepresented the survey (relative to population distribution), we’d need to apply a multiplying weight (i.e., w > 1). This would artificially inflate five people’s experiences to represent the population. If we had had more than 50 responses per sub-population, this would not have been a concern.
We expect that if this survey adds value to the builder community, and gains traction, future samples will be larger and we can revisit the weighting decision.
The majority of our analyses are counts and percentages. We asked people to pick answers to questions that best reflected their true underlying answer. We then counted how many, or what percentage, of people chose a given answer.
We generally kept to the simplest calculations. Wherever there are exceptions, we note them in the footnotes of the chart.
We also looked for relationships between answers and themes captured in our survey. When making use of statistical tools like correlations, regressions, and analysis of variance, we keep to the most straightforward formulas that would be standard in any master’s course on survey analysis in the social sciences. As a rule of thumb, we also excluded any findings that are statistically significant, but not practical, meaningful, or large enough that we can see them in raw data visualizations.