The Shape
of Building

Balsa Research × A Hundred Monkeys

Introduction

What is this?

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.

      Why are we doing this?

      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.

      How?

      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. 

      What this isn’t

      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.

      The joy of building

      Why do builders build?

      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,

      Why do you build?

      Here are the most common answers, which we collectively refer to as builders' Joy of Building:

      73%

      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.

      [I build for the] ability to create things that other people can use.

      Anish Agnihotri
      63%

      Overcoming a challenge
      Building is a way to overcome challenges. The reward is experience that can be used again and again.

      Like standing at the foot of a mountain, I know that if I put one foot in front of the next, I’ll eventually be at the top, then climb down, and then onto the next mountain. It’s a sense of achievement and adventure.
      Alonso Holmes
      59%

      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.

      I love seeing great inputs translate into great impact
      Jaren Glover
      53%

      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.

      50%

      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.

      Of course, all this hard work is in service of the business succeeding. That’s how we get rich [because we have equity].
      Engineering Manager at Samsara
      46%

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

      46%

      Reaching flow state
      Flow can exist in any pursuit, but it is particularly powerful for builders. When work becomes focused and energized, time flies.

      I live for the moments when things just start to click. It’s a confluence of people, priorities, focus, tool stack, and skills coming together, and you can finally start to see all your bets paying off.
      Paul Rosania, Balsa
      20%

      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.

      Moving [tickets] to ‘done’ is satisfying. Identifying the most intuitive way to use tickets is :chefs-kiss:
      Erica Engle, Staff Engineer at Slack

      Building as a day job

      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.

      It's electrifying to find other builders who share my ethos and help me unlock my best work. Even if our careers diverge over time, their names are in permanent ink at the top of my rolodex. I call them first every time I'm looking for a collaborator, and always answer the phone when they call me.
      Jason Eberle, engineer at Balsa
      I learned to program in high school and I really liked seeing the computer do what I told it to do.
      Thom Mahoney, Software Engineer

      Builders sacrifice joy in order to build in their day jobs

      What's the best/worst part of software development at your current company?

      Worst
      /
      Best
      My relationships with my teammates
      The technical challenge that I own
      My total compensation
      The software development culture
      My relationship with my manager
      The time it takes to ship or deploy things
      The software development process
      The software or tools we use to do our work
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Key findings

      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?

      Company size governs the tradeoffs builders make

      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Key findings

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

      Do [builders’] managers fundamentally give them the benefit of the doubt? Do they often set these folks up for success? Do they understand that not every single thing is going to work and that’s okay?

      I think the give and take becomes harder and harder the more of those layers [of management] you add, because at the end of the day it's a game of lowest common denominator.

      Even one manager in the chain who lacks the trust, takes the trust down for every single other party. Even one person who needs more certainty than everyone else now sets the new bar for what certainty and detail need to be. So it's hard.

      Madhu Muthukumar, VP, Product
      As a builder, the more ownership I’m given over the thing I’m building, the better I’m going to perform. When I have ownership over my work, I can feel the proud triumph of shipping a well-built feature, and the teeth-gritting guilt of encountering a bug. These feelings are powerful motivators for a builder!

      This is why product quality and builder performance decline the larger an organization grows—the diffusion of ownership softens these feelings and the motivating drive to perform 
drops off.

      Jason Eberle, engineer at Balsa
      It’s really easy to work with two people—two ideas of the world will have 95% overlap. When you get to 50 or 60 people, everyone sees the world through a slightly different lens. They need a way to describe what they’re seeing and interact with what they’re doing. As you scale up, you trade comfort for unpleasantness and diversity—better ideas and better results.
      Wayne Fan, designer at Balsa

      Takeaways from The Joy of Building

      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? 

      The makeup of teams

      Building is a team sport

      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?

      Who is on a team?

      Across the industry, we saw striking similarities in team composition. While there are occasional exceptions, most teams comprise the following trades:

      • Engineers: building software based on scope, designs, user stories, and insights. They make tradeoffs between what needs to happen now, and what can be done later.
      • Designers: visualizing and honing the actual product experience customers use.
      • Product Managers: documenting product plans, shaping the roadmap, and navigating the organization to help the team achieve its goals.
      • Researchers & Data Scientists: ensuring decisions are supported by facts and data. They search for insights and perspectives to share with their teams and ensure perspectives being spread and discussed are unbiased.

      Beyond the team itself, builders are impacted by their relationships with other people, including:

      • Stakeholders: a broad category of people from other teams who have input on what’s being built but aren’t typically directly involved. This often includes people from departments like Marketing, Legal, Communications, or Security.
      • Leadership: which includes executives like the CEO, head of product, head of engineering, or head of design. In large companies there are often many additional layers. These people can block or support the team—they can hand out a golden ticket or stop the whole train.

      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.

      How do builders spend 
