Structure should begin with motivation. Not the other way around.
I recently wrote about the challenges a start-up company faces when it grows into a mature, medium sized business. Yet there’s one topic of debate within the company I work for that particularly frustrates me: Structure.
How an organization coordinates its activities and organizes itself sounds like a horribly mundane topic. It is. But that’s not why it’s frustrating. The biases for and against certain ideas, principles or frameworks are what drive me bat-shit crazy because they often get in the way of making actual improvements. Or they just make things worse. Either way, it’s a major problem when performing any work begins with structure. And since I manage a group of people that depends on almost everyone else in the company to get shit done, structure really, really matters to me personally.
Even after a year of trying to evolve the company structure into something that supports our growing organization more effectively, we don’t talk much about specific processes or workflows. We still argue mostly about the differences between departments and project teams, and how they can best serve an organization like ours. It’s like we’re stuck in an existential loop talking about David and Goliath. To summarize the popular beliefs expressed in these countless discussions: Departments are inherently bad, and project teams are inherently good. Therefore, we must minimize the importance of departments and focus on making project teams succeed. Perhaps, in the not-so-distant future, project teams will replace departments altogether and our utopian dream of the ultimate workplace will finally be realized.
Although I understand the sentiment, I vehemently disagree with that assessment.
In the early days at eyeo there was no structure — just a dozen or so people doing the work of 50. Departments and teams weren’t necessary, and would only have consisted of single individuals anyway. But by the time we were 50 people, de-facto departments had already begun to emerge as a byproduct of natural self-organization. At around 80 people, those departments were determining processes and workflows that defined our culture and how we worked. As a result, we had suddenly become a big, slow beast that was easily paralyzed by major decisions. That’s not a good thing when opportunities are scarce and competition is abundant.
Illustration 1: Departments – In the beginning there were just departments, some of which were explicit, others implicit. Projects were always ad-hoc, and work was driven primarily by the executives.
Thus we set up a task force to analyze the current structure and operational patterns. Our mandate was to come up with a better way of organizing ourselves and working together under increasing external pressures. Our goals were to improve efficiency and increase speed overall, while preserving the fundamental values that make eyeo a unique, fulfilling place to work. In other words, a small group of people were tasked with engineering a solution to a huge, complex problem that would affect everyone in the company. (No pressure!)
The real problem, many believed, were the departments themselves. Departments — especially traditional ones — are typically large, include only certain types of people, and represent the most basic, obvious way to organize a bunch of people. They are the opposite of “agile”. They often establish self-serving processes that get in the way of everyone else. And, worst of all, they are by nature exclusive (which, ironically, automatically makes them mutually dependent on one another). When thought of in these terms, departments are like giant ships on a canal that need a long time and lots of space to properly coordinate so that they’re all going in the same direction… And if just one ship wrecks, the whole fleet can go down with it. That’s a lot of risk, and tremendous overhead, to manage.
The solution, the same “many” believed, were project teams. Smaller units of people that worked on a particular thing until that thing got done were easier to manage and maintain. They could focus like a laser on limited, specific goals. They wouldn’t be so dependent on other teams if every role required was already a dedicated resource. Most importantly, they would be free to work however they wanted if they didn’t have to worry so much about external processes.
By creating project teams that could get day-to-day work done more quickly and independently, departments would then only be responsible for two things:
- Hiring the right people
- Keeping those people happy
Everyone would still have a “meta-group” they could identify with on a general level, but their contribution would have a more direct, immediate impact on project teams.
It all sounded really good at the time, even to me.
Early on we decided that all project teams should share some characteristics. For example, every team should be:
- Small (no more than 2 pizzas should feed an entire team)
- Autonomous (there should be few, if any, external dependencies)
- Self-organizing (teams should decide what they work on and how they get work done)
- Cross-functional (teams should include roles from across departments and include a variety of specialized roles)
- Flexible (most teams will have people that are dedicated all the time, and members who contribute only when needed)
Based on this criteria, our knowledge of all existing work streams at the time, and months of extensive interviews with individual employees, we proceeded to carve up the company into over 30 individual project teams (with no more than 12 people each) in addition to the 9 departments we had explicitly identified. Then we rolled out the new structure to the organization with an announcement and corresponding manifesto. We had kickoffs with each team, and gave some general guidance. By the summertime, everyone was supposed to be working within their project teams in earnest.
Illustration 2: Departments & Project Teams – We kept the departments in place, but made them all explicit. Then we added project teams to drive all the work. People from each department are either dedicated members, or occasional contributors. How work gets done is determined by the individual project teams.
So we were really surprised when things didn’t go very well. Sure, we thought, some tweaks and coaching would be necessary. But with time, we anticipated that project teams would naturally replace traditional departments and workflows, resulting in efficiency and increased “velocity”. In actual application, though, many teams were confused about what they were supposed to actually do and/or failed to make much progress on anything substantial. A few did in fact work great out of the box, but that was mostly because they were working like that before any teams were formally announced. For the most part, the majority of teams struggled to function as intended, and couldn’t resolve their issues on their own. Even after 6 months of trying, it’s obvious that something isn’t “clicking”.
As a consequence, departments have since become even more entrenched than they were to begin with. This should not have been surprising. When goals aren’t clear, processes are undefined, and help is hard to come by, people often retreat to the one group they can relate to, rely on, and get help from: their peers. And where do all their immediate peers “live” in a professional environment? Departments.
Now the debate between between departments versus project teams has resurfaced. Only this time we can’t just hope that departments will eventually go away. We have to face entrenched issues that are not easily solved by a reorganization exercise.
What was the perceived problem?
After copious reflection, I’ve come to the conclusion that we didn’t understand the actual problem we were trying to solve, and then prescribed solutions based on ideology.
We thought the problem was the structure itself. The original structure was getting in our way and slowing us down. Thus, we assumed that by arranging the parts differently, people would start to work more efficiently/effectively naturally. We approached the whole situation like a mechanic approaches tuning a car. Replace all the slow parts with lighter, faster, more powerful ones. Boom. Now you’ve got a track vehicle. Just get in and drive.
But organizations aren’t inanimate objects made up of parts. They’re living, breathing organisms made up of complex, fickle humans. You can’t just arrange them a certain way and expect better results. In the case of a company, structure is a function of its humanity, not the variable that defines it. You first have to deal with the things that make humans human. Otherwise you just end up making everyone miserable.
And that’s where we failed.
What was the actual problem?
It wasn’t until after things started going pear shaped that I remember a course I once took in psychology (shortly before dropping out of college). I had learned about Maslow’s hierarchy of needs. Whether wholly or partially true for every person, I always thought it was a simple way to figure out what drives people.
I fully believe that at the most basic level, our personalities, activities, and personal choices are all driven by one thing: Motivation. We’re not humans because we have big brains and opposable thumbs. We’re humans because of our innate, internal desires. Everything else is an outward expression of those desires. Maslow simply arranged them into a pyramid according to relative priority.
Considering that every employee at our company has their basic needs met, and a safe place to live (presumably), belonging within the company in general is thus the basis we should start from in terms of structure. We all want to belong. It’s the foundational requirement for a happy, healthy, productive company culture. Until we truly believe we belong, however, we’ll always be seeking to prove ourselves as worthy, or find ways to avoid rejection. Neither of these motivations serve a company very well in the long run, since they are essentially self-preservation instead of the long-term success of the organization.
Only once we feel like we belong can we start being our true selves. This is the basis for Maslow’s fourth layer of the pyramid: Esteem. Having “self esteem” is another way of saying that we recognize our value or contribution to something bigger than ourselves. It’s achieved only through applied, consistent actions that yield demonstrable success. We gain self-esteem from positive experiences, and garner the esteem of others by being reliable and trustworthy.
The very top of the pyramid, self actualization, is something much deeper and more complex. If all our other needs are met, we believe that we belong and that our work makes a difference, then our motivations start to become a lot less about us fitting in and more about our long-term purpose. Or, to put it another way, that’s when we start caring about our legacy. Who we really are, as individuals, matters most when there are no other external deficiencies to drive our motivations. Then we can ask ourselves, “when I’ve done and said all that I can, what actual value will remain?”
Bringing it all back to the discussion of company organization, departments, and project teams, the problems we faced were never really about structure. They were about motivation. People want to feel like they belonged and make a difference, not an org chart and manifesto. They want to be able to trust their coworkers and be trusted in return, not enforce trust through specific process and procedures. Above all, they want to know that they’re truly valuable.
In prescribing a solution based on ideological principles, we ignored the human motivations any good structure should actually support and focused too much on logic and “measurable results”.
What were the lessons learned?
Applying Maslow’s hierarchy of needs to how things worked out in reality, I now see the requirements we came up with for project teams in a different light.
Absolute size doesn’t matter
The requirement that all teams should be small was purely arbitrary, and stemmed from an ideological point of view that “smaller is always better”. However, the “right size” for any group of people trying to get something done is entirely relative. If we’re talking about a collection of close friends who are trying to arrange a dinner party, then sure, there’s an absolute maximum number. But we’re not talking about that. We’re talking about professionals who are trying to build software products. Sometimes it takes a lot of people to accomplish just one thing. And that should be okay. By forcing a requirement to keep teams small, we ended up with too many small teams who can’t get shit done by themselves.
At the end of the day, what actually matters is not size, but a common purpose… which is all about belonging.
Autonomy is relative
The biggest problem we recognized with the old structure was the labyrinth of dependencies needed to ship something. Somebody owned the goal or vision. Others owned the visual design, content, or user experience. Someone had to build it, yet another had make sure it was built correctly, and still another person had to develop the communications plan. So how do you assemble all those necessary parts into a small team that doesn’t rely on other people or teams to deliver results? (The answer: You can’t — at least not all the time.)
Dependencies are not in themselves a “problem”. The real issue is whether or not the dependent parties trust one another, and value one another’s contribution… which is all about esteem.
Self-organization is a soft principle without a hard application
Okay, so as a project team you are expected to define how you will work together, what tools you’ll use, and the priorities of things you want to work on. But how do you know if your workflow will work for everyone else in the company? Will your processes or infrastructure be compatible with those from other teams? Are your priorities aligned with the company’s larger goals or other important projects you’re not responsible for? What if you have a big disagreement and nobody is the obvious decision-maker? Suddenly “self-organizing” seems like a fragile principle that falls apart the moment you apply it.
But so what? Most people don’t really want to make all their own decisions, even if they could. (And those who do/can rarely make the best decisions all the time). Rather, they just need to know if they’re making the right decisions, in the right context, and have the full support of the rest of the organization. In retrospect, the problem we were trying to fix had nothing to do with raw power or explicit authority, but had everything to do with a sense of belonging and shared esteem.
Cross-functionality in not a problem that needs to be solved
It’s almost weird to include cross-functionality as a requirement. Of course any team performing complex work will include various specialists. If you want to build and launch a massive product update, you’ll need designers, developers, content and translation managers, quality assurance people, legal experts, and marketing/communication folks (at a minimum). Specifying that a bunch of different roles should be a part of any project team is therefore not helping anything. It’s stating the obvious.
What isn’t obvious, however, is how to ensure all those cross-functional people work on the right things, recognize when to bring in other contributors to achieve success, or ultimately reach their full potential. Only the self-actualized team can do all those things successfully.
Flexibility is an illusion
Our original thinking was that there would be a bunch of people who would be dedicated to ongoing project work, while a few others would only contribute as needed. Our intention was make sure each team had enough resources to perform their work without hogging all the resources (especially in cases when only a few people contributed to a bunch of different project teams, like content creators). In practice, however, dedicated members were always waiting on those ad-hoc resources to get shit done. And the ad-hoc resources never knew exactly what was going on and/or were rarely included in important decisions. Basically, we learned that there isn’t such a thing as an “occasional contributor”. Everyone should be considered a dedicated resource.
Why is this important? Because the most basic need a employee has is to belong. If they’re temporary, or only needed once in a while, then they aren’t actually a part of the core team… so they don’t belong. And if they’re not included in important decisions, or invited to recurring meetings, their self esteem erodes while their value to the rest of the team is questioned.
As for departments…
Departments have a bad reputation because they can often be bloated, slow, procedural, and bureaucratic. Yet the one hugely important characteristic they all share is that departments are permanent. Permanent things are stable things. And when humans get frustrated or feel insecure they tend to seek refuge in the most stable things they can find. So, on a primal level, departments are “entrenched” within our professional psyche because they are stable, and therefore predictable. Stability and predictability are foundational to one’s sense of belonging.
This is in direct opposition to the idea of project teams. Projects are temporary because they have a clear end. A team that does nothing but temporary work may feel a sense of accomplishment, but not necessarily a sense of belonging and meaning. For example, let’s say that there are 3 teams dedicated to a major product, but then the company decides that the product is no longer worth the investment. What happens to all the people who were on those project teams? They will all have to be absorbed somehow, or else fired. Neither outcome is especially appealing to somebody who just wants to know they have a permanent role in a company that values them.
And by the way, when defined and managed correctly, departments have far more value than just hiring and keeping people. For many folks, they are like an extended family who depends on one another for advice, comfort, and validation.
What’s the solution?
To be honest, I have few concrete solutions. What I do have is a deep sense that our current solution was fundamentally flawed to begin with. We should have first started with the motivations that drive people at our particular company, and then defined structures that supported those motivations while facilitating the collaboration necessary to produce consistent, meaningful outcomes. Some work is temporary. Some of it’s never-ending. But the people who do the work should always be regarded as permanent assets.
If I were to go back in time, and had total control over how the task force approached our mandate, I would start by redefining the permanent structures of the company according to shared motivations. Leaving aside the negative connotations, I’m perfectly comfortable calling these permanent structures “departments”. What I care more about is how departments are defined so that they cultivate a sense of belonging. A few ways come to mind:
- by areas of expertise (product, development, legal, etc.)
- by strategic focus (communications, delivery, operations, etc.)
- by product platforms (desktop, mobile, services, websites, etc.)
- or by geographic locations (Cologne, Berlin, North America, etc.)
Any way would have advantages or disadvantages. The important thing is that the majority of people genuinely feel they belong in their department.
Illustration 3: Departments & Functional Teams – Maybe a better approach would be to establish departments according to product platform, and then form teams based on functional roles. All work would be driven by the departments, but teams of like-minded people would determine how work gets done for each individual work-stream within a given project. Projects and products can come and go, yet everyone would still have clear goals and a permanent place where they “belong” since the platforms and functional roles would never change.
Then I’d figure out a way to facilitate both short-term and long-term work within those departments. Again, I would start with some basic motivations. Any work a dedicated group of people perform can be a few things:
Now pick two. No, seriously.
A very transparent department can be a highly effective one as well… but transparency is overhead, and so everything will take longer. Or else a department can be extremely fast and effective… but decisions will have to be made by a limited number with minimal debate (or documentation). A department can even be transparent and fast… but they’ll likely never go very “deep” when solving problems, and therefore will be less effective. Which might be okay if you can make small, iterative improvements that makes a big difference over time.
The real question is: Which of those two attributes do you value most? Only then can you possibly derive the best processes, platforms, and protocols to reinforce those values. Also keep in mind that the two most appropriate attributes might be different for each department.
To summarize, a company’s structure and its processes are extremely complex issues. When defined and implemented well, people will feel like they belong and can make a difference. When defined or implemented poorly, people will become unmotivated and unhappy. So, start with what motivates your people. Until you truly understand those motivations, any structure or process is going to feel arbitrary and prove ineffective.