We are building the engineering Team of the future

At integral, take great pride in our work. A senior engineering team that thinks globally about the entire system while acting locally at the service level. Every engineer on this team is a Founding Engineer: a role that embodies ownership, collaboration, and a deep understanding of architectural tradeoffs. We are required and empowered to make frequent, meaningful contributions to the product and the company’s future.

Every engineer is expected to take a requirement, break it into smaller, testable pieces, and thoughtfully consider how their changes impact the broader platform. Decision-making is distributed across the team, with clear documentation through Linear issues and an implementation plan. We distinguish between Big-D Decisions (hard to revert, requiring team alignment) and Small-d decisions (easy to revert, made independently by engineers). This framework ensures autonomy while maintaining alignment on critical choices.

The problem with existing processes

Small teams need structure, but most abundantly available “good” advice assumes you’re managing at least 20 people.

We’ve worked with agile ceremonies designed for large teams that end up slowing down small teams. We’ve observed flat organizations with no process at all.

Large-team processes create overhead that kills velocity. No process creates chaos that kills focus.

“How We Work” is our approach to structure that scales with small, senior teams. It’s not a framework or methodology; it’s our specific, ever-changing, very personal practices that create rhythm and accountability.

All successful small teams end up building their own frameworks. They start with something that sounds reasonable, try it for a few weeks, realize half of it doesn’t work, and then change it. The best teams have processes that would make consultants cringe because they’re messy, specific, and built for exactly the people who use them. We can’t scale someone else’s solution to our problems, especially when our problems change every quarter as we grow.

Shared Ownership and Collaboration

All code is co-owned, and we actively help each other succeed. We don’t limit ourselves to one domain; one engineer may work on the ledger, AI infrastructure, a collaboration module, or the tax engine, it all depends on the need. This fluid collaboration relies on minimal friction, so we prioritize simplicity and rein in complexity wherever possible.

We document code, tips, and best practices in every repository because we know someone else will extend or modify our work. Every repository includes:

  • A comprehensive AI Generated and humanly maintained README.md file
  • adocs folder with:
    • plans holding specification documents we build for AI agents.
    • logs that track the conversations engineers have with models during the implementation of the plans.
  • Conventions.md file for AI and other tools (similar to agents.md and .cursor/rules)
  • Just scripts for repeated commands.

Larger discussions are documented, ensuring knowledge stays accessible and actionable. By maintaining thorough documentation, we also provide the context AI tools need to function effectively.

AI as a Tool, Not a Crutch

We use AI extensively for coding, documentation, and exploration, but we treat it as a tool to augment, not replace, human expertise. AI is not always accurate, but like any tool, it improves with intentional usage. Engineers are expected to critically evaluate AI-generated solutions, usually using other AI tools alongside their judgment to ensure quality. This is where the experience of a Founding Engineer shines: knowing when something is “good enough” without over-engineering is an art, not an exact science.

Culture and Growth

Our ultimate goal as a founding team is to establish strong habits and a culture of clear communication, practical simplicity, and continuous growth. We believe that with a lean, supportive, and AI-empowered engineering group, we set ourselves up for lasting success. While we don’t have formal professional development programs, being part of this team means shaping the future of software engineering. The era of large, impersonal scale-up teams is fading, and we’re building a model that values craftsmanship, ownership, and innovation.

We also recognize the importance of diversity, inclusion, and work-life balance. These are tough questions, and we’re committed to addressing them as we grow. For now, we are focusing on creating an environment where everyone feels empowered to contribute, challenge, and thrive.

How We Work: The Series

This series focuses on what actually works for engineering teams of 3-8 people:

Plan Mode, Build Mode, Deploy Mode: How Three Words Fix Meeting Chaos

Three simple phrases that drag your team back to reality when conversations spiral into the wrong dimension.

Weekly Cycles: Rhythm Without Rituals

How we structure weeks to balance planning, building, and shipping without daily standups or sprint ceremonies.

Guardian Role: Protecting Focus

The rotating role that shields the team from interruptions and handles operational issues so others can build.

Captain Role: Driving Features Forward

How one person takes ownership of feature delivery without becoming a bottleneck or micromanager.

What We Learned

Structure serves focus. The goal isn’t to follow a process perfectly; it’s to minimize context switching and maximize time spent on valuable work.

Small teams can’t afford dedicated project managers, scrum masters, or DevOps engineers, not in the AI world. Everyone wears multiple hats, so the process needs to be simple enough that engineers can execute it themselves.

Good process is invisible. When it’s working, you don’t think about it. You just know what to work on, when to ship, and who to ask when something breaks.

Core Roles

To ensure we balance innovation with stability, our team operates with two key roles each week:

  • Captain, who drives new features forward
  • Guardian, who protects the integrity of our product and user experience.

We’ll share what works for us, why we chose these specific practices, and how to adapt them to your team’s context.