their time?

      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.

      Always
      Never
      Planning
      Coordinating with my teammates
      Updating project stakeholders
      Coordinating with leadership
      Updating projects in the tools or software that I use for work
      Doing the work of my trade
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Alignment is everyone’s job

      Always
      Never
      Design
      Engineering
      Product
      Research & data science
      Design
      Engineering
      Product
      Research & data science
      Design
      Engineering
      Product
      Research & data science
      Design
      Engineering
      Product
      Research & data science
      Engineering
      Product
      Research & data science
      Design
      Coding (Engineers only)
      Designing (Designers only)
      Conducting research (Researchers only)
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.
      [On spending majority of time together] The best teams I’ve been on, the roles disappear. Obviously, there are functions and responsibilities, but the whole team is also really focused on the shared goals and how we can reach them.

      Working together on things like planning and brainstorming takes up a lot of time, but doing them well means things are healthier from the outset.
      Nick Merola, Research & Analytics at Slack
      Trust is one of those things that you build up slowly and spend quickly, and when it’s gone you get all sorts of team dysfunctions.

      As a PM, a “go/no-go” decision on a feature launch might ultimately be my call. But I need to make space for the team to see my thought process and potentially disagree.

      That’s what builds trust. It’s not just that people trust leaders because they make the right calls. People trust leaders because they’re level-headed, open-minded, and inclusive.
      Paul Rosania, Balsa
      Like many engineers, I actually love coding! My best days tend to be ones where I know what I need to do and I find solid chunks of uninterrupted time to get in the flow.

      Like many humans, however, I don’t want to live full-time in noise-cancelled isolation. It takes an artful org (and self-aware ICs) to successfully balance collaboration, heads-down IC work, and freeform socializing to build worklives that feel productive, connected, and meaningful. 

      Zach Totta, engineer at Balsa

      The value of time spent together

      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.

      Building strong teams looks like this, not that

      This: Time spent on alignment, trust, and deep thinking

      [Having a team that is greater than the sum of its parts means] a lot more conversation... Long hours talking about very minute things, but that's where the product is good. That's how you find things that may change your whole design or may influence things significantly. So that by the time you get to like, actual users, it's been pretty stress-tested.
      Jordan Williams, engineer at Balsa
      [What it was like on a high performing team] We were literally all at the same table for a week and able to talk through all these different decisions. When you have all of the experts there and you have their focus, it becomes so straightforward and easy to execute. In contrast, if you don't have all of those people there, you have to go and ask someone and then wait for them to come back to you. You don't have the confidence to make these different decisions quickly.
      Madeline Wu Shortt, engineer at Balsa
      The feeling of ownership requires deep thinking. You can only do deep thinking if you’re given the time and space to do that. You can’t do that if you’re always getting shuffled around, chasing after the hot new idea or chasing after growth..
      Gary Tsang, Software Engineer at Color

      Not that: Time monitoring and exerting control over something inherently hard to control

      In the case where a team is not getting the outcomes you want, you often see managers push even harder on things like deadlines or status updates. This creates a false sense of security in the process and the team starts to spend more time on leaning into those proof points rather than the hard problem that they’re trying to tackle. This creates a negative spiral where management time gets focused on the wrong parts of building when what’s probably needed is exactly the opposite.
      Madhu Muthukumar, VP, Product

      Takeaways from the makeup of teams

      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.

      The role of tools

      The role of tools

      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 do builders rely on to stay on top of their primary project?

      What is the most reliable source of information for your primary responsibility or project?

      Other
      Checking internal dashboards
      Asking a project teammate
      Checking with my boss (only shown if manager is not an exec)
      Checking with my reports (only shown to managers)
      Checking with leadership
      Checking the systems of record (e.g. tickets, docs, wikis)
      Attending planning meetings (e.g. standup, roadmapping, reviews)
      Myself (e.g. personal notes, self-driven progress)
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Key finding

      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.

      Whither tools?

      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?

      Stale, missing, and unaccounted for

      • Other
      • I don't know
      • Missing
      • Stale
      • Fresh
      Tickets
      Documentations
      Designs
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Key findings

      We asked builders to describe the status of their systems of record, for their primary project—designs, documentation, and tickets.
      The results are stunning:

      • 63% of documentation is stale, missing, or unaccounted for
      • 54% of project management tickets are stale, missing, or unaccounted for
      • 38% of designs are stale, missing, or unaccounted for

      Documenting work is hard work

      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.

      Documenting the work is work, but it takes away from time that you can spend doing the [real] work.
      Behzod Sirjani, builder resident at Balsa
      Sometimes, my day is just spent updating this tool and that tool. It’s a necessary evil that I have to do, before I can actually get to the work itself.
      Bernadette Le, Staff Software Engineer at Slack
      Informal Slack communications can feel lightweight and it's great to be able to make decisions without having to book a conference room, but sometimes a week later you're like, ‘Where did we document that whole decision and who else needs to know about it?’ Convenience can make you lazy about communications.
      Mike Davidson, Vice President at InVision

      One teammate’s solution is another’s burden

      [Ticketing system] is largely marketed to engineering managers as ‘a customizable solution’ to sprint planning and project tracking. So, as an EM I can go in and create a specific sprint board, with these features and these rules… another EM can go in and do the same for their team. But then if every manager in a company can do that, I see how it can lead to confusion for the engineers or designers on a specific team.
      Senior Director of Engineering at Slack
      Every organization that you go to might use [project management system] differently. If you change teams within a company they might use [it] differently. How designers use [it] is very different from how engineers [do]. Engineers live and die by [it] but designers are like… it’s just the kind of stuff that you have to deal with.
      Design Leader at Instagram
      I don’t understand [ticketing system] at all. When I changed teams, I tried to create a ticket, and it had totally different fields. I didn’t even know how to search for boards on my new team. I just don’t understand why there’s so many differences. Like, when I try to add a label, I see ‘bugs-ios’ ‘ios-bugs’ why?
      Erica Engle, Staff Software Engineer

      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! 

      How many tools do builders use? 

      Design
      1
      73%
      2
      22%
      3
      2%
      4
      3%
      Documentation
      1
      46%
      2
      44%
      3
      9%
      Project management
      1
      30%
      2
      33%
      3
      23%
      4
      9%
      5
      3%
      6
      1%
      Source control
      1
      91%
      2
      8%
      3
      1%
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Key findings:

      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.

      So many tools, not enough attention

      Companies that can effectively focus their employees’ attention on what matters are at a huge advantage compared to their competition, because we are so inundated with things that want our attention throughout the work day. 

      Some of it is work‑related. Some of it is not. Your phone is buzzing. You're checking Twitter. Your email inbox is exploding. Your Slack is exploding. You're on Zoom calls all the time. Today's information worker is so inundated with distractions—it's kind of like an amusement park that they're trying to get through just to get their work done.

      Companies have, up until this point, taken a 'more is better' strategy where it's like, ‘Hey, we've got a Wiki over here and we have Slack over there. We have email over here and hey, everything that you could possibly need is documented.’

      That sounds good in theory, but the way it breaks is people don't know where to store or look for things anymore.
      Mike Davidson, Vice President at InVision

      Takeaways from the role of tools

      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.

      Big Picture

      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?

      Thank you

      We gathered qualitative and quantitative data from over 351 people working at the following companies.

      fastly
      salesforce
      slack
      zillow
      clockwise
      etsy
      imgix
      confluent
      cruise
      twitter
      polychain
      oculus
      alan
      shopify
      unity
      skyscanner
      reddit
      homedepot
      iggy
      twitch
      obama
      hp
      airbnb
      robinhood
      espn
      stripe
      lyft
      ford

      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:

      • Eli, Liam, and Nora at A Hundred Monkeys
      • Friends of Balsa: David Benudis, Caroline Blake, Mary-Lynn Cesar, Wilson Chan, Albert Choi, Mike Davidson, Mike Demmer, Erica Engle, Jack Flintermann, Jaren Glover, Tom Hammer, Christina Janzer, Shane Johnston, Chuck Kwong, Bernadette Le, Michael Lopp, Mike Massimi, Nick Merola, Madhu Muthukumar, Katie O'Connor, Desiree O’Brien, Celeste Ridlen, Behzod Sirjani, Siddhi Soman, Gary Tsang, April Underwood, Joaquim Vergès, Marcel Weekes, DanDan Zhang

      What we believe

      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.

      What we’re building

      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.

      Team

      Balsa

      Madeline Wu Shortt
      ,
      Engineer
      My joy of building:
      Reaching flow state.
      First build:
      Fabricating ferromagnetic nanorings and nanowires.
      Nicole Zeng
      ,
      Operations
      My joy of building:
      Mastery over a challenge.
      First build:
      Custom Myspace profile.
      Alonso Holmes
      ,
      Engineer
      My joy of building:
      Impact on the world.
      First build:
      Building a platform to snowboard off of the roof of my garage. Subsequently repairing the roof.
      Zach Totta
      ,
      Engineer
      My joy of building:
      Reaching flow state.
      First build:
      Lincoln Logs and Hot Wheels tracks.
      Paul Rosania
      ,
      CEO
      My joy of building:
      Impact on the world.
      First build:
      A news site for a virtual world way back in 1996 (Activeworlds).
      Wayne Fan
      ,
      Design
      My joy of building:
      Being on a team that is greater than the sum of its parts.
      First build:
      MSPaint drawings.
      Jason Eberle
      ,
      Engineer
      My joy of building:
      Being on a team that is greater than the sum of its parts.
      First build:
      Rudimentary point-and-click games in PowerPoint and Hypercard.
      Behzod Sirjani
      ,
      Researcher
      My joy of building:
      Being on a team that is greater than the sum of its parts.
      First build:
      A very poorly constructed skate ramp OR Messing with HTML and CSS for Livejournal and Myspace.
      Jordan Williams
      ,
      Engineer
      My joy of building:
      Being on a team that is greater than the sum of its parts.
      First build:
      Myspace! Didn’t realize it was “building” at the time.
      • Wayne Fan
      • Paul Rosania
      • Nicole Zeng
      • Jason Eberle
      • Madeline Wu Shortt
      • Alonso Holmes
      • Behzod Sirjani
      • Zach Totta
      • Jordan Williams

      A Hundred Monkeys

      • Eli Altman
      • Liam Humble
      • Nora Trice
      Nora Trice
      ,
      Senior Creative Lead
      My joy of building:
      The grand opening.
      First build:
      A series of short stories about my dog, Felix, c . 1997.
      Liam Humble
      ,
      Senior Creative Lead
      My joy of building:
      Removing the masking tape and deciding it’s finished.
      First build:
      “Flying Machine” rubber band-powered balsa plane.
      Eli Altman
      ,
      Creative Director
      My joy of building:
      Taking something apart to understand it and then probably forgetting how to put it back together again.
      First build:
      Lionel wooden railways.

      Research methods

      • Recruitment and sampling
      • Qualitative analysis and survey development
      • About the survey data
      • Survey analysis
      • Survey sample demographics 

      Recruitment and sampling

      The report comprises three primary pieces: 

      • Over 50 qualitative interviews with builders of all types: engineers, designers, product managers, researchers, marketers, executives, and investors.
        • Qualitative research sessions ran from June 2020 through July 2021. 
        • Most sessions had preset questions; some were open-ended. 
      • A survey, completed by 301 builders at companies of all sizes, from early stage startups to multinational corporations.
        • The survey ran from April 13th through June 3rd, 2021. 
        • We also collected some data from builders between jobs; they did not see the questions related to work.  
      • Our own experiences across a combined 75+ years of working in the technology industry.

      Research participation recruitment came from these sources:

      • Our personal and professional relationships
      • Our investors and their networks
      • People that follow us on Twitter
      • People on our product waitlist

      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.

      Qualitative analysis and development of survey

      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.

      About the survey data

      Survey data inclusion and exclusion criteria

      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.

      Attention and bot checks

      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.

      Weighting and sample skews

      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.

      More on survey weighting: 

      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.

      Survey analysis

      Counts and percentages

      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.

      Correlations, regressions, and analysis of variance

      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.

      Builder trades represented in our survey

      Engineering
      34%
      Design
      14%
      Product management
      31%
      Research & data science
      10%
      Other
      11%
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Survey respondents' position at work

      • 110 individual contributors
      • 89 members of leadership or managers
      • 50 executives
      • 52 founders

      Survey respondents' company sizes

      Just me
      7%
      2-100 employees
      39%
      101-1000 emp.
      17%
      1001 or more emp.
      34%
      Not working right now
      3%
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.

      Survey respondents' area of focus at work

      Products or features, for customers of my company
      78%
      Internal tools, for other employees at my company
      9%
      Systems and services, for other engineers and designers at my company
      7%
      Technical infrastructure, for developer operations at my company
      2%
      Other
      4%
      Including internal tooling, financial modeling, data analytics, or metric reporting, marketing, wearing mult hats, and doing multiple/all of the above
      About the sample: 301 people who took our survey, between April 19th, 2021 and June 3, 2021. The sample represents engineers, PMs, designers, researchers, data scientists, managers, founders working at companies that range from small startups to large enterprises.