We'll see | Matt Zimmerman

a potpourri of mirth and madness

Archive for the ‘Uncategorized’ Category

Scaling Human Systems: Alignment

This is part 1 in a series on organizational design and growth.

An important lens for thinking about organizations at this stage of growth is alignment. In an organization which is aligned, the efforts of different people and teams all contribute to forward progress in a shared direction. If two teams are pulling in opposite directions they may make little progress despite great effort, and quickly become frustrated. To take an obvious example, if a marketing team is targeting an audience of large enterprises while the product being developed is only suited for small businesses, the end result of both teams doing a good job will be a failure (i.e. unhappy customers).

It’s important to note that alignment does not imply sameness. Different teams within an organization can function and behave very differently while still being strongly aligned with each other.

When an organization is small, alignment comes naturally. Everyone has some visibility on what everyone else is doing, and when something doesn’t line up, the people involved can talk it over and resolve the issue relatively easily. But as the organization grows, the propensity for misalignment increases, and these situations become much more difficult and time-consuming to resolve. The metaphor of the right hand, which doesn’t know what the left hand is doing, seems like something that would only happen in larger companies, but it begins much earlier, especially when the company goes through a period of rapid growth. Critical infrastructure, such as communication tools and patterns, lags behind the accelerating needs of the people involved, creating a surprising distance between teams.

Organizational alignment is a critical part of scaling successfully. With alignment, growth and momentum are assets. Without it, they are liabilities.

Further reading: The Advantage: Why Organizational Health Trumps Everything Else in Business

Written by Matt Zimmerman

June 20, 2013 at 12:32

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 medium-sized (100-500).

There are many different ways to categorize companies by size, and not everyone agrees with me that different organizations tend to face certain similar problems as they grow, based on the number of employees. In any case, hopefully we can all agree that human systems are mind-bogglingly complex entities, and any two organizations will have many important differences—such as their culture and market situation—which 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 is a perfect fit, the process of organization change is a feat unto itself, one about which many books have been written.

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:

Written by Matt Zimmerman

June 20, 2013 at 12:32

Decoding a .mobileconfig file containing a Cisco IPsec VPN configuration

When someone wants to give you access to a Cisco VPN, they might give you a .mobileconfig file. This is apparently used by MacOS and iOS to encapsulate the configuration parameters needed to connect to a VPN. You should be able to connect to it with open source software (such as NetworkManager and vpnc) as long as you have the right configuration. Some helpful soul has tried to give you that configuration, but it’s wrapped up in an Apple-specific container. Here’s how you rip it open and get the goodies.

File format

A .mobileconfig appears to contain:

  1. Some binary garbage which is safe to ignore
  2. An XML document containing the good bits, i.e.:
    1. The “local identifier” (i.e. IPsec group name)
    2. The “remote address” (i.e. IPsec gateway host)
    3. The shared secret (base64 encoded)
  3. Some more binary garbage which is safe to ignore

…and it looks like this:

<plist version="1.0">

The shared secret is base64-encoded, so you can decode it with:

$ echo -n 'BASE64_ENCODED_SECRET_HERE' | base64 -d

Network Manager configuration

  1. Make sure you have network-manager-vpnc installed
  2. Click the Network Manager icon, select “VPN Connections”, “Configure VPN…”
  3. Create a “Cisco-compatible (vpnc)” connection

    Create a “Cisco-compatible (vpnc)” VPN connection

  4. Configure the connection settings as follows:

    Configure the connection settings

    • Enter the “remote address” in the “Gateway” field
    • Enter the “local identifier” in the “Group name” field
    • Enter the shared secret in the “Group password” field
  5. To connect, click the Network Manager icon, select “VPN Connections”, and select the connection you just configured

Good luck and enjoy!

Written by Matt Zimmerman

November 15, 2012 at 18:29

Ada Lovelace Day 2011: Dr. Marian C. Diamond

For Ada Lovelace Day this year, I want to share my appreciation for Dr. Marian C. Diamond.

In years past, I’ve saluted women in the field of computing, which is my field as well. Dr. Diamond, however, is a biologist. Her research includes “neuroanatomy, environment, immune functions, and hormones. In particular, she is interested in studying the effects of the external environment, aging, and immune responses on the cerebral neocortex.” She has, in her words, had a love affair with the brain for about 70 years.

I know very little about biology. The content and methods of her research are, frankly, beyond me, though some of her results have garnered popular attention. She has inspired me by demonstrating that rare combination of gifts: a deep understanding of a technical subject, and the ability to explain it to other people in an accessible way.

