Organizational Debt

Continuing one of my favorite themes in this blog, of using technical metaphors to explain organizational issues, I happily came across one of Steve Blank‘s recent posts:

Organizational Debt is like Technical Debt, but worse

Steve’s definition of Organizational Debt is short and simple: “all the people/culture compromises made to “just get it done” in the early stages of a startup. ”

Just like technical debt can hinder your ability to scale your product, organizational debt hinders your ability to scale your company.  Accruing these debts is sometimes the right business decision to make. But you need to be aware that you’re taking them on, and have a well defined trigger for identifying when you should stop whatever else you’re doing, and invest the time and focus in refactoring them.

Onboarding, training, culture and compensations, are a few examples of organizational systems that are likely to accrue organizational debt at the early stages of a startup.

A secondary theme that Steve calls out in his piece, is also worth noting: VCs tend to be not particularly good at helping their companies identify organizational debt and refactoring it. Fred Wilson also tangentially acknowledges that challenge in his “What VC can learn from PE” piece.




Organizational Debt

Open Space?!

The “open space” physical space architecture, a core staple of modern tech/startup culture, seems to be getting some healthy criticism , over the last few months in particular. Representative examples can be found here and here. Responses arguing the exact opposite are abundant as well.

So who is right? Is open space the worst productivity-killer ever invented? Or an essential environment for collaboration and innovation?

Fortunately, science and a some smart people can shed light on a perspective that seems closer to the truth.

On the one hand, serendipitous interactions (which I previously covered here), a true accelerant of innovation, increase when people from multiple disciplines interact. On the other hand, open-office plans seem to reduce productivity and satisfaction (though there’s some evidence suggesting otherwise).

As it is almost always the case with complex problems, and human interactions is definitely such problem, the solution is more nuanced:

  1. A physical architecture that is not aligned with the company’s culture will do more harm than good. You would not reap the benefits of an open space layout in a culture where employees feel judged based on the hours they spend in the office. Similarly, cubicles will not lead to productivity increases in a culture that champions collaboration and teamwork. Other cultural guidelines around noise, presence and use of space can have a meaningful impact as well.
  2. Regardless of the broader culture, neither “extreme open-space” nor “extreme private-spaces” seem to offer a compelling trade-off of productivity and innovation.  Both research (1, 2), and my own personal experience, suggest that optimal results require a space that has a mix of collaboration areas, quiet zones, team/project spaces and private nooks. If you’re looking for a real world example, the folks at TargetProcess wrote a great post about their new office space and how they want about designing it. For those of you who are more visually-inclined, here’s a quick teaser from the wonderful work that they did:


Open Space?!

Holacracy or Humacracy? (Book Review)

Holacracy has been on my radar for the last couple of years as an organizational paradigm that’s worth further exploration. I’ve covered some pieces of it on this blog as well.

I was thrilled to learn that Brian Robertson, Holacracy’s creator, has finally written a book about it, and was really looking forward to reading it:

Holacracy: The New Management System for a Rapidly Changing World

If you have no idea what Holacracy is, I won’t suggest jumping straight to the book, but starting with this short article instead:

Here’s Why You Should Care About Holacracy

The book provides the most holistic, yet still readable, description of what Holacracy is really all about (pun intended). Though it still leaves much to be desired (which we’ll get to in a second), it does a great job illustrating how governance and tactical meetings work and touching on some of the less known aspects of Holacracy such as its approach to strategy and to deadlines, both strongly resonating with me. The aspect that would have probably benefited the most from further exploration is the circle-based org structure. It doesn’t address some of the key org design challenges that exist in traditional hierarchical structures, like the need to alternate organization and focus by function, product/service and customer/region. It also enacts a meaningful organizational constraints that doesn’t get acknowledged: if each sub-circle is represented in governance and tactical meetings by both a lead-link and a rep-link, it puts the limit on the number of sub-circles within a circle at about 4-5. Otherwise the number of people attending the meeting quickly jumps to over 10 people, which makes them exponentially more challenging to run.

Sadly, my high level takeaway is that Holacracy is an exciting but incomplete paradigm. And there’s some reason for pessimism since this omission was made by design. Let me explain:

Many of the principles and concepts that Holacracy is based on and consists of strongly resonate with me: roles as living and evolving entities, the radical distribution of authority through the circles-based org structure, the unique and highly effective governance and tactical meeting structure, even thinking about strategy as a set of heuristics rather than a high-level, executable plan.

The one principle that Holacracy takes too far, in my opinion, is the decoupling of “role from soul”. Holacracy accurately observes that under the traditional paradigm, four “spaces” are too tightly coupled:  the person space, the role space, the tribe space and the organization space. A good example is the traditional manager’s job being simultaneously responsible for both for the business outcomes accomplished by her employee (role space) and her employee’s professional growth and development (person space). The solution that Holacracy prescribes is radical decoupling, ignoring the fact that in cases of extreme decoupling, misalignment will lead to chaos. Holacracy explicitly takes the “human spaces” (left column, person+tribe) out of scope:


Or, to use a more familiar diagram to the readers of this blog:


Dealing with “human spaces” problems such as hiring/firing, compensation, growth, etc. is not part of the Holacracy “operating systems” but mere “add-ons/apps” that each business should figure out on its own, once they adopt Holacracy. Yet at the same time, it’s been acknowledged that Holacracy is at odds with traditional “human spaces” solutions, and the friction between the two is a key cause for some companies attempting to adopt Holacracy but failing to successfully do so. To go back to our manager example, Holacracy offers clear guidance on what to do with half of her traditional responsibilities, but leaves practitioners completely on their own about the other half. To me, that sounds like a classic case of mistaking a bug for a feature.

