[cebert]

I don’t understand how writing documentation or attending meetings is “trivial”. Writing good documentation is a skill and is essential to effectively disseminate information throughout an organization. Meetings, if managed effectively, fosters collaboration and helps ensure everyone is on the same page. While you may love coding, as I do, we’re getting paid to solve problems and deliver business value. Communication is a critical element that ensures business value is delivered.

[Jaedon_Proctor]

I certainly didn’t intend to undervalue the importance of strong and clear communication, which is undeniably crucial for the success of any team. However, my comment was aimed more at questioning the balance between the creation of documentation/meetings and the direct development work that contributes to shipping value.

From my experience, especially within the startup ecosystem, there’s a tendency to prioritize rapid development and iteration over extensive documentation and lengthy meetings. This approach is often rewarded in such environments because it aligns closely with the need to move quickly and adapt to market demands. In my view, a piece of well-written, efficient code that directly contributes to a feature or product often delivers more immediate value than the documentation that accompanies it. This perspective isn’t to say documentation isn’t necessary, but rather that its depth and scope should be carefully weighed against the urgency of delivering functional, value-adding features to the market.

Of course, this balance shifts as teams and projects scale. Larger teams and more complex projects require more structured communication and documentation to maintain coherence and alignment. The challenge, as I see it, is finding the right balance that allows us to remain agile and innovative without losing the thread of effective communication and documentation.

In essence, I believe in the importance of both coding and communication tasks. My aim is to spark a discussion on how we can better align our efforts to ensure that we’re not only creating value through our direct development work but also supporting that work with the necessary documentation and meetings in the most efficient way possible. How can we optimize our approach to these essential tasks to support our main goal of shipping value, especially in fast-paced environments?

[kstenerud]

This isn't a problem of just building vs meetings; it's the entire package of a company run by human beings.

There needs to be a certain amount of communication between the different "organs" of a company in order for it to run efficiently and effectively. With 2-3 people, it's easy: Just go up and talk to the person. Up to 10 people it's still pretty easy, although you now need some coordination to make sure you're not stomping over each other's stuff.

At 20-30 people, you can't get anything done without team leads/managers. And this management layer would then handle most of the day-to-day while pushing important information to the exec layer (likely 1-3 people).

Getting up to 50 people and now you need to expand the exec layer to cover finance, marketing, production, legal, mission, etc. You'll also have managers handling multiple teams, each with a team lead.

Up to 100 people and now you probably have two layers of middle management just to keep the information flow and coordination at human scale.

It's a lot like the elevator conundrum ( https://elevation.fandom.com/wiki/Elevator_conundrum ): The taller you build a building, the more space is needed by elevator shafts in order to get people efficiently between floors. There are tricks that allow you to use the elevators more efficiently, but eventually you hit a maximum. People don't like the elevator shafts taking up valuable space, but you also can't have an efficient building without them.

And the bigger your organization becomes, the more of these management and policy "elevator shafts" you need. And then your organization just starts to slow down. Innovation stagnates because it takes so damn long for an idea to make its way through the organization, get all the sign-offs, get funding etc. It's why Google can't innovate anymore, despite their attempts to bake innovation into their DNA. A quick visit to https://gcemetery.co/ is enough to show what that "innovation" policy accomplished, and demonstrates that this isn't a culture problem, but rather a human scaling problem.

And it's even worse with human scaling, because unlike elevator shafts, humans aren't cogs built to specifications. We also have to handle the chaos of different personalities and traits and skill levels in various things that contribute or detract from harmony IN THAT PARTICULAR ORGANIZATION (that's right: one org's success story can't just be transplanted to another).

So yeah, you're not just dealing with production and documentation and meetings; you're dealing with the whole package. And your solutions will have to take that whole package into account. And you'll have to keep revisiting it as your organization grows.