Worknotes: Week 9

Two months! In my last update I wrote about an overwhelming sense of normalcy. That has continued, in a good way.

I am making good pace at completing my Engineering Manager bingo card. So far I have:

  • Worked with team and directors to write out quarterly OKRs, and close out the previous quarters
  • Gone through (well, shadowed) the half-yearly performance review process
  • Worked with a report through their departure from the team
  • Participated in the candidate interview loop, though not yet as a hiring manager

Something I’m inspired by

Writing OKRs with my team, boss, grandboss, and peer managers has been really, really, nice.

  • My team has been open within the OKR writing process, and creative, and participatory. I fumbled a bit trying to design an async but consensus Enthusiasm/Complexity matrix, but it’s been a great resource for me to understand the backlog and the team’s interests.
  • My boss and grandboss have been understated , but driving the importance of OKRs. I’ve particularly appreciate them say “Let’s get it right, but it’s also just a Google Doc and we can change it”
  • My peer managers as bar raisers in the process. We write OKRs for the department within the same document and I’ve appreciated getting comments and questions about consistency and measurements and categorizations.

I think planning is a fun challenge, with the two things that I focus on being:

  • Strategic Planning vs Operational Planning. In my sideline as a strategic planning consultant, separating out these threads is the work.
  • Team participation. I wasn’t surprised that participatory OKR planning was a stretch. At my previous jobs it’s not uncommon to have coworkers go from griping about long participatory planning meetings, to then asking “I don’t understand how the team prioritizes work.” Sometimes that can mean “I don’t agree with what came out of planning” but it frequently can mean “I didn’t see that planning as the venue for what I want to advocate for.”

I’m still uncomfortable writing essays in Slack, but I did write this for the team:

OKR thoughts: It might be interesting to explain how I view the OKRs in case it changes your feedback about them.

I write OKRs is that they’re a summary of what the team wants to do, to be communicated upwards. And then we expect management/leadership to protect/fund those activities over the duration of the quarter.

So they’re things that we believe (hopefully, feedback wanted) :

  • we’re enthusiastic about doing (most importantly)
  • AND we think we can reasonably accomplish during the quarter (maybe with a bit of stretch, but that should come from us)

And then that gets sent upwards, and (usually, in my experience elsewhere) Leadership says “great! let us know how we can help.” And if there is feedback, it’s usually of the form of “do you think this falls more into X or Y bucket?” (because they have to write their OKRs) and then maybe it’s a conversation. I’ve seen Leadership start meddling when a team doesn’t put forward a confident set of objectives, not usually in opposition to them. They’re part of a team umbrella ☂️

I have never seen OKRs be inflicted on a team; if it feels that way, I think that sucks. Hence why I’m wanting to explain my perspective in case that’s new.

Bring thoughts to our Sync Meeting next Tuesday, or add them to the OKR chat above, or DM me.

Thank you for coming to my TED Talk 😃

Something I’m challenged by

One way you might design a performance review process is to combine:

  • Evaluative feedback, simple quantitative metrics (does not meet, meets, exceeds) expectations, grounded against a career ladder or functional job description.
  • Coaching and appreciation, qualitative narrative about past contributions and future opportunity and explains the gaps between the true work and the ideals of the career ladder.
  • Unifying economic model for salary adjustments (and bonus, new to me) and promotions that answers what the company “recognizes” (“recognition” is how across my career I hear ICs talk about their perceived match between personal/team contributions and compensation/hierarchy)

The challenge of these systems (like my essay on OKRs above) is keeping them simple enough to be transparent, while recognizing that the map is neither the landscape, nor the expedition. I think there is room for improvement in all things, and I haven’t yet seen any of the worst pathologies of my past (like a long ago director who pushed back against a transparent career ladder because of their fear people would “game it”). I’m hoping I remember all this 6 months from now when it kicks off again.

What’s next

I get to see how the team executes on our OKRs and how our quarterly engineering rotation kicks off. I’m excited for both.


I read "Programmed Inequality: How Britain Discarded Women Technologists and Lost Its Edge in Computing" by Mar Hicks

| Review | ★★★★★

The experience of learning about systemic racism in the US is a constant derailing of “but we can’t know the actual intent”; systemic sexism on the otherhand is “oh, here are the receipts”. Which is not to discount the research and scholarship of author Mar Hicks, more just to say “wow, there it is”.