In her interviews, articles and lectures, many of which are available online, Dr. Diamond displays these gifts in abundance. Her skill and enthusiasm for both learning and teaching is unmistakable. After applying her gifts in the classroom for many years, digital distribution has now enabled many more people to see and hear her, through millions of YouTube views.

In 1960, she became the first female graduate student in UC Berkeley’s anatomy department, and was apparently given the job of sewing a cover for a magnifying machine. I can only imagine the persistence required to continue from there to become a recognized leader in her field. She has gone on to help many other students along their way, and was named an “unsung, everyday hero” for the support she provided to students outside of the classroom or lab.

As if that weren’t enough, she has also traveled to Cambodia to apply her expertise in helping children injured by land mines. She still teaches today, just across the bay from where I write this, and will turn 85 next month.

Written by Matt Zimmerman

October 7, 2011 at 19:29

Building a personal data locker

If you were building a digital container to store your personal data, what would it look like?

Personal data being information associated with you: your contacts, your photos, the web pages you’ve visited, the places you’ve been, the messages you’ve sent and received, and so on. In short, your stuff.

Here’s my personal wish list of technical requirements:

  • It has to be made of free software, of course
  • It must keep my data secure, while allowing me to share it when and how I want to
  • It needs to handle a range of different data types natively, and be extensible to new types, from photos to real-time sensor data
  • It should be able to collect my data from many different places where it is being created and stored
  • It should have a rich API, so that I can create applications which access my data
  • If I want to, I should be able to host it myself, on my own hardware, without compromising my ability to access and share it

Of course, this isn’t merely an academic exercise, as my new day job at Singly is about building exactly this type of system. With a technical team including Jeremie Miller of Jabber and XMPP fame, our goal is to develop a personal data platform which meets these criteria and more.

There’s a lot of work to do, but today, you can check out the code and run a locker of your own, which can sync in data from Facebook, Twitter, Google, Foursquare, Github and dozens of other services. It’s a bit of a bear to set up, particularly if you don’t already have API keys for these services, but that’s fairly normal at this early stage of development.

If you try it, or have thoughts about what we’re doing, please let me know in the comments.

Written by Matt Zimmerman

August 15, 2011 at 16:00

Where’s your data center?

Thanks to the tremendous growth of “social” applications over the past five years, we have our pick of services for collecting, saving and sharing our experiences online. We each have collections of photos, contacts, messages and more, spread across multiple popular services like Twitter, Facebook, LinkedIn, as well as many less popular services which address particular needs or preferences. We’re also producing a wealth of “exhaust data” through our browsing history, mobile sensors, transactions and other activity streams that we rarely if ever examine directly.

This ecosystem is becoming so complex that it’s easy to lose track of what you’ve created, shared or seen. We need new tools to manage this complexity, to make the most of the wealth of information and connections available to us through various services. John Battelle calls these “metaservices”, and points to growth in the number of connections between the services we use.

I expect that this next age of information tools will center around data rather than services. Data is a common denominator for these online experiences, a bridge across disparate services, technologies, social graphs, and life cycles. Personal data, in particular, has this property: the only thing that links together your photos on Flickr, Facebook, Picasa and Twitpic is…you.

So where’s your “data center”? I don’t anticipate the emergence of a single service where you do everything. There will continue to be innovation in the form of new and specialized services which meet a particular need very well. There won’t be a single service which is everything to everybody.

Instead, I foresee us wanting to track, save, use and control all of our “stuff” across the web. That’s why my new colleagues and I are working to make that possible.

There’s open source code available on github, a vibrant IRC channel (#lockerproject on Freeenode), and lots more I’d like to write about it. But it’s time to get back to work for now…

Written by Matt Zimmerman

August 9, 2011 at 15:53

DEX finishes first batch of derivative patches for Debian

It’s been a few months since Zack and I announced the DEX project, which aims to improve the Debian ecosystem by working jointly with derivative distributions.

Our first milestone

The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn’t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old.

I’m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them.

One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project.

This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian.


Although we weren’t quite able to clear the whole list, we still consider the project to be a success because:

  • We ensured that all of the patches received due consideration for inclusion in Debian
  • We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
  • Most importantly, we learned from the experience

What’s next

In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:

  • Our second major project, nicknamed “big-merges”, will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
  • Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
  • Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
  • Zack is organizing a derivatives BoF at DebConf 11

We’re looking forward to seeing DEX develop further. If you’d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on freenodeOFTC).

Matt Zimmerman and Stefano Zacchiroli

Written by Matt Zimmerman

June 8, 2011 at 14:21


Get every new post delivered to your Inbox.

Join 2,245 other followers