by people, for people

#VelocityConf @VelocityConf @timoreilly

By People, For People

Tim O’ReillyVelocity New York

September 17, 2014

Wednesday, September 17, 14

The title of this talk is lifted from Lincoln’s Gettysburg Address, by way of the Code for America mission statement, but it’s a great way to think about one of the most important problems facing technologists today.


“We know about all these new technologies. What we don’t know is how to organize ourselves to use them

effectively.”

- An IT executive at Fidelity, during Q&A after a talk I gave there in 2008


It is well expressed by this quote from an IT executive at Fidelity investments, during a Q&A after a talk I gave there in 2008. “We know about all these new technologies. What we don’t know is how to organize ourselves to use them effectively.”



Because of course, every new technology involves massive changes in how people are organized. From factory assembly lines....



through more modern examples like open source software



wikis



and the web itself,



as well as new services like AirBnb

#VelocityConf @VelocityConf @timoreilly@conference @timoreilly


Uber



And the Apple Store


Are New Ways of Organizing People


are all based on new ways of using technology to organize people and the work that they do for each other. Think about how Uber and the Apple Store have both completely rethought the workflow of their respective industries - hailing a cab, and the retail store - by using the sensors and connectivity of smartphones to augment and empower the people using them. In a way, these services are actually made OF PEOPLE and computers in a new kind of symbiosis.But I expect that the Fidelity executive was thinking of something closer to the world most of you live in.



The world of DevOps. Which is about a profound technology change - the move to the cloud and software as a service - but as you know, and as you can see from the titles of various O’Reilly ebooks on the topic, is also deeply about people and culture. @oreillymedia, http://oreilly.com

Von Kempelen's Mechanical Turk


After all, one of the key things that corporations and developers have had to learn is that software applications are no longer artifacts. They are business processes, with people still inside them. Oh wait, they are also made of people.

I first started talking about this idea back in 1998, when I wrote a paper about the importance of “scripting languages” like Perl and Python. http://oreillynet.com/pub/a/oreilly/perl/news/importance_0498.html They were taking over, I thought, because of the way that web applications were different from previous generations of applications. They were changing all the time.

Then, in 2003, I hit upon the notion that Von Kempelen’s mechanical Turk as a wonderful metaphor for the difference between web applications and the previous generation of PC or enterprise applications. For those who don’t know about it, the Mechanical Turk was a 19th century hoax that purported to be a robotic chess master, but in fact had a human hidden inside the machine. It struck me that this metaphor was one of the great secrets that distinguished web applications from all prior applications. The humans were still inside - the developers changing the code every day, not in massive periodic software releases; the use of new collective intelligence techniques to harvest data from users; new ways of coordinating work - from Wikipedia, to GitHub, to Uber and AirBnb. I could talk for hours about all the implications, from the rise of cloud computing to the importance of dynamic languages, and now, increasingly, functional languages, and the importance of data in all modern applications. (By the way, his slide is actually taken from an All-Hands presentation I gave to Amazon in 2003, where I made the point that every Amazon employee was, in some sense, inside the application. Jeff took the idea in a very different direction, of course, realizing he could build a system to engage people outside the company in the vast machine he was building. He is a genius at thinking through hidden implications of any idea he comes across.)But let me focus in on this notion of DevOps - that it is how you develop and manage software in the age where software is a process and a performance, not an artifact - and how it has had a big impact in today’s world.


Rescuing healthcare.gov

A team of engineers. They came in and worked tech wizardry, right?

Maybe some of that, but a lot of the work was debugging the communications failures that led the contractors to build software components that didn’t work together.


You heard from Mikey Dickerson, one of the key players in the healthcare.gov rescue. (That’s him, third from the right, on the cover of Time.) I was struck by Mikey’s story, the first time I heard it, about what a classic version of the DevOps story this was.


17 hour days100 days straight

Standup meetings focused on why people weren’t able to keep the promises they’d made to each other

Mikey DickersonGoogle Site Reliability Engineer



Wednesday, September 17, 14It was right out of the Phoenix Project!

(If you want to understand more about that cultural revolution, this book is a great read - a novelized version of how DevOps was brought to a failed IT project in a big manufacturing company.)


Emergent Enterprise

“Promise theory doesn’t naively assume that all promises will be kept. Humans break their promises all the time; machines (which can also be agents in a network of promises) just break. But with promise theory, agents are aware of the commitments they’re making, and their promises are more likely to reflect what they’re capable of performing. ...

... we know the estimates were made with accurate information by the agent responsible, not by external wishful thinkers without a clue.

And a well-formed network of promises includes contingencies and backups. What happens if Actor A doesn’t deliver on promise X? It may be counterintuitive, but a web of promises exposes its weak links much more readily than a top-down chain of command. Networks of promises provide services that are more robust and reliable than command and control management pushed down from above.”


It also has powerful echoes of what Mark Burgess calls Promise Theory. Mark Burgess wrote...

“External wishful thinkers without a clue.” That’s a pretty good summary of a lot of government officials and corporate executives!


Of course, what Mikey found out was that healthcare.gov was designed and delivered by a system that doesn’t allow developers to make promises to each other, or to operations engineers, or to end users. Instead, all of the promises were from policy makers and politicians to other policy makers and politicians, and were handed down from on-high through hard-coded specifications and waterfall project management methodologies.