Programmed Inequality is focused on one particular aspect covered by the more surveyish Recoding Gender. To attempt to summarize a lot:

  • Take a systemic inequality, like the Marriage Bar, which made it unlawful for women to keep their job once they became married.
  • Then it’s reasonable to imagine that managers will invest less time in training and developing women in the workplace.
  • Then it’s reasonable to imagine that women are less likely to be promoted into management and leadership.
  • Then it’s reasonable to imagine that women will be tracked into roles and functions that do not offer training or management potential.
  • Then it’s reasonable to imagine that roles and functions will be designed and shaped around these constraints and will develop bureacratic inertia.
  • Then it’s reasonable to imagine that other roles and functions (who happen to be men, because of the previous reasonable assertions) will be bureacratically competing for power and resources and prestige with those feminized roles and functions (and the women who fill them). And it will be ugly.
  • Then it’s reasonable to imagine that, people being people, on human timescales with human constraints, and talent being equally distributed even when opportunity is not, they’ll do their best to navigate and come to terms with it in different ways.

It’s a book about an 80 year trainwreck. It has some interesting details about deskilling, and also about femininization: how expertise is reframed as “temperment”.

Although government reports referred to the great mass of their women workers as doing the “ monotonous toutine work” that made up the broad base of the Civil Service “pyramid,” inquiries into the exact content and nature of machine operation commissioned by the Treasury itself repeatedly contradicted the characterizations of it as deskilled work.” These reports showed how machine workers needed many of the same skill sets as higher clerical workers and how machine operation jobs were best performed by higher-skill, more educated workers. Even machine workers at the lowest levels, who dealt with narrowly specialized calculations, possessed similar skills as clerical workers: “The lower grades of the technical part of the engineering field and the scientific Assistants are both fairly close to the Clerical Class in many respects,” admitted an internal Treasury memo. Despite this, most women workers were now partitioned off from the higher-status clerical class. Eventually, the machine operator class would have three levels: The entry-level rung was the position of machine assistant. The middle rung of machine operator, took on more complex work. Women would rise to machine operator in their midtwenties. The top grade was senior machine operator. These women would perform the most complicated work in the class, including programming and systems analysis. The expectation was for women to attain that rank in their later twenties or early thirties, because at that point promotion and pay increases ceased–much earlier than for workers in clerical jobs. The structure of the new class enforced a shortened, dead-end career, partly because of the idea that women should leave by this point to get married and take care of a family, but also as a reflection of the low worth accorded to this work. Many Civil Service leaders in this era could not conceive of technical or machine-aided office work as interesting, as complex, or as providing preparation for higher work. The fact that the association of women with machine work in offices had initially evolved from women’s association with typewriteers helped reinforce this attitude. Yet the machine class was not simply a reflection of the status quo. It was the Treasury’s attempt to deal with rising numbers of women employees by reorganizing the government’s postwar workforce.

And surfaces a lot of stuff that’s seemingly baked into computing and labor relations:

Even before White Heat raised the profile of computing, a 1962 overview of government computing policy reported that the government hoped to recruit most programmers from the ranks of the seventy thousand workers in the executive class–the management class of workers with A-level secondary school training, but without the university training of the higher administrative class or any particular skill set commonly associated with early programming expertise. Executive class officers dealt with long-term departmental goals and developed processes for greater efficiency. They were also overwhelmingly men. Paradoxically, these new recruits were thought to be more qualified for the technical aspects of computer jobs even though they lacked any machine experience. The tacit expectation was that higher-level civil servants would be more intelligent overall and therefore would have no trouble picking up supposedly lowly technical skills. A widespread belief persisted in government that work involving machines did not require much intellect. Yet the Treasury’s initial feelings that “the operation of computers was expected to be similar to that of punched card equipment and thus proper to SMOs [senior machine operators]” was giving way to the idea that computing jobs were actually too complex and required too much training to continue using feminized labor. “ Although a number of staff currently graded in the MO (Machine Operator) class are demonstrably suited to be computer operators,” opined one 1966 report, “it must not be assumed that all machine operators capable of traditional responsibilities for that class have in fact ‘operating’ ability.”

This shift in attitude reflected the rigidity of the class hierarchies of the Civil Service. Even though government workers were supposed to be able to rise through the ranks meritocratically, by means of examinations, those in the lower classes of the service were often seen as fundamentally inferior to those at higher levels. As a result, there was little focus on grooming workers already in computer posts for higher positions. Instead “better” workers would be brought in from the executive class and trained to do those jobs. Whether the nation was headed by Labor or the Conservatives, the highest administrators within the service remained relatively constant in their opinions about modernization within government. “It was early on decided that for most programming orderical operations one did not need graduates in mathematics or other Growledge of professional standard, but a reasonable level of intelligence and certain aptitudes,” explained an organization specialist in the Treasury who authored a 1962 report titled “Electronic Computers Oil the Wheels of Government,” Management potential and a broad understanding of the workings of government agencies were the key qualities the Treasury now sought in computer workers.


