🕸️

Organizational Structure

🚨

This document represents a new methodology we have switched to effective Q3 2021. You can find the prior

here.

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.

Background

Since around 2015 we have maintained a separate Support & Production department, with staff separated into teams supporting websites and teams creating new ones. At various points in that history we have frequently blurred the lines between the teams, so it hasn’t always looked like that to everyone, but the idea has been there. In 2021 we defined QA as its own department as well. We also added a second dimension with the launch of our European office. This amount of stratification and division between teams has created problems:

  • If a project requires specific knowledge or expertise, we have to hand that off between teams whenever a project changes hands. This causes challenges for the new team, as they have to absorb the requirements of the existing project and relationship and gaps in service.
  • The line between "Support" and "Production" are fluid. What about a 20 hour one-time project for an existing retainer client, or a retainer to work on a new website over a period of time? These issues have always confounded our department structure.
  • When a client changes project managers, they have to build rapport and understanding all over again.
  • Some people dislike working on the same kinds of things over and over. Others enjoy this, but those who do not need the ability to have variety.
  • People would sometimes like to remain on a project, but can’t because it is leaving their department.
  • If the company has one primary expert on a given topic, that person is underutilized in the offices/departments that they are not a part of.
  • Basing teams on geography does not make sense, but our European entity is clearly better for handling paperwork/employment of European staff.
  • Clear divisions are an impediment to growth. We may have enough work across all departments/locations to bring in a new person, but not in a single location/department. Or we may have a huge need in a department today and hire, but that department’s needs shrink soon after.

Ironically, as we have grown, the need for cross-functional collaboration has grown as well. We can accommodate more people with specialty skillsets, but can’t take full advantage of those skillsets because of division of groups by department/physical location and not by skill or interest. We have decided to modify our structure to be more flexible and common-sense.

Our QA department has already been using a model under which a QA engineer is assigned to a project for its lifespan, avoiding unnecessary handoffs and maintaining domain knowledge better. That is inspiration for our updated structure.

An important concept to understand relative to this structure is

.

Updated Structure

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

Instead, team members are be organized into cross-functional, client-based teams. For each client, the Production leadership 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.

Clarity and Consistency

We are transitioning into this model over the course of Q3 2021. As of now, all new work should be planned with this model in mind, not the prior department model. When fully implemented:

  • Clients should understand who the team is working on their stuff, and who their DRI is.
  • Each project in our project database should have a clear label showing who the DRI is and who the other staff are
  • Each project in Basecamp should show the DRI in the project description
  • 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.

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)