Skip to main content

sakha (Business Unit)

I have a set of constraints that I follow when building business units:

  • WhatsApp Group. We have a single group for all communication. This can be within a community.
  • Github. We use Github for all code, documentation and issues.
    • Issues. All tasks are tracked in Github issues.
      • release
      • feature
      • bug
      • waste
      • pull-request
      • support
      • fire
    • Actions. All automation is run through Github actions.
    • Code. All code is stored in Github.
      • README.md. Overview of the sangh or sakha.
      • tasks.py. Task runner using pyinvoke.
      • app. The backend code written in Django and Python.
      • www. The frontend code powered by Docusaurus.
        • /one-pager. A one pager that explains the business unit and made public.
        • /presentations. All sales presentations.
        • sop. Standard Operating Procedures
          • prfaq. PRFAQ for the business unit.
          • flywheel. The flywheel and the associated processes.
          • checklists. Checklists for various processes.
          • reviews. Reviews for various processes.
            • wbr. Weekly Business Review
      • infra. Infra terraform code.
        • aws. AWS terraform code.
        • cloudflare. Cloudflare terraform code.
        • bnet-0. Internal business code.
        • github. Github terraform code.
  • Google Workspace. We use Google Drive for all documents and spreadsheets.
    • Shared Drive
      • Competitors
      • One Pager
      • Contracts
    • Calendar
      • Meetings
        • Weekly Competitor Review

Our individual business units are built using a decentralized team with a standardized technology stack and process. Each sakha is run by a small team of three sevakas.

The sakhas has a few core characteristics that are common:

  1. Do one thing well. A sakha can be explained with a single sentence.
  2. Small team. Each sakha is run by a small team of three sevakas. a. Business Lead. The business lead is responsible for the overall success of the sakha. They are responsible for sales, marketing, and business development. b. Technical Lead. The technical lead is responsible for the technical implementation of the sakha. They are responsible for the code, infra, issue management, and deployment. c. Support Lead. The support lead is responsible for customer support and operations.
  3. Independent. Each sakha is independent and can be run without any external dependencies including the Sangh.

Boring Businesses​

The problem being in proximity to San Francisco is that newness is always the rage, entrepreneurs chasing the newest gold rush. Makes sense since San Francisco started with the actual gold rush! But if we look at the companies remaining in San Fransico from the actual gold rush of 1849 the two prominent remaining companies are are Wells Fargo and Levi Strauss.

Bank and pants are boring businesses. These businesses are not going to be changing rapidly but will remain the same for a long time. sakhas should not to chase to build innovation led products with high capital costs. We build things that people need delivered at a lower cost than our competitor with exceedingly simple business models.

Boring businesses have some advantages that we can provide them:

  1. Entrepreneurs don’t find them sexy so don't work on them.
  2. The legacy players are not nimble enough.
  3. They tend to be process heavy.
  4. Costs can be driven down with standardization.

All of these are advantages that we have as a small, process oriented organization.

Definition of Done​

There is tendency in software towards enshitification. To avoid this, all sakhas will reach a point where they will be considered done. The way to determine this is if it meets the objective that it started out with. This means that a sakha has a specific goal in mind and once that goal is achieved, the sakha is considered done.

Once it is done, the sakha will continue to exist but will not add new features or functionality. It will be maintained and supported but will not be actively developed. There will be security updates and updates to any upstream API changes.

The goal is to avoid feature creep and to keep the sakha focused on its original purpose. If there is a new opportunity or idea, a new sakha will be created to address that. If this results in multiple sakhas that are similar, they can be later merged or one can be deprecated or both can continue to exist if there is a market for both.