Laws of Spacecraft and Software

Lots of similarities between Akin’s Laws of Spacecraft Design and software management; via AJ’s weekly email:

  1. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

  2. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

  3. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

  4. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

  5. (McBryan’s Law) You can’t make it better until you make it work.

  6. If there’s not a flight program, there’s no money. If there is a flight program, there’s no time.


I read "Hench" by Natalie Zina Walschots

| Review | ★★★★

Hench moves past “but what if superheroes were actually bad?” and into exploring whether one can have superpowers without aligning/performing as a hero (not according to the heroes) and can someone be villaneous without being evil? (open question)

It’s delightful in the Becky Chambers’-style of “let’s (try) to be our best selves while navigating our differences against a backdrop of adversity”. For some moments I felt like I was reading The Phoenix Project to the extent it was describing contemporary professional life …but then drops in a story of using child abuse as a supervisory tactic and that was not enjoyable.


Worknotes: Week 5

I just had my 1-month anniversary. The new job feels…. normal 🤷‍♀️ It’s 1:1s and sensemaking (dot-connecting, aligning, stortytelling) and gently holding and sharing and developing opinions about how people should collaborate in the worksplace and engineering the infrastructure that supports that. I dunno, given that I’m still working from home, it’s all still people stuff just different people. One of those Boasian “variations within groups are greater than variations between groups” things. People are great!

Something I’m inspired by

I’ve observed a lot of reinforcement of goals and values. I’ve been impressed seeing my team jump on an issue and not just say “I can help” but also “Our team’s purpose is to help.” Or seeing my Director hop in a comment and not just say “Great work” but also “This is a great example of our group’s charter”.

I think the majority of the feedback a manager should be giving is shining a spotlight on the things someone is already doing that are good and meaningful, and I’ve been inspired to see that in action from others.

Something I’m thinking about

I’ve been working through Lara Hogan’s “Questions for our first 1:1”, which is part of my personal manager runbook.

The question “How do you prefer to receive recognition?” gets spicy answers! I’m managing a very high level team and the answers closely line up with my own high-level friends and high-level former coworkers and myself: people are uncomfortable with recognition.

Which is… a not unreasonable reaction. In the words of a close friend “This is total shit, but… thanks, I’m glad you like it.” When I think about my own reaction, I attribute it to navigating a lot of intersecting supremacy cultures (conscious and unconscious) which are complicated: perfectionism, humbleness, honest practice, a desire to recognize all contributors (which has its own recursive sympathy).

I get it. I think about how much self-work I’ve done in my own life to reply to “I like your X” with simply “Thanks!” (and not “oh, and I like your..” or “oh, it’s not that great”).

What’s next

Two quarterly activities are upcoming that I’m excited to be organizing for the first time: engineering rotations and OKR setting. I’m sure I’ll learn a lot.


Weeknotes: Week 0

I started a new job midweek this week at GitHub, managing their Ruby Architecture team. I love the team’s mission:

Making it easy for our engineers to create, deliver, and operate best-of-class Ruby and Rails applications, and sharing the best of it with the world.

I also took about 2.5 weeks in between leaving Code for America and starting this job, so I’m feeling fresh and ready for several weeks of official onboarding, and several months of growing into the role.

Something I learned

GitHub is heavily into written documentation. “If it doesn’t have a URL, it didn’t happen.”. And not just cross-referencing, but emoting and emoji-ing, and being, well, extra. Writing and communication has been reinforced a lot during onboarding, more even than the content itself. Which makes sense: if you understand how the organization communicates, you can seek answers independently.

Something I was inspired by

Despite formal onboarding being my number one focus, I’ve been having casual 1:1s with my team. They’re great! I’ve been inspired by the nuance and understanding they bring to the work. On its own, being a service team is hard, and corporate open source is hard. I’ve found myself heavily nodding along hearing them discuss the challenges of moving people forward. It’s brought to surface a few thoughts and memories:

  • Of being a frontend lead at Pantheon and the challenges of getting platform-team resources to build up to the outcome and vision we all agreed on, but that had some uncomfortable zigs and zags to get there. A case of make the change easy (which can be hard), then make the easy change.
  • My falling out of the Drupal ecosystem as it developed more in line with the needs of full-service agencies than of solo devs and configurers like myself. As one of my colleagues admitted this week, our developers aren’t running “rails new” a whole lot and that’s something to be mindful of how it shapes the contributions.
  • “If you’re leading and no one is following, you’re just out for a walk.”

