At TextLayer, we hire experienced people and give them the space to make decisions and own their work.
It's an important part of how we operate as a team. But it also raises a question: how do we make sure people benefit from each other's thinking, rather than working through every problem on their own?
How we think together
Across TextLayer, we're exploring ideas, questioning approaches and solving difficult problems. Someone might be testing a new AI capability, thinking through an architectural decision or challenging an assumption about how a product should work.
There's value in individual expertise. But there's also value when people bring their different perspectives together.
Someone raises an idea. Another person sees a constraint they hadn't considered. Someone else has encountered a similar problem and asks a question that changes the direction of the discussion.
The original idea gets better.
Knowledge doesn't become more valuable simply because it's shared. It becomes more valuable when people question it, refine it and build on it together.
That's what we mean by compounding knowledge, and it's a big part of why we're also working on an internal system to help ideas and expertise move more freely across TextLayer.
Why knowledge sharing is more than documentation
Organizational knowledge sharing is often treated as a documentation problem: capture what people know, put it somewhere searchable and make it available to everyone.
That's useful, but it only gets you so far.
We're not short of places to put things. We have documents, code, project updates, Slack conversations and AI assistants.
What can be harder is knowing what other people are thinking about, where you might have something useful to contribute, or whose perspective could help you work through a problem.
Part of the challenge is that not all knowledge is easy to write down.
There's explicit knowledge: the things we can document, organize and search.
And then there's tacit knowledge: the understanding and judgment people develop through experience, especially when they've spent time working through difficult problems.
One way to described it: the "scar tissue" you accumulate from doing the work.
You might remember an approach that failed, a constraint that changed your thinking or a small detail that made one solution better than another. But you don't necessarily think to write all of that down. Often, it only comes out when someone asks you about it.
A document can tell you what someone decided. A conversation can help you understand how they got there.
That's an important distinction. Making information easier to access is useful, but it isn't the same as helping people develop a shared understanding.
We want to make it easier for people to find each other, exchange perspectives and work through ideas together.
How different perspectives improve technical decisions
One way to improve technical decision-making is to bring relevant expertise into a discussion while there's still room for the idea to change.
It's easy to share something once it's finished. By then, though, many of the decisions have already been made.
The more interesting opportunity is earlier, when an idea is still taking shape and another perspective can genuinely influence it.
That's part of the thinking behind our Braintrust approach.
Rather than waiting until a product brief, architectural decision or proposal is complete, we want people to have opportunities to bring others into the discussion while there's still room to change direction.
Someone might challenge an assumption, introduce evidence the author hadn't considered or suggest a simpler way to solve the problem.
And disagreement should be useful. If someone sees a problem with an approach, the conversation should help improve the idea, not simply end with an approval or rejection.
The point isn't to involve more people in every decision. It's to involve the right people when their thinking can make a difference.
That distinction matters to us. We want people to retain the autonomy to experiment, make decisions and move quickly, while having better ways to draw on the experience around them.
Making expertise visible across an organization
Sharing knowledge also means helping people discover whose experience could be useful to them.
When you're working through a difficult question, knowing who to ask can be as valuable as knowing what to ask.
Not everyone has the same experience with every problem. Someone who's built a particular type of system, tested an approach in production or spent time investigating a technical question may have a perspective that's especially useful.
But that experience isn't always visible outside the people who work with them regularly.
We're interested in how we can help people understand where expertise sits across TextLayer, who has relevant experience and why their perspective might be worth seeking out.
That last part matters. Expertise isn't simply having an opinion on a subject. There's a difference between someone who's read about an approach and someone who's worked through its trade-offs in practice.
Understanding the basis for someone's thinking helps others decide how to use it, challenge it or build on it.
And sometimes the most valuable outcome isn't finding an answer. It's discovering the person who can help you ask a better question.
How we're working to support knowledge sharing
These ideas are influencing how we're thinking about collective intelligence.
We're bringing together projects, teams and insights to make more of the thinking happening across TextLayer visible and accessible.
Insights is one part of that. Rather than treating every observation as a finished piece of knowledge, we're exploring how people can share ideas, invite different perspectives and refine their thinking over time.
Some contributions might be useful as they are. Others may need questions, challenges or experience from several people before they become something the wider team can rely on.
We want to support that process without turning it into another layer of administration or approval.
We're also thinking about how to preserve the context around an idea as it evolves, so someone encountering it later can understand not just the conclusion, but the different perspectives that shaped it.
And there are boundaries to consider. Sharing an engineering perspective is different from sharing confidential client information. Atlas needs to respect that distinction in what can be surfaced and who can access it.
We're still figuring out the right approaches, and those decisions will continue to evolve as we build and use the product.
Making knowledge sharing part of how we work
For knowledge to become more useful across an organization, people need opportunities to encounter ideas, question them and contribute their own experience. That has to happen without taking away the independence that helps small teams move quickly.
We're learning as much about how knowledge moves through the company as we are about what can shape the product itself.
We'll judge its usefulness by whether people encounter ideas they wouldn't otherwise have seen, find colleagues who can help them work through a problem or change their approach because someone brought a perspective they hadn't considered.
We don't want to capture everything people know or turn every conversation into documentation.
We want people to have more opportunities to benefit from each other's experience.
There's a benefit to clients in that, too. The people working on their products bring their own expertise, but they're also part of a company where ideas can be challenged, developed and improved by colleagues with different experiences.
Ultimately, that's what we're trying to make easier: not just sharing what people know, but making it easier to think together.
Tell us what you're working on.
