Older blog entries for mdz (starting at number 57)

Liberty and justice for all, but not in equal measure

200302020-001

As Americans we might like to believe that the US legal system is intended to protect all of our citizens.  Unfortunately, it doesn’t protect us all equally, and in fact disproportionately fails to protect the most vulnerable. We’re surrounded by instances of injustice related to gender, race and other axes of social privilege, and the machinations of law are not exempt. The state of Florida has recently provided an especially stark example in the application of its self-defense laws in two cases: Marissa Alexander and George Zimmerman. This example is notable because although there were many similarities between the cases, the outcomes were very different.

Alexander’s case was tried in May 2012 , Zimmerman’s in July 2013, both prosecuted by Florida state’s attorney Angela Corey. Both cases involved the use of firearms which were legally purchased and carried, and their owners were trained in their use. Both prosecutions cast the defendant as the aggressor, who could have avoided the confrontation. Both of the encounters were with unarmed persons. Both defenses were based on Florida self-defense laws, which include “stand your ground” laws justifying the use of deadly force without the obligation to retreat. Both shooters admitted to firing a single shot with the intent of defending themselves.

Beyond those similarities, each case had its own unique circumstances.

The events of Alexander’s case took place in her home. Her altercation was with her husband, Rico Gray Sr., who was under a restraining order following a conviction for domestic battery which put Alexander in the hospital.  After Gray threatened to kill her, Alexander retrieved a handgun from her car, returned to confront him, firing once. She was arrested and charged the same day. She had had no prior criminal record. A jury deliberated for just 12 minutes before convicting her. A judge sentenced her to 20 years in prison, in accord with mandatory minimums specified by law.  Gray, previously sentenced to probation for his earlier conviction, remains free.

Zimmerman,_George_-_Seminole_County_MugZimmerman’s shot was fired in his neighborhood, in an altercation with a teenager, Trayvon Martin, who was a guest in the community and walking by himself. The two were not acquainted. Zimmerman called police from his car, claiming that Martin appeared suspicious, and began to follow him. Some of the facts of their encounter remain in dispute, but that Zimmerman fired his gun is not in question. Afterward, Zimmerman was detained by police, questioned and released the same night without being arrested or charged. Following a public outcry, a new investigation was launched and two months later he was arrested and charged. He had been previously arrested and charged with assaulting a police officer, but the charges were later dropped. After 16 hours of deliberation, the jury found Zimmerman not guilty, and he is free today.

The most striking difference between the two cases is where each defendant aimed their gun: George Zimmerman shot Trayvon Martin in the chest and killed him, while Marissa Alexander fired at a wall and injured no one. Alexander, a black woman, is in prison for scaring her abusive husband away, while Zimmerman, who killed a young black man, walks free. Alexander and Martin’s families have lost a mother and a son. The outcomes for the people involved in these cases could not be more different. Regardless of the merits of the relevant laws themselves, their radically unequal application is deeply troubling. What does this tell us about the relative value of these human lives, as weighed by the judicial system?

