This chapter is from the book
This chapter is from the book
This chapter is from the book
Q&A
Why is there no one perfect agile Organizational Design?
If you were looking for a simple solution—“just do this organizational structure, and you’ll be agile”—you might be disappointed by this chapter. In fact, even the Organizational Designs I detail in the chapter most likely will have changed by the time you read this. As part of the research for this book, I spent time with Anders Ivarsson, the Spotify employee who wrote the initial snapshot of the Spotify model with Henrik Kniberg back in 2012. Asked on his view of the Spotify model and how it has affected the discussion on agile at scale, he was unequivocal: “There really wasn’t a ‘Spotify model’ in the first place—we just documented what we had at the time to illustrate how we organized our work; it was never meant to be a static model. It sometimes concerns me that some people think this is the one way to organize if you want to be more agile.”12
Ivarsson’s point is well taken: it wouldn’t be very agile to implement a snapshot in time (what may indeed have been a good approach for that context) and expect this to simply be the answer to future challenges. One of the key themes of this book is that unlocking agility means being aware of your context and adapting accordingly. Instead of striving to find “the perfect organizational structure,” it is more important to be open to trying new models, mixing in learning from existing models, and finding a structure that works for your organization and your business strategy. In fact, that’s how Spotify’s model came about in the first place. If you take a closer look, you’ll notice elements from matrix structure, divisional structure, and even some functional structure elements sprinkled in—together with self-organization often associated with Sociocracy. What made Spotify’s model work for the company then is not what it looks like today. Since 2012, Spotify has grown tremendously. Although some of the same structures still remain (tribes, chapters, and so on), there are now additional layers, roles, and more structure added to accommodate a different context. And it’s still evolving.
So does this mean there are lessons to be learned, that simply “trying whatever you’d like” is the way to go? Well, not quite. Although there may not be a simple solution, that does not mean there is not meaningful guidance that can help you on your way toward a more agile organization. The four simple heuristics I outline at the end of this chapter are central to all agile organizational structures I’ve seen, regardless of size, industry, or type of organization.
There’s a lot of emphasis on face-to-face communication in agile organizations. What about working from home and the concept of fully virtual organizations?
Indeed, the very first value in the Agile Manifesto spells out “individuals and interactions over processes and tools.” And the research I did for this book—as well as my own experience—indicates that, all things being equal, it is more effective for team collaboration and communication when people work together, in a shared physical space, than it is being virtual. The information we convey through subtle facial expressions, body posture, and even changes in the tone of our voice is not easily picked up in a virtual medium—and it matters. Companies have caught on to this. There is a distinct trend—even among hot tech companies—to invest more in physical workspace designs to make them more attractive for employees to stay at work and interact with their colleagues. Some companies go as far as outright banning the practice of working from home altogether. (That’s not necessarily something I’d recommend as a policy, mind you.)
That being said, everything is not always equal. Some work benefits from solitude; interactions with others can break deep concentration and be harmful. Employees can gain peace of mind and focus when they know they are available to take care of an aging parent or sick child at a moment’s notice. There are people with unique skills, knowledge, and abilities that your company may need—but who may not be looking to move to the town where your company operates. I think you see where I’m going with this.
Yes, humans tend to collaborate better when they share the same physical space. But in the face of real constraints, it is advantageous to take a more pragmatic approach to working together. Here’s what I’ve seen to be effective:
Clarify that although there is a preference for face-to-face collaboration, working virtually is perfectly acceptable as long as the team can work out the constraints. This might mean that we meet outside of regular office hours at times, we upgrade the network infrastructure to increase our bandwidth, we invest in better virtual meeting software and cameras in our home office, and so on. And we still meet face to face on a regular basis, but perhaps not all the time. Employees at Paylocity, a successful payroll company based outside Chicago, routinely work from home 2–3 days each week; this balance and flexibility is part of what helps them recruit great talent in a fiercely competitive job market.
What about fully virtual organizations, where there are no offices at all? In this case, I’ve still found it helpful to come together as a team once every 2–3 months or so. In fact, I drink my own champagne in this regard: Comparative Agility, where I work, is a fully virtual company with offices in Oslo, Sarajevo, and Silicon Valley. We still meet face to face every quarter or so, however. We try to always change venues—one time it’s Berlin, the next it’s London, and then Oslo, and so forth—but getting together for a few days every quarter has proven to be very helpful for us when we discuss larger features, articulate and shape our strategy, or simply want to have fun together as a team.
What works for your organization may be different; there is no easy answer here. The point is to recognize the constraints involved in embracing certain approaches while dampening the negative consequences and amplifying the good. And if something is not working—change it. Again. Until it works. Then keep improving.