,
27 tweets,
12 min read
Read on Twitter
I've been working on a piece of writing for some time, working title — "Start Where You Are"
The thrust: people working in complex problem spaces like government sometimes err tactically in making a dependency that others do some change before getting to work, producing value.
The thrust: people working in complex problem spaces like government sometimes err tactically in making a dependency that others do some change before getting to work, producing value.
Put more positively:
I believe very strongly in starting by creating value in *some* way, shape, or form before ever even asking someone for their time and attention.
To most of the people working on complex problems, hearing someone's idea is a poor use of their time.
I believe very strongly in starting by creating value in *some* way, shape, or form before ever even asking someone for their time and attention.
To most of the people working on complex problems, hearing someone's idea is a poor use of their time.
"Starting where you are", to me, means accepting that if you are an outsider, or without much power, in a system then the only winning first move is to create some value without requiring anyone else to do anything first.
The number of well-meaning projects I've seen die on the branch due to waiting on data access would astound you.
And yet I still see people do it. Worse, they hear that "it's coming" and wait, wait, wait.
And yet I still see people do it. Worse, they hear that "it's coming" and wait, wait, wait.
Interestingly, Xerox PARC had a version of this:
They called it "Error 33" or what I'll call the external dependency error.
(Source: vpri.org/pdf/m2004001_p… )
They called it "Error 33" or what I'll call the external dependency error.
(Source: vpri.org/pdf/m2004001_p… )
In @PublicDigitalHQ's book "Digital Transformation At Scale" they have a similar prescription:
@PublicDigitalHQ This in particular applies to technologists — generally used to being in young, small organizations — working on problems inside or related to old, long-lasting, big organizations.
New people with ideas have been coming forever. You are not different.
New people with ideas have been coming forever. You are not different.
@PublicDigitalHQ Technologists *can* provide differential value — but the burden of proof is on them.
So: start where you are.
*How* do you do that? Here are a few thoughts.
So: start where you are.
*How* do you do that? Here are a few thoughts.
@PublicDigitalHQ First, use whatever existing interfaces there are, and build on top of them. Yes, this includes:
- PDF forms
- Fax machines
- Paper
- Mail
- Telephone trees
- **Going in person on behalf of people**
Existing interfaces require no change. They are stable APIs at small scale.
- PDF forms
- Fax machines
- Paper
- Telephone trees
- **Going in person on behalf of people**
Existing interfaces require no change. They are stable APIs at small scale.
@PublicDigitalHQ The virtue of "we made things better and, hey, you don't have to change anything" is that, culturally, many in large, long-lasting organizations are used to technology being quite the opposite of that:
takes forever, requires tons of human change/training, never works well
takes forever, requires tons of human change/training, never works well
@PublicDigitalHQ Another virtue of building on top of existing interfaces — as analog as they may be — is that you are then instrumenting the Really-Existing Process™.
Journey mapping with a cross-disciplinary group can be useful, but it is nonetheless an aggregation of individual myths.
Journey mapping with a cross-disciplinary group can be useful, but it is nonetheless an aggregation of individual myths.
@PublicDigitalHQ In fact, the best journey maps come from a synthesis of "what people think the process is" and "what an end-user experiences it as".
The latter can come from user research, but it's even higher fidelity when it's *real* transactions.
The latter can come from user research, but it's even higher fidelity when it's *real* transactions.
@PublicDigitalHQ (In some ways the programming metaphor here would be monitoring vs. testing:
Yes, you can cover a lot from devising test cases, but monitoring gives you a wider view of what's happening.)
Yes, you can cover a lot from devising test cases, but monitoring gives you a wider view of what's happening.)
@PublicDigitalHQ If you don't want to actually *use* these existing interfaces — to build or maintain relationships — that's totally fine!
If you've built something that is an order of magnitude better (on, say, UX) with "you don't need to change anything to use this" — that's leverage.
If you've built something that is an order of magnitude better (on, say, UX) with "you don't need to change anything to use this" — that's leverage.
@PublicDigitalHQ - "Don't build anything before deep research!"
- "Ship ASAP!"
This is a false binary to me.
Building *something* good, fast, with clear value and requiring no deep change demarcates you as a different actor.
Most value-add changes (say policy) cannot be done in isolation.
- "Ship ASAP!"
This is a false binary to me.
Building *something* good, fast, with clear value and requiring no deep change demarcates you as a different actor.
Most value-add changes (say policy) cannot be done in isolation.
@PublicDigitalHQ Even if you throw it away (I've done this!) you can blow people away with delivering a real thing — a real thing you could turn on today! — without requiring 13 meetings and a change management process to do so.
@PublicDigitalHQ There's also a critical part of "starting where you are" which is more philosophical:
As a technologist coming into a domain that's calcified over decades, why do you presume the change you make will be positive?
Starting small, changing little—but shipping—can tell you.
As a technologist coming into a domain that's calcified over decades, why do you presume the change you make will be positive?
Starting small, changing little—but shipping—can tell you.
@PublicDigitalHQ (This is where I tell you to read "Seeing Like A State" by James C. Scott.
Or, this fairly well-written digestion of it: samzdat.com/2017/05/22/man… )
Or, this fairly well-written digestion of it: samzdat.com/2017/05/22/man… )
@PublicDigitalHQ The tech-oriented observer will notice this outlook bears some intellectual debt to @ericries' "The Lean Startup".
I agree. The idea of technology as hypothesis testing exercise —and technology as *subservient* to establishing causal relationships—is powerful.
I agree. The idea of technology as hypothesis testing exercise —and technology as *subservient* to establishing causal relationships—is powerful.
@PublicDigitalHQ @ericries But I'll add that it also bears intellectual debt to "permissionless innovation" — wherein the societal default is that something is allowed unless it's explicitly prohibited.
This is usually not the case in large, long-lasting orgs like govt.
Starting where you are helps.
This is usually not the case in large, long-lasting orgs like govt.
Starting where you are helps.
@PublicDigitalHQ @ericries Very tactically let me offer a concrete suggestion:
Start by offering a "shim" layer of customer service.
AdWords + splash page.
Stand outside a lobby.
Whatever.
Get people and help them through the process you're working on.
You'll find things no one else in the world knows.
Start by offering a "shim" layer of customer service.
AdWords + splash page.
Stand outside a lobby.
Whatever.
Get people and help them through the process you're working on.
You'll find things no one else in the world knows.
@PublicDigitalHQ @ericries (I'll save for another time that "customer service shim layers" on top of govt services could forge a fundamentally different form of advocacy driven more by actual users' experienced problems another day. I believe this model is viable.)
@PublicDigitalHQ @ericries Anyway, thank you for indulging this as I draft my scattered thoughts on this via Twitter.
I hope it has been valuable, and would love to hear your experiences or more abstract challenges to this thinking that your experience gives you.
I hope it has been valuable, and would love to hear your experiences or more abstract challenges to this thinking that your experience gives you.
@PublicDigitalHQ @ericries (Oh, if you happen to have a problem fitting these contours, I do a little side consulting with folks tackling impactful problems — DM me if you think a few hours of time could help you with such a problem.)
@PublicDigitalHQ @ericries Not a stupid question!
A "shim" (Googles...) is defined as "a washer or thin strip of material used to align parts, make them fit..."
That's actually not a bad definition for its use here. I mean it to say a simply bridge layer on top of what is now.
A "shim" (Googles...) is defined as "a washer or thin strip of material used to align parts, make them fit..."
That's actually not a bad definition for its use here. I mean it to say a simply bridge layer on top of what is now.
@PublicDigitalHQ @ericries 100%. @genevievegau gets the order of magnitude right here, and also the deeper point that when “going live with SOMETHINGABSTRACT” is your pitch you are going to have a bad time compared against “CONCRETESMALLTHING”.
@PublicDigitalHQ @ericries @genevievegau (I should say “corrects my somewhat optimistic/pirate view”)