I read "Recoding Gender" by Janet Abbate

| Review | ★★★★★

Recoding gender

I enjoyed the book. It’s a quick survey of early computing and software history, and the lens of gender makes a lot of it new.

A few themes stuck out to me, from my standpoint of 2022:

  • Contemporary development, and even agile (by other names) come from feminized sources.
  • The distinctions between the activities of plugging, coding, programming, solving, planning, and training; and the roles of “Engineer”, or “Architect” or “Manager” which are largely gendered.
  • The feminization of “technical” work of interacting with business machines (e.g. a typewriter, photocopier, etc.) and the perceptual “de-skilling” of those roles despite them being, well, heavily technical.
  • Programming productivity gains being gobbled up by increasing complexity…. Well, sometimes… because there is a perceptual emphasis on complex edge-cases rather than the needs of the “typical” business.
  • Conference on Software Engineering sponsored by NATO and held in Garmisch, Germany on 7–11 October 1968 was a big deal in the history of programming.

Sure sounds like contemporary collaborative practices:

[Elsie] Shutt’s [of Comp Inc.] approach was to organize her programmers in teams that collaboratively divided the work among themselves: “We would get together every week, everybody working on the project. One thing we had to learn to do was to take a job and to break it into pieces—meaningful pieces—and then we’d get together, talk about it, assign jobs.” She coached her programmers to be meticulous, which resulted in efficiencies for the company and a better product for the client. For example, she emphasized desk-checking, the practice of having programmers review each other’s code before running it on the computer. Although desk-checking was a fairly common practice in the 1950s, Shutt believed that she “emphasized it more than others did” because we were doing things that we broke up into more pieces than some people did.” Comp Inc. had no room for “egotistical” programmers who refused the share their code. Another key priority was “documenting it—well—so that someone else would be able to maintain it if they needed to.” Producing modular, well-documented code also made it easier for Comp Inc. to repurpose programs for subsequent clients, which saved on programming costs.

…and Agile:

Women may have been uniquely situated to participate in these innovations because of their gendered role in the workplace. As working programmers—and as the staff members who stereotypically were asked to assist customers or in-house users—women had both the expertise to devise solutions and the incentive to make programming easier for experts and novices alike. And although women usually lacked the formal authority to impose workplace practices, this was unnecessary in a computer culture that left the choice of techniques largely up to programmers themselves.

On productivity and the never-realized goal of getting rid of programming as a specialization:

In many ways, the campaign for automatic programming was a rousing success: The new techniques were widely adopted, and as promised, they greatly reduced the time that was needed to produce programs and transferred much tedious work from humans to machines. Many programmers took advantage of these new tools to improve the organization of that programs, creating a visible, logical structure that made code faster to produce and easier to maintain, reuse, and share. However, to the disappointment of some, the overall effect of compilers and associated tools was not to eliminate programming but to redefine it. Much of what had been included as an integral part of programming practice–tedious copying or recoding of subroutines, the need to be aware of machine design and physical memory configuration, and the use of machine codes-was no longer required. But the programmer still had to design and specify the higher-level structure of the program, tasks that proved too complex for most end-users. The new techniques also did nothing to automate the initial analysis of the problem–the task of modeling a real-world activity as an ordered flow of computable steps. Although this work could potentially be shifted from the programmer to a systems analyst, in either case it was a person and not the computer that performed it.

To the extent that a factory-like version of automation failed to materialize, it vindicated programmers’ holistic view of their work as complex and creative. It also reflected a conscious decision by computer manufacturers and their customers to use automation to increase productivity and quality rather than to shrink the labor force. Managers asked programmers to tackle more ambitious projects or create more sophisticated user interfaces, expanding their demand for skilled labor to absorb the available supply. The ever increasing complexity of cutting-edge systems would soon lead to new calls for a reform of programming methods.

An ongoing discussion about what happens.

