Deprecate Management
There are many aspects to “making things” that open source just does better. Regardless of if at the end of the day you ship bits or cogs, certain aspects of “office” work are universal: ideation, vetting initiatives, resolving conflicts, and shipping product. Now imagine if you had to do all this not across conference tables, but across geographies and timezones. You’d have a pretty kick-ass process for sure. Welcome to the world of open source.
Think about it this way: in the traditional office setting, we use management to facilitate this collaborative building process. Management does many things, but at the most basic level they:
- Shuttle Information
- Coordinate across business units
- Align efforts to organization priorities
- Make sure people do work
- Recruit new people
This makes sense if you look at the history of the role. In an age when conveying information was onerous, the only way for Adam to tell Becky what he was working on (and thus to ensure Becky was not duplicating efforts) was to stop what he was doing, walk down the hall, and interrupt Becky. So instead of doing this every day, we hire Charlie to facilitate a standing meeting and shuttle that information back and forth. Makes sense.
But what if when that problem first arose Adam could send Becky an email or an IM or post an update to a shared collaboration space. Do you think they’d need Charlie in the first place? Would management as we see it today have arisen in an age where technology reduces the friction of collaboration to nearly nil?
Take the open source community, as a test case, which was afforded just such a unique opportunity. Same problem, same outcome, and (for the most part), no traditional hierarchical structure. How do you overcome the management burden? Transparent, persistent communication — everything from code to decisions happen in the open and are archived for all to see — and pure meritocracy — a bunch of ideas arise and are voted on (through opt-in participation) and the best are seen to fruition.
But does it blend scale? WordPress, the open source content management system had nearly 300 individual contributors to its latest release, in just under four months, all working on a single project downloaded more than a million times within days of its release. And there’s no reason this process has to be limited to software. Collaboration is collaboration.
So what aspects of the open source process make this management free collaboration possible? Ryan Tomayko outlines his experience applying the open source philosophy to an entire (for-profit) venture, noting four key features to the system:
Electronic: Discussion, planning, and operations process should use a high fidelity form of electronic communication like email, GitHub.com, or chat with transcripts wherever possible. Avoid meatspace discussion and meetings.
Available: Work should be visible and expose process. Work should have a URL. It should be possible to move backward from a piece of product or a system failure and understand how it came to be that way. Prefer git, issues, pull requests, mailing lists, and chat with transcripts over URL-less mediums.
Asynchronous: Almost no part of the product development process requires that one person interrupt another’s immediate attention or that people be in the same place at the same time, or even that people be in different places at the same time. Even small meetings or short phone calls can wreck flow so consider laying it out in (a thought out) email or sending a pull request instead.
Lock free: Avoid synchronization / lock points when designing process. This is distributed version control writ large. We don’t have a development manager that grants commit bit to repositories before you can do work, or a release manager that approves deploys, or a product manager that approves work on experimental product ideas. Work toward a goal should never be blocked on approval. Push approval/rejection to the review stage or automate it, but surface work early to get feedback.
Granted, this open-source philosophy doesn’t apply to every workplace, but how much better would the process of “making things” be if we could eliminate traditional pain points of managerial friction entirely — conference calls, status meetings, “sync ups”, and other non-decisional “check-ins”. Work happens in the open, rather than hidden away in one-on-one emails or behind closed doors, and decisions are made by those who show up to do the work.
Straddling the line between arguably the world’s most bureaucratic, hierarchical organization (federal government), and it’s definitional polar opposite (open source), provides a unique perspective. There are so many aspects to the work day that we do just because it’s the way thing’s have been done since the dawn of the industrial revolution, and it puzzles me why nobody’s stopped to think critically about how these processes could be reimagined in an age of technology. I need to get this (physical) form approved by Joan? Okay, you just took two people away from doing what they’re paid to be doing. I have to email someone for the latest version or figure out where we’re at on this project? Again, just moved someone from high-level to low-level work.
Granted, not every workplace is apt for such radical egalitarianism, but the buttoned up (offline) world of “serious” business could learn a thing or two from open source’s collaborative experiment. In many respects, organizational friction is no longer a sunk cost, and thus, arguably, so too is management.
If you enjoyed this post, you might also enjoy:
- Why open source
- 15 rules for communicating at GitHub
- Five best practices in open source: external engagement
- Four characteristics of modern collaboration tools
- 19 reasons why technologists don't want to work at your government agency
- Why everything should have a URL
- Bringing open source workflows to the enterprise
- Five best practices in open source: internal collaboration
- Leaders show their work
- Manage like an engineer
- Twelve tips for growing communities around your open source project
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit