I've been professionally writing software for over a decade, and I've seen quite the spread of workplaces for product teams. A large corporation, academia, start ups, open source, and scale ups. A relatively wide range of experiences.

Throughout the years, I thought that tools and systems mattered more than anything beyond your wildest dreams. You rise and fall to the quality of your systems, and you're only as good as the mastery of your tool kit. There is some truth to that, but I was forgetting to consider two areas: culture and place.

Culture is the more obvious of the two. I think culture is the running average, over the past 60-90 workdays, of your company (or team) transmissions. Both internal and external.

Culture changes as a company's time horizons multiply, stretch, and shrink, and it's how people influence each other. Culture is what happens when people are watching each other all the time. "Employee of the month" is on the wall because of culture. It's the experiments and the mistakes in the small that permit us to gain confidence to do it at a larger scale, because we've learned the ways people like to do things around here.

Almost any tool works well when the culture is good, and almost any tool works poorly when the culture is bad. Culture supersedes tools.

Place was much less obvious.

I recently watched the television show, The Bear. I love the scene where Carmy, a world-class chef, is being timed in the kitchen to see how fast he can go from station to station, pretending to plate a dish as if he was running dinner service. His goal was to plate the imaginary dish in less than seven seconds.

Try after try, each run took him exactly seven seconds. No matter how fast he thought he was moving, or how hard he pushed, the place he was operating in dictated the time he spent. It capped his ability.

This situation illustrates the concept of mise en place. Where you put things matters, because that placement guides where and how you and others get things done. We should be thoughtful about it. Place influences communication, information distribution, and a sense of achievement and ownership. It facilitates the flow and blending of creativity and effort; it is where we rise to the occasion, and how we follow through.

When a place makes a task effortless, it feels magical.

The thing is, there aren't that many tools and systems that feel magical in product development today.

So what if there was such a place?

A place that brought people together such that culture was beside product. We could have less digital walls between each other.

What could a product like this do? What would it look like?

The final piece of inspiration for me to start working on this idea was this video of Virgil Abloh talking about designing the room students learn in.

If I put this candle in an all-white gallery space, it looks like a piece of art. If I put it in a garage, it looks like a piece of trash. [...] I often use this analogy in design. I could either design the candle, [...] or I could just design the room that it sits in.

– Virgil Abloh, the late founder & CEO of Off-White, artistic director at LVMH

What if we redesigned the room our code sits in? Could that lower some digital walls and create a new place?

So I decided to build Casa to test my assumptions about what it could mean to bring mise en place to the world of product engineering.

Finally. This place had everything I needed and wanted.

I could write my design docs, notes, message teammates, push code, run workflows and applications (application deployment not included in the MVP 😅) such that I could carry conversation and observe activity throughout the entire software development lifecycle (SDLC).

This felt so much better than before. A tighter feedback loop.

Before, I felt like Carmy. Constantly running from station to station to work with other chefs just so I could ship my product to the customer. And I couldn't go any faster no matter how I tried to adjust each station! My kitchen just wasn't designed for it.

In fact, until now, that kind of place didn't even exist. There are a couple of companies doing something similar, but they're using the same language that engineers use. I find this interesting because engineers aren't the only kinds of professional people contributing to software that has to be shipped to customers.

There are various types of designers, product mangers, and business stakeholders that also care about the product that's being shipped, how customers are using it, and how well the team is executing. We all need a shared language in this new place.

So, after a six-week MVP build phase before the 2023 end-of-year break, I gradually on-boarded some friends, developers, and tiny teams (less than five people) to test and review Casa.

I quickly learned that small teams didn't need Casa. They thought it was cool, like me, but their culture superseded the need for it.

Their workplace was already fluid enough, and often times, their teammates were just a call or Slack message away from solving the problem for a customer and shipping that change.

Team after team, developer after developer, after about a handful of reviews, I found a common theme:

This looks useful for when we're bigger.

When we're bigger.

My hypothesis that Casa would be perfect for smaller teams was totally invalidated and I had to refocus my minimum viable segment to whatever "bigger" might mean. Bigger teams, bigger products, maybe bigger problems?

After speaking with about thirty professionals across engineering, design, and product functions from companies like Google, OpenAI, Duolingo, Lyft, Meta, Spotify, BCG DV, NVIDIA, and more, bigger actually meant: our teams are building across multiple time horizons.

These time horizons were separate timelines, milestones, and implications on what products needed to be delivered when, and the driving factors behind it.

Turns out those driving factors come from decisions from many different kinds of stakeholders. Decisions made about business models, engineering improvements, how someone fixed a bug, why a project was canned, why something was changed, etc. Not a single professional I talked to could specifically reference a single, global, source of truth for logging the decision making process. Some professionals described environments that were more streamlined than others, and the more streamlined organizations and teams often prioritized dogfooding, and were mostly tool-agnostic. Some organizations even had Jira and Linear, and let teams decide which tool was best for them to manage their task management.

Culture superseded the tools again, and showed that dogfooding made the need for that global decision log less necessary due to constant product usage and focus. The playing field was set so there was no guessing about the source of truth because the source of truth was the product.

So what if there was a product that created a place that made dogfooding the default methodology?

What if we had a way to run back the tape, like professional soccer players re-watch games to learn what worked and didn't work? What if product development was an immersive team sport?

The point isn't to tell professionals how to be professionals, the point is to let them be professionals how they need to be, and make sure the culture around them supports information distribution such that they know the right things at the right time so they can make their best effort to do the right thing.

This is the single most important factor for a product team's success: solving the right problem for the right customer at the right time.

So where do we go from here?

The insights I've gleaned from my interviews, and my intuition tell me that it's time to re-imagine the room the code sits in so that dogfooding culture can form around product engineering teams naturally.

I believe the need for this new kind of system is heightened today, and will only become greater, because the systems for product engineering today are not designed for a future of AI augmented workplaces. There's a massive opportunity to reimagine the way we work from the ground up.

My vision for the future of product engineering is an engaging, expressive, team sport.

Let's start playing on the same field, at the same time, with new abilities we didn't have before.

If you liked this post, and have perspectives you'd like to share with me about this, I'd love to hear from you. Please reach out to me via the links below.