We'll see | Matt Zimmerman

a potpourri of mirth and madness

Posts Tagged ‘Leadership

Scaling Human Systems: Organizational Design and Growth

This is the beginning of a series of articles about the challenges of growing an organization. I’m writing them to share some principles that I’ve derived from my own experience, as well as many valuable discussions with friends and colleagues, about helping companies grow from being quite small (say, 1-50 employees) to less small (100-500).

Every organization is unique, but all organizations face some common challenges as they grow. Human systems are incredibly complicated, and require frequent adjustment like any complex system. Any two organizations will have many important differences—such as their culture and market situation—which can (and should) influence their growth and development.

For this reason, I believe there are few if any hard and fast rules, and organizational design patterns can be difficult to translate from one organization to another. One organization’s solution can be another’s problem. Even when there seems to be a perfect fit, the process of implementing organizational change can be its own challenge

Even so, I think there is much to be learned by comparing different organizations, and much inspiration to be found in their successes and failures. Two organizations merit specific mention here, as sources of inspiration for me: Canonical, where I worked as Ubuntu CTO from near inception to when it reached nearly 500 people, and Heroku, where I currently serve as VP Engineering as it grows beyond 100 people.

Several of them share a common form:

  • What it means – a short conceptual overview
  • Why it’s important – an explanation of why this particular change is important at this juncture
  • Old status quo – what things looked like when the organization was smaller
  • New status quo – what things should look like for the next stage of growth
  • Behaviors that help – practical suggestions for how to work toward the new status quo
  • Obstacles that hold us back – anti-patterns that prevent progress

Table of contents:

Advertisements

Written by Matt Zimmerman

June 20, 2013 at 12:32

Listening to users

In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don’t know what they want, invoking the quote attributed to Henry Ford, “If I’d asked customers what they wanted, they would have said ‘a faster horse'”. Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers “vote with their wallets” (anything else is “anecdata”).

Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used.

One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won’t rehash his points here, but will add a few of my own.

If what we’re looking for is inspiration for a new product, it’s here that Henry Ford was right: users generally won’t hand you a complete product vision on a silver platter. They’ll frame their input in terms of what they know, and the choices already available to them. However, this doesn’t mean that users don’t have a role to play in this instance: watching users can be a great source of inspiration. It’s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer’s interests to a problem which was evident all around him.

If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don’t know if we’re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don’t find what they think until our new product is released, we risk making something that no one wants. Why wait until it’s too late? It can be challenging to extract useful feedback for a product which doesn’t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering.

When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they’re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better.

By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.

Written by Matt Zimmerman

March 7, 2011 at 12:56

Breathing information

I’ve written previously about my reading habits, online and offline, and the patterns I extrapolate to content consumption in general. I’ve been talking with other people about this as well, and am beginning to develop a model to apply to my daily life.

There are plenty of unsatisfactory metaphors circulating in this area: we eat the “information diet”, drink from the “fire hose”, endure the “information explosion”, and so on. None of them describe the richness of my experience: the profound variations in style, texture, speed, depth and movement are lost in this kind of dry imagery.

Instead, I think of it like respiration.

We inhale information, and we also exhale it transformed. We do this, consciously or unconsciously, every moment of our lives. Sometimes we do it quickly, other times slowly, and it can be relaxing or stimulating. We only retain a small amount of what we take in, but it becomes a part of us. We can immerse ourselves deeply, meditatively, in a series of breaths, or fail to notice as we breathe shallowly or pause altogether. One breath may be virtually silent, the next filled with a song or a question or a piercing whistle.

We maintain a balance in our breathing, and I aspire to do the same with information: reading and writing, listening and speaking, seeing and being seen. I don’t mean this simplistically, that I should do both in equal proportion (imagine trying to write as many words as you read!), but doing both consistently. It is often only when I share an idea that I come to understand it deeply, no matter how much I have read about it. By writing it down, or telling someone about it, I naturally fill in the gaps in my understanding and create mental structures which help me recall and apply what I’ve learned.

My input and output should be balanced appropriately for my circumstances. Rapid-fire email is like hyperventilation: I can do it for a while, reading and replying in quick succession, and even feel energized by it, but if I go on for too long, I get dizzy. Running might call for a certain breathing ratio, and Yoga quite a different one. Both can be healthy practices, but they are different, and each requires focus and consistency.

Another key lesson from breathing is to let go. A friend recently told me about his daily online news routine, which included closing any unread tabs at the end of the session. I will sometimes hang onto an article or a video for days or weeks before I find the opportunity to take it in. I eventually get around to most of them, but meanwhile they are taking up space and causing a continuous low level of anxiety or guilt. This information isn’t going anywhere, and if it’s truly significant for me, it will most likely turn up again. If it doesn’t, that’s OK too.

