Hi! I'm Sumana Harihareswara of Changeset Consulting and I'm not using any slides today, so you're free to take a few minutes to stretch, fold some laundry, what have you.
Introducing the question/problem
We have a pipeline for getting folks with coding skills to start or contribute to open source projects. That's great and I'm glad.
But I'm pretty sure we don't have a pipeline to recruit or grow contributors with leadership and management skills. A maintainer of a widely-used project *is* a manager, but since skilled managers are scarce in open source, we're seeing important projects stumble, or even wither, for lack of managerial work. (At least, this is what I've seen, and if you are seeing something to the contrary, I want to hear about it.) And I think this is a factor in the open source sustainability problem.
Knowing why this is happening can help us fix it. So in this talk I'll share a few hypotheses: one about the tooling we build and use, one about the effects of corporate involvement, one about changes in the problems we're trying to address, and one about values and culture. And I'll talk about how we would check whether any of these are true. I hope that considering this question will aid your efforts in focusing time and energy on things that will make a difference to project sustainability.
A little more about the problem I see
Founders start projects but are unprepared for the managerial demands of maintaining things that other people depend on. And, when legacy projects stagnate, contributors don't know how to take them over and stabilize them by solving common strategic, team, communication, workflow, and financial problems. Since they don't know how to rehab existing projects, individuals and orgs fork or start new ones, exacerbating fragmentation headaches.
So what hypotheses do we have?
Tooling hypothesis
Here's one. It used to be that, if you were going to run an open source project, you had to make the tooling platform yourself. You had to set up and administer, and maybe even build, your own bug tracker, source code repository, wiki, documentation site, and tarball release repository. Now these are hosted services -- GitHub, Read the Docs, PyPI. That means that it's easier to start a project, but that also means it's easier to start a project without learning a lot about the value and capabilities of these platforms along the way. And then project founders are less equipped to use those things well.
Corporate involvement hypothesis (hypotheses)
Here's another: it changes things when companies get more and more involved in open source, or hire people from open source. Maybe big companies hire the people who have managerial skills, and sometimes take them out of open source work entirely, and leave behind the ones who don't. Or maybe open source would be failing worse without corporate involvement, and corporate engagement is sort of subsidizing the poor management that we would otherwise see.
New problems hypothesis
Here's another: what got us here won't get us there. We're trying to address new or unsolved or undersolved problems and areas in open source -- distributed and cloud computing, getting telemetry while protecting user privacy, user experience design that can stand up to the best that industry can offer, diversity, equity, and inclusion, and so on. So, in general, open source contributors have grown a certain median level of leadership skill, but we're seeing cracks in the infrastructure because of the new loads they are trying to handle.
Values and culture hypothesis
Here's another: Let's talk about our culture and values, and how that affects contributor retention and promotion. We in open source recognize and promote people for the code they write, but we're bad at recognizing and valuing people for the managerial contributions they make -- we treat glue work https://noidea.dog/glue as invisible. So we don't attract or retain people with managerial skills or with the interest in growing in that direction.
And I'd like to thank Amye Scavarda for some thoughts about some of these hypotheses.
How would we check?
So. How would we check whether any of these are right? A few thoughts. We could talk with the scholars who were funded by the Ford and Sloan Foundation grants on critical digital infrastructure to get their thoughts. We could work with the CHAOSS people, the open source metrics working group, to construct a means to quantitatively measure maintainership actions happening within a project, and find out what other attributes it correlates with -- like whether or not those particular projects, or the domain areas they're in, were particularly influenced by companies. We could look for conversations from 15 years ago to check what our forebearers were saying, whether they thought this was likely to be a problem. We could try to offer explicit skills learning opportunities to contributors, to see whether people are interested, and whether we can find ways to retain the people who take those offers as open source maintainers.
My gut says that the source of the problem is a mix of the corporate involvement and values and culture hypotheses. So that's the basis I'm working from. I am working on a book outlining and teaching the skills open source software maintainers need, and teaching these skills to contributors who have never managed public-facing projects before. It'll be a textbook or a self-help guide for new and current maintainers of existing projects (what I call "brownfield projects", as opposed to "greenfield") and will focus on teaching specific project management skills (such as initial project audit, grantwriting, bug triage, and meeting facilitation) in the context of open source. If you go to changeset.nyc, under "resources" you'll find a free sample.
But let's talk during the Q&A session on Thursday. Which, if any, of these hypotheses ring true to you, and how could someone check whether you're right?
#29 Apr 2021, 04:07PM: Thinking About Safety And Competing Access Needs:
I don't have much to say about this but this piece ("safe spaces and competing access needs") and this discussion ("Safe" isn't a monolith.) have been rolling around in my head a lot, and I thought you might like to think about them too. Especially if you have responsibility for any shared physical or virtual group or venue that has a Code of Conduct, and especially if anyone in it has ever suggested that particular words or topics ought to be off-limits.
#09 Apr 2021, 01:11PM: If You Call Me A Thought Leader For This Post I Will Give You A Stern Look:
In scifi/fantasy fandom there's this phrase, "Big Name Fan". This is someone who is well-known, influential, for the fannish things they say and do and make. The idea is that a BNF is a minor celebrity -- not at the television-interviews level, but still, within their Internet and convention circles, someone who gathers a crowd, and whose tossed-off words have disproportionate power to help or hurt others.
The chunk of fandom I'm thinking of is, mostly, women. We're socialized to not admit when we have power, and to shut up and use it to serve others. Joanna Russ wrote about this dynamic in "Power and Helplessness in the Women’s Movement"; fan Hope reiterated that expectation in "Nobody Ever Admits They're a BNF", advising Big Name Fans that they get to benefit from feelings of belonging but "You are not allowed to have hurt feelings, you are not allowed to argue with someone, and you absolutely are not allowed to have an opinion." I think the only/first time I've found out that I've been called a BNF, it was in the context of someone criticizing my too-abrupt comments in a Dreamwidth thread; they were disappointed, taken aback, at such a BNF acting in this way.
Given that it's considered arrogant to call oneself a BNF, at least in public, perhaps you can infer how difficult it then is for a person to honestly and transparently reckon with the concomitant opportunities and constraints.
And perhaps you can draw a line from this dynamic to ones in the developer relations industry, or in large collaborative volunteer groups such as major open source projects, etc. If you have an explicit role such as "conference chair" or "professor" or "maintainer" then you know whether you inhabit it or not, you can straightforwardly mention that you hold it, and you and your peers can come up with norms for the special powers and responsibilities that come with it. But absent that? As far as I am aware you do not get a how-to book and access to an all-celebrities group chat upon achieving some number of Twitter followers. A person who has gradually accreted influence must notice that they have more intangible influence than most of the people they talk and listen to, and -- through reflection, study, and private conversation -- develop their own guidelines for how to use that influence.
But: there's how you act, and then there's how everyone else acts toward you. No matter whether or not they get some explicit roles to help everyone understand these kinds of expectations, I think -- at least in the bit of US society that I'm used to, where we have strong egalitarian ideals -- we don't help newly powerful people get used to all those social epiphenomena that will now start brushing against them. Envy, intimidation, and so on. Maybe there are now influencer finishing schools that include "you are now the object of other people's projections and their parasocial interactions with you will get very weird" in their curriculum.
I have counterproductive feelings and habits in my head that relate to this whole issue, around envy, martyrdom, etc. As with the stuff I mentioned earlier this week in "Paralipsis", this blog isn't the right place to work through those things. This week I'm particularly grateful to friends of mine with whom I can talk candidly about this stuff. And if you and I are friends, perhaps we can talk about it too.
# (1) 22 Mar 2021, 09:09PM: A Spec For A Sandboxed Open Source Project Environment:
I'm writing a book on maintaining legacy open source projects to help teach people vital skills. Right now, as far as I know, there's no textbook or course you can work through to learn skills like assessing an open source project systematically, triaging bugs, noticing quiet-but-promising contributors to promote, improving code review processes, writing a grant proposal, and finding your successors. Or, more accurately, there are courses and guides that cover different software leadership areas, but there's nothing that covers the whole toolbox.
When I'm teaching skills, I want to give learners exercises they can use to develop and practice those skills. And if I turn the book into a course, I'll want to be able to assign those exercises and review their homework. So I started thinking: how nice it would be if I could snapshot or composite together a sample legacy FLOSS project, complete with messy old issues, docs, and chat and list archives, and replicate it in self-serve sandbox instances for exercises!
I've been thinking about this for a while. Today I wrote up a spec. I don't know what to call it - "Maintainer Sandbox", "Snowglobe Factory", and "Diorama" all sound good. The spec below assumes that I'd be leading a cohort of learners through a semisynchronous online course; it would work fine for an in-person class as well, but I'd have to adapt the access levels part for a completely self-paced and self-driven course.
Spec
As instructor, I would create a snapshot of a sample open source project (comprising materials listed below). The hosting platform would replicate it in self-serve instances, usable over the web, for user exercises. Upon signing up for a course, a user would get access to a freshly provisioned instance, complete with project history.
Materials: Each instance would include the following artifacts, all browseable and searchable via the web browser:
Bugtracker-type artifacts and history that would generally be available as part of a GitLab or GitHub project: a git repository for code history, past and present issues and patches/pull requests/merge requests (complete with tags/labels, milestones, assignees, and similar metadata), past release announcements, and a wiki
Project documentation and overview information for users and for developers, as would generally be available on a project's website (even if documentation source is available in the git repository, the snapshot we provide should include the docs as rendered into HTML)
Archives of the project's mailing lists, as would generally be available as a Mailman, Majordomo, or similar instance, browseable and searchable via a web interface like this web view of python-dev (a Mailman 3 list)
Access privileges: The learner would not only interact with the example project materials as a reader but also as a participant, moving through the three access levels described below. The instructor would be able to view a learner's instance, with administrator (Level 3) access, to assess the learner's actions.
Level 1: The learner starts with the same user privileges that a new user would ordinarily have -- they can read all the public mailing lists, chat histories, wiki, and bugtracker items, and file bugs.
Level 2: The instructor can promote the learner to the second access level, at which point they can (for instance) triage, label, and close bugs and pull requests/patches, edit the wiki, and post to public mailing lists.
Level 3: The instructor can promote the learner to the third (administrative) access level, at which point they can (for instance) browse and post to private mailing lists and chat channels, and use maintainer powers on the git repository (such as merging pull requests/patches).
Authentication: I imagine that dealing with authentication within the application could get sticky. My preferred approach:
As a signed-in platform user, the learner is automatically logged in to all the web applications within the instance, and cannot log out.
It is not possible to view an instance unless you are either the learner or instructor associated with that instance.
Multi-user access: Ideally, it would also be possible for an instructor to expand access so that a project can have multiple users (in other words, give Learner A access to Learner B's project instance), so that learners can engage in peer learning and group exercises. However, I expect that would lead to a much larger range of headaches, including Code of Conduct problems in interactions between learners, so -- in earlier versions of this tool -- I am fine with not having this functionality, and instead advising pairs and small groups to use screen sharing for group exercises.
End of life: At the end of the course, each instance would turn read-only for two weeks (to allow the learner to make notes, and to make local copies of any work they had done), and then the platform would delete the instance.
Thoughts? In particular, if you know of software that already does more than half of what I want, I'd like to know about it.
more hypothetical budgeting details: Seven months of working full-time is probably enough time for a skilled Python developer to port a command-line tool for geology researchers from FORTRAN to Python. Or, if you split that money between a user experience researcher and a technical writer, again at $150 per hour, then they could work together for three and a half months, which is probably enough time to interview a bunch of your users, make a really detailed report on user needs to help your developers prioritize your roadmap, overhaul all of your documentation, and overhaul a lot of your error messages.
an overview of the kinds of information most funders want in grant proposals:
basic contact details, including the person or organization that will receive the money
a few paragraphs about the task you want to perform
the amount you're asking for, and a short description of what you'll spend it on
who uses your software? have some statistics here - download numbers, users on the mailing list, etc. -- but also this is where you talk about specific important or prestigious users and downstreams.
what goals will this accomplish? how it will make the world a better place? and why do people need this? why is it important?
what is your plan for how you'll do it -- how will you use this money? what's your proposed schedule? try to break things down so no chunk of work takes longer than a month; if your project stretches out over 6 months or more, try to break that up into 3 or more milestones, each of which is a few months' worth of work, to help the reviewer think about what you might get done if the project goes over schedule and you run out of budget
does this project currently get any other regular income?
(Since funders are mostly asking the same questions, you can take a rejected proposal and lightly rewrite it to submit to another funder. Kind of like how I gave a version of this talk in 2020, then added some more material to share at MozFest in 2021.)
European Broadcasting Union (recommended by one participant who said: "the last one I applied for was with the EBU and was 10000 euros. This was filled in by me and was one form on their site. Nice and simple, perfect for a single developer")
Below are some session notes, including some of the live collaborative document we used to take notes during the discussion. I've removed individuals' and projects' names.
What kind of danger is it in? If no one intervenes, then 5 years from now, what will happen?
Principles of getting a project unstuck
Some premises I use in my work:
There is no one tech industry and there is no one open source community.
Open source contributors, as a population, disproportionately want to code.
Skills are fungible; domain knowledge can be learned; credibility can be earned.
Every open source project has a life cycle. (Including an end.)
Five major areas where legacy projects get stuck. I need help with the names for these categories! (And of course sometimes combinations of problems crop up.)
strategy, e.g., what work do we need to prioritize, and how urgent is it? what is our goal, and should this project exist (or should we decommission it)? has the team agreed on these things?
team, e.g., do we have enough maintainers to do the essential work, and do we have up-and-coming contributors who can replace us as maintainers in the future? does everyone know who has what powers, or are some people confused about who has the power to do certain things? do we run into team workflow problems when different groups want to participate at different speeds? is there a malicious, offputting, or flaky person who needs handling? do we have the social processes we need to support the project and each other, like meetings, mentorship programs, and Requests for Comment?
connection, e.g., who are our users and what do they need? are we listening to them? are we responding quickly enough to their concerns? do they have a way of listening to us? who are our partners and upstreams? do we talk to each other? do new contributors fall through the cracks?
workflow and digital infrastructure, e.g., do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?
money, e.g., do we have enough money to do what we want to do? have we developed plans or proposals to turn money into progress? can we persuade funders to give us money?
Thank you to a participant who suggested "interfacing" rather than "connection". I do like that better.
The sequence of steps for gaining credibility within a project and helping turn it around:
Settling in (doing routine tasks that do not require much trust, assessing and earning credibility)
Taking charge (doing things that require trust but that the group has already agreed needs to happen)
Making change (modifying and adding social, digital, financial, and legal infrastructure)
What kinds of "stuckness" have you seen in FLOSS projects? I feel like I've seen 5 major areas where legacy projects get stuck (strategy, team, connection/interfacing, workflow, and money). Does that reflect your experience?
not having motivation to promote it
"I think sometimes (especially in an operating system) we have too many requests and this makes the development of the core slower"
What circumstances make it easier or harder for projects to get unstuck?
harder when it requires more dev skill to contribute
how easy dev toolchain is, to bootstrap project
whether project will accept small submissions or needs to be 100% complete ... a lack of small problems for people to fix
"how much it is connected to other communities, sometimes if more than one community is using the project there will be more people willing to maintain it and help in general"
findability & presence of important information, e.g., code location
conflict over whether to release a breaking change, because of refactors/rewrites
sometimes there is no one interested in taking the money to help improve the project, or the amount of financial support available is insufficient to hire someone in North America or Western Europe
(I was struck by how much easier it was for participants to come up with programmer-specific problems -- especially problems with onboarding new contributors -- than to remember and bring up people, money, and other problems. After all, most mature software projects have a backlog of patches awaiting review, and so making it easier for more new contributors to get onboarded is a less crucial bottleneck than widening the code review bottleneck, which is probably a team, workflow, and money problem.)
Do you know a stuck project? What support would you need to start getting it unstuck?
I have all the support I need, except I need a push... I don't use the program myself anymore, I do this to help users, so lack of motivation.... thinking about motivation and how we help ourselves in moments when we need more
need help improving core skills (managerial and similar professional/interpersonal skills)
Plans for followup
I suggested that people form optional accountability pairs, to talk with each other regularly and help both stay motivated to get their project unstuck. Two people did pair up.
In the process, I've developed a list of existing books and online resources on open source maintainership and on software management, and I've thought more about why general software management advice -- which usually assumes you and your colleagues all work for the same company or other organization -- doesn't address most open source maintainers' needs.
Writing a book proposal: kind of necessary, kind of a drag
In nonfiction book publishing, a book proposal is the way you say to a publisher, "I think it would be a good deal for both of us if you published this book I'm writing." For example, No Starch Press would like a summary, an outline, and descriptions of the audience, the competition, the market, and the author. All the publishers I'm considering want to know those things, and some also want to know the schedule for completion, which other books from that publisher cover related or similar topics, the authorial approach I'll use, what keywords readers would search for to find this book, and more.
I might not go with a traditional publisher; I might self-publish, either all at once or in stages, such as via my email newsletter. But writing this proposal gives me more options and makes me think through what I'm planning to do. Still, it can be a drag to spend time on persuading other people that something is a good idea instead of executing on the idea itself, and it is a specific drag for me to spend time writing something that very few people will see.
The most immediately-useful-to-others part is probably the literature review, the overview of books and similar resources that are in any way comparable. Thus:
My competition
So here's my competition. I don't mean to disrespect any of these works or their authors, just to clearly state what they do and what they don't do (and thus why there is still a need for my book).
I hired Audrey Eschright to start this and then I continued it myself -- thanks, Audrey! I know this is incomplete and I'll remember another thing three hours after I post this (I may edit to add things), but I figure it might be useful to folks looking for books and web curricula about open source, project management, maintaining legacy systems, and so on.
Audience: FLOSS newbies, programmers and managers, new project contributors and maintainers
Covers/teaches: FLOSS culture, communication tools and techniques, project management, governance, structured collaboration
Good: Friendly, detailed, aimed at software professionals at least as much as side-project folks
Missing/needs (or, not designed to cover): Mostly about greenfield projects; does not cover how to come into an existing project and lead it (Fogel has thus encouraged my own project as a kind of sequel to his); limited discussion of managing problem contributors, bug triage, and planning roadmap; very little/no discussion of budgeting, grant proposals, and succession planning; somewhat out-of-date regarding discussing modern tooling
Audience: Technologists, managers, and interested bystanders such as sociologists and economists
Covers/teaches: General principles regarding FLOSS sustainability and dynamics
Good: “An anthropological dive into the stories of real developers” with some useful explanations of some dynamics in open source projects (such as the categories of "toy, club, federation, stadium," based on the ratios of users and contributors and user growth and contributor growth)
Missing/needs (or, not designed to cover): Is inaccurate in ways that accumulate page by page. This surprised me badly, especially since her Roads and Bridges report was so helpful. My copy of Working in Public has corrections and rejoinders from me in the margins of about every fourth page. I need to write a more thorough review but, in short, Eghbal's choices to ignore all projects that don't use GitHub, and all contribution types other than code commits, and all of the effects of venture capital on the economics of open source, and the roles governments can play in funding digital infrastructure, constrict the analysis and recommendations towards a disappointing conclusion that will not help most of the infrastructural open source projects (and their maintainers) I know and work with. Also, it does not provide practical advice for maintainers (such as instructions and exercises) on dealing with specific issues to rescue legacy projects. (Updated this summary in July 2021.)
Audience: “Anyone starting up or leading open projects– project leads, collaborators, or small groups of co-leaders responsible for project success and growth”
Covers/teaches: Communication, community-building, using GitHub, mentoring, project maintenance, organizing events
Good: Multiple kinds of content, exercises to use, explains FOSS collaboration without requiring a technical background
Missing/needs (or, not designed to cover): Budgeting, working with a legacy project instead of starting a new project
[Edited 2021-02-05 to add] Online Resource: TODO Group guides (online), various authors, started in 2019
Audience: engineering executives at large organizations
Skills taught: participating in open source communities, building leadership in a FLOSS project and improving open source development impact, and related topics
Covers/teaches: General overview of how to start participating in open source projects and grow into leadership; realistic and business-focused understanding that contributing to existing projects often has greater return on investment than starting new ones; specific tool recommendations
Missing/needs (or, not designed to cover): Detailed instructions on providing coordination and maintainership; assumes incoming participants have an architectural/feature agenda (rather than just wanting more frequent releases); lack of detailed examples, exercises; assumes reader already has basic project management skills (since it is aimed at executives rather than individual contributors)
Audience: Practitioners and funders in open source software
Skills taught: "This primer covers non-technical aspects that the majority of projects will have to consider at some point. It also explains how FOSS foundations can help projects grow and succeed." Like a shorter, high-level and up-to-date version of Karl Fogel's Producing Open Source Software, focusing on governance and related systems and processes.
Covers/teaches: FLOSS governance approaches, legal and financial issues, structures to accommodate and encourage project team growth
Good: Very recent, has lots of examples of how existing organizations address certain kinds of needs
Missing/needs (or, not designed to cover): examples, techniques, and exercises for learning the skills to implement Michlmayr's suggestions
Audience: People, with varying levels of experience participating in open source projects, who want to participate in and lead them
Skills taught: Participating in open source communities, building leadership in a FLOSS project and improving open source development impact, and related topics
Covers/teaches: General overview of how to start participating in open source projects and improve their user and participant bases, and measure one's success; realistic advice based on experience
Missing/needs (or, not designed to cover): Mostly about greenfield projects; does not cover how to come into an existing project and lead it; limited discussion of managing problem contributors, bug triage, and planning roadmap; very little/no discussion of budgeting, grant proposals, and succession planning
Online resource: Opensource.guide (online curriculum), GitHub team and other contributors, started in 2016
Audience: GitHub users, maintainers of new projects, FLOSS newbies, people outside existing FLOSS organizations, programmers
Good: Overview of many important aspects of running an open source project
Missing/needs (or, not designed to cover): How to turn around a legacy project, especially when starting as a non-maintainer contributor; non-GitHub forges (resource is entirely GitHub-specific)
Covers/teaches: Mentoring, communication, FOSS cultural knowledge, commit/patch management
Good: Detailed guidelines for mentor/student interaction and evaluating progress
Missing/needs (or, not designed to cover): Organization could be improved; indicates but doesn’t address the issue of project culture not being friendly to newcomers aside from how you guide the student through it; no guidance for how to run a project overall, since it concentrates on just the act of mentoring an intern.
Covers/teaches: FOSS culture, tech skills, documentation, community management, leadership transitions, starting a new project as open source or opening the source code to an existing project
Good: “Handoffs and Sunsets” section, good examination of the beginning and ends of projects
Missing/needs (or, not designed to cover): Is still unfinished and lacks thorough examples. Does not cover the case of coming into and reviving an existing open source project, and has little to no advice on project management
Audience: Novice contributors/leaders/community managers for open source software and open culture organizations (assumption that reader does not already know the basics of how open source contribution works)
Covers/teaches: Making a mission statement and strategic plan, introducing process, marketing, governance
Good: Specific advice on communication channels, writing skills, governance, conflict management, basic event planning, and marketing; anecdotes and lessons learned from many projects. Online component.
Missing/needs (or, not designed to cover): Is at least eight years out of date (example: Gobby and Identi.ca recommendations); assumes you can build new processes and communities from scratch, instead of helping people who are joining midstream, quirky writing style will put off some readers
Book: People Powered, by Jono Bacon, 9781400214884, published by HarperCollins Leadership, 2019
Audience: Executives at businesses
Covers/teaches: Initiating and exploiting user groups for products and services (not specific to open source software)
Good: Specific instructions on sequence and strategy for creating new user groups
Missing/needs (or, not designed to cover): No discussions of joining and co-maintaining existing open source projects; aimed at existing executives who are not yet open community contributors, not current open source contributors
Software management
(There are dozens of reasonably well-regarded books on software management in general, from classics like DeMarco & Lister's Peopleware to more recent works like the Fournier I mention below; most of them are only partially suitable for my target audience for the reasons I mention in "What doesn't get covered".)
Audience: People who are doing, or want to do, civic technology -- developers, entrepreneurs, and people in related fields
Covers/teaches: How government tech works, choosing contribution and project types, ways to avoid common gotchas to make long-term change without burning out
Good: Distills a wealth of experience, clearly written, realistic, good sequencing
Missing/needs (or, not designed to cover): Has only a single section within a single chapter on “Open-source teams and assumptions”; generally assumes institutional funding
Audience: Managers within existing large organizations
Covers/teaches: “How to evaluate existing architecture, create upgrade plans, and handle communication structures.”
Good: Probably engagingly written based on Bellotti's other work; “team exercises and historical analyses of complex computer systems”
Missing/needs (or, not designed to cover): Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects such as volunteer-run open source projects
Audience: Engineering managers within companies and similar organizations
Covers/teaches: Leadership, planning, decision-making, team culture, people management
Good: Coverage of common dysfunctions, good sequencing and clear writing; covers both line-level and senior leadership roles
Missing/needs (or, not designed to cover): Very little attention paid to open source dynamics; Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects such as volunteer-run open source projects
Book: Making Things Happen: Mastering Project Management by Scott Berkun, 9780596517717, published by O'Reilly, 2008 (formerly “The Art of Project Management”)
Good: Detailed, funny, includes guidance on communication methods (such as meetings and emails) as well as discussion questions
Missing/needs (or, not designed to cover): Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects; assumes in-person collaboration and does not accommodate open source project approaches
If I've made any substantial errors in my descriptions of these books and websites, please let me know. And if you think I've missed a work, if you think the book I'm working on substantially overlaps with prior work that I have not mentioned, please tell me. I don't want to waste anyone's time and I wish to minimize duplication of effort.
What doesn't get covered
There are lots of guides to starting open source projects, but overall they do not address the needs of a new maintainer of a legacy project. As Marco Rogers recently observed regarding code-related tutorials: "there is very little content that is appropriately labeled as intermediate to advanced....A lot of content is pointed towards either newbies or people doing greenfield work."
And there are many books about managing software projects, including complex infrastructural and legacy projects. They generally assume you're making proprietary software, and so (except for works like Bacon's) they don't account for the benefits of working in the open, the possibility of getting gratis contributions from users, open source strategy for the enterprise, and so on.
But also -- more crucially for a project management book -- on the whole they assume that all contributors are paid staffers, usually of the same organization. This is a somewhat less obvious distinction so I'll discuss it at a bit more length.
The job of a project manager varies wildly depending on how much power you actually have to say no to things and change delivery deadlines, whether you have the power to hire and fire people, and whether the colleagues who work on your project are solely working on your project (or splitting their time among multiple projects). Much of the existing writing on software management assumes that you are working in a mostly-hierarchical environment bounded by a single organization, where someone has the power to hire and fire, there is a monetary budget you control or have to keep track of, and so on.
Certainly some orgs are more hierarchical than others and there exist some where you basically have to use persuasion if you want a change to happen. First, of course that dynamic privileges some people, and it's worth checking for -isms in who gets to just veto things for no reason and who doesn't. And second, even so, if you and the other people you are influencing are in the same org and are being paid by the same employer, you still have different cues and levers available to you. Here are some structural differences between managing a more cross-org or extra-institutional project and managing one where everyone is being paid by the same employer:
If you send an email or assign an issue, they are more likely to feel pressure to actually read and answer it; at some point, if they absolutely never listen to or respond to stuff their colleague is saying, that may lead to repercussions in the rest of their job. Ditto for if you invite them to meetings, retreats, etc.
It's much more possible to make systematic changes that then affect lots of projects/individual contributors through systematic incentive or environmental nudges that apply to ALL contributors, e.g., working with senior managers to make [activity] a factor in promotions, which then facilitates getting [activity] to happen in YOUR project(s).
If your team is remote, it's somewhat easier to arrange an in-person retreat, because it's way easier to get and figure out budget, it's easier to figure out *whom to invite*, to *schedule* it, to deal with expenses and so on. This means you can have more and better high-bandwidth meetings to build trust and make complicated decisions.
The existence of centralized IT that you (and individual contributors) probably don't have to run yourself, and that everyone already is accustomed to using, and forces that somewhat delay/prevent tool fragmentation, means that if you set up a project management dashboard or similar, it's easier to ensure that all your colleagues are getting reports from it, that it ties into their existing communication feeds, and so on.
You likely can access a list of your colleagues and (in organizations that are not giant) you can find out a fair amount about them when a new one comes onboard in a role that you will interact with, and you can be alerted or find out when one leaves the org entirely.
There is a more bounded, finite set of stakeholders for you to deal with (including whom you could possibly ask for more budget), and it's easier for you to know who your users are.
If someone really does not want to obey the Code of Conduct, it can escalate to the personnel department and they may get fired.
Who this book is for and what you should get out of it:
You are about to get an open source project unstuck.
Maybe a bunch of work is piling up in the repository and users are getting worried, waiting for a release. Maybe developers have gotten bogged down, trying to finish a big rewrite while maintaining the stable release. Maybe the project's suffering for lack of infrastructure — testing, money, an institutional home.
You noticed the problem. So that means it's up to you to fix it. Or you're getting paid to fix it, even though you didn't start this thing.
A while ago I blurted out the phrase "dammit-driven leadership." Because sometimes you look around, and you realize something needs doing, and you're the only one who really gets why, so you say, "Dammit, okay, I'll do it, then."
After reading this book, you should be prepared to:
Assess a legacy project to decide whether you should get involved.
Settle into a legacy project and become a competent and credible contributor.
Take charge of a legacy project on a project, people, and financial level.
Execute transformative change in a legacy project.
Make a legacy project more sustainable, and pass leadership on to someone else.
This sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:
Introduction (including my controversial? "Basic assumptions about open source and the tech industries")
Conducting a SWOT analysis (assessing a project's strengths, weaknesses, opportunities, and threats, with example analysis of the pip project)
How to start thinking about budgets and money (including two exercises)
Teaching and including unskilled volunteers (with twelve specific tactics)
An outline of the full forthcoming book
Thanks to Julia Rios for paid services editing and producing this book, including the cover! Julia is a Hugo Award-winning editor as well as a writer, narrator, and podcaster, and is available for freelance work!
A special note for my blog readers: I'm keenly interested in your feedback once you read the sampler. Have you solved any of these problems in a different way? Would a different structure, for each chapter or for the book, help you better? Did any of my examples or phrasings particularly ring true? Are there things I've written that you have found useful and that you hope I will incorporate into this book? Email me with "Unstuck" in the subject line.
Next: In 2021 I'm looking forward to finishing this book and either self-publishing or working with a publisher. And I will likely bring this sampler from behind the subscribewall once I produce a new edition of it that can have a "the full book is coming on [date] from [publisher]!" line. In order to do that, I need to finish the book proposal, submit it to publishers, and get cracking on the rest of the book.
This talk will draw from the same material as the book I'm writing on getting open source projects unstuck. I aim to teach the skills open source software maintainers need, aimed at working scientists and other contributors who have never managed public-facing projects before. And I hope to have more news about that project soon!
#07 Dec 2020, 08:55AM: Reflecting on Alexandria Ocasio-Cortez:
The other night I watched two films in a row: Knock Down The House, the documentary about four progressive candidates running to unseat Democratic incumbents in the 2018 US election, and Douglas, Hannah Gadsby's comedy special.
They're both very interesting, and afterwards I read and thought a bunch in particular about what's striking about Alexandria Ocasio-Cortez's political career.*
Making expectations explicit
In Douglas, Gadsby starts the show with a lengthy table of contents, telling you what she is going to do, saying that she would like for everyone to have their expectations properly set. She calls her shot.
In this exchange Ocasio-Cortez demonstrates one of the skills that makes her an aspirational figure, a role model for so many marginalized people: live and in the moment, she can notice an unfair or misleading criticism coming her way, refute the specific criticism, and then name and categorize what's illegitimate about the criticism so as to defuse it and get the upper hand (and point out the problem to all watching).
This is such a powerful skill. I see it in Ocasio-Cortez, in Sarah Taber, in Rep. Katie Porter, in Alexandra Erin, in Tressie McMillan Cottom, in siderea, and in some other public intellectuals and activists and politicians (often women) who are unapologetic and sharp in their fast-paced analysis of illegitimate criticism. It's like they don't just deflect the object coming their way, but they also X-ray it and show everyone the schematics so we can build our own shields too.
I don't think I have this skill. I think it really helps to have gone through the school of hard knocks, which they have way more than I have. And it helps to have a ton of practice in fast-paced live oral argument, which I've probably atrophied in recent years since so much of my work is in written conversation.
But, in organic conversation, when conflicts crop up, I think I do a tolerable job of stepping back and asking (to myself or out loud): what mismatch of expectations brought us here? Which is definitely useful.
Analytical and organizing skill
You can watch the part of Knock Down the House where Ocasio-Cortez analyzes the difference between two campaign mailers and predicts their effectiveness. This is an example of the level of skill in analysis and organizing that Ocasio-Cortez brings to her job. Which is less surprising when you remember not only that she was a promising researcher as early as high school, and that she worked as an organizer for the Sanders campaign in 2016 and got a bunch of experience in on-the-ground political work.*** The skill she demonstrates in articulating progressive arguments in compelling ways is not just a general gift of gab; it comes hand-in-hand with wonky behind-the-scenes research and thinking that brought her to those positions, and deep and specific expertise in what disengaged voters need to hear to get them to turn out at the polls.
Back in October 2008 I wrote about Obama's success and noted: "people used to think the Clinton machine was the best there was. But with the right tools, investment in time, and leadership, a networked/egalitarian group will beat a linear, top-down group." Hillary Rodham went to law school instead of taking a job with Saul Alinsky's new training institute. What if she'd leaned harder into the organizing model? I think with Ocasio-Cortez you get a glimpse of what kind of independent political force she might have been.
I believe the right’s attacks on AOC (and a few of the left’s to be honest) are a visceral reaction to their inability to control what they see is her only legitimate source of power.....
We also feel icky about pointing out that someone is attractive and that is a certain kind of power because powerful women make us squeamish. And beauty as power makes us deeply afraid for our own self-worth.
Gadsby would probably agree with something Ocasio-Cortez says in the Vogue video (hat tip to kristi for highlighting it):
Our culture is so predicated on diminishing women and preying on our self-esteem, and so it's quite a radical act - and it's almost like a mini protest - to love yourself in a society that's always telling you you're not the right weight, you're not the right color, you're not the right, you know, whatever it is ... When you stand up and say, 'You know what? You don't make that decision. I make that decision,' it's very powerful. But that doesn’t mean we can't have fun.
Trusting one's own judgment
And, to reinforce that point about figuring out what expectations of you are legitimate, and tying that to authenticity, the Vogue article continues:
Just over two years ago, after defeating a 20-year incumbent and winning what was seen as the biggest upset of the 2018 midterm election primaries, Ocasio-Cortez was thrust into the spotlight at just 28 years old. "I went from working in a restaurant to being on cable news all the time," she recalls. "I initially really struggled with that. At a certain point, I just learned that you cannot get your feelings of beauty and confidence from anyone but yourself ... If I'm going to spend an hour in the morning doing my glam, it's not going to be because I'm afraid of what some Republican photo is going to look like ... It's because I feel like it," she says with a smile. Here, she picks up Fenty Beauty's Contour Stick, which she glides lightly down her cheekbones, over her forehead, and around her jawline. "I'm not trying to change my features or shape-shift -- I'm just trying to accentuate my existing features," she says as she adds a touch of the cream-to-powder pigment to her nose. "I'm not trying to make it look bigger. I'm not trying to make it look smaller ... I'm just trying to show people what I got."
When I get past reticence to advertise my company's services, to realistically say "I am one of the world's experts on [thing]," I too am just trying to show people what I've got. I remember N.K. Jemisin's articulation, for fiction writers:
...care better. I think the shift from extrinsic to intrinsic valuation .... is a fundamental part of the transition from amateur to professional, perhaps even more than pay rates and book deals and awards and such. .... How do you know your judgment of yourself is sound? .... But for pro writers -- and I include aspiring pros along with established ones in this designation -- it's an absolutely necessary transition. Otherwise you spend all your time caring about the wrong things.
The incentives you can see, the appealing and obvious ones, will often try to make you care about the wrong things. This means that integrity comes with inherent discomfort -- but by demonstrating integrity in public you can reduce the difficulty others run into when following your path. We've only gotten to see Ocasio-Cortez's integrity in action for a few years of public service so far. I look forward to seeing who follows her path.
* I have a caveat for Knock Down The House; it seems like the filmmakers made some misleading choices in the sequence of scenes in the NY-14 primary race.
In particular: The film makes it seem like Crowley fails to show up for a candidate forum in the Bronx (instead sending Councilwoman Palma as a surrogate), and then, maybe weeks later, he calls the Ocasio-Cortez campaign and agrees to appear on a TV debate with her. The implication is that her growing popularity, and news attention to his surrogate gaffe, have possibly shamed or scared him into agreeing to a fresh debate.
This is particularly difficult to reconcile with a bit of audio the filmmaker uses, where Ocasio-Cortez wryly says (just after we are shown footage of a Pride event from June 17th) that Crowley didn't show up to a 100-person event, but now wants to debate her on NY1.
The way I can sort of square the circle is if the filmmakers are using audio recorded before June 15th, and the skipped debate Ocasio-Cortez is referring to is the first debate that Crowley skipped (and which the filmmakers have no footage of).
In any case, the filmmakers are compressing and reordering stuff to strongly imply a particular narrative that is not congruent with the chronological record, and once I come across a discrepancy like this I gotta wonder what else in the film I should question.
As long as I'm talking about the research I ended up doing for this post: Reddit user lpetrich seems to be a solid contributor to the world of AOC fandom. Thank you for your posts, lpetrich!
#08 Sep 2020, 10:13PM: Breaking Release Bottlenecks -- What Changeset Can Do:
I did some volunteer work earlier this year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use). Here's what I did, how long it took, and how you can do the same.
Dan Ryan ("techalchemy") knew what was blocking him:
techalchemy: if you're purely evaluating 'how do we release the code', yeah I might just be the main roadblock? techalchemy: someone to yell at me to stop doing things that are not related to the goal? techalchemy: lol sumanah: let us assume that a successful release -- even as a pre-alpha -- is something that does not instantly break every user's life techalchemy: yeah longer term planning though would require tech writing for sure and onboarding help, god do I struggle with that techalchemy: have you heard me explain something... sumanah: if you JUST want someone to yell at you to stop doing those unrelated things, just for about a month, then that can be cheaper .... would you actually _listen_ to that person? techalchemy: historically speaking, I'd insist I was doing something important briefly but probably reassess, I do know what needs to happen sumanah: :-) ok. So, how frequently do you need those checkins? like, 4 times a day, 5 days a week? techalchemy: hopefully not that much, but I could see a few checkins being helpful especially if we were also onboarding some new people sumanah: techalchemy: ~10 minutes of conversation, via IRC, 4 times a day, 5 days a week, for 3 weeks....
That would have worked out to about ten hours. We underestimated how long it would take Dan to address some nasty continuous integration bugs, so instead of three weeks it took three months. Over those months, I donated about 15 hours of my time, helping him release two betas, then a stable version in May. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release.
Dan needed someone to help him with prioritization, release management, and communications. So I:
I regularly have conversations like this, and it's a toss-up as to which of the two roles I play.
Yeah. An external perspective can help a lot. And, ideally, a project manager is a supportive accountability partner who helps with the bits you're not great at.
If you/your company depends on an open source project and you're getting annoyed or worried because the release cadence has slowed to a standstill, there's a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation you see in the IRC log above.
#03 Sep 2020, 11:48AM: Making Groups, Leading Them, Treating Others Well:
Some writing I've appreciated in the past year, on leadership, and on understanding others and treating them well:
His decision to take energy away from his marathon coding sessions and put it into creating a positive and collaborative environment is a major reason why DW development is what it is today, and it was more than worth the extra few weeks' delay in going from closed beta to open beta.
Espionage hinges on human relationships. "The best assets I ever ran weren't in it for money," Skinner said. "They had this urge to be part of something bigger. It wasn't patriotism -- they just wanted to be part of a high-functioning team.”
So we saw a need, we came together with a group of friends and like-minded folks we gathered on the internet, and we made a thing to fix it. One of the best aspects of our genre is that it is full of such people and the organizations they’ve built.
In the nationwide debate over campus free speech, a lot of apparent disagreement derives from failing to separate the objects of study, and the habitat where study takes place.....the conditions needed to cultivate hard thought and judgment are not the same for all students...
Fred Clark, Slacktivist, writes about how to deal with the dishonest weights of post-transaction surveys in "All fives (ready or not, here I come)". "You are asked questions in a language of lies and are thus forced to respond in kind."
"We want to belong, but we also want to be individuals .... I think we need to recognize that no matter how necessary it might be to simplify our experience somehow, there's always going to be an injustice in putting people into categories and dealing with them through roles and scripts. That's an injustice that we both suffer and inflict on others."
I also liked the phrase "to come into right relationship with our own pain".
I'm talking in this post about wikis, political clubs, open source projects, fanvidding exchanges -- any groups where people try to work together and are open to the public.
"No, what's that?"
Some people joining your groups don't know things you take for granted.
Years ago, while helping new applicants to Google Summer of Code get into working on (I think) MediaWiki or Zulip, I was talking with a person who was (at that time) a student in an Indian engineering college. He had run into trouble and was trying to debug a setup issue. He seemed to be asking for help but not systematically investigating what the problem might be.
So I said, let me give you some tips on troubleshooting. You've heard of the scientific method?
I then said: so, you do that. You come up with a hypothesis for what might be the problem, and figure out how you would check to see if that is the case. You run the experiment, and you use the resulting data to refine your hypothesis -- if you're wrong, you try to come up with a new hypothesis. And then you either find and fix the problem, or if you get stuck, you at least have a bunch of data to give someone so they can help you better.
He said: THIS IS AMAZING! I'M GONNA USE THIS ALL THE TIME! And I was like IT IS! And then in a separate private conversation with colleagues, I was privately very angry with the educational system that had let him get that far without teaching him this!
Don't act surprised when people say they don't know something. Because (as I said a few years back) that’s just a dominance display. That's grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.
In open source projects, I think it's also okay to exclude unskilled people from a project based on "we do not have time to help them learn remedial skills, and this is not a suitable project for novices." If you are going to do this, explicit is better than implicit. You should try to forewarn contributors with explicit "not good for beginners/prerequisite skills are [list]" language in your README and CONTRIBUTORS files. And when you need to tell contributors that they aren't ready to participate in your group yet, you should offer them a redirect to a project more suitable to their skill level, you should take care not to insult them while redirecting, and you should tell them they'll be welcome back in the future after learning more of the prerequisites.
The scientific method is still as kickass a cognitive tool as it has ever been. It's amazing and empowering!
Thanks to Dr Linda McIver for the conversation that spurred this post.
#27 Apr 2020, 06:00PM: Remote Sprint Tips:
Every year, many developers of Python (the language itself, not just stuff written in Python) get together for a sprint. This year it will probably be virtual. How should that work? I offered to share my experiences and tips, the folks in the core development group asked me to do so, and I listed some tips. My approach is less "top-down schedule" and more "here's how to adapt to and support the emergent ways people will act".
I will put a transcript in the comments of this blog post.
(Please note that they massively condensed this video from 30+ minutes of interview. In the video, I say, "the site got popular before the code got good". In the interview, I did not just say that without acknowledging the tremendous effort of past volunteers who worked on the previous iteration of PyPI and kept the site going through massive infrastructure challenges, but that's been edited (for brevity, I assume).)
This video is the first in a series meant to encourage people to apply for MOSS funding. I mentioned MOSS in my grants roundup last month. If you want to figure out whether to apply for MOSS funding for your open source software project, and you need help, ping me for a free 20-minute chat or phone call and I can give you some quick advice. (Offer limited in case literally a hundred people contact me, which is unlikely.)
The main goal of the BSSw Fellowship program is to foster and promote practices, processes, and tools to improve developer productivity and software sustainability of scientific code. We also anticipate accumulating a growing community of BSSw Fellowship alums who can serve as leaders, mentors, and consultants to increase the visibility of those involved in scientific software production and sustainability in the pursuit of scientific discovery.
That's why I'll be at
the Exascale Computing Project Annual Meeting next week in Houston, so if you're there, I hope to meet you. In particular I'd like to meet the leaders of open source projects who want help streamlining contribution processes, growing more maintainers, managing communications with stakeholders, participating in internship projects like Google Summer of Code and Outreachy, expediting releases, and getting more out of hackathons. My consulting firm provides these services, and at ECPAM I can give you some free advice.
Book
And here's the project I'm working on -- why I received this honor.
In 2020, I am writing the first draft of a book teaching the skills open source software maintainers need, aimed at those working scientists and other contributors who have never managed public-facing projects before.
More than developer time, maintainership -- coordination, leadership, and management -- is a bottleneck in software sustainability. The lack of skilled managers is a huge blocker to the sustainability of Free/Libre Open Source Software (FLOSS) infrastructure.
Many FLOSS project maintainers lack management experience and skill. This textbook/self-help guide for new and current maintainers of existing projects ("brownfield projects") will focus on teaching specific project management skills in the context of FLOSS. This will provide scalable guidance, enabling existing FLOSS contributors to become more effective maintainers.
Existing "how to run a FLOSS project" documentation (such as Karl Fogel's Producing Open Source Software) addresses fresh-start "greenfield" projects rather than more common "brownfield", and doesn't teach specific project management skills (e.g., getting to know a team, creating roadmaps, running asynchronous meetings, managing budgets, and writing email memos). Existing educational pathways for scientists and developers (The Carpentries, internships and code schools) don't cover FLOSS-specific management skills.
So I'm writing a sequel to Karl's book -- with his blessing -- and I'm excited to see how I can more scalably share the lessons I've learned in more than a decade of leading open source projects.
I don't yet have a full outline, a publisher, or a length in mind. I'll be posting more here as I grow my plans. Thanks to BSSw and all my colleagues and friends who have encouraged me.
#30 Jul 2019, 01:18PM: Comparing Y2K and Climate Change:
When you know there's a big upcoming threat, how do you get big institutions to commit and follow through? And in particular, how useful is it to frighten whole populaces?
from my POV as a computer geek who saw what it took to get the... very fine people... in management moving was panic and doom saying....
...those calm and measured meetings only took place because of the general panic. If they were going to have calm rational meetings without the outside pressure of people convinced their toasters would explode (or whatever) they'd have done it earlier.
From my POV panicking the masses, while not good, was literally the only reason the billionaires paid the slightest attention to the problem. The billionaires and the rest of the management types didn't panic, or not much anyway, but their non-panic reaction was produced entirely by the panic.
So I wanted to double-check whether that is in fact the dynamic that actually happened back in the 1980s and 1990s. Was the causality fairly simple, or was the course of events was shaped by lots of conversations among regulators, shareholders, customers, boards of directors, etc. that weren't as visible to a working engineer's point of view?
So I started looking for a little more research and data about Y2K mitigation/prevention decisionmaking especially on the institutional level, beyond the US Senate special committee report. This question -- what caused institutions to take Y2K seriously? -- seemed like the kind of thing historians of technology and organizational sociologists and political scientists must have studied. I did some digging and here are some things I think are useful to consider:
Y2K was a technology problem at heart, and so IT investment, where IT sat in an organization, senior leaders' attitudes towards IT, etc. were factors that slowed down planning & compliance.[1]
Banks, for instance, found it hard to get their customers/users to understand the importance of Y2K compliance, because it was an abstruse technological issue.[2]
Getting companies to actually act involved some amount of influence/pressure from the outside, especially from the mass media and from regulators, state and federal agencies, and industry-wide consortia and working groups (including credible experts talking about the risk of legal liability), but also people inside companies needed to believe that the threat was not being overstated by doomsayers or IT departments seeking more turf.[3] [4] [5]
Auditors at private companies -- whose work was often required by insurers -- did lots of disclosure, separately from anything customers or the public at large demanded via grassroots action.[6]
Y2K was a software problem, and so countries that made a lot of stuff but made and used way less software didn't need to do nearly as much to address it. I see a bunch of stuff in the Y2K prep literature about the US and the UK, and way less about, for instance, China.
Companies in countries with stronger political rights and civil liberties disclosed more about their Y2K preparedness.[7] I'd assume that disclosure made market pressure more possible (from investors and customers) but I haven't researched it.
Apologies for how much of that research is behind paywalls.
I only looked at this for a few hours but (a) I think there are a lot of important differences between the structure of the Y2K problem (and its mitigations) and climate change, and (b) I believe the story's a lot more complicated than "mass panic -> billionaires finally paid up". I think widescale media attention to the concern played a big part in directly motivating regulators and institutional decisionmakers, and grassroots concern in the general public (as citizenry and as customer base) played a part in that, but it looks like insurers and auditors and industry groups were also really crucial. To sum up, yeah, we have lessons to learn from Y2K -- I'm drawn to Bob Bennett's phrasing, that we must be Paul Revere but not Chicken Little -- but I'm very hesitant about drawing the conclusion that literally panicking the world's populaces is the only way to drive climate change mitigation.
[1] Ho, A. T.-K., & Smith, J. F. (2001). Information Technology Planning and the Y2K Problem in Local Governments. The American Review of Public Administration, 31(2), 158–180. https://doi.org/10.1177/02750740122064901
[2] Huang, J. C., Newell, S., & S-L, P. (2001). The process of global knowledge integration: A case study of a multinational investment bank's Y2K program. European Journal of Information Systems, 10(3), 161-174. doi:http://dx.doi.org/10.1057/palgrave.ejis.3000402
[3]
Backus, George, et al. "Comparing Expectations to Actual Events: The Post Mortem of a Y2K Analysis." System Dynamics Review, vol. 17, no. 3, 2001, pp. 217. doi:http://dx.doi.org/10.1002/sdr.217.
[4] Chang, Hsiu-Hua, Chun-Po Yin, and Huey-Wen Chou. "Diffusion of Enterprise Resource Planning Systems in Taiwan: Influence Sources and the Y2K Effect." International Journal of Enterprise Information Systems, vol. 4, no. 1, 2008, pp. 34-47. doi:http://dx.doi.org/10.4018/jeis.2008010103.
[5] Solomon, H. (2005, Sep 23). Y2K: The disaster that wasn't. Computing Canada, 31, 46-48.
[6] Clarkson, Peter M., Colin Ferguson, and Jason Hall. "Auditor Conservatism and Voluntary Disclosure: Evidence from the Year 2000 Systems Issue." Accounting and Finance, vol. 43, no. 1, 2003, pp. 21.
[7] S, M. W. (2004). An international investigation of associations between societal variables and the amount of disclosure on information technology and communications problems: The case of Y2K. The International Journal of Accounting, 39(1), 71-92.
#11 Sep 2018, 08:55AM: Now Imagine Switching The Lead Actors For Those Two Shows:
I was in the midst of talking with my pal Jed about Star Trek: The Next Generation. He'd kindly checked whether I was ok hearing criticisms of this show-of-my-heart and I said dismissiveness no, criticism yes. We talked a little about Picard. I said how interesting it is that he's an introvert leader, how we don't often see that kind of person represented on TV. (And I informed him that I want him to text me immediately once he watches "Allegiance".) But he's still collaborative and listens well to his subordinates...
Me: you did not warn me you were going to be that incisive when we started this phone call.
I mean, maybe! In some ways Star Trek: The Next Generation* is to my management style as Mad About You is to my marriage style -- the formative-influence TV show that I, sometimes even consciously, modeled myself after. But maybe it goes deeper -- maybe those are also shows that made me think it would be awesome to be a leader, and to be married.
I’m interested in hearing about [open source software] projects that have successfully adopted an "only insiders use the issue tracker" approach. For instance, a project might have a mailing list where users discuss bugs in an unstructured way, and project insiders distill those discussions into bug reports to be entered into the issue tracker. Where does this approach succeed, and where does it fail? How can projects that operate this way effectively communicate their expectations to non-insider users, especially those users who might be more accustomed to using issue trackers directly?
Both Kuper and York get at: How do we open source maintainers get the bug reports we need, in a way that works for us and for our users?
My short answer is that open source projects should have centralized bug trackers that are as easy as possible to work in as an expert user, and that they should find automated ways to accept bug reports from less structured and less expert sources. I'll discuss some examples and then some general principles.
Dreamwidth: Dreamwidth takes support questions via a customer support interface. The volunteers and paid staff answering those questions sometimes find that a support request reveals a bug, and then file it in GitHub on the customer's behalf, then tell her when it's fixed. (Each support request has a private section that only Support can see, which makes it easier to track the connection between Support requests and GitHub issues, and Support regulars tend to have enough ambient awareness of both Support and GitHub traffic to speak up when relevant issues crop up or get closed.) Dreamwidth users and developers who are comfortable using the GitHub issue tracker are welcomed if they want to file bugs there directly instead.
Dreamwidth also has a non-GitHub interface for feature suggestions: the suggestions form is the preferred interface for people to suggest new features for Dreamwidth. Users post their suggestions into a queue and a maintainer chooses whether to turn that suggestion into a post for open discussion in the dw-suggestions community, or whether to bounce it straight into GitHub (e.g., for an uncontroversial request to whitelist a new site for media embedding or add a new site for easy cross-site user linking, or at the maintainer's prerogative). Once a maintainer has turned a suggestion into a post, other users use an interface familiar to them (Dreamwidth itself) to discuss whether they want the feature. Then, if they and the maintainer come to consensus and approve it, the maintainer adds a ticket for it to GitHub. That moderation step has been a bottleneck in the past, and the process of moving a suggestion into GitHub also hasn't yet been automated.
Since discussion about site changes needs to include users who aren't developers, Dreamwidth maintainers prefer that people use the suggestions form; experienced developers sometimes start conversations in GitHub, but the norm (at least the official norm) is to use dw-suggestions; I think the occasional GitHub comment suffices for redirecting these discussions.
Zulip: We use GitHub issues. The Zulip installations hosted by Kandra Labs (the for-profit company that stewards the open source project) also have a "Send feedback" button in one of the upper corners of the Zulip web user interface. Clicking this opens a private message conversation with feedback-at-zulip.com, which users used more heavily when the product was younger. (We also used to have a nice setup where we could actually send you replies in-Zulip, and may bring that back in the future.)
I often see Tim Abbott and other maintainers noticing problems that new users/customers are having and, while helping them (via the zulip-devel mailing list, via the Zuliping-about-Zulip chat at chat.zulip.org, or in person), opening GitHub issues about the issue, as the next step towards a long-term fix. But -- as with the Dreamwidth example -- it is also fine for people who are used to filing bug reports or feature requests directly to go ahead and file them in GitHub. And if Tim et alia know that the person they're helping has that skill and probably has the time to write up a quick issue, then the maintainers will likely say, "hey would you mind filing that in GitHub?"
I think another good topic is to just have folks list the things that feel like they're some of our uglier/messier parts of the UI that should be getting attention. We can use this topic to collect them :).
Several people spoke up about little irritations, and we ended up filing and fixing multiple issues. One of Zulip's lead developers, Steve Howell, reflected: "As many bug reports as we get normally, asking for 'warts' seems to empower customers to report stuff that might not be considered bugs, or just empower them to speak up more." I'd also point out that some people feel more comfortable responding to an invitation in a synchronous conversation than initiating an asynchronous one -- plus, there's the power of personal invitation to consider.
As user uptake goes up, I hope we'll also have more of a presence on Twitter, IRC, and Stack Overflow in order to engage people who are asking questions there and help them there, and get proto-bug reports from those platforms to transform into GitHub issues. We already use our Twitter integration to help -- if someone mentions Zulip in a public Tweet, a bot tells us about it in our developers' livechat, so we can log into our Twitter account and reply to them.
MediaWiki and Wikimedia: Wikipedia editors and other contributors have a lot of places they communicate about the sites themselves, such as the technical-issues subforum of English Wikipedia's "Village Pump", and similar community-conversation pages within other Wikipedias, Wikivoyages, etc. Under my leadership, the team within Wikimedia Foundation's engineering department that liaised with the larger Wikimedia community grew more systematic about working with those Wikimedia spaces where users were saying things that were proto-bug reports. We got more systematic about listening for those complaints, filing them as bugs in the public bug tracker, and keeping in touch with those reporters as bugs progressed -- and building a kind of ambassador community to further that kind of information dissemination. (I don't know how well that worked out; I think we built a better social infrastructure for people who were already doing that kind of volunteer work ad hoc, but I don't know whether we succeeded in recruiting more people to do it, and I haven't kept a close eye on how that's gone in the years since I left.)
We also worked to make it easy for people to report bugs into the main bug tracker. The Bugzilla installation we had for most of the time that I was at Wikimedia had two bug reporting forms: a "simple" submission form that we pointed most people to, with far fewer fields, and an "advanced" form that Wikimedia-experienced developers used. They've moved to Phabricator now, and I don't know whether they've replicated that kind of two-lane approach.
A closed-source example: FogBugz. When I was at Fog Creek Software doing sales and customer support, we used FogBugz as our internal bug tracker (to manage TODOs for our products,* and as our customer relationship manager). Emails into the relevant email addresses landed in FogBugz, so it was easy for me to reply directly to help requests that I could fix myself, and easy for me to note "this customer support request demonstrates a bug we need to fix" and turn it into a bug report, or open a related issue for that bug report. If I recall correctly, I could even set the visibility of the issue so the customer could see it and its progress (unusual, since almost all our issue-tracking was private and visible only within the company).
some spam messages managed to send mails to -done addresses. Those are usually easily caught, and given that everything can get reverted easily it's not that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.
The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.
But being open and inviting everyone to work on bugs totally outweighs the troubles that sometimes pop up because of misuse of the control bot.
And that leads us to:
General guidelines: Dreamwidth, Zulip, MediaWiki, and Debian don't discourage people from filing bug reports in the official central bug tracker. Even someone quite new to a particular codebase/project can file a very helpful and clear bug report, after all, as long as they know the general skill of filing a good bug report. Rather, I think the philosophy is what you might find in hospitable activism in general: meet people where they are, and provide a means for them to conveniently start the conversation in a time, place, and manner that's more comfortable for them. For a lot of people, that means email, or the product itself.
Failure modes can include:
a disconnect among the different "places" such that the central bug tracker is a black hole and nothing gets reported back to the more accessible place or the original reporter
a feeling of elitism where only special important people are allowed to even comment in the main bug tracker
bottlenecks such that it seems like there's a non-bug-tracker way to report a question or suggestion but that process has creaked to a halt and is silently blocking momentum
bottlenecks in bug triage
brusque reaction at the stage where the bug report gets to the central bug tracker (e.g., "oh that's a duplicate; CLOSE" without explanation or thanks), which jars the user (who's expecting more explicit friendliness) and which the user perceives as hostile
Whether or not you choose to increase the number of interfaces you enable for bug reporting, it's worth improving the user experience for people reporting bugs into your main bug tracker. Tedious, lots-of-fields issue tracker templates and UIs decrease throughput, even for skilled bug reporters who simply aren't used to the particular codebase/project they're currently trying to file an issue about. So we should make that easier. You can provide an easy web form, as Wikimedia did via the simplified Bugzilla form, or an email or in-application route, as Debian does.
# (1) 04 Apr 2017, 12:37PM: How to Teach And Include Volunteers who Write Poor Patches:
You help run an open source software community, and you've successfully signalled that you're open to new contributors, including people who aren't professional software engineers. And you've already got an easy developer setup process and great test coverage so it's easy for new people to get up and running fast. Great!
Some of the volunteers who join you are less-skilled programmers, and they're submitting pull requests/patches that need a lot of review and reworking before you can merge them.
How do you improve these volunteers' work, help them do productive things for the project, and encourage and include them?
My suggestions for you fall into three categories: helping them
improve their code, dealing with the poor-quality pull requests
themselves, and redirecting their energies to improve the project in other ways.
Teaching them to improve their code
Collect and suggest relevant learning resources, like certain talk recordings or freely available articles/exercises (e.g. The Architecture of Open Source Applications), and ask them to come back after they've watched/read/done them. Example: Zulip's collection.
If developers have trouble writing good comments and commit messages, or diving into the codebase to find relevant files and commits, point them to my blog post "On the scientific method and usable history". It explains why it's important to do that, and gives them pointers.
Ask more experienced contributors to pair program with them, both as leader and as follower. Here are a few tools to help.
Follow Sage Sharp's advice on three-phase review, and consider using nicely phrased labels/tags in your patch tracker to indicate what phase the PR is in. Then you can, while reviewing, search for particular labels and concentrate on a class of patches at once.
Be kind even as you criticize (see this Zulip example) and prioritize getting back to people fast, to signal that you genuinely want them to come back with a better patch (see this Mozilla analysis).
Using their knowledge and curiosity to improve the project in other ways
Ask these developers to write "discovery reports". They're already user-testing your developer onboarding process; ask them for their experiences, so you can find and fix pain points.
Ask them to run through some manual testing (example manual testing guide from Zulip), and to tell you how long certain kinds of tests took, so you can get bug reports and improve the docs.
Ask them to teach about your project in their communities -- to develop learning and presentation materials and speak at meetups. You may have just found your most enthusiastic marketer.
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.
Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.
I think anyone who thinks for a second about awards -- assuming the judgment is carried out in good faith -- says, well, it's to reward excellence. Yup! But what are the particular ways an award rewards excellence, and when might an award be a useful tool to wield?
Let's say you are an organization and you genuinely want to celebrate and encourage some activity or principle, because you think it's important and there's not enough of it, particularly because there are so many norms and logistical disincentives pushing to reduce it. For example, you might want to encourage altruistic resistance. Let's say your organization already has a bunch of ongoing processes, like teaching or making products or processing information, and maybe you make some changes in those processes to increase how likely it is that you're encouraging altrustic resistance, but that isn't really apparent to the world outside your doors in the near term, and the effects take a while to percolate out.
So maybe you could set up an award. An award can:
get publicity for the idea that altruistic resistance is a thing to celebrate
help one specific person or group who's currently practicing altruistic resistance keep going, with money and attention, and make a big difference to their stamina and effectiveness
maybe bring attention to a list of finalists and help their work get more coverage
ensure the award administrators (and any judging committee involved) and, to a lesser extent, the reporters covering the award, will spend time thinking about the importance of altruistic resistance
cause a bunch of people to think "hmm, whom should I nominate?" and write a couple paragraphs about why their work is good and award-worthy (and, by causing that writing, also solidify the nominators' commitment to respecting and rewarding altruistic resistance)
demonstrate your institutional commitment to altruistic resistance, potentially sending a hard-to-ignore message to your future self to guide future decisions
And if an award keeps going and catches on, then people start using it as a shorthand for a goal. New practitioners can dream of winning the acclamation that a Pulitzer, a Nobel, a Presidential Medal of Freedom carries. If there's an award for a particular kind of excellence, and the community keeps records of who wins that award, then in hard moments, it can be easier for a practitioner to think of that roll call of heroes and say to herself in hard moments, "keep on going". We put people on pedestals not for them, but for us, so it's easier for us to see them and model ourselves after them.
So, all awards are simplistic summative judgments, but if the problem is that we need to balance the scales a bit, maybe it'll help anyway.
# (1) 31 Oct 2016, 11:47AM: How Do We Encourage Technologists in the Public Interest?:
As I mentioned when the Recompiler interviewed me, my inspirations and role models in technology are technologists who serve the public interest. The person who introduced me to free and open source software, Seth Schoen, is a kind teacher and a rigorous thinker who deploys his software engineering expertise at the intersection of technology and activism. I was lucky enough to meet the right people early in my career so I see public interest technology as a desirable and viable career path AND something you can integrate into a career that doesn't focus on nonprofit/government work -- but not enough people know about it, and not enough institutions encourage it.
How do we help encourage and employ more Seths, more Bruce Schneiers, more Eleanor Saittas, more Kelsey Gilmore-Innises? If you were to say "Sumana, that's a pretty infosecurity-centric list there, what about people who are more about analytics to enable policy work, or the web developers at 18F, or --" then I would agree with you! This is a broad and deep field, and thus a broad and deep question.
Again and again, we were told that public interest organizations and government will not succeed if they do not quickly figure out how to better harness the wave of innovation sweeping the world, and that one key element of that challenge will be to implement more effective strategies for developing and integrating technologists into relevant organizations and projects.
That is from A Pivotal Moment: Developing a New Generation of Technologists for the Public Interest, a new report that aims to help philanthropists choose what to fund (and how) to make this change happen. This is not just a bunch of vague "let's grow the pipeline" stuff. The authors interviewed 60 experts, laid out 26 specific things we can do (many of which are already in progress), and made a bunch of recommendations. Section III, starting on page 10 (page 16 of the PDF), summarizes the interventions in five categories: interest cultivation, skill-building, recruitment and training, skill deployment, and growth and retention.
If you can influence decisions on grants or donations, or if you just want a framework for thinking about this problem and its solutions (and where your existing work sits in the ecology), check out the report.
#27 Oct 2016, 11:06AM: Learning Styles:
For years, while mentoring others, I've been using these engineering learning styles as a tool to help newer engineers reflect on how they learn, and to give them a sense of the possible toolbox of learning approaches, so that if they get stuck, they can recognize what approach they're using and try another one. But students don't have different learning styles, really, per science-based required reading for a Software Carpentry train-the-trainer class I'm about to attend. I need to rework my advice.
#04 Aug 2016, 03:51PM: Advice on Starting And Running A New Open Source Project:
Recently, a couple of programmers asked me for advice on starting and running a new open source project. So, here are some thoughts, assuming you're already a programmer, you haven't led a team before, and you know your new software project is going to be open source.
I figure there are a few different kinds of best practices in starting and running open source projects.
General management: Some of my recommendations are the same kinds of best practices that are useful anytime you're starting/running/managing any kind of project, inside or outside the software world.
For instance: know why you're starting this thing. Write down even just a one-paragraph or 100-word bulleted list description of what you are aiming at. This will reduce the chance that you'll look up one day and see that your targeted little tool has turned into a mess that's trying to be an entire operating system.
And: if you're making something that you want other people to use, then check what those other people are already using/doing, so you can make sure you suit their needs. This guards against any potential perception that you are starting a new project thoughtlessly, or just for the heck of it, or to learn a new framework. In the software world, this includes taking note of your target users' dependencies (e.g., the versions of Python/NumPy that they already have installed).
Resources I have found useful here include William Ball's book on theatrical direction A Sense of Direction, Dale Carnegie's How to Win Friends and Influence People, Fisher & Ury's Getting To Yes, Cialdini's Influence: The Science of Persuasion, and Ries & Trout's Positioning: The Battle for Your Mind.
Tech management: Some best practices are the same kinds of habits that help in managing any kind of software project, including closed-source projects as well.
For instance: more automated tests in/for your codebase are better, because they reduce regressions so you can move faster and merge others' code faster (and let others review and merge code faster), but don't sweat getting to 100%, because there's definitely a decreasing marginal utility to this stuff. Travis CI is pretty easy to set up for the common case.
Open source management: And some best practices are the specific social, product management, architectural, and infrastructural best practices of open source projects. A few examples:
If you're the maintainer, it's key to reply to new project-related emails, queries, bug reports, and patches fast; a Mozilla analysis backs up our experience that a kind, fast, negative response is better than a long silent delay. Reply to people fast, even if it's just "I saw this, thank you, I'm busy, will get to this in a few weeks," because otherwise the uncertainty is deathly and people's enthusiasm and momentum drip away.
Make announcements somewhere public and easily findable that say something about the current state of your project, e.g., about whether it's ready to use or when to expect it to be. This could even just be someplace prominent in your README when you're just getting started. This is also a good place to mention if you're going to be at any upcoming conferences, so people can connect to you that way.
Especially when it comes to code, docs, and bug/feature/task lists, work in the open from as early as possible, preferably from the start. Treat private work as a special case (sometimes a useful one when it comes to communication with users and with new contributors, as a tidepool incubates growth that can then flow into the ocean).
I am sad, as a FLOSS zealot, to say that you should probably be on the closed-source platform that is GitHub. But yeah, the intake funnel for code and bug contributors is easier on GitHub than on any other platform; unless you are pretty sure you already know who all the people are who will use and improve this software, and they're all happy on GitLab or similar, GitHub is going to get you more and faster contributors.
You are adjacent to or embedded in other programming communities, like the programming language & frameworks you're using. Use the OSI-approved license that the projects you're adjacent to/depending on use, to make reuse easier.
It's never too early to think about governance. As Christie Koehler of Authentic Engine warns, to think about codes of conduct, you also gotta think about governance. (The Contributor Covenant is a popular starting point.) If you can be under the umbrella of a software-related nonprofit, like NumFOCUS, that'll help you make and implement these choices.
Top reading recommendation: Karl Fogel's Producing OSS is basically the bible for this category, and the online version is up-to-date with new advice from this year. If you read Producing OSS cover-to-cover you will be entirely set to start and run your project.
#23 May 2016, 10:02AM: Two OSCON Conversations, And A Trip Report Between Them:
Conversation the last night of OSCON, reconstructed from memory:
"So, Neil Young --"
"The singer-songwriter?"
"Yeah."
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"
In honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.
My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.
These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.
I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.
I shall carry with me several memories of this OSCON, such as:
Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
Listening to an enthralling performance by rapper Sammus
Discussing pull request workflow, Contributor Licensing Agreements, the engagement funnel, the future of OpenHatch and of Apache Zookeeper, the failings of Google Summer of Code, whether GitHub should allow no-license repositories, how Facebook/Amazon/Google's idiosyncrasies come out in their open source work, performing femininity in the workplace, productivity and routines, effectively signalling to one's employees that they should not work on weekends, what maintainership is, JavaScript and data binding, and BLESS
Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!
But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.
He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.
Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it] Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this] Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here] Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card] Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."
Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.
#21 Mar 2016, 04:58PM: What Is Maintainership?:
Yesterday, at my first LibrePlanet conference, I delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I spoke without a script, and what follows is what I meant to say; I hope it bears a strong resemblance to what I actually said. I do not know whether any video of this session will appear online; if it does, I'll update this entry.
What is Maintainership?
Or, approaches to filling management skill gaps in free software
Sumana Harihareswara, Changeset Consulting
LibrePlanet, Cambridge, MA, 20 March 2016
Why do we have maintainers in free software projects? There are various different explanations you can use, and they affect how you do the job of maintainer, how you treat maintainers, how and whether you recruit and mentor them, and so on.
So here are three -- they aren't the only ways people think about maintainership, but these are three I have noticed, and I have given them alliterative names to make it easier to think about and remember them.
Sad: This is a narrative where even having maintainers is, fundamentally, an admission of failure. Jefferson said a lot of BS, but one thing he said that wasn't was: "If men were angels, we would have no need of government." And if every contributor contributed equally to bug triage, release management, communication, and so on, then we wouldn't need to delegate that responsibility to someone, to a maintainer. But it's not like that, so we do. It's an approach to preventing the Tragedy of the Commons.
I am not saying that this approach is wrong. It's totally legitimate if this is how you are thinking about maintainership. But it's going to affect how your community does it, so, just be aware.
Skill: This approach says, well, people want to grow their skills. This is really natural. People want to get better, they want to achieve mastery, and they want validation of their mastery, they want other people to respect their mastery. And the skill of being a maintainer, it's a skill, or a set of skills, around release management, communication, writing, leadership, and so on. And if it's a skill, then you can learn it. We can mentor new maintainers, teach them the skills they need.
So in this approach, people might have ambition to be maintainers. And ambition is not a dirty word. As Dr. Anna Fels puts it in her book Necessary Dreams, ambition is the combination of the urge to achieve mastery of some domain and the desire to have your peers, or people you admire, acknowledge, recognize, validate your mastery.
With this skills approach, we say, yeah, it's natural that some people have ambition to get better as developers and also to get better at the skills involved in being a maintainer, and we create pathways for that.
Sustain: OK, now we're talking about the economics of free software, how it gets sustained. If we're talking about economics, then we're talking about suppply and demand. And I believe that, in free software right now, there is an oversupply of developers who want to write feature code, relative to an undersupply of people with the temperament and skills and desire to do everything else that needs doing, to get free software polished and usable and delivered and making a difference. This is because of a lot of factors, who we've kept out and who got drawn into the community over the years, but anyway, it means we don't have enough people who currently have the skill and interest and time to do tasks that maintainers do.
But we have all these companies, right? Companies that depend on, that are built on free software infrastructure. How can those with more money than time help solve this problem?
[insert Changeset Consulting plug here]. You can hire my firm, Changeset Consulting, to do these tasks for a free software project you care about. Changeset Consulting can do bug triage, doc rewriting, user experience research, contributor outreach, release management, customer service, and basically all the tasks involved in maintainership except for the writing and reviewing of feature code, which is what those core developers want to be doing anyway. It's maintainer-as-a-service.
Of course you don't have to hire me. But it is worth thinking about what needs to be done, and disaggregating it and seeing what bits companies can pay for, to help sustain the free software ecology they depend on.
So: sad, skill, sustain. I hope thinking about what approach you are taking helps your project think about maintainership, and what it needs to do to make the biggest long-term impact on software freedom. Thank you.
#23 Feb 2016, 04:00PM: Leadership Crisis at the Wikimedia Foundation:
This week, the Wikimedia Foundation, the main organization supporting Wikipedia and several other free knowledge projects, is at the peak of a leadership crisis more than a year in the making. Molly White's timeline of the crisis is a useful guide to the facts, and I feel compelled to speak publicly for the first time about the problem, and share my personal perspective, with a bit of context to help non-Wikimedians understand.
I left the Wikimedia Foundation in September 2014 after four years. I mentioned the reasons then, in that post, around learning new things and working on projects with less of a public spotlight. I'm happy with my new direction, Changeset Consulting LLC, but still have so many fond memories of working with fantastic people and making a difference.
I left WMF thinking that it was fine -- in fact, that's a reason I felt okay about deciding to leave a place I cared about so much, because I thought WMF could cope without me. As I perceived it, former Executive Director (nonprofit-speak for "CEO" basically) Sue Gardner had led the organization to a stable enough place that she felt free to move on. For years, when I was at Wikimedia Foundation, our top priority was reversing the decline in the number of active Wikipedia contributors and other Wikimedia contributors; Sue Gardner articulated this priority and ensured everyone knew what we were aiming at and why. Lila Tretikov, the new executive director, was settling in and I perceived WMF to be on the right track, iteratively moving closer to reversing the editor decline, with solid management and plans in place to keep positive momentum going. I thought the conflicts and stumbles from summer 2014 were normal temporary pains, not unusually worrying.
A few months after I left, when I caught up with old Foundation colleagues, I started hearing wariness about the new high-level management (the ED and some other newer executive hires). The worries progressed into stronger and stronger concerns, getting more and more disturbing. For instance, in November 2015, a committee that disseminates Wikimedia funds to budget other Wikimedia institutions (such as chapters) wrote a scathing critique:
...the [Funds Dissemination Committee] laments that the Wikimedia Foundation's own planning process does not meet the minimum standards of transparency and planning detail that it requires of affiliates applying for its own Annual Plan Grant (APG) process....
The FDC is appalled by the closed way that the WMF has undertaken both strategic and annual planning, and the WMF's approach to budget transparency (or lack thereof).
I nearly could not believe my eyes when I saw this. For those of you who don't follow these bureaucracies, let me assure you that the FDC does not throw around words like "appalled" lightly. (Followup on the FDC recommendations.)
I have confidence in senior leadership at Wikimedia: 10% agree
It is a miracle if 90% of Wikimedia Foundation personnel agree on anything beyond the fact that WMF's commitment is to "a world in which every single human being can freely share in the sum of all knowledge." And to be clear, "confidence in senior leadership" here means that the employees trust that the C-level executives have the basic competence to run the organization. This isn't about agreeing or disagreeing on particular choices of method; when I was at WMF, the Executive Director and the Chief ____ Officers made decisions that some employees disagreed with, but they explained their reasoning, they encouraged feedback and responded to it (example), and we fundamentally knew they were aiming to collaborate with us in achieving the mission. It sounds like some big pieces of that trust are now missing.
1. In late December the Board of Trustees dismissed a well-liked community-elected trustee, Dr. James Heilman, for reasons that remain somewhat mysterious...
3. Revelations about newly appointed Board trustee Arnnon Geshuri's involvement in an illegal anti-poaching scheme while at Google has drawn community outcry
4. Besides failing to vet Geshuri, the WMF's increasing tilt toward the Silicon Valley and focus on (perhaps) the wrong technology projects have come into sharper relief
So, Arnnon Geshuri. You know that scandal where it came to light that big Silicon Valley tech firms were colluding to suppress wages and reduce employee mobility with illegal "no-poaching" agreements? With evidence including super damning emails? Guess who sent some of that email, perpetuating that pact? Arnnon Geshuri. The WMF Board of Trustees appointed him as one of the trustees. He's since stepped down but the incident damaged already-shaky trust between the Board and the larger Wikimedia community.
And as of last week it's clear that the situation's gotten even more dire. Fantastic colleagues are voting with their feet and leaving (and do you know how hard it is to find and hire the right people for an org this weird and this important?). People who would rather walk with rocks in their shoes than throw their coworkers under the bus are compelled to speak in public about dysfunction at the top: Ori Livneh, Anna Stillwell, and Greg Grossmeier, for instance, and Brion Vibber, who was the first employee the Foundation ever hired. Faidon Liambotis, Principal Operations Engineer at the Foundation & a longtime Debian Developer. Gayle Karen Young, former WMF Chief Talent & Culture Officer, who has a world-class ability to fuse compassion and systems-level thinking in the management of people processes, writes publicly about "dysfunction at the top" and "the enormous toll" it's taking on the staff. Erik Möller, who served on the Board of Trustees before he served as WMF second-in-command for more than seven years and then left in April 2015, a guy who has seen a thousand Wikimedia thunderstorms come and go and could probably charge for calm-as-a-service, says that "the situation is very much out of control" and "this is a crisis". This is not just the ordinary grumblings of a transparent organization. This is dire.
But overall, it seems premature of speaking of "stemming the decline", unless I'm missing something (entirely possible).
There have been a thousand thunderstorms before. The Image Filter, SOPA, the transition from Toolserver to Tool Labs, Narrowing Focus, paid editing, the first VisualEditor rollout, the India Education Program, I could keep going and the point is that we Wikimedians have big ideas and big passionate arguments and we know some things about how to get through them. The movement, thank goodness, is bigger than the Foundation. The volunteers, the chapter staff, the teachers and photographers and coders and editors and everyone in the hundreds of subcommunities in our ecology have some buffers against the ripples coming out of the Foundation. There's frustration, sometimes, in how hard it can be for one subcommunity or organization to persuade or lend a hand to another, but right now it's a good thing because there is short-term resilience in that loosely federated structure.
This has been a singularly destructive time, but we still have time to keep the leadership problem from further damaging the Wikimedia movement.
One of the things I admire about Wikimedia's best institutions is our willingness to reflect and reinvent when things are not working.
I don't know what the answer is.
The choice between exit and voice is conditioned on loyalty. We know that Wikimedians have been exercising the "voice" option; the Board and the ED have heard these criticisms loud and clear. And we know they've witnessed the stream of talented employees exiting, their steel-clad loyalty finally succumbing to the pressure. If unaltered, this is the kind of dynamic that leads to schisms and forks. I would hate for the movement to have to pay that kind of cost but, unless the Wikimedia Foundation Board of Trustees and Executive Director change course, I think that's a potential outcome.
#19 Feb 2016, 06:50PM: What Should We Stop Doing? (FLOSS Community Metrics Meeting keynote):
"What should we stop doing?": written version of a keynote address by Sumana Harihareswara, delivered at the FLOSS Community Metrics Meeting just before FOSDEM, 29 January 2016 in Brussels, Belgium. Slide deck is a 14-page PDF. Video is available. The notes I used when I delivered the talk were quite skeletal, so the talk I delivered varied substantially on the sentence level, but covered all the same points.
I'd like to start with a story, about my excellent boss I worked for when I was at the Wikimedia Foundation, Rob Lanphier, and what he told me when I'd been on the job about eight months. In one of our one-on-one meetings, I mentioned to him that I felt overwhelmed. And first, he told me that I'd been on the job less than a year, and it takes a year to ramp up fully in that job, so I shouldn't be too worried. And then he reminded me that we were in an amazing position, that we would hear and get all kinds of great ideas, but that in order to get anything done, we would have to focus. We'd have to learn to say, "That's a great idea, and we're not doing it." And say it often. And, he reminded me, I felt overwhelmed because I actually had the power to make choices, about what I did with my time, that would affect a lot of people. I was not just cog # 15,000 doing a super specialized task at Apple.
So today I want to talk with you about how to use the power you have, in your open source projects and organizations, and about saying no to a lot of things, so you can focus on doing fewer things well -- the Unix philosophy, right? I'll talk about a few tools and leave you with some questions.
Tool 1: Remember to say no to the lamppost fallacy
The lamppost fallacy is an old one, and the story goes that a drunk guy says, "I dropped my keys, will you help me look for them?" "OK, sure. Where'd you drop them?" "Under that tree." "So why are you looking for them under this lamppost?" "Well, the light is better here."
A. Quantitative vs qualitative in the dev data
The first place we ought to check for the lamppost fallacy is in overvaluing quantitative metrics over qualitative analysis when looking at developer workflow and experience. Dave Neary said, in the FLOSSMetrics meeting in 2014, in "What you measure is what you get. Stories of metrics gone wrong": Use qualitative and quantitative analysis to interpret metrics.
When it comes to developer experience, you can be analytical while both quantitative and qualitative. And you rather have to be, because as soon as you start uncovering numbers, you start asking why they are what they are and what could be done to change that, and that's where the qualitative analytical approach comes in.
qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.
This is applicable to developer experience as well!
For help, I recommend the Wikimedia movement's Grants Evaluation & Learning team's table discussing quantitative and qualitative approaches you can take: ethnography, case studies, participant observation, and so on. To deepen understanding. It's complementary with the quantitative side, which is about generalizing findings.
B. Quantifiable dev artifacts-and-process data versus data about everything else
Another place to check for the lamppost fallacy is in overvaluing quantifiable data about programming artifacts and process over all sorts of data about everything else that matters about your project. Earlier today, Jesus González-Barahona mentioned the many communities -- dev, contributor, user, larger ecosystem -- that you might want to research. There's lots of easily quantifiable data about development, yes, but what is actually important to your project? Dev, user, sysadmin, larger ecology -- all of these might be, honestly, more important to the success of your mission. And we also know some things about how to get better at getting user data.
Tool 2: know what kind of assessment you're trying to do and how it plays into your theory of change
Another really important tool that will help you say no to some things and yes to others is knowing what kind of assessment you're trying to make, and how that plays into your hypothesis, your theory of change.
I'm going to mess this up compared to a serious education researcher, but it's worth knowing the basics of the difference between formative and summative assessments.
Formative assessment or evaluation is diagnostic, and you should use it iteratively to make better decisions to help students learn with better instruction & processes.
Summative assessment is checking outcomes at the conclusion of an exercise or a course, often for accountability, and judging the worth/value of that educational intervention. In our context as open source community managers, this often means that this data is used to persuade bosses & community that we're doing a good job or that someone else is doing a bad job.
As Dawn Foster last year said in her "Your Metrics Strategy" speech at the FLOSSMetrics meeting:
METRICS ARE USEFUL Measure progress, spot trends and recognize contributors.
Start with goals: WHY FOCUS ON GOALS? Avoid a mess: measure the right things, encourage good behavior.
Here's Ioana Chiorean, FLOSS Community Metrics meeting, January 30th 2015, "How metrics motivate":
Measure the right things... specific goals that will contribute to your organization's success
Dave Neary in 2014 in "What you measure is what you get. Stories of metrics gone wrong" at the Metrics meeting said:
be careful what you measure: metrics create incentives
Focus on business and community's success measurements
And this is tough. Because it can be hard to really make a space for truly formative assessment, especially if you are doing everything transparently, because as soon as you gather and publish any data, people will use it to argue that we ought to make drastic changes, not just iterative changes. But it might help to remember what you are truly aiming at, what kind of evaluation you really mean to be doing.
And it helps a lot to know your Theory of Change. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B.
There's a chicken and egg problem here. How do you form the hypothesis without doing some initial measurement? And my perhaps subversive answer is, use ideas from other communities and research to create a hypothesis, and then set up some experiments to check it. Or go with your gut, your instinct about what the hypothesis is, and be ready to discard it if the data does not bear it out.
For help: Check out educational psychology, such as cognitive apprenticeship theory - Mel Chua's presentation here gives you the basics. You might also check out the Program/Grant Learning & Evaluation findings from Wikimedia, and try out how the "pirate metrics" funnel -- Acquisition, Activation, Retention, Referral, Revenue, or AARRR -- fits with your community's needs and bottlenecks.
Tool 3: if something doesn't work, acknowledge it
And the third tool is that when we see data saying that something does not work, we need to have the courage to acknowledge what the data is saying. You can move the goalposts, or you can say no and cause some temporary pain. We have to be willing to take bug reports.
Here's an example. The Wikimedia movement likes to host editathons, where a bunch of people get together and learn to edit Wikipedia together. We hoped that would be a way to train and retain new editors. But Wikipedia editathons don't produce new long-term editors. We learned:
About 52% of participants identified as new users made at least one edit one month after their event, but the percentage editing dropped to 15% in the sixth months after their event
Inviting contribution by surfacing geo-targeted article stubs was not enough to motivate or help users to make their first edits to an article. Together, all new editors who joined made only six edits in total to the article space during this experiment, and they made no edits to the articles we suggested.
Providing suggestions via links to places users might go for help did not appear to sufficiently support or motivate these new editors to get involved. 50 percent of those surveyed later said they didn’t look for help pages. Those who did view help pages nevertheless did not edit the suggested articles.
But over and over in the Wikimedia movement I see that we keep hosting those one-off editathons. And they do work to, for instance, add new high-quality content about the topics they focus on, and some people really like them as parties and morale boosters, and I've heard the argument that they at least get a lot of people through that first step, of creating an account and making their first edit. But that does not mean that they're things we should be spending time on, to reverse the editor decline trend. We need to be honest about that.
It can be hard to give up things we like doing, things we think are good ideas and that ought to work. As an example: I am very much in favor of mentorship and apprenticeship programs in open source, like Google Summer of Code and Outreachy. Recently some researchers, Adriaan Labuschagne and Reid Holmes, raised questions about mentorship programs in "Do Onboarding Programs Work?", published in 2015, about whether these kinds of mentorship programs move the needle enough in the long run, to bring new contributors in. It's not conclusive, but there are questions. And I need to pay attention to that kind of research and be willing to change my recommendations based on what actually works.
We can run into cognitive dissonance if we realize that we did something that wasn't actually effective. Why did I do this thing? why did we do this thing? There's an urge to rationalize it. The Wikimedia FailFest & Learning Pattern hackathon 2015 recommends that we try framing our stories about our past mistakes to avoid that temptation.
Big 'F' failure framing:
We planned this thing: __________________________
This is how we knew it wasn't working: __________________________
There might have been some issues with our assumption that: __________________________
If we tried it again, we might change: __________________________
Little 'f' failure framing:
We planned this thing: __________________________
This is how we knew it wasn't working: __________________________
We think that this went wrong: __________________________
One trend I see underlying a big chunk of FLOSS metrics work is the desire to automate the emotional labor involved in maintainership, like figuring out how our fellow contributors are doing, making choices about where to spend mentorship time, and tracking a community's emotional tenor. But is that appropriate? What if we switched our assumptions around and used our metrics to figure out what we're spending time on more generally, and tried to find low-value programming work we could stop doing? What tools would support this, and what scenarios could play out?
This is a huge question and I have barely scratched the surface, but I would love to hear your thoughts. Thank you.
#09 Aug 2015, 10:52PM: How To Improve Bus Factor In Your Open Source Project:
Someone in one of my communities was wondering whether we ought to build a new automated tool to give little tasks to newcomers and thus help them turn into future maintainers. I have edited my replies to him into the How To Build Bus Factor For Your Open Source Project explanation below.
In my experience (I was an open source community manager for several years and am deeply embedded in the community of people who do open source outreach), getting people into the funnel for your project as first-time contributors is a reasonably well-solved problem, i.e., we know what works. Showing up at OpenHatch events, making sure the bugs in the bug tracker are well-specified, setting up a "good for first-timers" task tag and/or webpage and keeping it updated, personally inviting people who have reported bugs to help you solve them, etc. If you can invest several months of one-on-one or two-on-one mentorship time, participate in Google Summer of Code and/or Outreachy internship programs. If you want to start with something that's quantitative and gamified, consider using Google Code-In as a scaffold to help you develop the rest of these practices.
You need to quickly thank and give useful feedback to people who are already contributing, even if that feedback will include criticism. A fast first review is key, and here's a study that backs that up. Slide 8: "Most significant barrier to engaging in onramping others is unclear communications and unfriendly community. Access to the right tools has some effect." Slide 26:
"Contributors who received code reviews within 48 hours on their first bug have an exceptionally high rate of returning and contributing.
Contributors who wait longer than 7 days for code review on their first bug have virtually zero percent likelihood of returning.
Showing a contributor the next bug they can work on dramatically improves the odds of contributing."
In my opinion, building bus factor for your project (growing new maintainers for the future) is also a solved problem, in that we know what works. You show up. You go to the unfashionable parts of our world where the cognitive surplus is -- community colleges, second- and third-tier four-year colleges, second- and third-tier tech hubs, boring enterprise companies. You review code and bug reports quickly, you think of every contributor (of any sort) as a potential co-maintainer, and you make friendly overtures to them and offer to mentor them. You follow OpenHatch's recommendations. You participate in Google Summer of Code and/or Outreachy internship programs.
Mentorship is a make-or-break step here. This is a key reason projects participate in internship programs like GSoC and Outreachy. For example, Angela Byron was a community college student who had never gotten involved in open source before, and then heard about GSoC. She thought "well it's an internship for students, it'll be okay if I make mistakes". That's how she got into Drupal. She's now a key Drupal maintainer.
Dreamwidth, an open source project, started with two maintainers. They specifically decided to make the hard decision to slow down on feature development, early on, and instead pay off technical debt and teach newcomers. Now they are a thriving, multimaintainer project. "dreamwidth as vindication of a few cherished theories" is perhaps one of my favorite pieces on how Dreamwidth did what it did. Also see "Teaching People to Fish" and this conference report.
Maintainers must review code, and that means that if you want someone to turn into a maintainer in your project, you must help them learn the skill of code review and you must help them get confident about vetoing and merging code. In my experience, yes, a good automated test suite does help people get more confident about merging changes in. But maintainers also need to teach candidates what their standards ought to be, and encourage them (many contributors' first thought when someone says "would you want to comaintain this project with me?" is "what? me? no! I'm not good enough!"). Here's a rough example training.
# (1) 21 Dec 2014, 11:10PM: Why You Have To Fix Governance To Improve Hospitality:
Fundamentally, if you want to make a community hospitable,* you need to work not just on individual rules of conduct, but on governance. This is because
the particular people implementing rules of conduct will use their judgment in when, whether, and how to apply those rules, and
you may need to go a few levels up and change not just who's implementing rules, but who's allowed to make rules in the first place
Sometimes it's the little stuff, more subtle than the booth babe/groping/assault/slur kind of stuff, that makes a community feel inhospitable to me. When I say "little stuff" I am trying to describe the small ways people marginalize each other but that I did not experience at Hacker School and thus that I noticed more after my sabbatical at Hacker School: dominance displays, cruelty in the guise of honesty, the use of power in inhospitable ways, feeling unvalued, "jokes", clubbiness, watching my every public action for ungenerous interpretation, nitpicking, and bad faith.
Another pattern of the privileged: not keeping track of the line between acceptable and unacceptable behavior. They only know they've crossed the line when someone in authority tells them so. If this doesn't happen, their behavior stays bad or gets worse....
Do not argue about their intentions. They'll swear they meant no harm, then sulk like fury because you even suggested it. In most cases they'll be telling the truth: the possibility that they were giving offense never crossed their minds. Neither did any other scenario, because unlike real adults, they take no responsibility for getting along with others. The idea that in a cooperative work situation, getting along with one's fellow employees is part of the job, is not in their worldview.
This too is a function of privilege. They assume they won't get hit with full penalties for their first offense (or half-dozen offenses), and that other people will always take on the work of tracking their behavior, warning them when they go over the line, and explaining over and over again what they should have done and why. It's the flip side of the way people of the marked state get hit with premature negative judgements (stupid, dishonest, sneaky, hysterically oversensitive) on the basis of little or no evidence.
And, in any community, rules often get much more leniently interpreted for members of the dominant group. And this is even harder to fight against when influential people believe that no marginalization is taking place; as Abi Sutherland articulates: "The problem with being lower on an unstated social hierarchy is that marginal judgment calls will
reliably go against you. It's an excusable form of reinforcement."**
Changing individual rules isn't enough. After all, individual rules get made by particular humans, who -- here, instead of babbling about social rule system theory at you, I'll give you a sort of sidebar about three successive levels of governance, courtesy of my bachelor's degree in political science:***
Actors: The actual set of people who run an organization or who shape agendas, on any given day, have particular ideas and policies and try to get certain things done. They implement and set and change regulations. Actors turn over pretty fast.
For example, in its five-year history, Hacker School has had employees come and go, and new participants have become influential alumni.
Dominant worldviews: More deeply and less ephemerally, the general worldview of the group of people who have power and influence (e.g., Democrats in the executive branch of the US government, sexists in mass media, surgeons in operating rooms, deletionists on English Wikipedia) determines what's desirable and what's possible in the long term. Churn is slower on this level.
Rules of the game: What is sacred? What is so core to our identity, our values, that breaking one of these means you're not one of us? The rules of the game (e.g., how we choose leaders, what the rulers' jurisdiction is) confer legitimacy on the whole process. Breaking these rules is heresy and amending them is very hard and controversial.***** Publicly disagreeing with the rules of the game costs lots of political capital.
For example, the rules of the game among Hacker Schoolers, as I see them, include: the founders of Hacker School and their employees have legitimate authority over admissions, hiring, and rule enforcement. Hacker School is (moneywise) free to attend. Admission is selective. A well-designed environment that helps people do the right thing automatically is better than one-on-one persuasion, which is still better than coercion.
(Where do the four Hacker School social rules fall in this framework? I don't know. Hacker School's founders encourage an experimental spirit, and I think they would rather stay fluid than accrete more and more sacred texts. But, as more and more participants have experienced a Hacker School with the four social rules as currently constituted, I bet a ton of my peers perceive the social rules as DNA at this point, inherent and permanent. I'm not far from that myself.)
(I regret that I don't have the citation to hand, and would welcome the name of the theorists who created this model.)
So, if you want a hospitable community, it's not enough to set up a code of conduct; a CoC can't substitute for culture. Assuming you're working with a pre-existing condition, you have to assess the existing power structures and see where you have leverage, so you can articulate and advocate new worldviews, and maybe even move to amend the rules of the game.
How do you start? This post has already gotten huge, so, I'll talk about that next time.
* I assume that we can't optimize every community or activity for hospitality and learning. Every collaborative effort has to balance execution and alignment; once in a while, people who have already attained mastery of skill x just need to mind-meld to get something done. But if we want to attract, retain, and grow people, we need to always consider the pathway to inclusion. And that means, when we accept behavior or norms that make it harder for people to learn, we should know that we're doing it, and ask whether that's what we want. We should check.
*** I am quite grateful for my political science background -- not least because I learned that socially constructed things are real too, which many computer science-focused people in my field seem to have missed, which means they can't mod or make new social constructs as easily. Requisite variety.
**** A non-comprehensive list, of course. And I don't feel equal to the more nuanced question: what beliefs do the most influential Hacker Schoolers hold, especially on topics where their worldview is substantially different from their peers'?
***** The US has a very demanding procedure for amending the Constitution. India doesn't. The US has had 27 amendments in 227 years; India, 98 in 67 years. I don't know how to interpret that.
I was working for Wikimedia Foundation for ~8 months before I broached the topic of a conference anti-harassment policy with the higher-ups - my boss & my boss's boss, both of whom liked the idea and backed me 100%. (I did not actually ask HR, although in retrospect I could have.) My bosses both knew that Not So Great things happen at conferences and they saw why I wanted this. They said they'd have my back if I got any flak.
So I borrowed the Ada Initiative's policy and modified it a little for our needs, and placed my draft on a subpage of my user page on our wiki. Then I briefly announced it to the mailing list where my open source community, MediaWiki, talks. I specifically framed this as not a big deal and something that lots of conferences were doing, and said I wanted to get it in place in time for the hackathon later that month. Approximately everyone in our dev community said "sure" or "could this be even broader?" or "this is a great idea", as you can see in that thread and in the wiki page's history and the talk page.
I usually telecommuted to WMF, but I happened to be in San Francisco in preparation for the hackathon, and was able to speak to colleagues in person. My colleague Dana Isokawa pointed out that the phrasing "Anti-harassment policy" was offputting. I agreed with her that I'd prefer something more positive, and I asked some colleagues for suggestions on renaming it. My colleague Heather Walls suggested "Friendly Space Policy". In a pre-hackathon prep meeting, I mentioned the new policy and asked whether people liked the name "Friendly Space Policy," and everyone liked it.
But approximately everyone on the community-wide list also thought the policy was fine -- both volunteers and paid WMF staffers. For instance, one colleague said:
"If a policy makes good sense, we clearly need it, and feedback about the text is mostly positive, then we should adopt it. Rejecting a good idea because of process wonkery is stupid.
Sumana is not declaring that she gets to force arbitrary rules on everyone whenever she wants. She is solving a problem for us."
"Perhaps you misread the width of this policy. Staff can and generally do set policies affecting WMF-run processes and events."
I didn't even have to respond on-list since all these other guys (yes, nearly all or all guys) did my work for me.
I was so happy to receive deep and wide support, and to help strengthen the legitimacy of this particular kind of governance decision: consensus, including volunteers, led by a particular WMF staffer. And, even though I had only proposed it for a particularly limited set of events (Wikimedia-sponsored face-to-face technical events), the idea spread to other affiliated organizations (such as Wikimedia UK) and offline events (Wikimania, our flagship conference -- thank you, Sarah Stierch, for your work on that!). And the next year, a volunteer led a session at Wikimania to discuss a potential online Friendly Space Policy:
"Explore what elements are essential for you in such a policy and what we can do collectively to adopt such a policy for Wikipedia and other Wikimedia websites."
So perhaps someday, all Wikipedia editors and other Wikimedia contributors will enjoy a safer environment, online as well as offline! I feel warm and joyous that the discussion I launched had, and is having, ripple effects. I felt like I took a gamble, and I looked back to see why it worked. A few reasons:
The Ada Initiative's template. I cannot imagine writing something that good from scratch. Having that template to customize for our needs made this gamble possible at all.
I started the discussion in January 2012; I had joined Wikimedia Foundation (part-time) in March 2011. So I had already built up a bunch of community cred and social capital.
In early 2012, open source citizens saw more and more reports of hostile behavior at conferences; people saw the need for a policy.
I added "or preferred Creative Commons license" to the big list of attributes (gender, disability, etc.), which gave the document a touch of Wikimedia-specific wit right at the start of the policy.
Honestly, I narrowly focused the policy to an area where my opinion carried weight and I held some legitimate authority (both earned and given), phrased my announcement nonchalantly and confidently, and ran the consensus process pretty transparently. I believe it was hard to disagree without looking like a jerk. ;-)
(If you can privately talk with decisionmakers who have have top-down authority to implement a code of conduct, then you can use another unfortunate tool: point to past incidents that feel close, because they happened to your org or to ones like it.)
By implementing our Friendly Space Policy, I created what I think of as a tidepool:
"...places where certain people can sort of rest and vent and collaborate, and ask the questions they feel afraid of asking in public, so they can gain the strength and confidence to go further out, into the invite-only spaces or the very public spaces....spaces where everybody coming in agrees to follow the same rules so it's a place where you feel safer -- these are like tidepools, places where certain kinds of people and certain kinds of behavior can be nurtured and grown so that it’s ready to go out into the wider ocean."
With the help of the Ada Initiative's policy adoption resources, you can make a place like that too -- and if you feel that you don't have top-down authority, perhaps that no one in your community does, then take heart from my story. If you have a few allies, you don't have to change the ocean. You can make a tidepool, and that's a start.
# (1) 13 Aug 2014, 03:48PM: Case Study of a Good Internship:
I'm currently a mentor for Frances Hocutt's internship in which she evaluates, documents, and improves client libraries for the MediaWiki web API. She'll be finishing up this month.
I wanted to share some things we've done right. This is the most successful I've ever been at putting my intern management philosophy into practice.
A team of mentors. I gathered a co-mentor and two technical advisors: engineers who have different strengths and who all promised to respond to questions within two business days. Frances is reading and writing code in four different languages, and is able to get guidance in all of them. The other guys also have very different perspectives. Tollef has worked in several open source contexts but approaches MediaWiki's API with learner's mind. Brad has hacked on the API itself and maintains a popular Wikipedia bot that uses it. And Merlijn is a maintainer of an existing client library that lots of Wikimedians use. I bring deep knowledge of our technical community, our social norms, and project management. And I'm in charge of the daily "are you blocked?" communication so we avoid deadlocks.
Frequent communication. Any time Frances needs substantial guidance, she can ping one of her mentors in IRC, or send us a group email. She also updates a progress report page and tells our community what she's up to via a public mailing list. We have settled into a routine where she checks in with me every weekday at a set time. We videochat three times a week via appear.in (its audio lags so we use our cell phones for audio), and use a public IRC channel the other two weekdays. We also frequently talk informally via IRC or email. She and I have each other's phone numbers in case anything is really urgent.
Strong relationship. I met Frances before we ever thought about doing OPW together. I was able to structure the project partly to suit her strengths. We've worked together in person a few times since her project started, which gave us the chance to tell each other stories and give each other context. I've encouraged her to submit talks to relevant conferences, and given her feedback as she prepared them. Frances knows she can come to us with problems and we'll support her and figure out how to solve them. And our daily checkins aren't just about the work -- we also talk about books or silliness or food or travel or feminism or self-care tips. There's a healthy boundary there, of course, since I need to be her boss. But our rapport makes it easier for me to praise or criticize her in the way she can absorb best.
Frances is great. I encouraged her as an applicant; from her past work and from our conversations, I inferred that she was resourceful, diligent, well-spoken, analytical, determined, helpful, and the kind of leader who values both consensus and execution. I know that many such people are currently languishing, underemployed, underappreciated. A structured apprenticeship program can work really well to help reflective learners shine.
I got to know Frances because we went to the same sci-fi convention and she gave me a tour of the makerspace she cofounded. Remember that just next to the open source community, in adjacent spaces like fandom, activism, and education, are thousands of amazing, skilled and underemployed people who are one apprenticeship away from being your next Most Valuable Player.
Scope small & cuttable. Frances didn't plan to make one big monolithic thing; we planned for her to make a bunch of individual things, only one of which (the "gold standard" by which we judge API client libraries) needed to happen before the others. This came in very handy. We hadn't budgeted time for Frances to attend three conferences during the summer, and of course some programming bits took longer than we'd expected. When we needed to adjust the schedule, we decided it was okay for her to evaluate eight libraries in four languages, rather than eleven in five languages. The feature she's writing may spill a few days over past the formal end of her internship and we're staying aware of that.
Metacognition. As Jefferson said, "If men were angels, we would have no need of government." But we're flawed, and so we have to keep up the discipline of metacognition, of figuring out what we are bad at and how to get better. I asked Frances to self-assess her learning styles and have used that information to give her resources and tasks that will suit her. Early in the internship I messed up and suggested a very broad, ill-defined miniproject as a way to learn more about the MediaWiki API; since then I've learned better what to suggest as an initial discovery approach. Halfway into the internship we realized we weren't meeting enough, so we started the daily videochat-or-IRC appointment. I have let Frances know that I can be a bad correspondent so it's fine to nag me, to remind me that she's blocked on something, to ask other mentors for help. And so on. We've learned along the way, about each other and about ourselves. My mom says, "teaching is learning twice," and she's right.
Setting up an internship on a strong foundation makes it a smoother, less stressful, and more joyous experience for everyone. I've heard lots of mentors' stories of bad internships, but I don't think we talk enough about what makes a good internship. Here's what we are doing that works. You?
(P.S. Oh and by the way you can totally hire Frances starting in September!)
# (1) 10 Aug 2014, 07:34PM: Resources For Starting Your Own Thing:
I've had two different conversations recently with feminist women who want to start their own tech startups. Even though I have never done that, it turns out that I had things to tell them that they did not already know! NON-ORDERED LIST TIME!
If you need to improve your own programming skills in order to found effectively, check out the Felder-Silverman learning styles and use your self-assessment to help you choose useful learning activities. If you're trying to choose and stick with learning projects, you may find my piece "From 'sit still' to 'scratch your own itch'" helpful. Maybe you'd enjoy making funny or feminist things. If you've already programmed a bit before, try porting something you already made into a new language. Go ahead and copy existing things that you think are cool, e.g., Hollaback, Listen to Wikipedia. This is learning time and it is OK not to make new things the world needs. You can learn and then build the thing you want to exist. (This helps us see why games are popular learning projects: you have a ready-made specification to work from, so you don't need to decide "how should this work?", and they make people feel happy.)
If you have, without knowing it, been waiting for someone to give you permission to do this: I give you permission. (No kidding, I said this to one of them, because she realized she needed it. Permission granted!)
I'm sure this is as incomplete as "Here Are Some Grants You Could Apply For" was. Also, as I mentioned, I totally have not done this and websearching around for startup advice from founders will get you a zillion interesting results, and if they contradict me then you should probably believe them instead.
#23 Jul 2014, 10:01AM: What Is To Be Done?:
When I worked at Salon.com I got to work with Scott Rosenberg. I never reported to him and barely got to collaborate with him directly, more's the pity, but I did get to witness him in meetings. He would listen for most of the meeting, then speak up, insightfully and concisely summarize others' viewpoints, and then say what he thought and why. (He was also the first person at Salon to predict that Schwarzenegger would win the governorship.) And he wrote Dreaming in Code, a book I frequently recommend to help non-programmers understand the infelicities and headiness of software engineering.
Anyway. Thinking about Scott's influence on me makes me think about management. I'm taking a break from formal management at my job right now, but I'm still on the board of directors of the Ada Initiative, and besides that there's my interest in influencing my communities informally. As Frances Hocutt put it,
when I talk about leadership and influence I am not talking about coercion or manipulation. I define influence as the ability to connect with others, and discover that their goals are also your goals.
(Hocutt and Rosenberg are also both saying interesting things about authenticity and leadership, by the way, in case you want to go read about that on their sites.)
A few years ago, I read the Project Gutenberg text of Florence Nightingale's On Nursing, and I thoroughly recommend it. Nightingale focuses on executive energy, attention, and putting the proper processes into place such that patients (employees) have the resources and quiet they need to get better (do their work). Once you get to a certain administrative level, instead of solving problems ad hoc you have to think strategically. As she puts it, a manager's question is, "How can I provide for this right thing to be always done?" You know, scaling.
One of the motivations for the post was a discussion I had with @PabloK on twitter about the Greek negotiations, in which he said, rather succinctly, that the purpose of protest was to change the space of what was politically possible. I think this is a crucial point; although it is important to make a good faith attempt to understand the constraints that people work under (which is why I wrote the post), it is equally important not to regard those constraints as necessarily being imposed by Ultimate Reality.
I am being super digressive today, thinking about the fact that I'm grateful for the chorus of thinkers and activists who sing so I can go take a breath, thinking about my choice to manage and lead adults and to probably not bear or raise children, thinking about how it gets tiringly abstract sometimes to always be setting up leveragable scalable systems, and thinking about the joy of mentoring future leaders. If I had to try to tie all of this together, I would say that the power of leadership is the power to change the constraints that people work under. And that I see a lot of my friends not-very-willingly constrained by Facebook, and I'm looking forward to seeing that go away.
# (6) 14 Jul 2014, 11:24AM: Why Job Titles Matter To Me:
A friend asked for help in thinking about job titles and job descriptions, and said she was specifically interested in how to think about them and whether they matter at all. I gave her some thoughts, from my experience, and thought I might share them here.
I think job titles *do* matter, in a few different dimensions. Here are the three major ones.
giving correct expectations about you (your skills, your expertise, your influence within your org, your seniority, your independence as a decision-maker) to people outside your company/org, who use that metadata as a hint to treat you appropriately (invite you to give talks, recruit you, ask you suitable questions when they meet you, introduce you to other resources, ask for introductions, offer to sell things to your org or buy things from your org or otherwise partner with your org, praise or criticize your org)
(A subset of these goals: demonstrating for future recruiters/employers a particular career progression on your résumé.)
giving correct expectations about you to people inside your org who don't already know you, e.g., new hires and Human Resources, so they treat you appropriately (assume you know/don't know certain skills and domains, take your advice seriously, invite you to the right brownbags and hackdays, put you on certain career ladders, ask whether you'd be interested in taking on a new project)
hint to yourself about what you should focus on or what you/your org values (e.g., "senior" implies mentorship/stewardship, "reliability" or "performance" or "happiness" tells you what goal to focus on, "researcher" or "manager" or "analyst" or "nurturer" tells you what methods/skillsets you should be employing) -- this should be Part Of A Complete Breakfast, I mean, Job Description
Some people find that job titles do not matter to them. I posit that those people believe, or act as though they believe, that it is unimportant to provide additional easily-graspable metadata about their own work-selves to strangers or colleagues (I could imagine lots of reasons that this would feel unimportant) -- or that they already know what they need to be working on and do not need additional guidance-reminders.
In the current US software industry, sometimes you run across deliberately informal titles - God/Guru/Ninja/Wizard/Grunt/Thing-doer/Goddess/Mistress/etc. I don't quite feel up to the task of laying out the particular signals one THINKS one is sending, and the signals one actually IS sending, with those job titles. This feels like Kate Losse territory. Here, as with so many other human relationships, you might run into the very natural desire to make a joke out of it to elide all the tension and status play. And I understand that. When I got married, Leonard and I had a HARD TIME getting used to the words "husband" and "wife"! To ease into them, we mispronounced them or banged them together with other words, so, e.g., he was a "funband" and I was a "funwife". I feel like new formal job titles can be like that too, uncomfortable, like "one size fits all" clothes.
Sometimes silly job titles signal to others, "we value whimsy/insider cliquishness more than we value clear communication about tasks and roles with people outside our internal culture."
So if someone dismissively says that job titles don't matter, I suggest you tack on a silent "to them right now" when you interpret their statement.
I hired our new bug wrangler and our new volunteer coordinator. I got Wikimedia Foundation participating in the Outreach Program for Women paid internships, and we got way better at new developer intake in general. I introduced the Friendly Space Policy for WMF technical events (and we sure ran a lot of them). I introduced some innovations that took, and a few that didn't. When you fix one bottleneck you notice the next one -- that's the nature of bottlenecks -- and so we worked on harder and harder problems.
By external measures I was doing really well. But my management style does a lot better face-to-face, and I found it tiring to try to manage logistics and emotional nuance almost entirely via text - managing up, down, and sideways. And community management is often a customer service job with big gobs of emotional labor (example). By late 2013, I'd sort of plateaued; I wasn't learning as much and as fast as I wanted.
Hacker School gave me an opportunity to reset and to look at Wikimedia with new perspective, and to reawaken my interest in hands-on technical contribution and learning. I came back to a WMF that had just renewed its search for a FLOSS-savvy technical writer with programming skills. And, fortunately, my colleague Quim Gil was willing to make his interim position permanent, and keep on leading the team. So, as of about a month ago, I'm Senior Technical Writer at the Wikimedia Foundation.
And it's great. I've taken our Requests for Comment process in hand, started drafting improved architecture guidelines (not there yet) and our first unified set of performance guidelines, and started planning improved API documentation. And I've been learning bunches. I've learned enough to summarize REST and SOA and HTML templating systems as they relate to MediaWiki. I've learned how our caching layers work and how the new parser works. And I get to translate what I learn into prose and visuals to teach others, and I get to mentor intern Frances Hocutt as we both learn about the MediaWiki web API. For the last several weeks I've concentrated on understanding big things like how SOA will change our architecture, but post-PyCon I'm raring to code more; I'm looking forward to pair programming with Frances.
I feel so fortunate to have such a strong team. (This is one reason you hire people who could replace you - it gives you more room to change.) And I'm grateful to be at Wikimedia Foundation, an organization that nurtured and promoted me, gave me a three-month sabbatical to go to Hacker School, and helped me find different valuable work to do when I came back changed.
The two big problems I worked on as MediaWiki's community manager: inculcating empathy in others, and designing processes that scale. I made a dent in both, and I'll come back to them, and to management in general, in some future when I'm yet another Sumana, changed again.
#06 Apr 2014, 03:18PM: Points of View:
I'm noodling around, thinking about vision, perspectives, and leadership.
In a 2012 interview with MIT Technology Review (in their compilation Twelve Tomorrows), Neal Stephenson spoke about science fiction's role in innovation (pp. 5-6):
... a less obvious utility, that science fiction can provide a coherent picture of an alternate reality in which some innovation happened. Not just the technical innovation itself, but the social context and the economic context that causes that innovation to make sense. It can be sort of like an invisible magnetic field that gets iron filings to line up. In big engineering organizations, you've got all these people working on small pieces of a bigger problem, and there's an enormous amount of communication that has to take place to keep them all working in a coordinated fashion. That communication is tedious and expensive, but if everybody's got the same picture in their heads, maybe you don't have to communicate as much.
Worldviews and ideologies sure are powerful things, and nearly all of Stephenson's fiction and nonfiction has focused on the effects of people's diverse perspectives. (See some of my previous thoughts on Stephenson.) I used to say that he and Le Guin were my favorite authors, and they have this in common. You see the arbitrage possibilities of a new, subversive perspective, and you see how much power you unleash by converting a whole community to a new worldview.
In the late nineties, Simon Stow introduced me to the idea that the social sciences provide many useful lenses. I still remember him in that ground-floor Kroeber classroom, miming an optometrist, checking whether A or B made things clearer, then B or C.
A few years later, a pal of mine said something about the difficulty of explaining scientific concepts to people who did not already have sufficient bootloaded prerequisites:
That one sort of floored me, because radiation is one of my "basis concepts" that I use to explain other things. (Yes, I think of my scientific knowledge as being spanned by a basis set of conceptual eigenvectors. The basis set idea is also one of my "basis concepts". Yes, I also know that I'm weird.)
For each of us, certain clichés are as foundational as the G, A, T, and C in DNA. I ought to really catalogue mine someday, but here's a start. I tell people about the career Venn diagram, or my version of exit, voice, and loyalty, or my rhetorical triangle. We cargo cult, or expand the Overton window, or arbitrage, or decide it's an efficient market. We decide that at least we'll earn some XP, or satisfice or do cognitive load-balancing, or concentrate on our core competence, or try to fix the kyriarchy. I think about that law of user interface, that if you make something 10% easier then twice as many people will do it. I remember
the three skills of adulthood. Recently I started noticing the activist-organizer split in my work and in others'.
Wouldn't it be great if job interviews helped you check the other person's basis concepts? (Or if matchmaking sites offered that, come to think of it.)
You have to have lots of lenses if you're going to be a leader, because you'll get ambiguous and inadequate information about situations and you want to pattern-match to see what fits your plan and what doesn't. You need to develop a clear, robust vision, persuade others it's what they should want too, and negotiate with them.
And even if you don't aim for formal leadership positions, it's probably worthwhile to catalogue the lenses you tend to use. Blog it if you want.
Several years ago, all I knew about organs I'd learned from a few pages in Cryptonomicon comparing them to vacuum-tube computers. And I liked their sound. I was a regular attendee at the Community Church of New York at the time, and CCNY featured organ music in its Sunday service.
One day I heard that they were fundraising for organ upkeep. To help people see what needed doing and why, someone led a small group of us on a guided tour of the organ. I got to see how its parts related to each other, how all the inputs turned into the sound we enjoyed.
Any sysadmin or manager trying to persuade others to invest in long-term infrastructure should consider a similar tactic. Give your stakeholders a tour of your system's anatomy, so they can appreciate it.
Four years and change later, I've become more and more like his audience, and like him. I became a community organizer, albeit in open source rather than electoral politics. I work to train contributors to mentor each other and to run events. I argue that we shouldn't do ineffective things, even if they're tradition. And in his 2008 speech, when he says:
Now everybody is counting on you, not just me. I know that's a heavy weight. But also what a magnificent position to find yourself in, where the whole country is counting on you to change it, for the better. Those moments don't come around very often....
he might as well be talking to me, about the stress and the opportunity of working for Wikimedia.
"And the work that I did in those communities changed me much more than I changed the communities," Obama says. That is the virtue of doing this work not in pairs, as missionaries do, but alone, as Genly Ai does in Ursula K. Le Guin's The Left Hand of Darkness:
Alone, I cannot change your world. But I can be changed by it. Alone, I must listen, as well as speak. Alone, the relationship I finally make, if I make one, is not impersonal and not only political: it is individual; it is personal, it is both more and less than political. Not We and They; not I and It; but I and Thou.
I also loved his explanation, "And it taught me something about how I handled disappointment, and what it meant to work hard on a common endeavor. And I grew up. I became a man during that process." What a tremendously hopeful conception of masculinity and adulthood, to be say that "I became a man" by growing a disciplined empathy.
But back to the thank-you speech: let me excerpt the most moving part.
You know, I try to picture myself when I was your age. And I first moved to Chicago at the age of 25, and I had this vague inkling
about making a difference. I didn't really know how to do it. I didn't have a structure. And there wasn't a presidential campaign at the time that I could attach myself to. Well, Reagan had just been reelected.
[laughter]
And was incredibly popular. And so I, I came to Chicago knowing that somehow, I wanted to make sure that my life attached itself to helping kids get a great education, or helping people living in, in poverty to get decent jobs and be able to work and have dignity. To make sure that people didn't have to go to the emergency room to get healthcare. And, you know, I ended up being a community organizer out in the South Side of Chicago with some, a group of churches who were willing to hire me. And I didn't know at all what I was doing....
And so when I come here and I look at all of you, what comes to mind is: it's not that you guys actually remind me of myself. It's the fact that you are so much better than I was.
[scattered laughter]
In so many ways! You're, you're smarter and you're better organized. And, you, uh, you're more effective. And so I'm absolutely confident that all of you are gonna do just amazing things in your lives. And you'll be what Bobby Kennedy called the ripples of hope that come out when you throw a stone in a lake. That's gonna be you!
You know, I'm just looking around the room and I'm thinking: wherever you guys end up ... you're just gonna do great things!
And, and that's why even before last night's results, I felt that the work that I had done, um, in running for office, had come full circle.
[Obama's voice chokes with emotion]
Because what you guys have done means that the work that I'm doing is important. And I'm really proud of that. I'm really proud of all of you.
[Obama tears up]
For the first time, I saw famously cool, self-controlled Barack Obama tear up. This is what gets at him, in his bones: empowerment.
I should check in again in another four years, and ask how I'm measuring up.
#19 Jun 2012, 06:17AM: Conference Seasoning:
You know you're traveling too much when you completely stop updating the "where I'm going to be" feeds (example).
Regardless: I'll be in San Francisco starting late today, and then in Portland on Monday the 25th, the day before I give the opening keynote address at Open Source Bridge. My tentative title: "Be Bold."
Wikimedians are giving several other talks during the conference:
The Wikimedia Foundation is also sponsoring the Friday unconference day, and will host a hacking table that day as well as (I hope) the Tuesday "Hacker Lounge Project/Community Night."
Then, I'll be in Washington, DC, July 10th-15th for Wikimania, especially the pre-conference Hackathon. I'm happy to announce that WMF is partnering with OpenHatch to make the pre-Wikimania hackathon even more useful. OpenHatch is planning and running the novice-focused half of the event, with trainings and projects to help people learn how to hack Wikimedia technology.
# (1) 19 Jun 2012, 05:54AM: Challenge:
Wikimedia Foundation is hiring a leader for volunteer software testing. I have ideas on what this person should do and how to do it* -- indeed, this position reports to me -- but more than that, I have ideas about what kind of person I need to find.
I need someone who has skills in open source contribution, who gets the wiki and open source way. Even if the person lives in San Francisco -- which they don't have to -- they have to collaborate well remotely, with volunteers and other colleagues. And I seek someone who has the focus and analytical skill one needs to test software, and the hospitable and generous temperament one needs to encourage and teach newbies.
* Had I worlds enough and time, I would start a retraining school that turned underpaid copyeditors into versatile and sought-after software testers. Proofreaders can already follow instructions and communicate effectively and deploy critical thinking skills while nitpicking, so they just need some guidance in learning some domain knowledge. (One of the great benefits of the modern technology industry is that it provides productive and lucrative channels for pedantry.) I do not have the time to do this for profit, but perhaps my Engineering Community Team can use this kind of arbitrage to recruit and train volunteers, give them some skills to put on their résumés, and get some more quality assurance.
In open source, we share our vulnerabilities and our milestones, so of course my boss announced my promotion to a public mailing list. I was surprised and delighted when colleagues and contributors in my community responded to that announcement with congratulations, privately and publicly. It is as though they believe I am doing a good job! Take that, impostor syndrome.
I'm thinking about the thirty years of influences that got me here. As a teen, I volunteered for the Peace and Justice Network of San Joaquin County, and met my mentor John Morearty, whom I saw this past weekend. Before I knew Sam Hatch, and before I knew Seth Schoen, even, I knew John, a teacher who took his values seriously and was always ready to teach. He led volunteer communities that aimed for inclusiveness and viral change. He modeled grit, open-mindedness, and compassion, and I saw in his example that another world was possible, another mode of being. He wrote a fascinating memoir that you should check out, if you like twisty life stories.
John had twin sons, Mike and Brian. I got to meet Mike on Sunday. On Monday he got write access to Wikimedia Labs, Git, and Gerrit. I find this confluence pleasant yet dizzying, like the bushels of jasmine in John's garden. There's so much to be done, and the abundance of my world may yet provide. As John reminded me this weekend, we cannot build the new systems we need; we must cultivate them.
Enjoyed in the last several weeks: Naomi Kritzer's "Scrap Dragon," a short story in the January/February issue of The Magazine of Fantasy and Science Fiction. "Recognizing Gabe: un cuento de hadas," a short story in Strange Horizons by Alberto Yáñez. "Things Greater than Love" by Kate Bachus, another story in Strange Horizons. Past Lies, a graphic novel by Christina Weir, Christopher Mitten, and Nunzio DeFilippis.
# (1) 02 Jan 2012, 01:48PM: Self-Care, Sometimes On A Larger Scale:
I think some people I know might find Sam Starbuck's experience useful. He has social anxiety but wanted to leave the house more often, so he developed methods to cause himself to do so.
The idea originally was just to get out more; not even necessarily to have more experiences, but not to spend every single night at home. There's nothing wrong with that, in and of itself, but it wasn't what I wanted for me. So I developed the Adventur Programme.
I should say that I suspect the Adventur Programme would be different for everyone, because the key to doing it is finding something that will motivate you to actually follow through. Here's how I did it; the basic theme of all of this is to arrange things in such a way that making the decision to go isn't difficult....
worked well. I think it's because it wasn't a resolution; it was a plan. Resolutions can be broken, and thus expose you to feelings of failure and despair. Whereas plans aren't broken. Plans are rescheduled for a later date. You haven't failed. You've just changed up your calendar a little.
I admire people and organizations that thoughtfully manage their sustainability. You can see Alexandra Erin develop this theme in her behind-the-scenes blogging; as a self-employed writer, she works as hard at developing her own infrastructure as she does at making fiction. For Sam, Alexandra, and me, the structure of a successful process must avoid causing feelings of failure and despair. We know that if we feel those, we'll stop. So we find patterns that suit our strengths and work around our weaknesses, and get us to our goals -- more adventures, more good fiction, better technical skills.
Maturity requires recognizing granite walls and finding workarounds, saying no to machismo.
We know from experience that counting only on unpaid volunteer effort to work on helping women in open technology and culture leads to burnout and inconsistency. So The Ada Initiative works as a nonprofit that pays two people's salaries to work fulltime on the issue. (I volunteer on their Advisory Board.)
In Notes on Nursing, Florence Nightingale wrote of management, "How can I provide for this right thing to be always done?" Even when she's not there? Nightingale focuses on executive energy, attention, and putting the proper processes into place such that patients have the resources and quiet they need to get better.
However, there is a habit of mind that scorns all visible processes (and sees no value in formal communication containers such as meetings or performance reviews). I was talking about this with Ari yesterday, about (for example) software developers who think source control is needless overhead. I imagine some of these folks have suffered from their own personal resource curse, coasting through day-to-day tasks, the accreted cruft not yet salient, atherosclerosis not yet completely blocking the bottleneck.
Some have the useful skill of translating to them, getting across why hygiene is important in some particular case. Sometimes I can do this with analogies. Others use diagrams. But by the time I'm working with someone, it's usually too late to inculcate in them that habit of mind, a critical respect of social infrastructure.
(If you can, try never to work for someone who has this blind spot.)
Like Sam, I'm also working on sustainability and process improvement in my personal life. For me, it's cleaning and housework. What can I do to make it more likely that I'll do my fair share? I already knew that podcasts help. As of last week, I've discovered that I am way better at doing the dishes if I do them first thing in the morning. With enough tips and tricks, maybe I can adequately simulate a good flatmate.
And I wanna also tell you that I am gonna talk a little bit about kind of managing up and managing down, but really more of what I'm talking about is managing up, because I think a lot of us have had at least some experience of managing other people and helping them understand what to do, but managing up is where it gets all mysterious, and people wear suits, and they talk about terms we don't understand.
And I think of this as kind of harm reduction. This talk that I'm giving right now. It's a little bit of the gentle art of self defense. Because, you know, you might be an engineer who has to deal with management and fight for your project, or you might want to take leadership of your open source project, and you might want to write proposals for what people should do or why they should give you a grant. Or you might accidentally turn into a manager at your firm. It might be foisted upon you.
And so I hope that some of the stuff in this talk will take you from, like, 0th percentile up somewhere else, and give you a bunch of keywords that you can look up on Wikipedia, the world's free, open source encyclopedia.
Because we released MediaWiki 1.17.0 (after 11 months of development and review!) while I was in Portland, I also led an unconference session on "What's new in MediaWiki 1.17 and How You Can Help". People volunteered to help us with PostgreSQL support, testing, design ideas, bug triage, the parser, and more. And I got to talk about the new release with Ward Cunningham, who invented the wiki. That has got to be a Sumana career highlight.
I also performed some geeky stand-up comedy, and people liked that. So that's nice.
A Dozen Databases in 45 Minutes -- I found this very useful in helping me understand, among other things, why one would privilege availability over consistency. Thanks to speaker Eric Redmond for some memorable metaphors.
The open source communities panel -- I did not pay enough attention to this, as I was finishing up work on my talk. I do remember some people disagreeing about qualitative versus quantitative release management decisions and about how to recruit and mentor new participants; sadly I don't have any useful recollections.
Selena Deckelmann led "How to Ask for Money", which I think many people will find useful. Some of their lessons: "Find a fundraising mentor," "Hire a graphic designer", "Your network is bigger than you think," "Ask again anyway," and "Do what you say you'll do. And if you don't, communicate why - now."
The Birds of a Feather session for Google Summer of Code proved educational; students, alumni, mentors, projects' administrators, and Google's GSoC administrators discussed challenges and opportunities. I learned that GSoC organizational administrators can email Carol Smith at Google to request possible travel stipends for their GSoC students to attend conferences, and possibly to look at previous mentors' evaluations to decide whether to keep them another year. Also, FLOSS projects report great success with the tactic of requiring applicants to do small tasks to prove they're serious and to set up those students to succeed, and mentors and org admins did not seem to think that this would unfairly weight admissions towards students who were already going to go into open source anyway.
# In Markus Roberts's #osb11 talk "Snooze, the Totally RESTful Language". Leonard, you never told me REST was a meaningless acronym. BETRAYAL
# Demo fail. "Anyone here have a laptop?" "What, you want me to go to localhost *for* you?" #osb11
# "I think there's a market for this, especially if we convince people that there is one." ... "Are you incepting?" #osb11
# Markus is now just riffing on soaking up consumer surplus, Bitcoin, NoSQL, pig Latin, & the joy of boundaries. #osb11
Elizabeth Naramore spoke on technical debt (slides). One item that really struck me is her experience that sometimes chipping away at little tech debts won't get you the momentum & buy-in you need. You need a big thought-provoking goal.
A few ego-stroking notes: Open Source Bridge's Melissa Chavez also interviewed me for an eight-minute video. And, with Asheesh Laroia and Igal Koshevoy, I was named one of three Open Source Citizens by the conference organizers. Thank you for the honor; I will wear my scarf with pride!
(Thanks to the Wikimedia Foundation for the plane flight, to the conference for letting me in free as a speaker, and to my friends Brendan and Kara for hosting me. Thanks to Reid Beels and John Parker for their photos, which are CC BY-NC-SA. Thanks also to Josh Triplett for his photo.)
#23 Jun 2011, 10:12AM: Learn Tech Management In Probably Fewer Than 45 Minutes:
I've put up slides and pretty rough notes from the talk I gave yesterday at Open Source Bridge, Learn Tech Management in 45 Minutes. I quote Langdon Winner and then Marx & Engels, summarize the efficient markets hypothesis as "we're not stupid," and give a list of spin tactics you can use to get or keep budget for a project. Audio & nicer notes to come soon.
It took me two years to get a master's in tech management. I save you $40K and give you the short version.
Managing innovation, intellectual property and employment law, corporate finance, building a business plan — my master’s degree in technology management gave me some grounding in a bunch of suit stuff. I’ll teach you a little of each of these, plus insights from my management experience and fish-out-of-water anecdotes. Aspiring executives welcome; ties optional.
It would be lovely to have time to hang out with acquaintances and friends in either location; contact me!
Better by Atul Gawande; How to Win Friends and Influence People by Dale Carnegie (attacker's POV) andInfluence: The Psychology of Persuasion by Robert Cialdini (defender's POV); The Dispossessed by Ursula K. Le Guin; Bossypants by Tina Fey; should have also mentioned Ellen Ullman's The Bug;
contributing documentation/bug triage/testing/packaging to open source projects you already use (example: my novice's guide to Telepathy);
My last email, on April 1st, mentioned that "my main TODOs today, this weekend, and early next week are to follow up on press contacts, the eReleases blast, and GNOME Journal." So I did that; that day, I got the eReleases press release out, and it went to more than a thousand publications. And then here's a list of what I did last week on GNOME:
Corralled answers for journalists. A few journalists asked me followup questions after the press release, so I got answers from other GNOME people, wrote answers, replied to the reporters via email and phone, and put these answers on the wiki (Talking Points).
Managed the GNOME Journal launch. Nagged the last few authors, edited articles for content and style, uploaded them, fought with Textpattern, continued planning to move us to WordPress, and sent out the publication announcement. I'd still love for people to continue publicizing this, since there are many interesting nuggets that I haven't seen picked up by the larger press.
(Started planning the next two issues of GNOME Journal, including hopes for a 3.x roadmap article in case anyone wants to write it.)
Did a teensy bit of web testing and feedback regarding gnome3.org. Great job!
Went to the Linux Foundation Collaboration Summit. There, I talked up GNOME 3 to reporters and other interested Linux folks, and made contact with some KDE people and started talking about publicity for the upcoming desktop summit. It sounds like we should be working to drum up attendance now, by planning special events, trumpeting rare speakers, and publicizing the unique benefits of attending GUADEC & the Desktop Summit.
Attended the marketing/PR training at the Linux Foundation Collaboration Summit (thanks for setting it up, Dave!). I sure did learn a lot, from strategies for resource-constrained projects (build relationships with five key reporters) to tips for being interviewed. I will link to Cloer's slides and add my notes when she puts them up.
Undone: I didn't put tasks in Bugzilla because they were moving too fast and I was in San Francisco, many timezones away from Allan in Bangalore, and couldn't coordinate effectively. Lesson for next time: do it early if we're going to do it at all. Similarly for setting up interviews with key GNOME developers; I dropped the ball there.
Now that we've launched, I talked with Allan about how to best use the rest of our contracts (we're booked to work on GNOME till the end of April). We think our priorities for the rest of April are:
(a) reach out to not-so-news-driven (more in-depth-reporting) journalists about aspects of the release that didn't get covered on launch day -- once we get some bites, prep developers who have volunteered, and get them interviewed
(b) write up lessons learned & ideas for next time
(c) infrastructure building & maintenance: update the wiki, consolidate audiovisual and textual resources, and otherwise help prep for future marketing, including press releases, talking points, etc. for the launches of GNOME 3 within distributions that will come out in the next weeks & months
So I'm going to make some progress on each of those this week. Specifically, I aim to reach out to two reporters, braindump a few lessons learned privately, and confer with Allan Day and Vincent Untz about resource consolidation. And I'm planning on pushing GNOME Journal's next issue forward, in collaboration with Paul Cutler, but that's not part of my contract since it's not GNOME 3-specific. :-)
# (3) 01 Apr 2011, 04:21PM: GNOME 3 Marketing: A Snapshot:
The story of this week, for me and GNOME marketing, is primarily the story of a press release. I collected quotes, revised it in response to feedback on marketing-list, added press contacts to our CiviCRM installation and emailed the press release to them (at least twenty contacts, with more to come). It should show up tomorrow on gnome.org once the "we're delaying six months" April Fool's press release runs its course. We're now getting responses from interested journalists and I'll be answering their questions and helping them set up interviews with some key developers.
Also, I heard a success story from another open source marketer about ereleases, so I plan on editing the press release down to 500 words and paying $200 (the nonprofit rate) for their press release publicity service this afternoon.
By the way, in a previous status report I mentioned looking into Collabtive. It's terrible and I won't make us use it. For tasks involving responding to press contacts, we are using CiviCRM. I will be checking with Allan after the hackfest to see whether the remaining tasks would benefit from being placed in Bugzilla; I had aimed to do that before I fell ill.
This week we also had the second User Day. I did not publicize it as far ahead of time as I wish I had, but we did get some participation and answer some users' questions. Thanks to all the hosts!
After a discussion with Sri and Diego, I added "Approaches That Work" to the GNOME 3.0 talking points. If you need to talk with a skeptic about GNOME 3, we're hoping you can get some ideas, tips, and answers to common skepticisms there.
I also did some nagging, editing, writing, and organizing around GNOME Journal's GNOME 3 issue, which we hope to put out this weekend.
So my main TODOs today, this weekend, and early next week are to follow up on press contacts, the ereleases blast, and GNOME Journal. Thanks to everyone in Bangalore who's at the hackfest and working on the release!
# (2) 22 Mar 2011, 08:45PM: A Slightly Disjointed (Due To A Five-Day Cold) Musing On Open Source, Fear, Motivation, And Witnessing:
I was introducing C. to a set of QuestionCopyright friends and acquaintances, and they were joking about indoctrinating her, and she was curious to hear what free culture is all about. So she wondered why I reflexively suggested that the others wait a bit, tell her next time.
They did give C. the introductory spiel, and conversation was pleasant and edifying, and nothing terribly awkward ensued. She has developed a substantial interest of her own, now, in the theory and practice of free culture. But why did I have that reflex? I felt around for it and grasped something. It makes it harder, I said, once you know these things and care about them. Becoming a free culture/free software person is like becoming a vegan.
No, G. replied -- at least people know what vegans are.
We happy few.
Here I was, a fulltime free culture/free software consultant, feeling an unaccustomed reluctance to give someone else the sunglasses, to witness.
There are self-constraining ideologies like veganity or chastity that modern society at least theoretically understands, even if some cohorts scoff. Then there are the practices that always require an introduction. When I explain how I met Leonard, I often start with the thirty-second "what is open source" explanation, because it's all of a piece. But my "what is open source" intro focuses on pragmatism -- many eyes making bugs shallow -- rather than free software values.
I think I'm a moderate sort of open source gal, an ovo-lacto vegetarian. There's an iBook running Mac OS tucked off in a drawer, and all these Linux boxen in our house surely have nonfree binaries driving bits of hardware. No Facebook but I surely use many cloud services that violate the Franklin Street Statement. I hang out with copyright abolitionists, Debian users, and other free culture/free software folks who make me feel namby-pamby. And then I go to dinner with someone who makes me feel like a Jain. Or I find myself saying, as I said a week ago, that developing on a closed platform is like trying to fall in love with someone who won't talk to you.
Our love is part of what energizes us, moves us to act. In FLOSS, volunteers do things for two basic reasons: either because we enjoy doing them for their own sake, or because the task needs doing and we want to do our bit. We see some goal the task will help us reach, or fear an outcome the task will help us prevent. [By the way, it's useful to have experienced that, because it's useful to assume those two as the means of persuasion whether my colleague's paid or not. As a leader, I should either set up tasks people will genuinely enjoy (and get the scutwork out of the way), or help my colleagues see a straight line from the task to a glorious future. Show them how what we're doing leads to something they want. This is my pet theory of How To Lead Knowledge Workers and your mileage may vary.] And -- as a zillion social scientists will tell you -- even if we momentarily burn out on caring about a goal for its own sake, we don't want to let the team down. We don't want to let our buddies down.
As we were talking about GNOME marketing, Andreas once asked me what I found special, what personally spoke to me about GNOME. I rambled: object code is compiled from source code, but the source code is compiled, too -- compiled from people, from time, from love. Every time I look at my desktop, every feature and every bug comes from someone, someone with a name and a face, and sometimes I can even remember. Hey, I remember when she added that feature to Empathy. Oh, right, I know he's working on that bug. It's like all of Planet GNOME is helping me out, every day. It's like my whole community's right there, on my desktop, every time I open the laptop lid.
I don't want to keep my friends blissfully ignorant of this. Is there a more loving human impulse than the joy of sharing? I'm sorry, C. I'm sorry I was afraid of making your life harder. I remembered the local minimum and forgot the greater maxima awaiting you. Why keep us a "happy few" when we can be an ecstatic many? And yes, it's harder, to learn our principles and try to walk this path alone -- but the whole point of our principles is that our multitude, our diversity, our union, our communion is far richer and more sustaining than individual hoarding ever could be.
I told my mom about it and it went something like:
"Mom, I'm working for the nonprofit that does Wikipedia! ... No, not them, they're different. Wikipedia is a big free encyclopedia that's online for anyone to use. Wikileaks is a ... well, they're a bunch of people who like to get and publicize secrets -- anyway, that's not us."
And no, this holiday season my photogenic face will not be on banner ads entreating you to give. As far as I know.
QuestionCopyright.org is a nonprofit that aims "to educate the public about the history of copyright, and to promote methods of distribution that do not depend on restricting people from making copies." I'm QCO's Fundraising Coordinator, meaning that I write and coordinate grant proposals. I also write a tiny bit for the QCO website. Case in point: "Three glimpses: Transformative work, public domain music, and ethics".
# (3) 01 Feb 2011, 08:47AM: When Am I Ever Going To Have To Use This?:
Yesterday, while negotiating with potential clients, I used:
You know, standard reading, writing, and interpersonal speaking skills (many courses, school newspaper, speech & debate, Academic Decathlon)
Basic algebra to work out some price quotes (elementary school math classes)
US and world geography (K-12, history classes)
The wheelbarrow anecdote from Benjamin Franklin's autobiography to make a point about open source contributions as a marketing tool (eleventh grade American Literature)
Political science concepts of authority and legitimacy, in determining a client's needs regarding open source leadership (college)
Knowledge of Unix-style design (started in college, especially at the Open Computing Facility)
The innovation S-curve, and cautionary tales of platforms that never got uptake from customers and vendors (master's in tech management)
# (7) 23 Aug 2010, 09:45PM: Two Tips On Convincing Managers & Executives To Invest In Your Technology Projects:
From a years-old job-advice email to a friend. The sort of knowledge that Rachel Chalmers or Karl Fogel finds obvious but that some of us still haven't quite integrated into our day-to-day communications and long-term strategies:
You need to be able to express your suggestions to your boss in terms of financial incentives and losses.
A few things I've picked up during a recent class in "Technology in the Business Environment" (when I was doing the master's in tech management at Columbia):
I) Management focuses on the things that drive the organization (directly making money), and tends to ignore things that support the organization's drivers. If you're directly making money, lowering the cost of producing the product/service, increasing management's control, increasing product quality, increasing the knowledge available to an important decisonmaker, or improving customer service, you can describe your work as a driver. Can you find a way to describe your high-level TODOs in one of those ways?
II) Here's a model of management's priorities for technology investment. The higher up this list you can get, the more attention you can grab from management.
Revenue. Guaranteeing a financial return. Not just cutting costs, but actually MAKING money from customers.
Increasing scarce productivity. If the demand for a product exceeds the supply, then this is attractive. [1 and 2 indicate that the company is growing, and interested in the future. A good sign!]
Cutting costs. More popular in a struggling company.
Competitive advantage -- this means the company is already behind its competitors and has lost first-mover advantage.
Tech for the sake of tech -- pizzazz and leadership.
So can you explain "creating system-monitoring scripts, streamlining processes, and installing and configuring new programs on the server" so that they're way up on that list?
Let's say a system-monitoring script would take your service from 95% uptime to 99.9% uptime. That's #2. Maybe one of the high-level tasks you do will make it possible for your company to serve twenty units instead of fifteen (#2) or even start a whole new line of products (#1). But "It's more elegant/technically correct" is #5.
I welcome comments, tips, examples, disagreement, and cake.
Even at pro-FLOSS businesses, logistical obstacles and incentive problems get in the way of giving back. I’ll show you how to fix that.
My session notes are now available. If you were there, please feel free to clarify them and add your notes or links to your notes elsewhere.
The very short version: a company does not upstream its patches, even though it should for long-term practical reasons, because of problems in four general categories. The company might lack a FLOSS culture. There might be legal confusion about what employees are allowed to do, and how to get permission. The project management workflow and timelines might not allow time for proper engineering. And the external project might have a terrible UI for new contributors.
Once you abstract these categories away from the specific problem of accidentally hoarded code rotting away, you see that they also apply to other problems of the type "I really know I should be doing foo but haven't gotten around to it."
WisCon prep. I'm helping with food for the vid party and I'm speaking on four panels:
Let's Create an Online Business Model That Works. I'm moderating this one: Sat, 10:30-11:45 pm with Jennifer K. Stevenson and an anonymous participant. What makes Facebook games very, very profitable, while online SF/F magazines are usually struggling? If the money from subscribers and from advertisers isn't enough, then where does the money come from? Is the word "magazine" holding some of these ventures back? Let's put our collective knowledge of fandom, web 2.0 and visions of the future together and see if we can't come up with something great.
Must Pleasures Be Guilty?, Sun, 10:00-11:15 am with Vito Excalibur, Lesley Hall, Sumana Harihareswara, John O'Neill, and Sonya Taaffe. Why are we ashamed of the books we love? Critical acclaim recognizes some SF/F as serious literature, works one might recommend to a non-genre reader who thought it was all talking squid and ray-guns in space, to demonstrate what the genre can do. But are these the books you love and reread over and over again, especially when feeling low? And if not, why not? What is the difference between love and admiration? And why is pleasure so often constructed as "guilty" or embarrassing to admit?
Once Upon a Time, Sun, 1:00-2:15 pm with
Vylar Kaftan, Terry Bisson, Richard Chwedyk, Sumana Harihareswara, and Ellen Klages. Pro writers use the card game "Once Upon a Time" to tell half-baked fairy tales for laughs. Find out what happens when four panelists play tug-of-war on a story, trying to bend it towards wildly different endings.
Facebook and Its Discontents, Sun, 4:00-5:15 pm with Cat T. Rambo, Kater Cheek, Sumana Harihareswara, Penny Hill, and Alena McNamara. Have your friends abandoned their blogs and LiveJournals for Facebook? How does writing on our friends' walls differ from commenting on their posts? How do you navigate privacy on a system that forbids anonymity? Is "liking" someone's update the same as commenting "This!"
In the first several months after I joined Collabora in April 2009, I served as lead project manager, got the new website up, and started putting some new project management processes into place, especially in research and development. Then I shifted to personnel management, and created and began implementing a performance assessment system. All the while I gardened the wiki, aggregated and edited weekly internal reports to keep the company on the same page, blogged about our work, and generally gave people the information and the nagging they needed to make informed decisions. (In retrospect, I played facilitator, historian, and journalist a lot, plus mentor to 50+ Collaborans.)
Collabora's a different place than it was ten months ago; I helped move them from a startup to an enterprise footing. Management structures change as needs and capabilities become apparent, so the directors and new hires (including the awesome Martin Barrett) will carry this work forward, and I offer them my best wishes. I'm happy to talk more in detail about what I did at Collabora, especially if you're interested in what I can do for your organization.
In the near future, I'm taking some time to relax and take care of existing obligations before I incur new ones. Then, starting in late February or early March, I'll be volunteering fulltime on some open source/free culture projects for several months. I haven't yet decided which ones, or in what capacity, so feel free to recruit me.
# (1) 25 Sep 2009, 08:49AM: We Already Know The Title Of His Management Tips Book:
I used to watch Project Runway identifying with the contestants. Now I watch and think, "Tim Gunn is really good at phrasing criticism in a way that's likely to get across to the designer. I want to be that kind of manager."
#25 Apr 2009, 11:27PM: Hiro-ics Don't Scale, They Say:
Now I'm rereading Neal Stephenson's Snow Crash bit by bit. Spoiler ahead:
The important thing is, Hiro, that you have to understand the Mafia way. And the Mafia way is that we pursue larger goals under the guise of personal relationships. So, for example, when you were a pizza guy you didn't deliver pizzas fast because you made more money that way, or because it was some kind of a [expletive redacted] policy. You did it because you were carrying out a personal covenant between Uncle Enzo and every customer. This is how we avoid the trap of self-perpetuating ideology. Ideology is a virus. So getting this chick back is more than just getting a chick back. It's the concrete manifestation of an abstract policy goal. And we like concrete -- right, Vic?
pp. 349-350, massmarket paperback
There's a lot going on in this paragraph.
For one thing, the speaker makes the same tripartite distinction that my ex-boss does. How do you get peons in an institution to act in the organization's interest? Financial incentives, military-style unthinking policy compliance, or a relationship that comprises part of the employee's identity. That last one is most interesting. Fog Creek, the Mafia, some religons, really elite military units, Joss Whedon fan clubs, open source, sports cheerleading, political activism and nonprofit work are all activities or groups that go from "something I do" to "something I am."
We say "drink the Kool-Aid," not just because we know loyalty will kill you, but also because the ingestion metaphor sounds right to us. You are what you eat. Mike Daisey has a moment in at least the book version of 21 Dog Years: Doing Time at Amazon.com that touches on that. He writes a letter to Amazon founder Jeff Bezos, detailing a dream in which he cuts off Bezos's left hand and runs away with it:
You're all behind me, spilling out of the building like so many ants, but I'm running too fast for anyone to ever catch me. I'm out on the lawn, eating your hand, hungry like I've never been in my life. I eat the whole thing, chew through the bones, and now I own part of you, just like you own the best part of me. I wake up so indescribably proud.
The speaker in Snow Crash, however, doesn't just value loyalty for sentimental reasons. The Mafia rescue Y.T. because she is a friend of Uncle Enzo. If they don't rescue her, then her relationship with Uncle Enzo means nothing, and the value of the personal relationships that structure the Mafia is suspect. That's the policy goal: to maintain the currency that is a friendship with a Mafia executive. Per existing real-life Mafia scholarship, organized crime aims to replace government, to become the main way people and households and businesses relate to each other and get their needs met.
This is why bureaucracy is a good thing: because otherwise it would be personal relationships that decided whether you could or couldn't get a license, or buy that car. No such thing as a sticker price without bureaucracy, incidentally.
But what is an institution that only comprises specific personal relationships, one that eschews ideology? Is it a family? Is it a tribe? Is it LinkedIn? It seems like a rather fragile thing to me, like the structures from "World of Goo," liable to fall over under their own weight, or when people find another social network with better swag. Thus L. Ron Hubbard's apocryphal line that the real money is in starting a religion. Ideology is a virus, sure, but it's also a trellis for the vines to grow up, to comfortably trap them.
Anathem is obviously about an institution (the monastery system) that has thought very hard about how to perpetuate itself over the thousands-of-years long term. But Snow Crash and Diamond Age are about institutions, too, and specifically about the challenges of building and leading multigenerational or world-changing institutions. Enzo, Y.T., Jason "Iron Pumper," the terra-cotta-blazer Mafia kids, and L. Bob Rife could make for a pretty entertaining "Management Secrets of Snow Crash" presentation. Maybe I should write it.
# (7) 01 Apr 2009, 09:17AM: New Awesome Work:
Martin and I are co-founding a new firm to produce the PoTeaTo, a food-and-beverage convergence device targeted at the United Kingdom and the Republic of Ireland. Simply drop the PoTeaTo into a small pot of boiling water and watch the seam split, revealing two pre-blanched potato halves and one strong teabag! Boil them together and you'll have a meal and the drink to go with it.
Just kidding. Actually, starting in a couple of weeks, I'll be working at Collabora, an open source consulting firm. I'll be managing projects and helping them develop awesome tools like the Telepathy framework and the Empathy instant messaging/IRC/VoIP/video chat application. Yes, people are using the phrase "Skype-killer."
I'll get to telecommute (casual day every day!), advance the cause of Free/Libre/Open Source Software, and facilitate the work of dozens of geeky colleagues around the world.
Exciting! The PoTeaTo shall have to wait (in a dry, dark, cool place).
#01 Apr 2009, 12:49AM: Cost-Benefit Analysis For Projects: Caution!:
We often say that something is/isn't "worth it" based on a reflexive guess. The important thing isn't quantifying all those guesses to the tenth decimal point, it's getting into the habit of interrogating them. How certain are you of the benefit & harm you're thinking of causing? Who, specifically, will benefit or hurt? Have you taken into account interest rates/inflation for long-term investments? And what's the opportunity cost? A CBA isn't an answer, just a tool for understanding the financial implications of a decision. But if you're overruling a financial decision with a cultural/ethical/positioning one, you should know you're doing it.
Tonight Stallman pointed out that twenty additional years of copyright monopoly, added onto the existing multi-decade duration, were basically nothing in a discounted-present-value calculation, and thus of zero benefit to a rational actor. Then again, as a repeated step in a "perpetual copyright on the installment plan" scheme...
#28 Mar 2009, 02:33PM: A Book Review About Leadership:
I mostly wrote this book review in the fall of 2008.
On the Psychology of Military Incompetence
by Norman Dixon
1976
On The Psychology of Military Incompetence is 400 pages long, and worth savoring. Its fundamental question: Given that information is the reduction of uncertainty, how do leaders of different temperaments react to information? The author limits himself to cases of British incompetence in battle, but of course you can extrapolate from that.
Dixon clearly but steadily builds his case against the prewar British military. The one-line summary is: culture stagnates into convention, which drives out the unconventionality you need to succeed. More nuances ahead.
From Skeleton to Prison Cell
Dixon shows that to advance in the British armed forces, in peacetime, demanded rule-following and an authoritarian mindset. But the mission of a military is to win wars, and that requires fluidity and a willingness to take risks -- and offend superiors.
So, what happened when peacetime promotions hit a war zone? Disaster -- in the Crimea, in southern Africa, all over Europe in the First World War, over and over again. Soldiers' courage and tenacity get their generals out of the holes they dig.
In general, institutions get the leaders who fit into those institutions and succeed at the unstated goals (for example, avoid retreats at all cost, impress politicians, keep civilians uninformed and complacent). If the unstated goals don't line up with the institution's stated goals, then leaders will tend to do the things they've been rewarded for in the past, especially in moments of high stress and low certainty. Therefore, in battle, bad commanders freeze up, wait for orders, ignore new information to appear "decisive," give panicked and contradictory orders, lie to maintain their personal reputations, and so on. And disaster happens, over and over again.
In Dixon's view, the British military suffered from groupthink and valued particular upper-class traits over merit. It's astonishing that military personnel would need to be told that the map is not the territory, the signifier not the signified, but indeed they cared more about the signs and forms of morale and professionalism (such as clean clothes and polished brass) than about warm clothes, edible food, and working equipment.
Narcotic Assumptions, Lenses & Blinders
I'm in India as I write this and dealing with my own need for shiny appearances. I often forget, once I return to the States, that I find -- for example -- hermetically sealed bathrooms reassuring. My parents live in a home where the plumbing and electrical work aren't consistently hidden beneath stucco and sideboards, and it surprises me how much that bothers me. I haven't seen any marked crosswalks in their city, either; we watch for a lull in the bicycles, mopeds, and rickshaws, then rush over the dusty, rocky street. No accidents yet.
I consciously desire function over form, but that only works if I can convince myself to rely on an ugly-looking system to work.
I calm myself with a fallacious appeal to statistics: if something's wrong, it would have broken already. If other people depend on similarly rickety-looking setups, then they must be dependable. Or I just go straight to infantilism and believe my parents wouldn't put me in danger.
In good times, insecurities and rationalizations like mine are a luxury. In battle and competition, they're delectable poison.
British commanders, similarly, clung to the false clarity of their chain of command, "masculinity," pride, and privileges when they faced the mess of battle. They feared shame more than they minded losing men, and they scorned the "motherly" chores (or retreats) that would ensure troop survival and readiness.
Valiant forays are masculine, but feints and retreating are girly? Again, ideology got in the way of success, as when insecure commanders pooh-poohed nonwhite adversaries, self-improvement, and new technology.
The lesson: Real self-confidence doesn't need ideology as a crutch. The flipside: if you see someone leaning on received assumptions, and repeating them rather loudly, it's because without them he wouldn't know who he was.
Leaderships
The argument above takes up most of the book. In an aside, Dixon suggests that "senior commanders have often to fill a number of incompatible roles": heroic leader, military manager, and technocrat, plus politician, PR man, father figure, and therapist. This is of special interest to me.
I've learned models describing styles of leadership: authoritarian, democratic, and whatnot. These days I'm more interested in the balance among managing up, down, and sideways. Reading these books and thinking aloud about them helps me get perspective. What leg of that tripod have I been shorting?
Works thematically related to On the Psychology of Military Incompetence: Dilbert, the Harvard/NASA case study on the Columbia shuttle disaster, and John Le Carre's The Tailor of Panama.
#27 Mar 2009, 02:46PM: Ada Lovelace Day, Belatedly:
I am abashed and thankful that Rachel and Danny thought to mention me in speaking of women in tech on Ada Lovelace Day. I offer a sidelong glimpse into a short list of my influences Right Now Today:
A woman, my manager at Exodus, a history major or something, whose career path reassured me that CS wasn't the only way into interesting tech jobs. I thank you, Jed, for making a similar point -- QA, tech writing, education, design, sysadmin, and management are damn cool.
Marissa Mayer at Google might be, among other things, Google's Steve Jobs, and inspired me to think more about product design leadership.
Rachel Chalmers, of course.
Mel Chua, who reminds me to learn about how I'm learning, and that my default answer should be "yes, I can do that."
And all my Systers. I thank them for daily popping up in my inbox, being the friendliest forum for questions stupid and subtle, and reminding me that we are legion, diverse, wage slave and entrepreneur bare-metal hacker and CIO and everywhere in between and sideways.
#26 Feb 2009, 01:05AM: Can I Be The Gardener From "Being There"?:
Creating custom software, and perhaps client services in general, are more like agriculture than manufacturing. We aren't stamping out identical units and trying to increase "efficiency" by speeding up the process; we can't, because we can't negotiate away the time it takes to grow. Debugging, or copyediting, is like weeding. Creators and managers aren't forcing a thing to happen; we're guiding the creative spirit, feeding it, and guarding the fruit from harm.
Brooks's Law, pointing out that adding more staffers to a late software project makes it later, has something in common with "Nine women can't have a baby in a month." Add that to No Silver Bullet and you see that the irreducible bottleneck is the complicated thought it takes to make a complicated thing, an artifact of (arguably) the summit of human civilization. Not to sound like Louis CK.
#28 Jan 2009, 06:41PM: Make It No:
Martin, newborn pub brawler, finds that the ST:TNG episode "Tapestry" speaks to him. He calls the theme among these episodes obvious. I'm guessing he saw that they are about leadership/organizational behavior. And thus if I had written Make It So: Leadership Lessons from Star Trek: The Next Generation, those are episodes I'd use as illustration.
I've read Make It So. It's supposedly a series of logs spoken by Picard, but the whole voice is wrong. Captain Jean-Luc Picard doesn't go for bulleted lists. And he wouldn't be so reductive as to choose one virtue (e.g., Focus, Urgency, Intellectual Honesty) to bolt on to his discussion of each episode.
Make it So rightly considers the leadership and career issues in "Tapestry,"
"The First Duty," "Chain of Command," "Lower Decks," and "The Drumhead." However, it also wastes time awkwardly shoehorning management lessons into "Coming of Age," "Darmok," "Encounter at Farpoint," "Peak Performance," "Relics," "Starship Mine," and "The Wounded" when it could be addressing "The Pegasus," "Allegiance," "The Game," "The Masterpiece Society," "I, Borg," "Ensign Ro," "Loud as a Whisper," "Samaritan Snare," "A Matter of Honor," "The Ensigns of Command," "Disaster," "Rightful Heir," "Lessons," and even the Troi subplot of "Thine Own Self." I'm really surprised the talky, ham-handed Picard impersonator didn't take on "Ensign Ro," "The Masterpiece Society," and "Allegiance," since they have more interesting things to say about organizations and management than "Starship Mine," "Relics," and "The Wounded" do.
What are the real leadership lessons of TNG? Other than "watch out for worm creatures taking over your superiors"? A few: You can't do a first-class job with second-class people (cf. every guest star in a uniform); everyone needs to be able to pinch-hit (away teams, "Disaster," "Starship Mine," "The Best of Both Worlds"). Explain your reasons and listen to suggestions when you can, so your colleagues will trust you when you can't ("Chain of Command" and "Allegiance"). The first duty of a Starfleet officer is to the truth. The mission has to take priority over individuals ("Lower Decks," "Darmok," "Lessons," and possibly "The Masterpiece Society" if you look at it from the perspective of the utopians).
# (1) 04 Jan 2009, 05:28PM: What I've Taken, And What I Have To Give:
As of right now, I'm looking for new opportunities in the San Francisco Bay Area, greater Boston, and here in NYC, starting in the next few months. I'm especially interested in tiny startups (let's say fewer than eight employees) or nonprofits starting new projects with tech. I'm starting machinations to ask friends and acquaintances for the names of relevant folks I should meet during my trips to Boston and the Bay this month.
I love writing technical and functional specs, translating among QA, engineers, and businessy/world-facing folks, and recruiting. I'm looking for someplace where I can bring my writing, public speaking, rolodexing, and investigative skills to bear. I want to work with superiors I can learn from, emotionally and intellectually. And I want to help make services/sites/products that delight people - for profit or non.
I'm not a programmer but I can be a good abstraction layer for software projects. I'm looking for someplace where I'll have equity or ownership, or the possibility of rising to those -- a project where I can exert all my talents and pick up real responsibilities.
That's what I'm seeking. I couldn't go after this if I hadn't already found unexpected treasure.
In order to have a sense of playful empowerment, one must be free to change, rewrite, scrap, delete, wreck, rebuild, and tinker with all aspects of the project at any time during its course.
We can play with the inessential things without anxiety if we know they're inessential and our heart feels safe. So what is my heart's desire? To feel useful, really. And this, right now, is how.
# (6) 18 Dec 2008, 07:38AM: Gig-Hunting & Travel:
My luck has turned. Last year around this time, my job search sputtered. Now, I've been consistently impressing possible bosses -- and, more excitingly, possible partners for cofound-y relationships. I have four strong leads in New York City alone.
What's different? I have a master's in tech management, a year of experience with the title Project Manager, a stronger network, and more confidence.
On a macro scale, my timing coincides with a terrible economic slowdown, but that means the competitive field will clear and good labor will be cheap. There will always be money for good ideas, whether from angels or customers. Even in New York City, hit hard by the Wall Street crunch, I'm finding lots of entrepreneurs excited because their nimble operations will be able to undercut lumbering giants.
I find the NYC tech scene surprisingly lively, given that so many presentations and launches one sees are just dumb boil-the-ocean ad crap. Still, innovative work is happening elsewhere in stronger hacking ecosystems. I'd gone on my Portland/Seattle trip assuming that I'd have an easier time finding a startup job there than in New York, but the strength of my connections here are leading me to opportunities that I couldn't have found in one whirlwind week in the Northwest.
More worrisome to me is my week-to-week timing. I'd been meaning to visit Boston and San Francisco in December to grow opportunities there, but jet lag and New York appointments have kept me in New York till the end of this week, and people's availability declines so precipitously in the second half of December that it's not worth it to go before January. Bleh.
Still, now is the time for me to plan big chunks of travel, so I can block out those weeks and plan potential work around them. So I'm going to try to avoid making any commitments here till I can visit San Francisco and Boston in January. Predictions I put down now so I can be embarrassed when I have to correct them: I expect the startup opportunities I discover there will include more revolutionary/elegant technology, more social benefit, and a longer time to profitability.
People who live in the Bay Area and Boston metro area: What are good weeks in January for me to visit you?
#25 Nov 2008, 02:45AM: Some images, tweets, and documentation from Seattle MindCamp 2008:
Please link to other relevant stuff in the comments!
I learned about MindCamp sometime Friday, Nov. 20th, and devised the idea for my talk in about 5 minutes late Friday night while going to sleep and talking with my incredibly patient host, Riana. This was the first talk I proposed and the last session I ended up leading: basic first-year political science concepts, boiled down for use by people who want to understand and change their organizations.
I eventually realized that tickets were sold out, but was determined to go anyway. So I made the 20-minute walk over and threw myself on the mercy of the front desk. Beth Goza gave me her extra registration and refused to let me give any money in return. In hindsight, maybe this is why I was determined to give extra value as a camper.
I filled out a proposal form and put it up. Andru encouraged me to propose as many as I wanted. So I did another for a standup comedy HOWTO, then another to ensure that there would be Powerpoint Karaoke (I was surprised no one else had proposed it yet), and then another to suggest the mini-debate session. I expected that about a hundred proposals would go up and that about half, including 1 or 2 of mine, would get "funded."
Then, during lunch, I discovered that there had been fewer proposals than I'd expected, and that almost all the proposed sessions would be scheduled, so I'd be leading 4 sessions. Eventually, after I swapped a few spots with people, my schedule was:
2pm: Powerpoint Karaoke
11pm: You, Yes You, Can Do Standup
8am: Zany Insta-Debates
9am: Three Models of Power: A Political Science Lens On Your Organization
I found out that Powerpoint Karaoke would be in the first session slot [2pm] at 1:55. Much thanks to David Whitlock and other troubleshooters for arranging the projector ASAP. It attracted attention, someapproval, and chickens.
Anthony Stevens's liveblog touches on how awesome Tom Music's self-help parody session "Winners Never Lose" became. Like spontaneous experimental theater, jazz meets sketch comedy.
After more sessions, dinner, and conversing, I went back to Riana's to enjoy her birthday party, but ended up fleeing after it got crowded. And they say I'm an extrovert.
You, Yes You, Can Do Standup Comedy - 11pm, specifically placed outside the regular session schedule by Andru to ensure everyone could come and the time limit wouldn't apply. David and about five other participants did these exercises, inspired by my Dec 2005 posts. I loved helping people develop skills in such a short time, walking in possibly scared of public speaking, walking out with some tools and something to work on.
Ride home, passed out for a few hours, woke up around 7 to hoof it back to the Synapse building for my 8am mini-debates activity. (Riana later noted that my marketing-speak in the proposal included "zany" and "quickly and reliably goes off the rails.") I was surprised that people got more into the serious topics -- censorship of profanity on broadcast TV, Prop 8 -- than the light starter on the color of Pepto-Bismol. I also learned that many participants and viewers wanted scrupulous consistency in the rules, liked having people argue a side they didn't believe in, preferred logic to eloquence, and deducted "points" if a debater did not at least try to refute his opponent's arguments.
My last session: Three Models of Power: A Political Science Lens on Your Organization. Completed the night before, despite the interruptions of the drunk guy who had to get kicked out. (You may notice that the slideshow is very heavy on the photos, which allowed me to leave my speaking parts less polished.) We started late, and only had 30 minutes and 4 participants, but I think people got some ideas out of it. The most resume-friendly talk title, but the session I feel least satisfied with. I intend to rework it for a future conference.
Much thanks to David Whitlock for running the projector at PPT Karaoke and the poli sci session. Iin the middle of all this, got rides from Nikhil & Leif -- thanks. Beth Goza and Andru Edwards let me in and started the show, respectively, so my thanks to them. And thanks to all the campers who encouraged me, participated in my sessions, and put on cool stuff.
# (1) 16 Nov 2008, 12:15PM: Rachel Chalmers, Will This Make You Laugh As It Made Me?:
I had not considered the necessity of gathering ammunition to use against your own children.
# (1) 13 Nov 2008, 11:04PM: Kickoff, With Elaboration Later:
Next week I visit Portland and Seattle, to visit friends and to interview for jobs. I'm interested in startups there and in Boston, the SF Bay Area, and New York City. I want to help make technology that delights people, and right now I care about equity and responsibility more than salary. Do let me know of any relevant opportunities.
Signs can cost a campaign a little less than $1 apiece, so a $100,000 investment would be enough to give Obama a significant presence on Virginia's lawns. -the Washington Post
In South Carolina [primaries], the Obama campaign refused to indulge in the time-honored, if slightly disreputable, practice of dispensing "walking-around money" to activists and preachers in the black community. The Clintons, by contrast, continued to hand out the usual favors and cash. Obama not only won the black vote overwhelmingly, he also won the state of South Carolina by 30 points.
....
"I think we should do it," the Obama aide told a NEWSWEEK reporter. "It's just part of the culture here, and what will it cost? A couple of hundred grand? ... For a lot of people, if they don't get it, they just flat-out won't engage." (The Obama campaign ultimately refused to provide any walking-around money, though as Politico reported, some was provided by local sources.)
In each case we see a tradition of campaigning, one whose results cannot be measured or audited, that involves spending money. And Obama refused to do it, despite warnings and complaints from the traditional recipients of swag. And he won.
In this way the Obama campaign was like Google. The rules: be untraditional, don't do things if they're not provably, auditably productive, and use distributed communications/database tech. The strategy: get tons of unpaid workers to substitute for paid personnel, and reward them with good feelings.
# (2) 26 Oct 2008, 01:54PM: We Are The That Ones We Have Been Waiting For:
Barack Obama's campaign's momentum (or Omentum if you will) causes me as a manager to marvel at the fusion of inspiration and discipline his organization manifests. Hmm, whodathunk a community organizer would know how to organize self-sustaining political communities?! I've touched on this topic briefly, earlier this month, but it deserves close attention.
Another [criticism] she laid charitably to an Alinsky character trait: "One of the primary problems of the Alinsky model is that the removal of Alinsky dramatically alters its composition," she wrote. "Alinsky is a born organizer who is not easily duplicated, but, in addition to his skill, he is a man of exceptional charm."
By the way, here is where she and Obama turn onto different roads:
Her options after graduation were attending law school at Harvard or Yale, traveling to India on a Fulbright scholarship, or taking the job with Alinsky's new training institute...
Imagine if she'd gone to India! She might have turned into Sonia Gandhi!
Obama built on Howard Dean's "50-state strategy," a long-term investment that is paying off right now in national, state, and local races. But more than that, inside the Obama campaign they recursively build leadership. They recruit and train leaders to recruit and train leaders to recruit and train leaders. The revolutionary technology includes software and three-ring binders telling you how to go recursive. It would be a pyramid scheme if the leaders were just going to reap profit and scurry away when the workers weren't looking, which has happened in previous attempts at this model. But if the organization can devise compelling new goals, as compelling as replacing Bush with Obama, then it will be a force to watch even after November 4th. Can it?
The Zack Exley report from inside the campaign details the risks of Obama's infrastructure investment, and what dividends it's paying. "Rather than say we have X leadership roles to fill, we're creating leadership roles for as many leaders as we have. So we have people in charge of whatever they ARE," says Patrick Frank, volunteer-turned-field organizer. (This is the Punch Bowl Czar done right!) I am amused to learn that the rules from the top include "no drama". Does empowering volunteers and staffers help them let off steam, staving off frustration, low morale, and drama in general?
A few months ago, after Obama won the primaries and caucuses he needed to become the nominee, Leonard and I watched a speech he gave to his headquarters staff [partial transcript]. (Leonard, who poured his heart into the Wesley Clark campaign last go-round, said, "So that's the speech you get if you win.") Commenters on the video say, "I wish that was my boss." But Obama doesn't just want to be that kind of leader -- he wants to make you that kind of leader.
Three years ago, the headlines made me want to "become a manager, a good one." I looked at Katrina and said, "For God's sake, we have to do better than that. And I could do better!" I wanted, and still want, to reduce the net amount of mismanagement in the world. We owe ourselves competence. But Obama's campaign has a higher aspiration yet. How will it change its people, and our expectations?
# (1) 11 Oct 2008, 08:55PM: We Make The Subtext - The Text!*:
Last night Hal [happy returns of the day, Hal!] told me a tale of a job-hunting workshop he attended wherein the leader told him, without irony, that he needed to pump more buzzwords into his resume. Yes, she said the word "buzzwords." She specifically recommended "proactive" and "think outside the box."
I cringed, not just because that's horrible, but because I can talk like that without thinking about it. And I'm glad it helps clients and bosses understand me, but I don't want to turn into a duckspeaker. So it's good to examine my shorthand and write it out in longhand once in a while.
One fraught word with several confusing meanings is "political," as in, "There's a lot of politics here" or "this is a very political situation." We hear stories about "political" workplaces where the term is a dis, but these last weeks of the US Presidential election make for a lesson, polished and cut, in why "politics" becomes a dirty word.
People don't use "political" to mean that we have to make decisions to allocate scarce resources. Or rather, if that's true but it's a decision that doesn't get bound up with anyone's allegiance or values, we say it's "strategic." "Political" means "emotional" or "touchy" or "dangerous, not to our goal but to people we'll need to support that goal."
At its worst, "politics" doesn't just mean that people don't like to look bad. It means that people let their obsession with status and chain of command get in the way of getting things done, and will in fact sabotage useful progress (consciously or not). And it limits the discourse to things that won't offend anyone, which -- when the truth is offensive -- means constant lies of omission.
"Politics" means that, instead of discussing disagreements like adults, people either throw tantrums like babies, or whisper and deceive and manipulate and sublimate conflicts like bullying schoolgirls.
"Politics" means that you have to humor and tiptoe around everyone like they're my dad.
"Politics" means that there are important things, things crucial to the success of the nation, that you're not allowed to say.
This means a politician must slow way the hell down every time she sends an email or takes on a task. Because she needs to calibrate herself. How do I phrase this as delicately as possible? Which audience do I select? Since too much information "confuses" some people, how do I minimize the payload of each of my messages? And so on, calibrating, hewing to "appropriate" talking points until they becomes second nature, then first.
I'd like this dance more if I thought it was a cooperative one where everyone got something out of it. As it is I'd prefer frankness. And I think adults in the citizenry, and workplace, generally should prefer that, and they're wusses if they prefer the truckling manipulation that they're calling tact.
Transparency, trust, boldness, and long-term investment and empowerment of non-bosses doesn't sound like politics as usual. In fact, if "politics" equals dysfunction, it doesn't sound like politics at all. But it is. It's politics -- the allocation of scarce resources -- with an entrepreneurial, dynamic mindset, instead of a tired zero-sum blame game.
"Entrepreneur" sounds nice, doesn't it? In a sense, the buzzwords "Business," "businesslike," "enterprise," and "professional" are the opposite of "entrepreneur," and show up in the kinds of arguments that don't acknowledge that they're arguments. The subtext for "businesslike/professional" goes like this:
The business's aim is to make money, so it must maintain profitable, long-term relationships with clients and employees. Ergo, the customers must trust the business to perform its duties competently, so as to continue their patronage and recommend services to others. Customers use certain measures of demeanor and register as proxies for trustworthiness. Thus, the business's employees must meet the customer's expectations, both in demeanor and register.
Which ends up as special "client-facing" codewords, a taboo on salary transparency, and dress codes. Speaking of dress, I'm guessing every feminist has a bone to pick with "feminine" or "modest". By definition anything I do is feminine. "Modest" and "feminine" crossed with "business" (especially "business casual") give me headaches: exactly what fabrics am I allowed to wear, and what about the inch of skin under my collarbone, and are unshaven legs or inch-long buzzcuts going to be a problem? I end up looking like a male engineer from 1950, matching two out of three desired buzzwords.
A larger question: how do you open up the pre-sealed bag of salad greens that is a buzzword and see if anything's rotted? Sometimes, when I make conversation partners stop to unpack our assumptions, we all come away with insights, as in a PSA for the value of diversity. Sometimes I just feel misunderstood or sense that I'm a pain in the ass. My third-rate Socrates impression, otherwise known as passive aggression, runs the risk of annoying friends and lowering my status with every question at work ("I haven't seen any women at that client, so would this outfit count as business casual to them?"). But speaking the subtext gets the frown; of course the reason it's subtext is that it's so tense and possibly unjustifiable. How political.
#04 Oct 2008, 12:30PM: Subjects And Objects In Geek Careers:
I love reading Derek Lowe's In The Pipeline to glimpse the shape of the biochem industry: what's inherently hard, what's common, and what's revolutionary. The grammar is familiar if the nouns aren't. This came through quite clearly in his recent post, "Hard Times: A Manifesto".
The more I think about all the research layoffs that have been going on for the last year or two around the industry, the more I think that we really are seeing a change in the way drug discovery is being done....
Everyone knows - including the people in Shanghai and Hyderabad - that the difficult, high-level research is still not being done there. That'll change, as the human and physical infrastructure improves, but the bulk of the outsourced chemistry is methyl-ethyl-butyl-futile stuff. It's "Hey, make me a library based on this scaffold structure" or "Hey, make me fifty grams of this intermediate"....
So improve your skills. Learn new techniques, especially the ones that are just coming out and haven't percolated down to the crank-it-out shops in the low-wage countries. Stay on top of the latest stuff, take on tough assignments. Keeping your head down in times like these will move you into the crowd that looks like it can be safely let go.
The comment thread includes much sniping at US firms that hire immigrants. According to protectionists, there is some static number of jobs available for research chemists, forever, and the only effects of "allowing" a US-based organization to hire a chemist who was not born in the US are to drive down wages and deprive a native-born US citizen of that job. They also hold that long-term benefits to the industry and country from immigrants are a myth, unnecessary, slight, or past.
I find these sorts of attitudes astonishing, not just because they're angry and incoherent, but because in a software developer they would betray a complete lack of initiative. There is no way to simultaneously hold these views and to conduct one's career with the attitude of an entrepreneur. Analyzing opportunities, targeting positions and markets, networking, and generally taking initiative means viewing situations as dynamic, not static. What's growing? What's dying? How can I ride that wave? And if someone is thinking that way, then naturally she recognizes the likelihood that an immigrant's discovery or shoestring startup will create a new and profitable micro-industry, and that US universities gain tremendous value from being world capitals of science research.
1) Rational drug design is the best way to find good treatments. We should try to target precisely one receptor with one molecule.
2) We need to understand the mechanism of action of a drug in order for it to be successful.
3) Drugs that are safe and effective in humans are likely to also be safe and effective in animal models. (We know that the converse is false, which is why we use rigorous human testing.)
4) The incentives of the FDA and patients are very well aligned.
5) The discovery of new therapeutic regimes using combinations of existing off-patent drugs does not deserve to be rewarded.
#04 Sep 2008, 10:54AM: Join Us [Me]:
Anecdotally, it looks like a hot market for project managers, a.k.a. producers. Behavior, Alexei's firm PlayFirst, and Brendan's firm inDelible are looking.
After our oldest, first female, or first nonwhite president, maybe we'll be ready to elect a president with a deep understanding of human interface design. This "Archident" would make sure the Presidential Daily Briefings clearly highlighted imminent threats and critical information, and would give US residents single-payer healthcare just as an act of user interface mercy. Any post hoc changes to federal websites or the Congressional Record would be recorded in a Subversion-like record management system for ease in search and retrieval, and to discourage Orwellian history erasures. The State of the Union would include Steve Jobs-esque Keynote accompaniment, a far cry from Ross Perot's posterboard charts or the school-project volcano dioramas that grace the floor of the House today.
Also s/he would have a blog. And constantly be redesigning it. With a White House IT team on call 24/7. And I'd probably be the poor PM dealing with the constant random enhancement requests. So maybe we should wait on a PresIAdent.
#03 Aug 2008, 10:33PM: Log:
L. Sprague de Camp's entertaining Lest Darkness Fall moves really fast. This is probably true even if you haven't just read a 900-page Neal Stephenson novel. I nearly mentioned Lest Darkness Fall in my brain candy recommendations to danah boyd, but fear it's not trashy enough.
William Ball's A Sense of Direction is fantastic and as soon as I return it to the library you should check it out. As I suspected, it has a mix of great inside baseball on directing plays (e.g., three pages on how to structure and practice curtain calls so that actors don't get their egos in a twist) and transferable advice on managing creative folk.
We learn in threes. The first step of learning is discovering; the second step of learning is testing; and the third step of learning is pattern-setting.
The actor will learn to relinquish his fear when he sees that the director never causes another actor to be frightened.
...a question from an actor is not a question. A question from an actor is an innocent bid to draw the director's attention to something unresolved. When the actor asks a question, a wise director doesn't answer the question. The answer to the question is not in the director; the answer to the question is in the actor. Answer the question by asking another question. Allow the actor to resolve the difficulty. He already has the best answer in mind before he asks the question.
Always begin rehearsal on time. There are some directors who like to gossip and joke and waste the first ten or twelve minutes. This awakens a sense of sloppiness in the actor and gives him the feeling that the work is not important.
For future reference, I'm also a fan of advice on pp 58-59, 66, 102-104, and 108 of the 1984 edition.
This weekend (among other activities) I went to a fun party, watched a lot of Babylon 5, saw a friend's wife and new baby, read the de Camp, ate Leonard's excellent sour cherry cobbler, walked around a lot, filed a bug or two on Miro, and rented movies to foist on my fellow jurors this last week of grand jury duty. All this and I still spent hours dinking around on the Web. So there, anxieties!
# (2) 04 Jul 2008, 06:39PM: One Peace At A Time:
In school the teachers said, the real world isn't so forgiving, you won't be able to get extensions on your papers, you'll get worse consequences than bad grades if you do a poor job. And indeed, in my working world, the challenges don't end, I have to seek out feedback from my superiors, and I don't get summers off. Yet I find that I experience greater motivation and less procrastination and anxiety at my current job than I did in college. Why?
I remembered those bad old habits when I read some oldblog entries about procrastination and avoidance in Ph.D. dissertation work. I found it reassuring to read those, and to see that I wasn't alone in my master's thesis experiences. My biggest problem was shame-related avoidance as a turbo maximizer on procrastination. And the gimmick that worked best for me: injecting a trusted third party. When I could talk to a friend about my problems, I often found out that I wasn't doing terribly, or at least that in the light of day my situation looked more manageable. When I made a first-draft pact with a friend, I had new motivation to start the project and gain momentum. Otherwise it was just me versus or with The System, possibly embodied in a teacher.
Talking and working with peers helps me set expectations (how original does this solution have to be? what's a reasonable amount of time to spend on this?) and break down big goals into sequences of little tasks. Socially I was a late bloomer, and it seemed to take me the vast majority of my academic life to grok that I work better this way.
I like working with people -- and for people. Aaron Swartz touches on this motivation in the Fog Creek Copilot documentary when he suggests that work is more interesting than institutional education -- why spend your time doing something fake when you could be doing something real? One inherent problem with academic make-work was that nothing except my own grades depended on it. I thought I was unmotivated, I had no idea how much responsibility I could handle, and I refused to consider a career in medicine because I didn't think I could handle being responsible for human lives. In retrospect, that was stupid, because basically all adults have to handle huge responsibilities with babies, money, driving cars, etc. and risk ruining and ending people's lives.
Then I moved up in the working world. Every time I gained real responsibilities, and saw my work serving others, I started working harder, valuing myself more, using my time more wisely, and attacking problems with greater energy. The experience of responsibility, not merely of earning money, nurtured my ambition.
A few weeks ago, Leonard and I ate at the Shake Shack in Madison Square Park, and we happened to talk to a trio of recent high school grads who were behind me in line. I think they were on a road trip, then off to freshman year at college. They asked us for advice, and Leonard said: start a business. Just find some random need that you can fill, part-time from your dorm room. There's a bunch of reasons why that's a good idea. You get pocket money. You get entrepreneurial experience while risk is cheap and your brain's more malleable. But the reason that strikes me hottest right now: you'll get people depending on you. If you find that tremendously motivating, that's a sign.
And if part of independence is disobedience, another, less frequently articulated part is the capacity for responsibility, not just for yourself but for your dependents. (From stuffed animals to computers to pets to clients to children? How will my staircase go?)
In school the teachers sounded like Morpheus from The Matrix: "Welcome to the desert of the real." But what grows in a sandbox?
Happy Independence Day, and Happy Interdependence Day.
#14 Jun 2008, 10:22PM: Brick To The Back Of The Head:
Zack Weinberg once told me that a relative of his had predicted a change in Zack. Zack was about to move to New York City to start at Columbia, and the relative predicted that, after two weeks, it would be as though a brick had hit him in the back of the head, and Zack would start walking faster. Evidently this was accurate.
I went to the retreat last weekend and stayed with Kristen and Aaron and Anne and Ben, and I need to write about that sometime soon. Then I came to work and went from managing 1.5 projects to 3.5. Today I brunched with Evan and Leonard at the soon-to-close Florent, caught up a little on project work, got new library books, went to a members' reception at MoMA, and met Ze Frank.
Maybe next week a brick will hit me in the back of the head and I'll manage all my projects with the tip of a single finger. Today it's all hands on deck.
One point in that discussion: communication of academic concepts to non-academics requires serious empathy. Gotta work on that. In fact, gotta work on my presentation in defense of my master's thesis, which is this Saturday around 11 am.
Yesterday I put on the new suit and visited the client for the first time as their project manager. The cubicles, corridors, and cafeteria sent me back to Silicon Valley during the first boom, specifically my tech writing internships at Exodus. After I got home, when I was changing into sleep attire and folding my business pants over a chair, I remembered folding my dad's gray and navy pants over hangers in Mom & Dad's tiny walk-in closet in Stockton, all those years that he worked at Caltrans on PERT analyses. For once bumping into the past was comforting. This isn't new. My dad did it and I can too.
#16 Apr 2008, 09:20AM: Transfoooooorm!:
I now grok feedback I've been getting from my superiors for weeks. I need to improve my listening skills and help other people feel comfortable in difficult discussions. Time to reread Carnegie!
Like one S. Jobs, Norton went to Reed College. And he spent at least a few months, possibly five years (it's hard for me to tell by Googling) in a Buddhist monastery. He started the company when he was nearly twice the age of today's stereotypical startup founder. I like how roundabout his story is.
You've seen pictures of Norton from his books and from the Norton Utilities box (software that's been in development and use for over twenty years, by the way), where he's wearing glasses and his hair has gone lighter. But check out 42-year-old Norton in 1985, who reminds me of Jim Fisher and Leonard of George Frankly from Mathnet, the serial within Square One TV.
#16 Feb 2008, 09:05PM: Lessons Of The Past Few Weeks:
I work better when I keep my inbox to fewer than ten messages on a daily basis. Everything that's not a to-do task goes into one big archive folder that I can search or sort if I need something. Thanks, Gmail, for giving the world the insight that, in a virtual environment without haptic reminders of size and relevance, search engines beat a zillion hierarchical folders hands-down. And IMAP rocks.
I still need to work on keeping my volume down when I'm excited in a conversation.
The art of the cc:, especially when sending out an email documenting what everyone just agreed to in a conference call.
If you provide a critical service that other people depend on, and you can't quickly get them an explanation describing the service with sample inputs and outputs, I throw up my hands in disgust. Bonus points if you change the service without telling anyone and respond to questions with "nothing's changed!" for a day or more.
I need more office pants. Black pantage is de rigeur for business-y women, it seems.
A bug tracker is orders of magnitude better than Basecamp To-Do lists for organizing software development tasks. A bug tracker is a collective memory, a place to prioritize, a wiki for specs and repro cases and screenshots, and an easy collection of nifty, gameable stats on How Many Bugs We Closed Today to wow the client and your manager. Even if the project manager has to spend time each day translating between the bugtracker and emails with clients and colleagues, it's worth it. I knew this before but I'm newly re-grokking it.
I am good at this job. This job is good for me. I am so grateful and proud.
#16 Feb 2008, 12:55PM: Superiority Dance:
A couple of years ago, I tried to explain to Eric that he had a bad conversational habit. When Person A brings what she thinks is a new item into the conversation, and Person B says "Oh yeah, I already know all about that," Person A feels as though her conversational effort has been rebuffed or she's being called stupid for thinking the item is new or interesting. I used the Gricean maxims, specifically quantity, to explain to Eric why his habit bothered me: he was acting as though I had broken the "be informative" rule.
Patrick Nielsen Hayden is a little more forthright and antagonistic when he sees this habit:
I personally think conversations about the current emergency would be
vastly improved by a general moratorium on the "What, You Just Figured That Out, Where Have You Been?" rhetorical gambit. Indeed, what that
particular routine indicates most clearly is that the speaker is more
interested in striking a pose than in actually forming a useful alliance.
...
"Charles Dodgson": "I must be a more cynical SOB than Patrick --- I'm
not remotely surprised. It's just a fact of human nature that [etc]"
Second, the game of "You're surprised by $ODIOUSBEHAVIOR???" is itself
odious. Hello, person who has, by dint of great effort, worked themselves
around to agreeing with me! Allow me to point out in the most withering
possible terms that I'm more worldly than you, more knowledgeable than
you, more sophisticated than you, and boy howdy, are you ever a chump.
I've indulged in this variety of superiority dance myself. Astonishingly,
it turns out to not be the most effective imaginable way of acquiring and
retaining allies. Human nature is so unpredictable; who could have known?
Last night I saw Eric and a bunch of other folks in my master's cohort at Jen's party. The Swiss guy played the piano and I joked that the hydrazine in that satellite the government's shooting down is just a Xeroxed zine for people who love water -- perfectly harmless! I mentioned how much I love my new job, especially because the people are friendly: more specifically, the founders at the top don't shun human interaction the way Joel and Michael do, and the company culture suits me far better. Sure I'll have moments of conflict with my coworkers, but they'll be about "who's in charge of this task" or "you should have done that more quickly," not a fundamental misapprehension of human nature.
#02 Feb 2008, 06:45PM: Here We Go:
By day two at Behavior I got assigned to a project. Every company advertising a job says that you must be comfortable in a fast-paced environment and this is the first time since Salon I've really felt the truth of that. And Leonard is back! Oh, how I've missed him. Now till May: hectic and full of accomplishment, I predict.
# (8) 28 Jan 2008, 07:35PM: New Job:
I have just accepted a job offer from Behavior Design as a full-time Project Manager. Behavior has done some awesome work, such as the redesign of The Onion, lots of sites for HBO, and interactive kiosks for New York's MoMA. And they're right on my subway line, where Chelsea and the Flatiron District meet Midtown South.
#24 Jan 2008, 04:54AM: Just In Time Idiot?:
Great, a new breed of anxiety dream. In this one I basically get told that my lack of coding chops means I have absolutely no right to make judgments in technology matters.
I woke up just before my haranguer told me what "JIT I" meant, and why the insight of that framework was that I sucked. Can't find anything relevant for that on Google.
#25 Dec 2007, 09:40AM: OMG Squee:
Yesterday I got David Neeleman's autograph. Rock! I was just stretching my legs walking the aisle around hour three of the flight when I saw a familiar-looking man in a yellow sweater talking with kids and flight attendants in the back of the plane. I approached, and it was him! Oh, how fannishly I gushed. A little while later he did the gladhanding walk through the plane.
Neeleman is LDS, and his religious values are part of why JetBlue uses distributed call centers for customer service (think eBlocks). He thought it would be good for families if moms could work from home and earn money while taking care of their homes and kids. Lots of JetBlue customer service personnel are housewives in Salt Lake City and environs.
#16 Dec 2007, 09:40AM: Odd One Out:
Things I've suggested that have not been received well in my classes:
If your boss asks what you think of your counterpart at the company you're about to acquire, and he's as good as or better than you, you have a responsibility to say that instead of subtly undermining the new guy.
Salary transparency within an organization. Everyone knows what everyone else is making. This one got a really vehement "That just isn't DONE!" reaction.
When are accounting principles going to get completely overhauled to recognize the non-fungible importance of people and information? Or at least the fuzziness of the line between cost of goods sold and operating expenses in knowledge industries?
Sumana: Practicing our defense speeches would make them better! So I'm holding a practice session. Other People: Great! Good idea! Sumana: I mean, yeah, no one's presentation will be perfect when we practice, but even if you just have a fraction of a proto-speech, no slides, it's better to try it out in front of people and get feedback early. Fail faster. Rapid prototyping. Agile. Stop procrastinating and get some small useful bit of work done on it right away and start improving! Other people: Absolutely. Glad you're putting it on. Great idea. Sumana: So you're coming, right? Other people: Ehhh, it's not ready yet.
# (1) 11 Dec 2007, 08:12AM: In Which Sumana Suggests That Jumping Off A Cliff Might Prove Beneficial:
I take a quick break from writing about a new technology strategy for TJX to mention something interesting about the job quest.
Given that I really enjoy helping people learn, achieve their goals, and create cool things, and that people do not seem to flee from my approach, and that I have an affinity for software, tech management is a good (and possibly lucrative) path for me. You've heard of the Value(able)s, Talents, Skills Venn diagram? I'm doing what makes sense: starting at the intersection of my talents and what the market values, and using that drive to get better at the domain-specific skillset.
I don't have any experience on my resume that says MANAGER in the title, other than about a year of stage-managing Heather Gold's one-woman show, I Look Like An Egg, But I Identify As A Cookie. But I have a bunch of experience in managing projects and teams. I was an editor on the high school newspaper for three years, after years of being editor-in-chief for other school papers. Quiz Bowl captain. Technical director and sometime producer/adviser for John Morearty's weekly TV show, Talking It Through, rising from camera operator. Creator and teacher of two UC Berkeley courses for three semesters. Not to mention various projects at Salon and Fog Creek.
But getting all this across to someone who only sees a resume (and possibly a short cover letter, if it hasn't been stripped off by the time it crosses her desk) is tough. So I meet people in meatspace and socially network so that my applications have more of a chance on the first reading, and I apply to nonprofits and startups where the big cheeses are more likely to take a chance on a smart, promising twentysomething.
And I'm young and childless and I want a career-building step, not just a job for money, so I'm more able to take those jobs. Or to start a startup with someone, speaking of taking a chance. Let me know if you've been aching to ask me to partner with you. I'm just woozy enough this morning to consider it.
#07 Dec 2007, 03:03AM: Question Time:
The Wednesday night mingling happened after a talk at the Columbia business school. One of the speakers: Martin Sorrell, whom everyone called "Sir Martin" since the Queen knighted him, even though we're in the US where titles of nobility cut no ice. Supposedly it's the polite thing to do, but I wish I'd just called him "Mr. Sorrell" instead of going with the flow and calling him "Sir Martin." He's just a guy who looks like if Harlan Ellison had Christopher Hitchens's face and a broken nose. If Douglas Adams never got a "Sir" then why should this guy?
It was later pointed out to me that he's an incredibly rich guy, one who over 22 years built WPP, the leading advertising firm in the world. But I'd never heard of it or him until the professor who organized the gig started raving about his catch, and gleefully wishing one of us would have the courage to ask Sorrell about his succession plan. I volunteered, since I didn't see what would be so brave about it.
Sorrell didn't mention, but I later heard, that he's divorced and has no children. When I asked the question, he first joked that he had to leave the room, then more seriously noted that the company's succession planning had found internal candidates who would be able to run WPP, externally and internally, as well as he had.
But! Other points of his: No one will run the firm quite as he does, and that's fine. Founding and running businesses are different skillsets and it's rare to find both in one person. He felt the lust for scale, the urge to grow his business to epic heights. Starting a business is the closest a man can come to having a baby.
Hmmm. There is a stereotype that women lavish(ed) ruinous attention on their children because other avenues of self-expression and achievement are/were closed to us. But I hadn't considered the reverse.
#06 Dec 2007, 11:56PM: Sociability:
For three nights in a row I have hobnobbed with people in suits to exchange business cards. I have been telling them that I am seeking a project management role in a small, flat organization where I'll listen to users, translate business needs into technical action plans, and coordinate developers who create sites, services, or products that have a chance of making someone smile.
It can be difficult to translate my set of preferences and peeves into a specific and positive objective. I love conversing, and in conversation one can take a few sentences, gauge a partner's empathy for said peeves and prefs, and clarify them with vivid descriptions. The one-way static text of my resume just isn't as social. The resume's necessary, but I'd rather hobnob, even if it means I have to put my nice shoes on.
#13 Nov 2007, 03:30PM: Medium-Term Plans:
Leonard and I have decided that we'll stay in New York City through the end of 2008. I'm now looking for a tech project management job in Manhattan or environs, so if you have a position or a lead please let me know.
Till now, I've been trying to concentrate on my master's degree and on some personal projects. One of them: learning programming basics, with an emphasis on Python. How am I to manage technologists if I don't have personal experience in at least the bare basics of their craft?
Surprisingly enough, van Rossum's Python tutorial is for people who already know how to program. I looked at a few introductions to programming for non-programmers and saw more than one recommendation (example) of How To Design Programs. It has more exercises than How to Think Like A Computer Scientist, and I already knew the basics of Scheme from my intro-to-intro-to-CS class at Berkeley. But I do want to learn Python, so I've implementing my exercise solutions mostly in Python, using IDLE, with a few stops in DrScheme for the cute GUI bits that make use of DrScheme's teachpacks. Thanks to my husband and to Magnus Lie Hetland, and of course the Python documentarians, for encouragement and reference material.
However, after the intro to data structures part of How To Design Programs, I began to run into more substantial burdens in the dual-language approach. I'm on functions that consume and produce lists now and haven't done much in Python for the last several weeks. So I'll be getting back into that in December. Being able to read and write code in some modern language is, after all, the point of the thing.
When I was at Fog Creek, Joel Spolsky helped me learn how to learn programming. It's not like history, he explained. When you read a how-to text, you have to do all the exercises and then some, playing around till you learn the abstractions by bumping into all their edges. So the abundance of exercises in HTDP is exactly what I needed.
I've also figured out how to focus and program for hours straight: turn off the Internet (I used lovely Unix toolness to How to Design Programs onto my laptop so I can read it anywhere) and sit with a friend who's also trying to focus and program. Michael Rehse and Fureigh have been great partners for this. Also good for general Sumana productivity: specific daily schedules, not just to-do lists, but task lists with time estimates.
With these career plans, I've laid out some tracks in front of me. Now I just need to stoke my engine.
# (2) 05 Nov 2007, 11:22AM: Ask The Hardest Polite Question You Can:
Last week was a tough week for some kings of finance. The heads of Citigroup and Merrill Lynch jumped, or were pushed, out of their jobs. In the months prior there were rumblings at lower levels, including the "resignation" (who knows?) of a financial services executive who had come to speak to our class at Columbia back in the spring.
He gave a good presentation about becoming more than just a tech person, becoming a strategist and a leader. He may have mentioned ambition, how much you have to want that brass ring to do the work that it takes to get it.
I thought hard to find a question for the Q&A. I raised my hand and he called on me.
"How do you measure your own success?"
That's where it took a turn. He didn't talk about money he's made, or jobs he's created, or people he's mentored. He said that he wasn't sure about calling himself a success. He found great fulfillment in the challenges of his work. Once, years back, when his family was settled in a house and in their lives on the East Coast, he'd gotten a job in Detroit, and he'd uprooted his family (including his college-age child) to move them to Michigan. His wife left him.
So, he said, he didn't know whether he'd succeeded or not, how to measure that.
I said: the measure is, would you do it all over again?
Someone said "whoa." The executive thought, and the room was silent, and he said he didn't know.
I've heard classmates reference that exchange, months later. They are grateful to him for his honesty. I wonder what they'll remember me for.
# (2) 05 Oct 2007, 02:05PM: Plans:
Planned for last night: a sprint of sorts, where I'd help a friend spec out and start writing an app he's writing for his job and I'd do a few chapters of How To Design Programs. We did some speccing, I did exercise 4.3.3, and we talked a bunch about careers, money, sex, and relationships. I'm surprised religion and politics didn't make it in there.
It was rejuvenating to do project-manager-y stuff with him and remind myself of why I'm on my path. It's been a tough week with Leonard away at Martha's Vineyard. As he has a concentrated week of working on his dreams, I'm alone in our apartment looking for any dreams I might have had and then buried. Necessary Dreams: Ambition in Women's Changing Lives showed up for $2 at a thrift store yesterday so I bought it and it's helping.
# (2) 16 Sep 2007, 04:37PM: Your Passion, Their Power:
Back on June 9th or so, way before Fog Creek and I parted ways, I read a blog entry on how to hire people for startups and posted a comment that doesn't show up there anymore. Marc Andreessen took down comments on his blog because it would take too much time to moderate them (definitely a better alternative than letting them run amok). So I'm reposting it here, slightly edited:
One of the good things about our industry is that there are frequently lots of new jobs being created and so you're almost never pushing someone out onto the street...
And, the implication runs, anyone driven enough can get another job anyway (in their city, with health insurance that starts instantly, even during recessions, etc.).
The drive/curiosity criteria do exclude some smart people. For example, the candidate who's just coming back into the job market from full-time parenting is only now getting up-to-speed on Sarbox, Vista, what have you. And this person might even make his family a priority (taking allotted vacation time and weekends)!
Startups don't like people like that. The drive and curiosity Marc seeks require sacrifice. What gets sacrificed? A job secure enough to support a spouse, or get health care for the kids. The time to volunteer for a charity, or take care of elderly relatives. Ongoing cultural literacy and engagement.
These tips sound like a great way to find Janissaries who will build your company as they build their careers. They've sharpened their ambitions, honing them to a point, shaving away concerns that regular humans might think important. You won't get "well-rounded," but you didn't ask for that. You want workers who will live and breathe the company with you. And you don't actually want people who care more about something else - family, church, dance -- than about their careers.
Marc basically says as much when he says that it doesn't matter to him why people feel driven - guilt, Type A personalities, what have you. What did happy, contented people ever do for corporate America?
In my del.icio.us-ing I said, "Marc Andreessen and Paul Graham believe that startups shouldn't bother hiring people who care about anything but career." Or, perhaps, once you're hiring people who aren't willing to sleep overnight at the office, you're no longer a Real True Startup.
A factory work shift is typically 12 hours, usually with two breaks for meals (subsidized or free), six or seven days per week. Whenever the action lets up--if the assembly line is down for some reason, if a worker has spare time at a meal break--many people place their heads down on the table in front of them and appear to fall asleep instantly. Chinese law says that the standard workweek is 40 hours, so this means a lot of overtime, which is included in the pay rates above. Since their home village may be several days' travel by train and bus, workers from the hinterland usually go back only once a year. They all go at the same time--during the "Spring Festival," or Chinese New Year, when ports and factories effectively close for a week or so and the nation's transport system is choked. "The people here work hard," an American manager in a U.S.-owned plant told me. "They're young. They're quick. There's none of this 'I have to go pick up the kids' nonsense you get in the States."
It gives me pause to know that this person from my country, a manager to whom probably hundreds of workers report, considers obligations to one's family "nonsense."
If you consider your job a means to an end, you can make the appropriate trade-offs. But if you get passionate about your work, especially at a workplace you don't control, then it has power over you, like a lover or a government. "Work hard" is a code phrase that bosses will use, sometimes knowingly, to make your life worse.
Thanks to "foobario"'s Ask Metafilter recommendation, I'm currently reading the Project Gutenberg text of Florence Nightingale's On Nursing and it's tremendous. This post's title comes from it. I thought it would be like Martha Ballard's diary, but instead it has a lot in common with Spolsky or my business-ish textbooks. Nightingale focuses on executive energy, attention, and putting the proper processes into place such that patients (employees) have the resources and quiet they need to get better (do their work). Once you get to a certain administrative level, instead of solving problems ad hoc you have to think strategically.
But it's still fun to solve a good puzzle, or to hear a good problem-solution story.
Now we're living on opposite coasts. I go to Columbia, where Zack did his undergrad. He lives in/near San Diego, where my sister did hers. OK, maybe that's too forced.
Zack criticizedThe Atlantic, at least the 2003-era Atlantic Monthly. I've been subscribing for at least a year since I find it good for long trips, so Zack, I'd be very interested in hearing what it was you found unimpressive. I try not to pay too much attention to Hitchens or Flanagan, but Fallows and Bowden seem solid. Am I wrong?
And it's light enough for good not-class reading, a.k.a. cardio-machine reading. Elliptical, stationary bike -- the machines in the Columbia gym have little perches just big enough for paperbacks or magazines, but there's really no way I can take notes during the experience. Some people have beach novels; I have Colson Whitehead's fun and moving John Henry Days and Atlantics from the past ten months. And once I've finished the mag, I can leave it in the mag-swap slots on the wall under the clock, next to the Columbia Spectators and Entertainment Weekly that people bring in. ("So that's what Chuck's about!")
Speaking of Fallows -- James Fallows, former Microsoft employee, current China correspondent -- he had an interesting article in the July/August issue: "China Makes, the World Takes." I can't glibly agree with the cover headline, "Why China's Rise Is Good For Us." Fallows does what the business folks would call a SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats) for the economic relationship between China and the US.
Right now, it's the half-automated processes, like snapping a part onto an electric toothbrush, where Chinese manufacturing excels. At the beginning (design, branding) and end (retail and service) of a product cycle, IP-heavy firms based in first-world countries do great. Manufacturing is a cost center; design and retail are revenue centers. It's classic division of labor to offshore the parts of your business where you have no competitive advantage, can't add value for the customer, and can't make profit for yourself.
That's how US businesses are thinking strategically. And Chinese manufacturers, optimized for cheap prototyping and quick turnaround (hmmm), can do quite well partnering with such firms. But the Chinese government is thinking strategically at a higher level of abstraction. How can China become a revenue center? How can China add value? By building or enticing the institutions that grow intelligent, cosmopolitan executives and entrepreneurs. So the government, being in charge, provides that these things will be done. Schools, Microsoft design labs, whatever you could imagine the frickin' communist dictatorship of the PRC coercing or encouraging. China's not content with being China; China wants to be India too.
#30 Jul 2006, 08:30PM: Marissa Mayer & I Both Use Pine:
Over the past week I've been to three different tech-related meetsup. I went to an EFF-NYC group, I helped host the Fog Creek open house, and I visited the Joel On Software discussion forum meetup in lieu of my traditional Saturday night SKP visit. It'll be a good yield if I get two lasting friends out of the whole trilogy. Today I played the hermit, rereading America: The Book and bits of Jane Eyre in between working on my column and playing Tetris with my husband.
I've spent half a year with Fog Creek now, and I know its strengths and weaknesses almost as well as I know my own. I've just downloaded a bunch of Audiofile songs and the music makes me pensive. I'm wondering what it'll take for me to become an IT leader with soul and cred.
Do I have to be a tall blue-eyed blonde with patents in artificial intelligence? Is it that or Fiorinadom? Is it possible to feel like a completely lost pioneer and a cliché sellout at the same time? That sort of thing.
Anyway, back to my columns. One is about times I've been truly happy. I think the other is about practice, craftsmanship, and the tradeoffs one makes to live a satisfying life. But I'm not sure yet.
#02 Sep 2005, 11:55AM: Impulses:
What we are now learning about the devastation in the Gulf combines with a growing desire, borne of my working life, to become a manager, a good one.
I'm working on a book proposal for the full-length book version of Getting Unstuck: Advice for Open Source Projects (38-page sampler available now for free download when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).)
The 
In honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.
![Wikimedia Hackathon 2013, by Sebastiaan ter Burg from Utrecht, The Netherlands [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AWikimedia_Hackathon_2013_-_Flickr_-_Sebastiaan_ter_Burg_(23).jpg "Wikimedia Hackathon 2013, by Sebastiaan ter Burg from Utrecht, The Netherlands [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons")
![Wikimedia Foundation all-hands meeting 2015, by Myleen Hollero (Wikimedia Foundation) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3A2015-wiki-allhands-group-0004.jpg "Wikimedia Foundation all-hands meeting 2015, by Myleen Hollero (Wikimedia Foundation) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons")
I'd like to start with a story, about my excellent boss I worked for when I was at the Wikimedia Foundation, Rob Lanphier, and what he told me when I'd been on the job about eight months. In one of our one-on-one meetings, I mentioned to him that I felt overwhelmed. And first, he told me that I'd been on the job less than a year, and it takes a year to ramp up fully in that job, so I shouldn't be too worried. And then he reminded me that we were in an amazing position, that we would hear and get all kinds of great ideas, but that in order to get anything done, we would have to focus. We'd have to learn to say, "That's a great idea, and we're not doing it." And say it often. And, he reminded me, I felt overwhelmed because I actually had the power to make choices, about what I did with my time, that would affect a lot of people. I was not just cog # 15,000 doing a super specialized task at Apple.
Dreamwidth, an open source project, started with two maintainers. They specifically decided to make the hard decision to slow down on feature development, early on, and instead pay off technical debt and teach newcomers. Now they are a thriving, multimaintainer project. 
![Wikimedia hackathon in Berlin, 2012, by Guillaume Paumier (Own work) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AWikimedia_hackathon_020_-_Berlin_2012_03.jpg)
![Sumana with two other women running Wikimedia hackathon in Berlin, 2012, by Yves Tennevin [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AWikiWomen8.jpg)
![Sumana teaching a Git workshop at Wikimedia hackathon in Amsterdam, 2013, by Sebastiaan ter Burg from Utrecht, The Netherlands (Wikimedia Hackathon 2013, Amsterdam) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AWikimedia_Hackathon_2013%2C_Amsterdam_-_Flickr_-_Sebastiaan_ter_Burg_(13).jpg)
![Wikimedia hackathon in Amsterdam in 2013, by User:Multichill (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AOpening_Hackathon.jpeg)
![Sumana and other Wikimedians enjoying a canal ride during the Amsterdam 2013 hackathon, by Andy Mabbett (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AMediaWiki_Hackathon_-_Amsterdam_2013_-_people_-_20.JPG)
![Lydia Pintscher and Lila Tretikov at the Wikimedia hackathon in Zurich, 2014, by Ludovic P (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AHackathon_-_Z%C3%BCrich_-_2014_-_Lydia_Pintscher_and_Lila_Tretikov.jpg)
![Sumana teaching a workshop participant at the Wikimedia hackathon in Amsterdam, 2013, by Sebastiaan ter Burg from Utrecht, The Netherlands (Wikimedia Hackathon 2013) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AWikimedia_Hackathon_2013_-_Flickr_-_Sebastiaan_ter_Burg_(5).jpg)
![Indic Wikimedians gathering at Wikimania, 9 August 2013 in Hong Kong, by Subhashish Panigrahi (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File%3AIndic_Wikipedian_meetup%2C_09_August_2013%2C_Wikimania%2C_Hong_Kong_02.jpg)
As of this month, I'm a full-time contractor for the Wikimedia Foundation, serving as 
