How we designed the engineering team at Nebula

For a software (now cloud) company like Okra, Engineering has always been at the heart of our ability to build amazing products. We strongly believe that the best team with the best product will win.

We still do, but it’s not always that simple.

Humans are complex creatures: opinionated, driven, and smart. Put us together, and we either create magic or madness.

Even the best teams need structure.

When we started, we kept a simple engineering structure. Today, we have something quite… unusual, but it works for us.

Here’s how we got there.

Where we’re coming from

In the early days, like most startups, Okra was made up of mostly full-stack engineers, with a few specialists in DevOps and Mobile Development.

As we grew, we naturally split into larger teams: Frontend, Backend, and infrastructure. The Product manager acted as an intermediary between teams, ensuring client needs were translated correctly into designs and implemented perfectly in code. This structure worked for a while, but as our customer base grew and the complexity of building a universal financial API connector increased, cracks began to show.

The problem with the old

Our old structure had its strengths, but it started to create bottlenecks. Teams waited on specs, designs, and approvals. Our strongest engineers were concentrated in one team, so when complex tasks arose elsewhere, we had to shuffle people around.

Any engineer will tell you: context switching is expensive.

The biggest issue though, was how disconnected engineering had become from our customers. Feedback flowed almost entirely through product managers. In the early days, everyone joined client demos. But as we scaled, that direct connection faded.

We knew we needed a change. When we decided to build Nebula, we saw it as an opportunity to rethink how our engineering team worked. After some experimentation, we landed on a structure that’s been a game-changer for us.

The teams and their roles

We kept some elements of the old structure but reorganized into six core teams:

1. Frontend Team: Responsible for the Nebula dashboard and user-facing interfaces.
2. Nebula API Team: Builds the core services powering the dashboard and client SDKs, and handles the core business logic.
3. Nebula Cloud Service (NCS) Team: Manages the core cloud and platform integrations that serve the Nebula API.
4. DevOps: Manages the infrastructure for all our applications, deployments, CI/CD, observability, and internal tools.
5. QA: Tests every edge, flow, and assumption—and even helps us see through the eyes of new users. More on that later.
6. Docs: Converts internal documentation into clear, developer-facing guides.

Each team has a distinct role, but they are deeply interconnected. These teams work in tandem to deliver a cohesive product, but their collaboration is structured in a way that minimizes dependencies, while delivering solid work on time.

Design-first approach

We follow a design-first approach to ensure each team is aligned and can work independently.

Tactically, this means:

1. We plan for the quarter and work in two-week cycles. Based on customer interviews and feedback from sales and marketing, we add features to our roadmap and select features to build in the current quarter.
2. At the beginning of each quarter, we take about 3 weeks to plan and scope product features. Sounds like a lot, but as a small engineering team, we’re aiming for precision. Unknowns and misalignment take away momentum, and can easily derail the company roadmap. It also helps reduce scope creep. The NCS team, and sometimes the Nebula API team, conduct this thorough research and create detailed documentation and PRDs.
3. Armed with the research and PRD, the design team creates wireframes, which are then reviewed by all engineering teams to ensure alignment. When we feel we have a solid understanding of what needs to be built, and with the research and PRD as our guide, each team independently begins executing on their deliverables. Details become more refined and clear as screens are marked ready by the design team. It also helps that our design team has a ridiculously high turnaround time. You can read about how we designed a developer-first console on our blog.
4. The frontend team integrates against the API specifications in the documents, often collaborating with the design team to resolve UI/UX edge cases.
5. The Docs team translates our internal docs and PRDs into clean developer-facing documentation—ensuring everything we ship is well understood, both inside and outside the company.

A written, version control source of truth has been essential to understanding the history behind technical decisions and creating transparency company-wide. We leverage Notion for this.

Shared responsibility

Engineers and designers take complete ownership of the product development process. Engineers define the scope of the work; QA and Design define quality. This structure encourages direct customer engagement—engineers often join client calls, ask questions, and gather firsthand insight.

Compliance, Security and QA

As a cloud platform with financial integrations, security isn’t optional; it’s foundational.

• NCS owns compliance for every integration.
• API enforces policies at the logic layer.
• DevOps builds tooling and guardrails to support it all.
• QA stress-tests every path and edge case.
• Engineers stay accountable for secure, reliable code.

Security is not a checklist. It’s a team-wide mindset.

Working with sales & marketing

Taking full ownership means engineers have to do their own information gathering, including talking to users. This is great for the sales team, and clients, as we are always building according to real direct customer interactions.

We've also integrated our QA team with marketing in an interesting way: QA team members now create most marketing videos, recording user flows from a first-time user perspective. This approach catches subtle usability issues that technical testing might miss—unintuitive workflows, misleading copy, and other friction points that are technically correct but frustrate users.

Tools we use

To make this work, we leverage a few key tools

1. Notion: To document our research and PRDs. Notion is also great because of it’s collaboration tools like commenting, suggesting features and the ability to see previous versions of a document
2. Linear: Our product management tool. A fantastic piece of software that helps everyone know what each person is working on
3. Slack: We try to reduce the meetings we have (still a work in progress), but when we’re not on Google meets, we are sharing async via Slack
4. Figma: For fast, iterative design reviews.
5. Github: For everything code; clean commits, good reviews, and clear ownership.

Unexpected benefits of this structure

While we expected this structure to reduce bottlenecks, we've been pleasantly surprised by several additional outcomes:

1. Heightened ownership: Engineers demonstrate stronger accountability for the end-to-end product experience
2. Faster decision-making: Removing intermediaries has accelerated our ability to make and implement decisions
3. Improved documentation: A robust writing culture has emerged that preserves knowledge and improves onboarding
4. Team satisfaction: Engineers express greater pride in their work under this new structure

Of course, hitting deadlines and shipping more, also feels pretty great.

Future experimentation

This isn’t our final form. We’re still refining the process, especially around reducing recurring meetings, and finding the right balance between product management and technical work. But the results speak for themselves: we’re shipping faster, and our engineers are more engaged and proud of their work.

In the end, your organizational structures should serve your company's needs, even if that means going contrary to industry standards. By designing our team structure around our unique challenges and goals, we've created an environment where engineers can do their best work while staying connected to the customers they serve.