🕸️

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 Responsible Individual”. They also have a Project Manager.
  • 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).

Structure

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.
  5. 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)
  6. 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 . 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.
  7. 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.
    8. ☝
    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.

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 Slack Channels 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.