Directing and managing systems

Hostile Sheep has worked with dozens of organizations to design systems their customers love. After a decade of working with a wide spectrum of organizations, from fortune 100 companies to startups to charities, we've identified some patterns regarding how organizations structure their teams, how they design systems and who's responsible for making it all happen.

The organizations we've worked with have all sorts of structures, which we may talk about in a future post. To simplify things, we specifically want to share some patterns regarding teams; even more specifically, those teams we've helped to build systems, services and products. 

The overarching pattern we've observed and want to share in this post revolves around an attractor landscape we've identified. The teams we've worked with tend to sit somewhere within the above 2x2 matrix, which has two continuum axes: (x) the horizontal axis represents a continuum from a 100% focus on discovery to a 100% focus on delivery, and (y) the vertical axis represents a continuum from a 100% focus on information to 100% focus on products. 

To set the stage a little better, let me explain what each side of the matrix represents:

Information represents critical components of most systems, it includes all the data, content, and knowledge that is produced, used or communicated within the system. Information can both support products/services within a system and be an independent component of a system, unto itself.

Individuals that belong to high-performing (effective) information teams tend to be attracted to the information space and repelled from the product space for a few reasons:

• An interest in creating content
• A passion for communication
• A passion for education and training
• Skillsets in research and analysis
• An interest in strategic direction

• A disinterest in direct market impact
• Preference for conceptual work
• A dislike of fast-paced environments
• Lack of interest in technology
• Lack of skills in UX

Products and services include both the visible and invisible; including physical goods, digital components, experienced and supporting services. These are outputs and activities delivered to users, customers or other system components.

Individuals that belong to high-performing (effective) product teams tend to be attracted to the product space and repelled from the information space for a few reasons:

• A desire to impact the market directly
• Enthusiasm for problem solving
• A passion for collaboration with cross-functional teams
• A desire for a dynamic work environment
• An interest in technical development

• Limited interest in content creation
• A disinclination toward quantifiable outcomes
• A dislike of research-intensive roles
• A desire for fast-paced results
• An inclination toward visual designs

The problem space encompasses all aspects of the problem being addressed. It includes the needs, pain points, and challenges that the target users or system components face. Understanding the problem space involves gathering and analyzing data about the current state, user experiences, and system limitations.

Individuals that belong to high-performing (effective) discovery teams tend to be attracted to the problem space and repelled from the solution space for a few reasons:

• A passion for research
• Empathy for users/customers
• An interest in strategic thinking
• Apprehension for complexity
• Curiousity; especially regarding root causes

• Overwhelmed by rapid changes
• A lack of interest in implementation
• Impatience with iteration and CI
• Aversion to friction felt by cross-functional teams
• Discomfort with ambiguity and "fuzziness"

The solution space involves generating, evaluating, and implementing solutions to the problems identified in the problem space. It's about creating actionable strategies and designs that meet the needs of customers and the system.

Individuals that belong to high-performing (effective) delivery teams tend to be attracted to the solution space and repelled from the problem space for a few reasons:

• An inclination toward creativity and innovation
• A desire for tangible results
• A love of collaborative work
• An interest in rapid iteration and CI
• An enjoyment of recieving feedback and critiques

• A disinterest in abstract problems
• Impatience with prolonged analysis
• A preference for action over thinking + discussing
• A discomfort with indecision
• Lack of enthusiasm for scientific rigor

So, teams tend to become really effective when the team topology consists of individuals that aren't struggling against attactors and repellers in order to get their jobs done. The individuals that form the team structure tend to develop a preference for working in one quadrant (or another), but tend to become uncomfortable being asked to continuously work in multiple quadrants. 

This doesn't mean integrated teams aren't beneficial and doesn't necessarily mean that standard team topologies are ineffective. It may mean that some minor changes can significantly improve the way organizations direct and manage their systems.

Many of the integrated teams we've worked with include a director of the system, or directors of products/services within the system. These directors tend to focus on establishing and communicating a vision and strategy. They also tend to be concerned with things like team topology and individual coaching/mentorship. (i.e., they want to help the people within the teams be as effective as possible.)

These directors may oversee a single team or may oversee multiple teams but each team tends to focus on one aspect of the system (or product or service). The director tends to communicate customer and organizational problems to the team; generally to "team leaders" such as product managers, content managers, lead engineers, etc. 

These team leads aren't usually leads in the sense of being leaders of the team (i.e., people managers) but lead the aspect of the system the team is responsible for. For instance, an integrated product team may be responsible for the "sign-in" functionality of the system. As a team lead, the individual is typically responsible for some aspect of the DVF (desirability, viability, feasibility) framework and are typically the first people to be presented with problems and opportunities regarding the aspect of the system they're responsible for. Thus, these leads tend to operate in the problem space.

Conversely, these integrated teams include a role (or roles) that are responsible for designing and implementing solutions to the problems. These roles are firmly entrenched in the solution space. And thus, we were often witness to these integrated teams becoming really great in the problem space OR really great in the solution space; sometimes, we'd observe that the team would fail to become great in either space but mediocre in both. 

Enter the parallel team topology. We discovered this type of team completely by accident; in fact, it wasn't purposely designed. The organization wasn't aware it existed until we identified how their top-performing teams operated. In most cases, these teams were self-formed. (i.e., they were given the freedom to self-organize and the structure wasn't officially documented.) 

This structure is very much two teams within a team. The team is still directed by someone who is responsible for the vision and strategy; who may be communicating important problems and opportunities to the team. Within the team, there are two groups (or guilds) that focus on the problem space OR the solution space. In many ways, these groups are self-managed teams in their own right. 

Each group functions independently when "working" but collaboratively when in "feedback loops". The concept behind the guild feedback loop model is a post of it's own, but they happen on a regular cadence and are usually facilitated by the director, who helps ensure problems and solutions are strategically sound and are moving the system toward the established vision.

This post is starting to get long, so I'll end it here. I think this introduces the concept well enough. I hope to add new posts that dive deeper into the concepts, frameworks, processes, and results experienced by parallel teams that we've worked with.