Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
>400 subscribers
>400 subscribers
Share Dialog
Share Dialog
Many of the high growth companies in our portfolio have run into scaling issues. There is a lot of information out there on various technical approaches to scaling. What most of those leave out is the interaction between the choice of architecture and organizational scaling. Some architectures lend themselves much better to organizational scaling than others. A horizontal approach with a Data Access Layer, a Business Logic Layer, and a Presentation Layer suffers from a lot of organizational coordination overhead. To implement new functionality the various horizontal teams need to coordinate so that anything can get done.
I am therefore a big fan of a services based architecture, which takes more of a vertical approach to dividing up systems. For instance, most web sites and services have a concept of a user profile. In a services based architecture everything having to do with user profiles might be encapsulated in one service (create a profile, retrieve a profile, etc). Organizationally it now becomes possible to have a team that’s in charge of the profile service. That team can make changes to the service implementation as long as the changes don’t break the service API. In fact, the team can even enhance the functionality of the service by adding new methods to the API. This allows for much better organizational scaling as innovation no longer requires nearly as much coordination. In addition to innovation by each service team, it’s also possible to innovate by combining the existing services in novel ways to deliver end user functionality.
Many of the high growth companies in our portfolio have run into scaling issues. There is a lot of information out there on various technical approaches to scaling. What most of those leave out is the interaction between the choice of architecture and organizational scaling. Some architectures lend themselves much better to organizational scaling than others. A horizontal approach with a Data Access Layer, a Business Logic Layer, and a Presentation Layer suffers from a lot of organizational coordination overhead. To implement new functionality the various horizontal teams need to coordinate so that anything can get done.
I am therefore a big fan of a services based architecture, which takes more of a vertical approach to dividing up systems. For instance, most web sites and services have a concept of a user profile. In a services based architecture everything having to do with user profiles might be encapsulated in one service (create a profile, retrieve a profile, etc). Organizationally it now becomes possible to have a team that’s in charge of the profile service. That team can make changes to the service implementation as long as the changes don’t break the service API. In fact, the team can even enhance the functionality of the service by adding new methods to the API. This allows for much better organizational scaling as innovation no longer requires nearly as much coordination. In addition to innovation by each service team, it’s also possible to innovate by combining the existing services in novel ways to deliver end user functionality.
No comments yet