Thus, startup founders will often get religion about transparency. “Our culture,” they’ll declare, “is to be radically transparent! Everything defaults to open. We hire adults, expect them to do great work, and give them the context they need.” Yay transparency!

And this works pretty well. Transparent orgs tend to delegate more effectively, have higher accountability, less politics, faster trust, and just plain ship more. Transparency helps bigger orgs adapt more quickly to the ground truth, responding to customer signals that execs might not be directly exposed to.

But, at a certain scale, radical transparency strains.

Some idle musing by the CEO sends a team off on an unimportant side quest. A well-justified compensation anomaly upsets a group who is missing background information. A 450-message Slack thread about bike shed paint color choices devolves into factions, hashtags, and philosophical arguments about the morality of taupe. #nevertaupe

And if you talk to people at a large yet highly transparent company, you’ll hear about the hazards of the relentless firehose. A thousand shared Slack channels, to start. But also a glut of docs – some critical, most unmaintained. Then there’s the meeting notes, meeting recordings, and meeting invites. Plus proposals, requests for comment, and requests to comment on your proposals’ comments’ resolutions. “So, you like information, eh? Well, have all the information in the world!” How do you make sense of all this?

While some people are tenaciously able to find, within this chaos, the important info they need to do great work, a lot of otherwise-capable people get easily distracted by information that just might be urgent, provocative, or even just… shiny. 💫

Meanwhile, allowing everybody access to every historical doc is occasionally useful, but it also presents an ever-growing surface area for leaks and legal liability. Are you sure there isn’t something highly sensitive or disagreeable in those 99,999 unmaintained Notion docs?

So, as companies grow, they tend to lock information down. Some – Netflix, Stripe, Shopify – do their best to keep as transparent as possible while still complying with necessary guardrails. Others – Apple, Palantir, Oracle – move toward a need-to-know basis, ensuring information flows top-down. With more control over information, it’s easier to ensure that leaks or internal distractions don’t derail your plans for surprising product launches and/or world domination.

Of course, every company’s culture is forged by the market they operate in, but there’s always some tradeoff here. And as companies grow, they tend to regress to a boring middle ground.

However. As with many tradeoffs, the balance has recently begun to shift.

Given this firehose, please assess my plan

Recently, we’ve seen a revolution in tools that can make better use of the firehose. Slack can now summarize your unread messages, albeit with mixed effectiveness. Tools like Glean and Unblocked can consider a mountain of your company’s data and answer important questions about it, albeit limited to the data they can actually see. And large open companies like Shopify and Stripe have internal tools that let employees’ agents query, analyze, and act on the copious data any given employee has access to – albeit with some sharp edges and exfiltration risks.

Just as LLMs are making the world’s data more useful to the world, they’re making companies’ internal data more useful to employees.

Of course, this can be misused! In some companies we’ll see further secrecy – I’ve heard of AI search tools and MCPs letting employees find accidentally-visible compensation data and other spicy docs that hadn’t been audited. I’ve heard of support agents giving customers true-but-problematic information because they surfaced it with internal AI tooling without proper training.

But as we evolve past early growing pains, and into teams and processes fully making use of this stuff, the anecdata points toward this new tooling becoming a superpower. Agents’ newfound ability to effectively query and reason about far more data than can fit into context is making the long tail of communications and docs much more useful for decision-making – but only when people have access to the relevant data.

Given that, the maturation of AI tooling will motivate companies to become more transparent.

In 2024, the cost of being internally secretive was meaningful but manageable. Although Apple keeping information need-to-know sometimes leads to waste, or important changes being slow to diffuse through layers of management, they’ve done, like, pretty well for themselves? With all the scrutiny from press, competitors, and regulators, you can see why they’ve kept it up.

But as all companies increasingly have tools that can assess, consider, analyze, and make use of all the business’ communications and documents, what kinds of org are going to benefit most? Well, the ones that let their employees access more context.

Extremely transparent orgs like Zapier, GitLab, and PostHog that might have struggled to cope with their firehoses – and who often had gaps in the data due to untranscribed meetings and decisions – will increasingly be able to leverage it. Sure, not all of it, certainly not at first. (Some of it is just junk.) But increasingly more of it. And critically, it won’t just be executives that will be able to attend to all this knowledge.

Where we ought to be

The frontend dev working on your internal admin dashboard should be flagged that the React upgrade issue they’re battling right now was just solved by the customer-facing dev team. The intermediate developer who is incensed about a company-wide tech decision should be able to build their understanding of why it was made without booking a 1:1 with the responsible Principal Engineer. Your go-to-market team should be able to “see” through to the code, developers’ conversations, and the recent decisions around a given feature, letting them give customers correct and timely information about what to actually expect from the product today.

And everybody in your company should, when it’s useful, have key company-wide strategy docs available to their agents as they make plans and decisions. And then, when a new revelation motivates the exec team to improve those docs, then bam. All the product engineers’ agents will take this new strategy into account right away. Anybody who’s worked at a large company and/or used CLAUDE.md knows this won’t be a silver bullet – deeply ingrained habits and momentum can not be simply prompted away. But as the tools and the data improve, the advantage will accumulate.