The term software engineering has become common enough today that its provocative effect has been lost. Yet when the term was introduced at Garmisch, it was purely aspirational. Rather than claiming to describe actual practices, the organizers named an ideal that did not yet exist. Nor was it obvious that engineering was the best model for programming. The computing literature of the 1960s is rife with competing metaphors, each or which was chosen to make a particular claim about the nature of programming. Some managers continued to view programming as creative art or craft—and in a positive sense, rather than as a problem to Be cured by imposing scientific rationality. In the academic community, computer science was often seen as a branch of mathematics, which had a higher intellectual status than engineering. The 1970 On the Management of Computer Programming, a book that targeted a business audience, ignored the new term software engineering and preferred to use managerial skill as its ideal. Maurice Wilkes argued in 1976 that the term engineering did not realistically represent the process of creating a large program. He suggested instead that “There are some analogies between writing a program and writing a treatise or a paper.” Computer industry writers invoked a host of other professions to emulate, including accounting (for its certification standards), medicine (for its skilled teamwork and strong professional societies), architecture (as a model for coherent design and precise specification), aviation (for its recognition of the dire consequences of failure), or even cooking (as a time sensitive production process).

Given this gendered status hierarchy, some practitioners—women as well as men—may have believed that programmers would rise in stature by adopting the title of engineer. An unintended consequence of this move may have been to make programming and computer science less inviting to women, helping to explain the historical puzzle of why women took a leading role in the first wave of software improvements but become much less visible in the software engineering era.
….
“For instance, getting your requirements right initially; understanding the materials you’re working with.” Susan Graham, the daughter of a mechanical engineer, got her Ph.D. in computer science a few years after Garmisch and easily identified as a software engineer. Referring to the process of checking the semantics of a programming language, Graham characterized engineering practice as trial-and-error: “You write a compiler, and then you do a lot of testing against real programs, and you try to see whether the right thing happens. And that’s why it’s engineer ing!” These examples demonstrate again the diverse meanings of engineering, as well as female practitioners ability to prioritize those aspects of engineering that matched their own needs, experiences, and values.

Some aspects of the software engineering ideal appealed directly to preferences that were widely expressed by women, such as the desire to create something that would improve users’ lives. Edward E. David of Bell Laboratories expressed this philosophy at Garmisch in 1968: “Software engineering and computing engineering have an extremely important and nice aspect to them, namely that people want to work on things that meet other people’s needs. They are not interested in working on abstractions entirely; they want to have an impact on the world.” Mary Shaw, who helped establish Carnegie Mellon University’s Software Engineering Institute in the 1980s, echoed this public service ethos in her own 1990 definition of engineering as solving “practical problems . . . in the service of mankind:”In her view, key aspects of an “engineering attitude” included “considering users” and realizing that design choices had to be made “for both technical and nontechnical reasons.’ Shaw’s emphasis on users and on real-word, nontechnical factors fits well with the computer-as-a-tool orientation more common among women. Although Engineering as a profession has been highly masculine, engineering as a discipline or philosophy has had wider range of potential meaning.

In at least three important senses, software engineering could be said to have failed. First, because of the divergent approaches and priorities of academic theorists and industry practitioners, much research investment has been wasted. Second, to the extent that software engineering was meant to revolutionize labor practices by deskilling and disciplining programmers, imposing standardized research-based methods, or mandating licensing, it has not succeeded. Finally, software engineering never solved the problem that was its raison d’etre—the software crisis. These failures call into question the notion that engineering is the most appropriate model for the programming profession.


I read "Science in the Capital" by Kim Stanley Robinson

| Review | ★★★★

The series is 3 books:

  • Forty Signs of Rain
  • Fifty Degrees Below
  • Sixty Days and Counting

It was subsequently re-edited into a single edition (Green Earth), but I read the originals. They have all the components of a KSR book:

  • Someone is smacked in the face
  • The last third of the book/series includes a travelogue of terraforming
  • Buddhism
  • Humanity rendered (and pondering) their place as a primates-out-of-forest/fish-out-of-water in a technology-based society.

And some uniquely nice and interesting things

  • Child characters. I found them the most interesting, especially toddler Joe. Older Nick is pretty boring and unmotivated (in the literary sense) in stark contrast to Aurora’s Devi.
  • Contemporary setting (which does have its problems, like suggesting fictional nano-rods instead of actual CRISPR). This is mainly why I gave it 4 stars; it’s fairly unique as a KSR book goes.

A main theme is “an excess of reason is itself a form of madness” with the various characters navigating contemporary rationalism (politics, bureaucracy, venture science, healthcare, courtship, family) within the constraints of their character’s authentic selves.

“We are animals. Animals whose wisdom has extended so far as to tell us we are mortal creatures. We die. For fifty thousand years we have known this. Much of our mental energy is spent avoiding this knowledge. We do not like to think of it. Then again, we know now that even the cosmos is mortal. Reality is mortal. All things change ceaselessly. Nothing remains the same in time. Nothing can be held on to. The question then becomes, what do we do with this knowledge? How do we live with it? How do we make sense of it?”

