Getting Real with the PPI Book Club
Shortly before we launched Partners in Public Innovation, the founder of a successful startup gave me one piece of advice: read Getting Real.
Now I'm giving that advice to you.
On its face, Getting Real, written by a team of software developers, is about how to build a successful web-based app startup. But just as lean principles apply far beyond their roots in auto manufacturing, the Agile-inspired principles in Getting Real apply to anyone who needs to build a service that's responsive to customers. (Read: all of us.)
This thing practices what it preaches: It's available online, for free, in 90 "chapters" that are less than a page each. I started reading it this morning on mobile and
finished it this afternoon, mostly while eating lunch or waiting in line at the store.
In the spirit of getting things out quickly and of promoting through education (chapter 72), here's 4 things the best public servants (you!) should learn from the best software developers.
1. Do less
So often in government, our solution to a problem is to do more:
The work is backlogged? If only we could add more staff!
Applicants keep making a mistake? Let's add more text to our reminder email.
A regulation changed? Let's add another acknowledgement, another inspection, another departmental review...
But here's the rub: Every element you add is more work to maintain, more complexity, more opportunity for error, more expense.
If there's one refrain in Getting Real, it's this: do less. Generate less mass (ch 10), program less software (ch 54), build fewer features (ch 23).
If programmers got paid to remove code from software instead of writing new code, software would be a whole lot better.
Instead, do fewer things, and do them better. It's the same lesson as in lean: you can't work yourself into higher quality. You can only build it into your system.
The 2-month hiring process is not only less expensive than the 10-month one, it's also more equitable, simpler for everyone, and yields better quality candidates.
2. Know why you exist
I've seen whole city departments that have no idea what their purpose is.
They may think they exist to promote compliance. Or worse, they exist only because they've always existed.
"Compliance" isn't a mission. Compliance with what? Why was that code written in the first place?
You need a vision. We issue building permits to keep buildings from falling down. We issue childcare facility licenses to keep kids safe.
Make the big decision about your vision upfront and all your future little decisions become much easier.
If you understand What's the Big Idea (ch 15), then you can orient your services around that purpose.
Let's reimagine your building permit process. If you know your purpose is: "Ensure buildings in our city are safe," then you can ask, does this inspection/form/regulation help make the building safer?
If no, it's actually making the building less safe -- by taking time, effort, and expense from the "real" safety-generating activities.
3. Start with the customer experience
In software development, the principle is "interface first" (ch 46): Figure out what you want the user to see and how you want it to work, then build backwards from there, ending with code, which is expensive and time-consuming.
How often do we build convoluted intake processes that reflect our convoluted data system, or messy multi-page citizen instructions that reflect our messy, multi-department process? I once worked on a project with a form so bad and so inflexible that we had to design a separate page of instructions to explain how to fill it out!
What if instead, we designed how we want it to go when a citizen calls to report a hazardous road condition -- and we designed backwards from there? Replace "programming" below with "process," and you'll get the idea:
Design is relatively light. A paper sketch is cheap and easy to change... That’s not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
What if you started with the assumption that your caller should be able to:
Find one obvious number to call easily from the side of the road,
Give details in 30 seconds or less, and
Get a call or email back letting her know the outcome?
How would that change what you build?
4. Shrink the change
Another Getting Real refrain is to shrink changes: compromise on scope, not time or budget (ch 7), build half a product (not half-assed) (ch 21), and shrink your planning horizon (ch 35).
We are bad at this in government! Our tendency is to:
Schedule another meeting to consult additional stakeholders
Wait until that position is filled
Coordinate this project with the upcoming election / IT implementation / budget cycle
What's the result? Looooooooong project cycles that leave us, in the meantime, with a heap of broken systems.
How does a project get to be a year behind schedule? One day at a time.
Friends, it doesn't have to be this way! What if we committed to finding small goals that could be done in a week or less -- every week?
Internally to PPI, we do this as Just Do Its on our huddle board. (Our Just Do It reference guide is included below!)
What could you or your team bring to completion today that would move you forward on your team's goal?
Update a web page
Revise a form, an email, a set of instructions
Clean one area of your work space
Write one article
Then make sure you celebrate small victories (ch 39)!
How do you make transformational change? One day at a time!
What will you do?
Give Getting Real a read -- it's worth the hour of your time it'll take. Then pick something to do!
(Me? I challenged myself to write and publish a blog on the book within 24 hours of finishing it. Mission accomplished!)
Comments