Decisions without managers

Decision making is tricky business. Decisions often move up and down the chain of command without the input of those best equipped to make those decisions. In smaller companies, there’s often too much reliance on the CEO, and that doesn’t scale as the company grows. Ultimately, we can easily end up in a situation where the input of those most knowledgeable is not considered.

At Particular Software, we’ve struggled with these types of issues as our company has grown, and that’s led us to rethink our organizational structure. We’ve eliminated our old departments and switched to working in small groups, bringing together those with the right skills, knowledge and context to get the work done. We’ve even gone a step further and eliminated our management positions.

Overnight, the former directors were stripped of their titles, but not one of them stormed out in protest. Instead, they chose to trust that their depth and breadth of knowledge would continue to guide staff and positively impact the organization. (And that’s exactly what happened.)

We had a general concept of how this management (or rather, lack-of-management) philosophy could look in practice, but we realized the best results could only be achieved with involvement from everyone. With our compass set in this direction, we navigated the twist and turns by placing the steering wheel in the hands of the staff. All staff members have been involved in designing this organization, shaping it to be one in which we want to work. Guiding principles keep us from hitting any icebergs while still providing plenty of room for autonomy. There’s no question the process is challenging… but it’s also liberating!

🔗Guiding principles

We know there’s no ideal structure, and we definitely didn’t get it right the first time. Our guiding principles proved to be critical, though, in keeping us moving toward a clearer vision.

• No such thing as a “right decision”: We don’t criticize or judge each other for making a decision that results in a negative or less-than-optimal outcome, nor are we excessively lauded for positive outcomes. We care about results, of course, but we recognize that there’s always an element of luck involved. If the decision-making process is sound, we have a better chance of long term success and we minimize the impact of events beyond our control.

• Fail small, learn big: Trying new ideas is critical to building the great products and services our customers expect. However, we need to balance experimentation with investment. Using a “fail small, learn big” approach, we try new ideas in the smallest way possible. We may spike new software features to see if there’s a viable option to pursue. This applies to process changes as well as software. For example, we recently tested providing peer feedback in a group setting to see if it would promote more feedback flowing through the organization. After three sessions with a small group, we decided that the idea was good, but not practical for rolling out to the whole organization. However, this experiment gave us two new ideas. These spikes allow us to fine-tune the processes before rolling them out to everyone, and potentially, having to roll them back if they don’t work.

• Humility, not heroism: Giving thoughtful consideration to the make-up of temporary teams helps mitigate the risk of relying on any one “rock star”. We do this by deliberately selecting the members of these groups, valuing those who constructively challenge the status quo. We build in checkpoints to test our assumptions.

• Timing isn’t usually critical: Have you ever been on a project, missed an artificial deadline, only to have management give you another equally meaningless one? It makes you wonder why you couldn’t have had that extra time from the beginning! We don’t believe we need deadlines to stay motivated, keep the work moving forward, and get the job done. We don’t assign deadlines or communicate them to our customers. Whether it’s a project or a task, we work together until we have the desired outcome, without artificial pressure.

🔗Building the structure

All our processes aim to assign work and decision making to those with the most knowledge and context. Here are a few highlights:

🔗Maintainer groups

To avoid a diluted sense of responsibility and ensure continuity of knowledge, each code repository is assigned to a maintainer group of three or four developers. Anyone can submit pull requests, but only the maintainers can merge them. This also gives us ample coverage for critical support cases and mitigates the effect of vacations and sick time.

🔗Task forces

Representatives from maintainer groups combine with staff from other areas of the company to form task forces where the work gets done. These are transitory teams that form as issues are raised, and disband when issues are closed. Through this proces, we are able to spread knowledge of our systems and process improvements throughout the organization.

🔗Squads

As a developer-focused business, it makes sense for our staff to help prioritize the work to be done. This happens through permanent squads, whose primary responsibility is to prioritize tasks and ensure work starts, progresses and finishes.

🔗Learning along the way

We’re learning a lot about how to improve our structure and processes as we mature. For instance, ensuring everyone on a task force has input, without stalling progress, is an ongoing challenge. Sometimes the pace of an issue can be slow and frustrating since there’s no manager to intervene if we disagree. We’re trying to improve on this by asking ourselves the following questions:

• Is this issue too big? Should it be broken down into smaller, more manageable pieces?
• Do we have the right skills and knowledge assembled on the task force?
• If we don’t agree, is there a “fail small, learn big” spike we can do to try out an idea?

🔗Slowly, but surely

Although we occasionally miss the days when a manager would overcome our indecisiveness and just tell us what to do, our staff can’t imagine going back to the old way. While the company embraced the new organizational structure and moved toward it quite naturally in the beginning, the past year has been more about making deliberate changes to tweak the model where needed. The trend is positive. Our task force model is adding the expected value and we predict it will continue to be beneficial as our company matures.

Given the pace of change in our organizational structure and processes, we’re looking forward to seeing what it will look like in the future. If you’re interested in helping to build a community of like-minded, organizational and cultural explorers, consider joining the “peopletechconnect” Slack team by emailing me at karen.fruchtman@particular.net.

About the author: Karen Fruchtman spends most of her time on activities that help make Particular staff love showing up for work each day. She happily barters her staffing insight for lessons on Git, GitHub, markdown, and other tools she never knew she loved.