Similarly, it’s not wise to breathe stale, indoor air for too long. I will try to step outside regularly, and engage with people and media from outside my usual sphere. When the weather is tolerable, I’ll open up the house and let plenty of fresh air circulate. This will help me avoid getting stuck in the “echo chamber” of my own ideas, or in groupthink.

Perhaps most significantly, I will try to remember that information exchange, like breathing, is not an end in itself. It is a means to action. This will remind me to get out of my head regularly, and do something significant with what I’ve learned.

Ready? Breathe.

Written by Matt Zimmerman

December 2, 2010 at 15:44

Back to the future

In my professional role as Ubuntu CTO, I take on a number of different perspectives, which sometimes compete for my attention, including:

  • Inward – supporting the people in my department, alignment with other departments in Canonical and reporting upward
  • Outward – connecting with customers, partners and the free software community, including Debian
  • Forward – considering the future of the Ubuntu platform and products, based on the needs of their users, our customers and business stakeholders within Canonical
  • Outside-in – taking off my Canonical hat and putting on an Ubuntu hat, and looking at what we’re doing from an outside perspective

My recent work, as Canonical has gone through a period of organizational growth and change, has prioritized the inward perspective. I took on a six-month project which was inwardly focused, temporarily handing off many of my day-to-day responsibilities (well done, Robbie!). I’ve grappled with an assortment of growing pains as many new people joined Canonical over the past year.

With that work behind me, it’s time to rebalance myself and focus more outside of Canonical again. It’s good to be back!

In my outward facing capacity, I’ll shortly be attending Web 2.0 Summit in San Francisco. I attend several free software conferences each year, but this is a different crowd. I hope to renew some old ties, form some new ones, and generally derive inspiration from the people and organizations represented there. Being in the San Francisco Bay area will also give me an opportunity to meet with some of Canonical’s partners there, as well as friends and acquaintances from the free software community. With my head down, working hard to make things happen, it’s easy to lose perspective on how that work fits into the outside world. Spending more time with people outside of Canonical and Ubuntu is an important way of balancing that effect.

Looking forward, I’ll be thinking about the longer term direction for the Ubuntu platform. The platform is the layer of Ubuntu which makes everything else possible: it’s how we weave together products like Desktop Edition and Server Edition, and it’s what developers target when they write applications. Behind the user interfaces and applications, there is a rich platform of tools and services which link it all together. It’s in this aspect of Ubuntu that I’ll be investing my time in research, experimentation and imagination. This includes considering how we package and distribute software, how we adapt to technological shifts, and highlighting opportunities to cooperate with other open source projects.

My primary outside-in role is as chair of the Ubuntu Technical Board. In this capacity, I’m accountable to the Ubuntu project, the interests of its members, and the people who use the software we provide. Originally, the TB was closely involved with a range of front-line technical decisions in Ubuntu, but today, there are strong, autonomous teams in place for the most active parts of the project, so we only get involved when there is a problem, or if a technical question comes up which doesn’t “fit” the charter of an established team. It’s something of a catch-all. I’d like to re-establish the TB in a more central role in Ubuntu, looking after concerns which affect the project as a whole, such as transparency and development processes. I’m also re-joining Debian as a non-uploading contributor, to work on stimulating and coordinating cooperation between Debian and Ubuntu. I’m looking forward to working more with Zack on joint projects in this area.

This change will help me to support Canonical and Ubuntu more effectively as they continue to grow and change. I look forward to exercising some mental muscles I haven’t used very much lately, and facing some new challenges as well.

Written by Matt Zimmerman

November 11, 2010 at 15:42

Management and information distortion

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so”
– attributed to Mark Twain

There is a lot that I don’t know about what goes on in my organization. This isn’t only because I can’t observe everything, or because it’s too complex, or because I make mistakes. These are all true, of course, but they’re also obvious. Much more devious is the way the flow of information to me is distorted. It’s distorted by me, and by the people around me, whether any of us are aware of it or not. This is most apparent in considering how people feel about their managers: this is why I have a deeply flawed view of what it’s really like to work for me.

My theory is that power bends information like gravity bends light. The effect is more pronounced with people of greater mass (more authority), and lessened with distance (less direct influence). The more directly you influence someone else’s fate, the more it is in their self-interest to be guarded around you. This means that the people closest to you, who you receive the most information from, may have the most difficulty being open with you, especially if it’s bad news. It also means that the higher your standing in the corporate hierarchy, the more influence you wield, the more people are affected by this.

Pretty scary, right?