When we launched a realtime meeting agent last month, we expected to get feedback about its defaults being too open – currently, Cedarloop defaults to sharing its collaborative notes and tools with all attendees live. But instead, we’ve seen two diverging kinds of feedback: many of our users want the tool to be less visible to external guests and customers, but more open internally within their companies. Which in retrospect makes a lot of sense: decisions and actions in your team’s work are increasingly useful across your company, but your customers shouldn’t need to worry about all that.

So long story short, more internal transparency is coming.

It will take some time. Apple isn’t doomed, and just because Zapier and Shopify are already working that way doesn’t mean they’re going to instantly be turbo-boosted. But it seems a new era is coming, where siloed knowledge, information hoarding, and secrecy-by-default will become less tenable.

The firehose will evolve from a spicy distraction to a useful input to important work.

One wolf wants to craft, polish and refine – make things of exceptional quality. The other wolf wants to move fast and get feedback now.

The two wolves don’t always get along.

For years, I’ve balanced this by working toward exceptional products but constantly collecting private feedback along the way. Then, once we’ve built something excellent, something worthy of attention, we launch it to the world with appropriate fanfare. Videos, marketing campaigns, polished onboarding, and so on. “Here’s something worth trying, we think you’ll really like it.”

This totally works. At least, it works as a path to eventually ship high-quality software. Polished, usable, even delightful software.

But when it comes to building something people will pay for, it’s neither reliable nor fast.

A tale of three products

Our first product at Forestwalk was a developer tool – a platform for building and running evaluations of LLM-powered apps. We learned a ton building it, but after a few months – as we approached our first pilot projects – feedback from demos and potential first customers convinced us that this was the wrong path. It was more likely to lead us into a lifestyle business than something big. So we pivoted.

We spent a few weeks building a prototype a week, showing demos, doing customer research, and found a second promising product path.

Our second product was a productivity tool – a work assistant that could capture, organize, and rationalize teams’ tasks. We learned a ton building it, but after a few months – as we approached a public beta – feedback from private testers and our investors convinced us that this was the wrong path. It was more likely to lead us into a lifestyle business than something big. So we pivoted.

The third time purports to be the charm. But at the same time, doing the same thing over and over typically gets the same results. We need to build something profoundly useful, something people really want. We can’t keep hiding away, sending out private demos and prototypes, not fully shipping anything!

So, we decided to push harder into the discomfort of showing our work early. Just before Christmas, we decided to commit to something and work towards getting it shipped.

This third product is codenamed Cedarloop¹. It’s a realtime meeting agent. Unlike AIs that passively listen in to meetings and just write up notes after the fact, Cedar joins calls and uses “voice in, visuals out” to screen-share useful observations and perform routine tasks live during a Google Meet or Zoom meeting. The vision is to build a kind of agentic PM assistant. It can respond within a second of you talking², which – when it works – feels like magic. We’ve been learning a lot building it.

On the todo list: a simpler layout for 2-person meetings.

Recently, we started working with an excellent designer here in Vancouver who was keen to get going.

I’d like to do some user testing. What do people say when you let them try it?

Well, obviously it’s so early right now. They won’t like it. The inference and onboarding need more work. But we’ve been doing research about problems, needs, willingness to pay, and things like that.

Sure… but we should also let people try it. What if we launched now?

Well, obviously we can’t launch now. I mean… obviously.

Right?

Launching now would be embarrassing. It’s not my brand to launch something publicly that’s not ready.

On the other hand…

I keep a printed copy of Y Combinator’s list of essential startup advice on my desk. And if you know YC, you’ll know that the first point of advice is “Launch now”.

Only last month I was interviewing Brett Huneycutt, Wealthsimple’s co-founder. He had a lot of great stories, but one that sticks out is that even as a $10B company, they prioritize launching “now”, for as close as they can get to that definition. It’s not just about speed: a rapid feedback loop is a core ingredient in getting to quality.

So we launched now. As of today, people can check out our research-preview realtime meeting agent at Cedarloop.ai. With luck, they’ll report issues, inform what we should prioritize next, and tell us what problems they’d love to have automated away.

We’re only a few hours in, and yep – people are reporting issues. Linear integration had an OAuth issue. Login didn’t work in social-media webviews. We’ve been so focused on the desktop experience that we’ve let the mobile layout get janky. This is embarrassing!

But also, there’s signal. People are trying the Linear integration. Our desktop-focused app is being discovered on mobile. Folks care enough to click at all. And in a week or so, we’ll have a smoother onboarding flow than we would have gotten to with weeks of private user tests. So it’s worth the pain.

We’re going to take the feedback, follow the signal, learn and re-learn, and do better. We’ll use it to forge the best damn live agent ever – or, if the feedback peters out, we’ll know we’re on the wrong path, and find the right one.

In the meantime, there’s a lot to do.³ Back to work!

As the pace of software development speeds up, we’ll feel the pressure intensify in other parts of the pipeline: thoughtful design, critical thinking, user research, planning and coordination within teams, deciding what to build, and whether it’s been built well.

The most valuable tools in this new world won’t be the ones that generate the most code fastest. They’ll be the ones that help us think more clearly, plan more carefully, and keep the quality bar high while everything accelerates around us.

We’ve known for a couple years now that faster coding will mean non-coding work will increasingly be a bottleneck, and now it’s happening. Deciding what to build – and whether it’s been built well – was already one of the most important tasks on a software team.

But in the face of tools that can add anything to your product, desirable or not, this judgement becomes the core of the work.