Well—indeed. Frank leaned forward, piqued, wondering what Drepung would tell them the old man had said next. That gravelly low voice, growling through its incomprehensible sounds—it was strange to think it was expressing such meanings. Frank suddenly wanted to know what he was saying.

“One of the scientific terms for compassion,” Drepung said, looking around the ceiling as if for the word, “… you say, ‘altruism.’ This is a question in your animal studies. Does true altruism exist, and is it a good adaptation? Does compassion work, in other words? You have done studies that suggest altruism is the best adaptive strategy, if seen from the group context. This then becomes a kind of … admonishment. To practice compassion in order to successfully evolve—this, coming from your science, which claims to be descriptive only! Only describing what has worked to make us what we are. But in Buddhism we have always said, if you want to help others, practice compassion; if you want to help yourself, practice compassion. Now science adds, if you want to help your species, practice compassion.”

This got a laugh, and Frank also chuckled. He started to think about it in terms of prisoners’ dilemma strategies; it was an invocation for all to make the always generous move, for maximum group return, indeed maximum individual return.… Thus he missed what Drepung said next, absorbed in something more like a feeling than a thought: If only I could believe in something, no doubt it would be a relief. All his rationality, all his acid skepticism; suddenly it was hard not to feel that it was really just some kind of disorder.

And at that very moment Rudra Cakrin looked right at him, him alone in all the audience, and Drepung said, “An excess of reason is itself a form of madness.”

Frank sat back in his seat. What had the question been? Rerunning his short-term memory, he could not find it.

Now he was lost to the conversation again. His flesh was tingling, as if he were a bell that had been struck.

“The experience of enlightenment can be sudden.”

He didn’t hear that, not consciously.

“The scattered parts of consciousness occasionally assemble at once into a whole pattern.”

He didn’t hear that either, as he was lost in thought. All his certainties were trembling. He thought, an excess of reason itself a form of madness—it’s the story of my life. And the old man knew.

The biggest problem with the book is that one of the main characters is super creepy. And it goes on too long. I think the latter is fixed in the edited Green Planet edition, but I dunno about the former. Fortunately he doesn’t act on it:

Now he was considering acting in accordance with his beliefs. Something else he had heard the Khembalis say at the Quiblers, this time Drepung: If you don’t act on it, it wasn’t a true feeling. … One can always just walk away. The Dalai Lama had said that for sure. Things you don’t like, things you think are wrong, you can always just walk away. You will be happier. Love and compassion are necessities, not luxuries. Without them humanity cannot survive. But compassion is not just a feeling. You have to act.

And if you make it to the third book, you’re treated to some good liberal head-canon in the newly elected President’s inauguration speech:

“Fellow Americans,” he said, pacing his speech to the reverb of the loudspeakers, “you have entrusted me with the job of president during a difficult time. The crisis we face now, of abrupt climate change and crippling damage to the biosphere, is a very dangerous one, to be sure. But we are not at war with anyone, and in fact we face a challenge that all humanity has to meet together. On this podium, Franklin Roosevelt said, ‘This generation has a rendezvous with destiny.’ Now it’s true again. We are the generation that has to deal with the profound destruction that will be caused by the global warming that has already been set in motion. The potential disruption of the natural order is so great that scientists warn of a mass extinction event. Losses on that scale would endanger all humanity, and so we cannot fail to address the threat. The lives of our children, and all their descendants, depend on us doing so.

“So, like FDR and his generation, we have to face the great challenge of our time. We have to use our government to organize a total social response to the problem. That took courage then, and we will need courage now. In the years since we used our government to help get us out of the Great Depression, it has sometimes been fashionable to belittle the American government as some kind of foreign burden laid on us. That attitude is nothing more than an attack on American history, deliberately designed to shift power away from the American people. I want us to remember how Abraham Lincoln said it: ‘that government of the people, by the people, and for the people shall not perish from this

Earth.’ This is the crucial concept of American democracy—that government expresses what the majority of us would like to do as a society. It’s us. We do it to us and for us. I believe this reminder is so important that I intend to add the defining phrase ‘of the people, by the people, and for the people’ every time I use the word ‘government,’ and I intend to do all I can to make that phrase be a true description. It will make me even more long-winded than I was before, but I am willing to pay that price, and you are going to have to pay it with me.