A fix for this bug, would require viewing the organization as a sociotechnical system, acknowledging that it has a human component that cannot be fully decoupled. The human systems that align with the process components of Holacracy have to be an integral part of the Holacracy “operating system” rather than an add-on “app”.

Note that none of this invalidates any other principles and concepts that are already an integral part of Holacracy. I am confident that Holacracy is a superior organizational paradigm compared to the traditional one. I’m just disappointed that its creators decided to “call it done” and draw the operating system/apps line where they did. I fear that only addressing half of the problem space will have a substantial negative impact on its adoption (and success) rate. To use another software metaphor, they seem to be building the right product, I’m just not sure they have a Minimum Viable Product. Yet.

Holacracy or Humacracy? (Book Review)

The Vice President of Business & People Operations

This post builds on a previous post in this blog, where I made the case for having architects for organizational systems. Under this paradigm, business outcomes hinge on the interaction between 5 sub-systems: org structure, incentive systems, work systems, collaboration systems, and people systems.

The Table GroupPatrick Lencioni’s consulting group, argues that “organizational smarts” – strategy, technology, marketing, finance, etc. – is no longer the driver of competitive advantage, since intellectual ideas are not a sustainable differentiator in an age when information is ubiquitous. Therefore, what truly matters is “organizational health” – minimal politics, minimal confusion, high morale, high productivity, low turnover, etc. I’d argue that even “healthy” is not enough. What we really need are organizations that are “fit” to deliver on their mission/business outcomes. All athletes/top performers need to be healthy. But a weight-lifter and a cyclist need to be fit in different ways in order to be the best in what they do.

Which brings us back to the 5 systems. Organizational fitness is reflected in the way these systems work in concert to drive the specific business outcomes an organization is trying to accomplish. And, without falling into a recursive trap, building and maintaining organizational fitness is then a business outcome in and of its own. Therefore, we must ask ourselves: since org design is a key system that enables business outcomes, are businesses organized in a way that enables them to build and maintain fitness?

The good news for the Table Group, and the bad news for almost everyone else, is that the short answer is: no. We know from Conway’s Law that the way we divide and assign responsibilities in the organization has a material impact on its function. A typical organization has departmental heads for all the “organizational smarts” disciplines: a head of marketing, a head of technology (R&D/CTO), a head of finance, and so on. Yet “organizational fitness” is not expressed in the organizational structure in any material way. Responsibility over the 5 systems is typically no-one and everyone’s job, so it’s no surprise that many organizations are not organically poised to build and maintain a high level of organizational fitness. The one exception to this rule is people systems, which have a well defined owner, at least in theory – the head of people. But that’s a story for a different blog post altogether.

So perhaps it’s time for organizations to revisit the traditional structure of the executive team, and consider whether an alternative structure can better express the growing importance of organizational fitness as a critical discipline driving competitive advantage.

The Vice President of Business & People Operations

Organizational Systems Need Architects Too!

This post builds on a lovely framework, I first encountered in a blog post by Michael Robillard at LeadingAgile:

Michael argues that achieving the desired business outcomes hinges upon the interactions between five sub-systems:


Org Structure – the structure of power and authority to facilitate decision making

Incentive Systems – rewards for individual and group performance

Work Systems – how people get work done in the organization

Collaboration Systems – systems to overcome the friction to collaboration introduced by the org structure

People Systems – hiring, firing, development, HR systems – both tactical and strategic

This perspective strongly resonates with me, and looking at various organizations through this lens reveals a very interesting opportunity. In many organizations, these systems are managed in one of two ways:

Either in a completely grassroots, ad-hoc, organically evolving manner. (the Shadow IT phenomenon comes to mind)

Or in a completely top-down manner, being wholly owned and operated by a functional department (IT, HR, etc.) with sole authority to make changes to the system.

Neither of those approaches work well. While the former often leads to increased variability and complexity that poses massive constraints on scaling the systems, the latter often leads to stale, disjointed systems with very limited flexibility and adaptability. In both cases, over time, the systems become less effective in driving the desired business outcomes.

If you are a software developer, this may start to sound all too familiar. Because, the problems the exist in organizational systems and the way they are managed, are very similar to problems the exist in software systems and the way they are managed.

Fortunately, this also means that we can draw on the parallels in the software world for potential solutions, to enable the broader community of employees to contribute to the on-going evolution of these systems while at the same time, not jeopardizing their structural integrity and effectiveness.

Enter the role of a “system architect”, as the good folks at Spotify describe it (they call it a “system owner”):

“The System [Architect] is the go-to person for any technical or architectural issues related to that system. He is a coordinator who guides people who [modify] that system to ensure that they don’t stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability  and [change management] process. The System Architect is not a bottleneck or an ivory tower architect. He does not personally have to make all decisions, or [make all modifications], or [handle all change management efforts]… We also have a Chief Architect role, a person who coordinates work on high-level architectural issues that cut across multiple systems. He reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with our architectural vision”.

One of the key challenges with adopting this systems approach to the various organizational components, is that it significantly raises the bar for the role that the “traditional” owners of those systems are expected to play in the ongoing evolution and management of those systems. However this, in my mind, is an investment that is well worth making.

Organizational Systems Need Architects Too!

Engineering Serendipity

“If so many discoveries – from penicillin to plastics – are the product of serendipity, why do we insist breakthroughs can somehow be planned?”

The short answer to this question, according to Greg Lindsay, is “because it can be planned”. To a degree of course.

In his essay, Greg covers the aspects of physical structures, organizational structures and networks that can foster or hinder reaching a serendipitous mindset.

More here:

Engineering Serendipity


Engineering Serendipity