“The Florida criminal justice system has sent two clear messages today. One is that if women who are victims of domestic violence try to protect themselves, the `Stand Your Ground Law’ will not apply to them. [...] The second message is that if you are black, the system will treat you differently.” - U.S. Rep. Corrine Brown

References


Syndicated 2013-07-14 20:56:59 from We'll see | Matt Zimmerman

Scaling Human Systems: From individual achievement to teamwork

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

What it means

Getting things done together, as a team, achieving more than the sum of our individual efforts.

Why it’s important

Once a company reaches a certain size, perhaps with a substantial customer base and ambitious goals for the future, it takes a lot more momentum to move it forward. No one person can do it alone. From product delivery, to strategic decision making, to customer service, no single individual has all of the knowledge, skills or time necessary to perform these functions at the scale and velocity necessary to make real progress. Cooperation is not just a good idea: it’s essential to success.

The most important system we’re building is the company itself: a system of people working together to achieve common goals.

Old status quo

In a startup, everyone embodies the spirit of the pioneer: passion, fortitude, individualism, daring, and the willingness to do whatever it takes to reach the goal. Individuals wear many hats: engineering, product management, marketing, customer support. We often don’t even think of them as distinct disciplines. Projects often depend on the resoluteness of a single jack-of-all-trades to drive them to completion, and the culture may reward this kind of heroism. Thanks to the relatively small scale of the company and its customer base, one person working independently can effect significant change without much risk. If what was delivered wasn’t good enough, it could be discarded with no great loss.

New status quo

In a growing company, we still need a variety of different disciplines in order to reach our goals, in fact more than ever. A successful product needs to be conceived, validated, designed, built, documented, adopted, supported, and we need to confirm that it satisfies customers over time.

These elements are all essential, and each requires deep knowledge, expertise and practice. Good engineering + mediocre product management + inept marketing = total failure. It’s not realistic to expect one person to do all of these things and deliver consistently good results, but consistently good results are exactly what we need. The solution is to organize for individuals to do what they do best, and cooperate effectively together.

We also need to manage risk more carefully: our customers are depending on us. We have a lot more to lose now, and need to learn how to maintain forward progress while continuing to meet our customers’ expectations. Delivering sub-par products would damage our reputation and erode their trust.

Most of all, we need to be getting better at all of this over time, faster than our competition.

Behaviors that help

  • When embarking on a new project, recruit others to your cause instead of going it alone. In particular, consider which other teams you may need help from, and ask for their support from the beginning
  • Make your work visible to others (for example through a shared work board like Trello). Push context out of your head and into a workspace where others can see it.
  • When you run into trouble, make a point of asking for help early. Not only does this help build relationships, it also gets problems solved faster.
  • Agree on explicit shared priorities with your immediate teammates, and stick to them until the team agrees to change. Make sure that you’re working on things that matter to the people around you, and that they know that’s important to you.

Obstacles that get in the way

  • Heroism. There is a place for heroism in growing organizations, but save it for responding to exceptional problems. Day-to-day work and objectives should not depend on one person’s heroism
  • Attributing too much credit to individuals. Feedback and praise are invaluable, but be careful not to excessively recognize and reward individuals for what are fundamentally team efforts. Few things will erode team spirit faster than rewarding someone for other people’s work.

Syndicated 2013-07-11 00:09:43 from We'll see | Matt Zimmerman

Scaling Human Systems: Making and keeping commitments

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

What it means

Taking responsibility for action, and following through. Every time.

Why it’s important

Commitments are a cornerstone of collaborative teamwork. Knowing what to expect from others makes it possible to plan beyond your own work. If you aren’t sure whether a task will be completed, you carry that uncertainty as low-grade anxiety, which accumulates and creates cognitive load. You may even spend extra time checking back to make sure the need has been met.

Old status quo

Most work happens without an explicit commitment at all. Consistency is highly variable from one individual, team or circumstance to another. Tasks fall through the cracks, and we may not even realize it until much later.

New status quo

When something needs to get done, someone agrees to take responsibility for it. When this happens, everyone involved can trust that it will get done. When exceptions happen, we acknowledge them, and seek to understand what happened so that we can do better in the future.

Behaviors that help

  • Make commitments explicit: say “I will take care of that”, and record that commitment somewhere, preferably in a shared work space where everyone concerned can see it. For example, meetings should generally result in decisions and commitments to act. Write them down, and check back on the commitments at the next meeting to confirm that they’re done.

  • Hold yourself accountable: Follow through on your commitments visibly, e.g. reporting back the next time you see each other. If you’re unable to deliver for some reason, apologize and explain.

  • Hold others accountable: Expect these same behaviors from others.

  • Celebrate success: Thank others for following through on their commitments.

  • Learn from failure: When commitments are broken, it should be treated as an exception. Something went wrong, and we should work to prevent it in the future.

  • Balance your workload: Doing fewer things at a time will help you complete them much faster and more consistently. If you don’t have the bandwidth to take something on, say no. Make space for someone else to take it, or ask for help. If you are unsure about whether you can commit, you probably shouldn’t.

Obstacles that stand in our way

  • Fatigue: It’s hard to commit to something new if you already feel overwhelmed by the status quo.

    • Slack is an essential component of any change. If we’re 100% busy just keeping the lights on, we’re not getting better at what we do, and that road leads to mediocrity

  • Cynicism: If past commitments have been made but not kept, people can become cynical about setting goals and priorities.
    • This needs to change. Setting and achieving goals needs to be normal, respected and valued behavior in the company.
  • Unclear roles and responsibilities: This makes it hard to tell who should take responsibility for getting things done

Further reading


Syndicated 2013-06-28 01:12:56 from We'll see | Matt Zimmerman

Scaling Human Systems: From implicit to explicit

What it means

Carefully communicating about what’s going on, and making fewer assumptions about what others know or think.

Why it’s important

As companies grow, many new people join who don’t have as much shared context. Many employees will also interact less frequently with each other, as we may not be able to maintain the same level of relationship with everyone. When we make assumptions about what our co-workers know, think or feel, we will increasingly be making errors of judgment. By replacing these tacit assumptions with explicit communication, we can help avoid mistakes and support cooperation within and between teams. Explicit communication is a vital tool for coming to agreement: by putting an agreement into words, we stand a better chance of understanding what we’re agreeing to, and can change it together.

Old status quo

We take a lot for granted. We know quality when we see it, but can’t explain it. New team members are expected to learn through osmosis or trial and error. Expectations are often ambiguous. Procedures live in our heads, and evolve in ad hoc fashion.

New status quo

We exercise care and thoughtfulness in our internal communications, telling others clearly what we expect and what they can expect from us. Key information and procedures are written down, and can be instantly shared with as many people as needed. We change them whenever we need to, and everyone concerned stays in the loop.

Behaviors that help

  • Document the basics: a new team member should be able to learn the essentials of how to do their work by referring to documentation. We don’t need to try to exhaustively document everything, but the essentials (e.g. for an engineer, how to deploy their changes) should be written and maintained, and where appropriate encapsulated in software tools
  • Make work visible: something as simple as a Trello board can offer a lot of insight into what’s going on in a team, both specifics (e.g. status) and meta information (this is how we get things done)
  • Define and track projects: a project has a beginning and an end and a scope. There will always be unknowns and changes, but there should be an explicit goal such that we can agree on when it’s “done”
  • Clarify roles and responsibilities: job roles are a tool to communicate with other people about what you do. By having a shared understanding of what roles we occupy, we can more easily divide up responsibilities and anticipate each other’s contributions.
  • Listen actively: “is this what you meant?” “who is taking responsibility for making that happen?” “do we have agreement on this point?”

Obstacles that hold us back

  • Fear of process: Tiny companies can get by with very little structure in their operations, and may become attached to this as part of the “culture”. As they grow, this is less and less true. Process doesn’t mean bureaucracy! A process is just a description of the way things work. It doesn’t have to be rigid or foolish. The worst kinds of process are those that only exist in people’s heads, and are divergent from each other.

Syndicated 2013-06-26 00:09:30 from We'll see | Matt Zimmerman

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


Syndicated 2013-06-20 19:32:40 from We'll see | Matt Zimmerman

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.


Syndicated 2013-06-20 19:32:32 from We'll see | Matt Zimmerman

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">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>IPSec</key>
      <dict>
        <key>AuthenticationMethod</key>
        <string>SharedSecret</string>
        <key>LocalIdentifier</key>
        <string>LOCAL_IDENTIFIER_HERE</string>
        <key>LocalIdentifierType</key>
        <string>KeyID</string>
        <key>RemoteAddress</key>
        <string>REMOTE_ADDRESS_HERE</string>
        <key>SharedSecret</key>
        <data>
        BASE64_ENCODED_SHARED_SECRET_HERE
        </data>
      </dict>
      <key>IPv4</key>
      <dict>
        <key>OverridePrimary</key>
        <integer>0</integer>
      </dict>
      <key>PayloadDescription</key>
      <string>...</string>
      <key>PayloadDisplayName</key>
      <string>...</string>
      <key>PayloadIdentifier</key>
      <string>...</string>
      <key>PayloadOrganization</key>
      <string>...</string>
      <key>PayloadType</key>
      <string>com.apple.vpn.managed</string>
      <key>PayloadUUID</key>
      <string>...</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>Proxies</key>
      <dict>
        <key>HTTPEnable</key>
        <integer>0</integer>
        <key>HTTPSEnable</key>
        <integer>0</integer>
        <key>ProxyAutoConfigEnable</key>
        <integer>0</integer>
        <key>ProxyAutoDiscoveryEnable</key>
        <integer>0</integer>
      </dict>
      <key>UserDefinedName</key>
      <string>...</string>
      <key>VPNType</key>
      <string>IPSec</string>
    </dict>
  </array>
  <key>PayloadDescription</key>
  <string>...</string>
  <key>PayloadDisplayName</key>
  <string>...</string>
  <key>PayloadIdentifier</key>
  <string>...</string>
  <key>PayloadOrganization</key>
  <string>...</string>
  <key>PayloadRemovalDisallowed</key>
  <false/>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>...</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

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!


Syndicated 2012-11-16 02:29:03 from We'll see | Matt Zimmerman

Singly is hiring engineers

I’ve written before about joining Singly and a little bit about the open source software we’re building. There’s now a bit more content on our website too, or you could watch my colleague, Jabber founder Jeremie Miller, talk about it on stage.

The Singly team gathered for a discussion
Suffice to say, it’s pretty interesting stuff, and we need more interesting people to join the team in order to achieve our goals in the next year. In particular, we’re looking for engineers to build highly flexible, resilient and performant back-end infrastructure using Ubuntu, and innovative, usable and beautiful front-end interfaces using HTML5.

For full details and how to apply, check out the Singly blog or contact me directly. At this time, we have a preference for candidates in the San Francisco bay area, but are open to exceptional candidates from elsewhere.


Syndicated 2012-01-19 03:41:41 from We'll see | Matt Zimmerman

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.


Syndicated 2011-10-07 19:29:34 from We'll see | Matt Zimmerman

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.


48 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!