“So, this winter, with your approval and support, I intend to instruct my team in the executive branch of government of the people, by the people, and for the people, to initiate a series of federal actions and changes designed to meet the problem of global climate change head-on. We will deal with it as a society working together, and working with the rest of the world. It’s a global project, and so I will go to the United Nations and tell them that the United States is ready to join the international effort. We will also help the under-developed world to develop using clean technology, so that all the good aspects of development will not be drowned in its bad side effects—often literally drowned. In our own country, meanwhile, we will do all it takes to shift to clean technologies as quickly as possible.” Phil paused to survey the crowd. “My, it’s cold out here today! You can feel right now, right down to the bone, that what I am saying is true. We’re out in the cold, and we need to change the way we do things. And it’s not just a technological problem, having to do with our machinery alone. The devastation of the biosphere is also a result of there being too many human beings for the planet to support over the long haul. If the human population continues to increase as it has risen in the past, all progress we might make will be overwhelmed.

“But what is very striking to observe is that everywhere on this Earth where good standards of justice prevail, the rate of reproduction is about at the replacement rate. While wherever justice, and the full array of rights as described in the UN Declaration of Human Rights, is somehow denied to some portion of the population, especially to women and children, the rate of reproduction either balloons to unsustainably rapid growth rates, or crashes outright. Now you can argue all you want about why this correlation exists, but the correlation itself is striking and undeniable. So this is one of those situations in which what we do for good in one area, helps us again in another. It is a positive feedback loop with the most profound implications. Consider: for the sake of climate stabilization, there must be population stabilization; and for there to be population stabilization, justice must prevail. Every person on the planet must live with the full array of human rights that all nations have already ascribed to when signing the UN Charter. When we achieve that, at that point, and at that point only, we will begin to reproduce at a sustainable rate.

“To help that to happen, I intend to make sure that the United States joins the global justice project fully, unequivocally, and without any double standards. This means accepting the jurisdiction of the International Criminal Court, and the jurisdiction of the World Court in the Hague. It means abiding by all the clauses of the UN Charter and the Geneva Conventions, which after all we have already signed. It means supporting UN peacekeeping forces, and supporting the general concept of the UN as the body through which international conflicts get resolved. It means supporting the World Health Organization in all its reproductive rights and population reduction efforts. It means supporting women’s education and women’s rights everywhere, even in cultures where men’s tyrannies are claimed to be some sort of tradition. All these commitments on our part will be crucial if we are serious about building a sustainable world. There are three legs to this effort, folks: technology, environment, and social justice. None of the three can be neglected.

“So, some of what we do may look a little unconventional at first. And it may look more than a little threatening to those few who have been trying, in effect, to buy our government of the people, by the people, and for the people, and use it to line their own pockets while the world goes smash. But you know what? Those people need to change too. They’re out in the cold the same as the rest of us. So we will proceed, and hope those opposed come to see the good in it.

“Ultimately we will be exploring all peaceful means to initiate positive changes in our systems, in order to hand on to the generations to come a world that is as beautiful and bountiful as the one we were born into. We are only the temporary stewards of a mighty trust, which includes the lives of all the future generations to come. We are responsible to our children and theirs. What we do now will reveal much about our character and our values as a people. We have to rise to the occasion, and I think we can and will. I am going to throw myself into the effort wholeheartedly and with a feeling of high excitement, as if beginning a long journey over stormy seas.”


Working the problem

From An Astronauts Guide to Planet Earth by Chris Hadfield:

Feeling ready to do something doesn’t mean feeling certain you’ll succeed, though of course that’s what you’re hoping to do. Truly being ready means understanding what could go wrong – and having a plan to deal with it. You could learn to scuba dive in a resort pool, for instance, and go on to have a wonderful first dive in the ocean even if you had no clue how to buddy breathe or what to do if you lost a flipper. But if conditions were less than ideal, you could find yourself in serious danger. In the ocean, things can go wrong in one breath, and the stakes are life and death. That’s why in order to get a scuba license you have to do a bunch of practice dives and learn how to deal with a whole set of problems and emergencies so that you’re really ready, not just ready in calm seas.

For the same sort of reasons, trainers in the space program specialize in devising bad-news scenarios for us to act out, over and over again, in increasingly elaborate simulations. We practice what we’ll do if there’s engine trouble, a computer meltdown, an explosion. Being forced to confront the prospect of failure head-on – to study it, dissect it, tear apart all its components and consequences – really works. After a few years of doing that pretty much daily, you’ve forged the strongest possible armor to defend against fear: hard-won competence.

Our training pushes us to develop a new set of instincts. Instead of reacting to danger with a fight-or-flight adrenaline rush, we’re trained to respond unemotionally by immediately prioritizing threats and methodically seeking to defuse them. We go from wanting to bolt for the exit to wanting to engage and understand what’s going wrong, then fix it.