What the healthcare.gov rescue team brought was a cultural revolution...

Which is only beginning!!!



DevOps

“…it’s not about making developers and sysadmins report to the same VP. It’s not about automating all your configuration procedures. It’s not about tipping up a Jenkins server, or running your applications in the cloud, or releasing your code on Github. It’s not even about letting your developers deploy their code to a PaaS. The true essence of DevOps is empathy.”

Jeff Sussna, “Empathy: The Essence of DevOps”


The other great statement about the role of humans in DevOps came from Jeff Sussna, who wrote, in a blog post entitled “Empathy: The Essence of DevOps”...

http://blog.ingineering.it/post/72964480807/empathy-the-essence-of-devops

http://blog.ingineering.it/post/72964480807/empathy-the-essence-of-devops


“…one privilege the insured and well-off have is to excuse the terrible quality of services the government routinely delivers to the poor. Too often, the press ignores — or simply never knows — the pain and trouble of interfacing with government bureaucracies that the poor struggle with daily.”

— Ezra Klein

Wednesday, September 17, 14I want to take this empathy idea a bit further. One of the most important pieces about the healthcare.gov rescue was written by Washington Postcolumnist (now vox.com founder) Ezra Klein. He wrote about how healthcare.gov was not an exception, but the rule, when it came to governmentservices.

http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/25/obamacares-problems-go-much-deeper-than-the-web-site/

http://www.washingtonpost.com/blogs/wonkblog/wp/2013/10/25/obamacares-problems-go-much-deeper-than-the-web-site/



And that brings me to the work we do at Code for America (codeforamerica.org). We engage civic hackers around the world to help local governments find solutions to thorny problems. One of our programs sends small fellowship teams - essentially, a civic startup in a box - to work with a city for a year. Last year, one of the Fellowship teams went to work in partnership with the Human Services Agency in San Francisco on a problem with Food Stamps - now known as the Supplemental Nutrition Assistance Program, or SNAP. It turns out that one third of food stamp clients were being unnecessarily cut from benefits due to bureaucratic snafus. Essentially, they’d failed to properly fill out a necessary form or to submit it on time.

Fellows went to work on this problem last year,



Recently, I heard an eye opening segment on the radio show Marketplace. Do you know that a huge proportion of food stamp dollarsare spent at stores like Walmart between midnight and 1 am on the one night that people’s SNAP cards are electronically refilled?

Who goes food shopping at midnight? People who haven’t eaten for a few days, that’s who. So it really matters when you show up at the front of the line, and suddenly your SNAP card doesn’t work because you didn’t know how to respond to a letter you received in the mail.



These letters can be truly confusing. Aha, missed that QR7, did you?

The fellows replaced them with a text message saying, essentially, “There’s a problem with your benefits. Call the office.”


“User needs. An empathetic service would ground itself in the concrete needs of concrete people. It’s not about innovation, big data, government-as-a-platform, transparency, crowd-funding, open data, or civic tech. It’s about people. Learning to prioritize people and their needs will be a long slog. It’s the kind of change that happens slowly, one person at a time. But we should start.”


Jake Solomon, one of the Fellows, wrote an amazing piece about his experience, entitled People, Not Data. In it, he describes the problem: nobody who was implementing the program had ever themselves tried to comply with the rules and to respond to the instructions, until the Code for America fellows did that. As Jake said, “User needs...”


Empathy


There’s that word again.There’s a lot of talk in Silicon Valley about measuring and paying attention to users. We talk about Lean Startup and “Growth Hacking.” But there’s a big difference between paying attention to user behavior so you can exploit it - say to drive ad clicks on in-app purchases - and paying attention to it so you can make a real difference in the lives of real people.

@timoreilly

Government can work

for the people,

by the people,

in the 21st century,

if we make it so.


And that leads me to the mission statement that serves as our sort of North Star, our guiding light, at Code for America.

@timoreilly

for the people


Of the people, for the people, by the people isn’t just a dusty line from the Gettysburg address. Most of the people I’ve met who work in government went into public service in the first place because of what this line represents: they wanted to serve the public. But Jen Pahlka, the founder and executive director of Code for America, has another way to say this, which I am repeating for you here, using her slides… “For the people”

@timoreilly

for people


also really means FOR PEOPLE. That’s what Jake Solomon was talking about in his work on Human Services in San Francisco. And it’s also what you should be thinking about in every application you deliver.

by people


I haven’t talked as much today about the notion of “by the people,” but if you’ve followed my work for the past decade, you know that I’ve talked nearly incessantly about the role of collective intelligence, expressed either explicitly through new forms of cooperation, or implicitly by the data we contribute simply by interacting with modern applications, or increasingly, implicitly, via the data shadows we leave with sensor-driven applications. And as I hinted at in the first part of this talk, modern services are made not only of computer programs but literally “of people.”

@timoreilly

Build 21st century services

of people,

by people,

for people


Taken together, I think that this is a pretty good mission statement for people outside government too! Technology trends tells us that we still will build services of people, and by people when we are using 21st century technology, but it’s essential that we also build services for people.

by people, for people

Software