Some managers respond to this terrifying reality by trying to collect more information. They’ll quietly cross-check what people are telling them, asking people in different levels of the organization, routing around managers, hoping to get “the real story”. This usually backfires, because it signals distrust to the people involved and makes the distortion worse.

Another common response is to check in constantly, trying to monitor and control the work as closely as possible (so-called micro-management). This is even worse; not only does it signal distrust, but managers who do this become more personally attached to outcomes, and lose perspective on progress and quality due to information overload, self-enhancement bias, and neglect of managerial work. The more it becomes “your” work rather than the team’s, the harder it is to see it objectively.

So what’s a better way to respond to this phenomenon? Here’s what I try to do:

  • Accept it – You’ll never have certainty about what’s happening, so get used to it, and don’t let it paralyze you. Learn decision making strategies which cope well with information noise, and allow you to experiment and adapt.
  • Admit it – Everyone else knows that you have this distortion field around you. If you pretend it isn’t there, you’ll appear deluded. Acknowledge that you don’t know, don’t understand, and can’t control.
  • Trust – The more you trust someone, the more they trust you. The more someone trusts you, the more confident they can be in telling you what they think. Be grateful for bad news, and never shoot the messenger.
  • Delegate – Enable people with a less distorted view of the situation to make local decisions. Don’t make people wait for information to propagate through you before acting, unless there is a clear and sufficient benefit to the organization.

I was inspired to think and write about this today after listening to Prof. Robert Sutton’s speech at the California Commonwealth Club, which Lindsay Holmwood shared with me.

Written by Matt Zimmerman

November 9, 2010 at 17:00

Posted in Uncategorized

Tagged with ,

The paradox of Steve Jobs

Steve Jobs is a name that comes up a lot when talking to businesspeople, especially in the technology industry. His ideas, his background, his companies, their products, and his personal style are intertwined in the folklore of tech. I have no idea whether most of it is fiction or not, and I write this with apologies to Mr. Jobs for using him as shorthand. I have never met him, and my point here has nothing to do with him personally.

What I want to discuss is the behavior of people who invoke the myth of Steve Jobs. In my (entirely subjective) experience, it seems to me that there is a pattern which comes up again and again: People seem to want to discuss and emulate the worst of his alleged qualities.

Jobs has been characterized as abusive to his employees, dismissive of his business partners, harshly critical of mistakes, punishingly secretive, and otherwise extremely difficult to work with. Somehow, it is these qualities which are put forward as worthy of discussion, inspiration and emulation. Is this a simple case of confusing correlation with causation? Do people believe that Steve Jobs is successful because of these traits? Perhaps it is a way of coping with one’s own character flaws: if Jobs can “get away” with such misbehavior, then perhaps we can be excused from trying to improve ourselves. Or is there something more subtle going on here? Maybe this observation is an effect of my own cognitive biases, as it is only anecdotal.

As with any successful person, Jobs surely has qualities and techniques which are worthy of study, and perhaps even emulation. Although direct comparison can be problematic, luminaries like Jobs can provide valuable inspiration. I’d just like to hear more about what they’re doing right.

Perhaps this is an argument for drawing inspiration from people you know personally, rather than from second-hand or fictitious accounts of someone else’s life. I’ve been fortunate to be able to work with many different people, each with their own strengths, weaknesses and style. I’ve seen those characteristics first-hand, so I also have the context to understand why they were successful in particular situations. If there’s one thing I’ve learned about leadership, it’s that it’s highly context-sensitive: what worked well in one situation can be disastrous in another. Is your company really that much like Apple? Probably not.

Written by Matt Zimmerman

October 3, 2010 at 17:33

Posted in Uncategorized

Tagged with ,

DebConf 10: Last day and retrospective

DebConf continued until Saturday, but Friday the 6th was my last day as I left New York that evening. I’m a bit late in getting this summary written up.

Making Debian Rule, Again (Margarita Manterola)

Marga took a bold look at the challenges facing Debian today. She says that Debian is perceived to be less innovative, out of date, difficult to use, and shrinking as a community. She called out Ubuntu as the “elephant in the room”, which is “‘taking away’ from Debian.” She insists that she is not opposed to Ubuntu, but that nonetheless Ubuntu is to some extent displacing Debian as a focal point for newcomers (both users and contributors).

Marga points out that Debian’s work is still meaningful, because many users still prefer Debian, and it is perceived to be of higher quality, as well as being the essential basis for derivatives like Ubuntu.

