Organizational Structure

At Cantilever we strive to maintain an egalitarian and collaborative environment. Our primary goals – client success, staff satisfaction, all-around sanity and good vibes – are dependent on clear, visible structure. Clients need results and a clear understanding of with whom the buck stops when it comes to their work. Team members need a schedule that matches their personal goals, and is clear and visible far in advance.

Golden Rules
  • Staff are organized into client teams that are not divided by geography, seniority, or role.
  • Each client has a “Strategist” who acts as their “Directly Responsibile Individual”. They also have a project manager. As much as possible, the same two people should hold those roles for all projects under that client.
  • The DRI on each project should get input from the full team as well as their leadership/management, but is ultimately allowed to make all the decisions when it comes to that client, including when to bring in Sales to discuss new work, what to charge, which staff to use, and which work to take on. Therefore the DRI needs access to all pertinent business intelligence around a client account.
  • Internally we have “Affinity Groups” to share knowledge among staff with the same roles (Design, Development, QA etc).


All project-related staff work in a single “Production” department. This department does not have specific boundaries of skill, specialty, or geography.

Team members are organized into cross-functional, client-based teams. For each client, the DRI for that client must assemble a suitable team to the client’s current needs and goals.

A team member may be a part of a single client team or many, depending on their role and capacity. For example, a designer may want to focus on one client for the duration of a project, while a support project manager or QA person may want to work on lots of accounts. Each team member’s manager, along with the leadership of the Production department, should collaborate to make sure the team member has the style and volume of work they are looking for.

Team members have the ability to decline to be on teams they don’t want to be on for personal reasons or because the work available on that project is not their favorite. However, if they decline lots of projects, we might not be able to find enough work for them. But, we do our best.

If a developer starts on a project during the build, then supports the project for a while, but then wants to move to something else, they should inform their manager and the lead project manager, and we should find different work for them. When new work comes in, we may choose to shuffle people around to satisfy specific specialty needs on a project. Staffing should always be a collaboration between the team member and various managers to ensure that people have a working schedule they enjoy and feel comfortable with.

Team members frequently join and leave client teams. A good example is a designer. For a new website, a designer will join the team for a while while the design is being done. Once it is finished, the team may not need a designer in the loop, and the designer can leave that team. If the client ever needs a new page designed for that same project, the same designer can join the team again to design that page (instead of having to brief a separate designer just because they are in a different department).

Sample Workflow

Here is a framework for how a project lifecycle goes under this approach. This would be for a new website lead.

  1. A lead comes in to our Sales team.
  2. Sales sells a Diagnostic project to the client.
  3. Prior to conducting the Diagnostic, Sales works with the leadership of the Production department to establish a staffing plan for the project. We would choose a single “Directly Responsible Individual” (DRI) for the project from among the project team.
  4. The DRI joins Sales during the diagnostic as a “consulting” member of the diagnostic team. The DRI may elect to include more people from the project staff as appropriate. Sales remains accountable for executing the diagnostic. Sales leans on the anticipated staff, namely the DRI, to create a budget and timeline that works for everyone. Since the DRI is accountable for the final results of the project including how we do on our budgets, they must have full authority/consent on numbers that are shared with the client.
  5. 💡
    The DRI might not be a project manager. In this case we would want to pair the DRI with a PM who can help with logistics on the project but who is not ultimately accountable for the project.
  6. Once the diagnostic is complete, Sales hands the project off to the DRI. The DRI is then accountable for us completing the scope on time and on budget (even if they themselves are not responsible for the work)
  7. When the project is complete, we enter Support mode. The same DRI remains in charge so long as they are happy to do so. The DRI is responsible for staffing the project throughout, with the help of the
    Head of Production
    . If the original DRI would prefer to bow out at this stage, they easily can. This may frequently be the case when the original DRI is a designer/developer who recruited a PM to help. The PM who helped with the original build would be a perfect DRI going forward.
  8. If the DRI wants or needs to move on (for their schedule, sanity, or because the client no longer needs a specific level of expertise), they can work with the Head of Production to identify an appropriate person to hand off DRI responsibility to.
  9. Often this would mean handing off to someone who has been on the project, but has not been DRI. For example, if someone acts as DRI for a new website launch and stays on for another year helping the client support their site, a new person might feel comfortable becoming the DRI since the intensity of the project has diminished. Or, if someone is DRI for a light support client who suddenly wants a big rebuild, they may want to shift the client to a DRI who can better accommodate that kind of project. DRIs should do their best to flex to their client‘s needs but also be willing to raise their hand when a client or project is no longer a good fit.

Key Questions

What about existing projects as of our transition to this model?

We don’t have to do much about existing projects. Clients don’t care about our internal department labeling. Our projects all currently have an Artisan and an Organizer, so for each project, the pair should decide who will act as DRI from now on. Once we complete some new site projects, we can simply keep the same DRI for the subsequent retainer or Phase 2. For support work, instead of having to bounce a client around when they need a new project done, they can work with the same DRI.

How do we handle scheduling?

We now have a more flexible scheduling model. We have everyone’s commitments logged in Forecast. For someone to take on a new project (as DRI or just on the team), they need to have the time to do so. If they don’t have the time but they want to take something on, they may ask to move another responsibility they have. Client teams will have to adapt and change as the client’s needs change, and the DRIs use the shared Forecast projection to identify who they can bring in and when.

Would people end up doing 100% support?

Yes, if we never cycled people off of projects they started with, eventually every team member would be mostly in support and our new hires would be the only ones doing new projects. Some staff would prefer this, as they could gain a comfort and understanding of a few clients and make that their focus. Others who prefer new projects might want to keep moving between clients. We allow people to choose to move off of client accounts just based on preference and comfort level, so as long as we are responsive to the needs of our people, we should be able to offer them the kind of schedule they are looking for. We have a wide diversity of preferences in our group and must continue to maintain that over time.

Affinity Groups

As a separate practice, we do maintain teams of people across different client teams who are filling similar roles:

  • Design
  • Development
  • QA
  • Project Management
  • Leadership

These groups should remain in contact through the relevant Basecamp Team and Notion board and should share information and best practices. This allows knowledge to cross-pollinate through the organization and for us to have a standardized, best-practices Cantilever methodology even when working across vastly different projects.

Reference Materials

Organizational Structure (Pre Q3 2021)
Background on changes during 2021