Hi all,
A few people have asked me lately to describe my approach to running projects. Really, it distills down to implementing two separate pieces of advice I received a few years ago that really made things "click" for me.
- Build systems so that information flows to you on a push basis, not a pull basis.
- You need to ask, "What do I get, and when do I get it?"
Taken together, these two things form the basis for how I gather information from large groups of people to run complicated, cross disciplinary projects.
When layered on top of a story map/service blue print/product breakdown structure, it provides a powerful way to think about projects using an easy to hold onto, cohesive mental model. It encourages people to keep their eyes on the prize, and communication on status of deliverables, rather than reporting on busywork.
Because at the end of the day, nobody cares about the work you did, (although, as an engineer, I'm actually incredibly curious and excited by it), they care about what they get.
Concept #1: Build Systems So That Information Is Pushed to You
I've always been cross disciplinary, so I used to run projects by running around and talking to everyone. I usually had a deep enough understand of other's work, that I could make an assessment of where things were, fairly intuitively.
That's fine in small groups, but it doesn't scale well past maybe 7 or so people, and more to the point, having the information in order to make high quality decisions is valuable, but gathering it is not a high value activity. That form of information gathering doesn't scale to large groups.
The right thing to do, of course, at scale, is to automate the information gathering, which means building a system. It's certainly possible to build a system through brute force, willpower, and intimidation, forcing people to write status reports, but in my view, that's a failure of system design.
Building this information system becomes a Design activity with a capital letter D, meaning piggybacking on habits and systems that people already use, and making things easy for engineers. It could be JIRA (although JIRA makes it hard to make it easy), a shared doc, Slack, or some other tool. And I do realize that this is glossing over a lot, but taking a moment to be thoughtful about what people actually do already will go a long way.
Finally, as with most habits, having a form of accountability, usually in the form of a status meeting, really brings things home. Of course, keeping that status meeting snappy, fast, light, and effective (we're trying to make things easy here, not painful and powered by force of will! This is capital "D", Design!), is critical. Which leads to the second thing that made all this click for me, gathering the right information.
What Do I Get And When Do I Get It?
Engineers can be notoriously adverse to writing status reports, and I've seen two typical behaviors. You either get nothing, or next to nothing, or you get way too much technical detail.
The trick to making it easy for engineers is to ask the right question, which takes something of the form "What do I get, and when do I get it?"
The follow up questions are along the lines of "Is that really true?", "Why?", "What are you doing about it?", and "What help do you need from me or others?"
If you don't know what you're getting, or when, then you're running a bit open loop, and it's time to think critically about breaking things down into smaller pieces, to the degree where you can predict it. In which case, the answer to "what do I get and when" might become "we don't know when you'll get X yet, because we can't be sure this will work, so you get the results of Y experiment by this date."
Sometimes I rephrase the "What do I get and when" to "when did we plan to get it?" or "when do we predict we'll get it?", followed by "and how has that changed"
Either way, you should be able to answer the set of questions in between two and three sentences, sometimes four if things are really complicated. That's about the length of about one or two 140 character, old school "tweets", which is fast, to the point, and simple enough that engineers can write it.
Putting it together with a Hypothetical Example
So, from the hypothetical restaurant example I used to illustrate a story map/service blueprint in this blog post, we take the top level question, which is
"Are we ready to open a restaurant and provide a quality dining experience?", and we might break that down to.
Marketing - "Are we on track for people to hear about and find our restaurant by X date?"
Reservations - "Are we on track to have a system for people to make reservations by X date?"
Front of house decor - "Are we on track to have FoH ready and set up to great and seat guests by X date?"
and so on...
Details
Sometimes, it's very necessary to clarify what's in scope for each of the questions to agree that you're done. In all cases though, I'm trying to ask for tangible things and not work. Because you'll always forget some piece of minutia, or some piece of work. It's great that you swept the floor. That's done. But the table cloths aren't on order yet. So, is the front of house set and ready for opening? That's the prize.
My recommendation is to get the all the answers, in writing, in full and complete sentences. Oddly enough, and I realize this is quirky, but it's effective, using the status meeting to literally read the status reports out loud, verbatim, makes the meeting fast, (no meandering answers to "what's your status?"), but also forces people to hear their own words coming out of their mouths, so they have to write good status updates.
And yes, I realized that's quirky, you'll have to figure out what works for you.
Making it all happen
Introducing a system like this is of course, an exercise in organizational change management. My recommendation is always to start by explaining the system to senior team members, and getting their buy in, than kicking things off with a training, and working an example with the team. In my experience, it takes about 2-3 cycles before it really starts to click, and because it's easy and effective, engineers buy in.
Good luck!
best regards
Sam Feller
aka THE Awkward Engineer