She conducted a survey (about 40 respondents) to ask what Debian’s problems are, and grouped them into categories like “motivation” and “communication” (tied for the #1 spot), “visibility” (#3, meaning public awareness and perception of Debian) and so on. She went on to make some suggestions about how to address these problems.

On the topic of communication, she proposed changing Debian culture by:

  • Spreading positive messages, celebrating success
  • Thanking contributors for their work
  • Avoiding escalation by staying away from email and IRC when angry
  • Treating every contributor with respect, “no matter how wrong they are”

This stimulated a lot of discussion, and most of the remaining time was taken up by comments from the audience. The video has been published, and offers a lot of insight into how Debian developers perceive each other and the project. She also made suggestions for the problems of visibility and motivation. These are crucial issues for Debian devotees to be considering, and I applaud Marga for her fortitude in drawing attention to them. This session was one of the highlights of this DebConf, and catalyzed a lot of discussion of vital issues in Debian.

Following her talk, there was a further discussion in the hallway which included many of the people who commented during the session, mostly about how to deal with problematic behavior in Debian. Although I agreed with much of what was said, I found it a bit painful to watch, because (ironically) this discussion displayed several of the characteristic “people problems” that Debian seems to have:

  • Many people had opinions, and although they agreed on many things, agreement was rarely expressed openly. Sometimes it helps a lot to simply say “I agree with you” and leave it at that. Lending support, rather than adding a new voice, helps to build consensus.
  • People waited for their turn to talk rather than listening to the person speaking, so the discussion didn’t build momentum toward a conclusion.
  • The conversation got louder and more dense over time, making it difficult to enter. It wasn’t argumentative; it was simply loud and fast-paced. This drowned out people who weren’t as vocal or willful.
  • Even where agreement was apparent, there was often no clear action agreed. No one had responsibility for changing the situation.

These same patterns are easily observed on Debian mailing lists for the past 10+ years. I exhibited them myself when I was active on these lists. This kind of cultural norm, once established, is difficult to intentionally change. It requires a fairly radical approach, which will inevitably mean coping with loss. In the case of a community, this can mean losing volunteer contributors cannot let go of this norm, and that is an emotionally difficult experience. However, it is nonetheless necessary to move forward, and I think that Debian as a community is capable of moving beyond it.

Juxtaposition

Given my history with both Debian and Ubuntu, I couldn’t help but take a comparative view of some of this. These problems are not new to Debian, and indeed they inspired many of the key decisions we made when founding the Ubuntu project in 2004. We particularly wanted to foster a culture which was supportive, encouraging and welcoming to potential contributors, something Debian has struggled with. Ubuntu has been, quite deliberately, an experiment in finding solutions to problems such as these. We’ve learned a lot from this experiment, and I’ve always hoped that this would help to find solutions for Debian as well.

Unfortunately, I don’t think Debian has benefited from these Ubuntu experiments as much as we might have hoped. A common example of this is the Ubuntu Code of Conduct. The idea of a project code of conduct predates Ubuntu, of course, but we did help to popularize it within the free software community, and this is now a common (and successful) practice used by many free software projects. The idea of behavioral standards for Debian has been raised in various forms for years now, but never seems to get traction. Hearing people talk about it at DebConf, it sometimes seemed almost as if the idea was dismissed out of hand because it was too closely associated with Ubuntu.

I learned from Marga’s talk that Enrico Zini drafted a set of Debian Community Guidelines over four years ago in 2006. It is perhaps a bit longand structured, but is basically excellent. Enrico has done a great job of compiling best practices for participating in an open community project. However, his document seems to be purely informational, without any official standing in the Debian project, and Debian community leaders have hesitated to make it something more.

Perhaps Ubuntu leaders (myself included) could have done more to nurture these ideas in Debian. At least in my experience, though, I found that my affiliation with Ubuntu almost immediately labeled me an “outsider” in Debian, even when I was still active as a developer, and this made it very difficult to make such proposals. Perhaps this is because Debian is proud of its independence, and does not want to be unduly influenced by external forces. Perhaps the initial “growing pains” of the Debian/Ubuntu relationship got in the way. Nonetheless, I think that Debian could be stronger by learning from Ubuntu, just as Ubuntu has learned so much from Debian.

Closing thoughts

I enjoyed this DebConf very much. This was the first DebConf to be hosted in the US, and there were many familiar faces that I hadn’t seen in some time. Columbia University offered an excellent location, and the presentation content was thought-provoking. There seemed to be a positive attitude toward Ubuntu, which was very good to see. Although there is always more work to do, it feels like we’re making progress in improving cooperation between Debian and Ubuntu.

I was a bit sad to leave, but was fortunate enough to meet up with Debian folk during my subsequent stay in the Boston area as well. It felt good to reconnect with this circle of friends again, and I hope to see you again soon.

Looking forward to next year’s DebConf in Bosnia

Written by Matt Zimmerman

August 25, 2010 at 16:57