Early on during my last stay on the ISS, I was jolted to consciousness in the middle of the night: a loud horn was blaring. For a couple of seconds I was in a fog, trying to figure out what that unpleasant noise was. There were four of us in the American section of the Station then, and like prairie dogs, we all poked our heads up out of our sleep pods at the same time to look at the panel of emergency lights on the wall that tell us whether we should be concerned about depressurization, toxicity or some other potential fatal disaster. Suddenly all of us were wide awake. That deafening noise was the fire alarm.

A fire is one of the most dangerous things that can happen in a spaceship because there’s nowhere to go; also, flames behave less predictably in weightlessness and are harder to extinguish. In my first year as an astronaut, I think my response to hearing the alarm would have been to grab an extinguisher and start fighting for my life, but over the past 21 years that instinct has been trained in, represented by three words: warn, gather, work.

“Working the problem” is NASA-speak for descending one decision tree after another, methodically looking for a solution until you run out of oxygen. We practice the “warn, gather, work” protocol for responding to fire alarms so frequently that it doesn’t just become second nature; it actually supplants our natural instincts. So when we heard the alarm on the Station, instead of rushing to don masks and arm ourselves with extinguishers, one astronaut calmly got on the intercom to warn that a fire alarm was going off – maybe the Russians couldn’t hear it in their module – while another went to the computer to see which smoke detector was going off. No one was moving in a leisurely fashion, but the response was one of focused curiosity; as though we were dealing with an abstract puzzle rather than an imminent threat to our survival. To an observer it might have looked a little bizarre, actually: no agitation, no barked commands, no haste.

The next step is the gather, so we joined the Russians in their part of the Station to start working on the problem. How serious was the threat? So far, all the signs were reassuring. We couldn’t smell smoke of see flames. Maybe one little wire had melted somewhere, or the detector was responding to dust. We talked to Mission Control in Houston and in Moscow, but as we investigated, checking the module where the detector had been triggered, it seemed more and more likely that we were dealing with a simple malfunction. Finally, everyone agreed that it had been a false alarm, and we headed back to our sleep stations. An hour later, when the fire alarm sounded again, we repeated the warn, gather, work protocol just as before. The response was similarly calm, though not perfunctory – possibly something had been slowly smoldering for the past hour. As it turned out, nothing had. The detector was a lemon, that’s all. I remember thinking, “That was a little like a sim, only better, because now I get to sleep.”

I doubt anyone’s heart rate increased by more than a beat or two while we were dealing with those fire alarms, even during the first minutes when the threat of a raging inferno seemed most real. We felt competent to deal with whatever happened – a sense of confidence that comes directly from solid preparation. Nothing boosts confidence quite like simulating a disaster, engaging with it fully, both physically and intellectually, and realizing you have the ability to work the problem. Each time you manage to do that your comfort zone expands a little, so if you ever face that particular problem in real life, you’re able to think clearly.


Sense-making list-making

From the “The MetaCryptoVerse”, which triggered my oft-observation that civic tech too-frequently regresses to resource directories (lists of services):

…what happens when our institutions become just lists. Lists scattered across a network of databases.

You see we are attune to the idea of data disrupting paper. What we are not attune to is this idea of data disrupting space. Or more accurately how information architecture is disrupting architecture. Banks become lists, manifest as a collection ATMs, PC and smartphones. Office blocks become lists manifest as web pages and mobile apps. Hospitals become lists manifest as patent records and augmented beds. Government agencies become lists manifest as web pages and pdfs. Libraries become Google. Which is to say they become lists. Our clubs and churches or more accurately our communal meeting places become Facebook pages. Which is to say they become lists. Our shops become lists. Be they Amazonian or iTuna. Or schools and colleges become Moocs. Which is to say they become lists.

Now these are ideas. Conceptual models. Thought experiments. Dare I say TEDs? worth exploring. What happens when our world evolves from the bucket list to a bucket full of lists?

What would this new architecture look like? How do we interact with these new spaces? And what are the types of games we will be playing to occupy our days? What is it like to live life as an endless fractal narrative? What will be the sum of our days? The sum of experiences in this brave new world? Of life lived as a bucket full of lists. Virtual or otherwise. Just how will these lists shape our behaviour? Regulate our emotions? Facilitate our transaction? Engineer our experiences? Provoke our responses? Design our Desires? Juxtapose our inner tensions? Manipulate our self image? Game our expectations?

We discovered these are conversations worth having… with others.