Retrospection on the Retrospective

A seemingly universal axiom for processes is that there is no universal process. They can vary as much as the people who practice them. Which is great when you remember that process exists to help people improve, and not the other way around.

So when the ForwardJS crew yet again invited this non-developer to speak at their bi-annual Javascript event, I thought of my trusted, respected colleague, DMose. One of the founders of the Mozilla Project, Dan has taken thoughtful and intentional steps to continually improve how he and his engineering teams work.

During my 4.5 years at Mozilla, I’ve grown to greatly appreciate Dan’s careful consideration of the process and human elements to his technical work. As we touched on some of these elements, we identified the Retrospective as a practice that can deliver many of these principles for teams.

Which, as with most processes (see above), has been tweaked, adapted, forked to meet the needs of the individuals using it. For Dan and his team, the Retrospective contains 4 questions, reviewed by the team at the end of each week:

    What did we do well?
    What did we learn?
    What could we have done better?
    What puzzles us?

The takeaways….

One Big Benefit
The Retrospective questions – in the above order – have done something critical for Dan’s team: they’ve built trust. More than any learning or process change, the development of trust among the team is what makes it effective. It allows for failure and its valuable counterpart, risk; and ensures that the costs of such risks are translated into valuable learnings for the future.

Another important guiding principle to create this trust is to not “shoot the messenger”: if someone shares something they think didn’t go well, it’s important that the team hears that person out and distances them from their feedback on the team’s performance.

Small things matter
Does the question order matter? Indeed. Because the questions start with a focus on things done well, the process begins with confidence. And by framing them in the collective “we”, and positioning failures as learnings or things to solve, the questions depersonalize negative impacts, instead reframing them as opportunities to get better.

From trust to change
Our session was quite lively (we took this to be a good thing), and one of our audience members cited the Retrospective as a key way they introduce changes to their org. Because the scope of the restrospective is often small (importantly, the work featured is positioned as “small experiments”, which allows folks to be healthily detached from the outcome), they allow for changes to be adopted while minimizing the fear and uncertainty that typically accompany change.

It’s this ability to introduce change in small increments that makes the Retrospective so empowering. Any team can adopt it.

We’re curious to hear of your own experience with retrospectives.

What is all the fuss?

It’s hard not to love Gilda Radner or SNL. And I’ll go one step further: for me, it’s impossible not to love Emily Litella. She never understood why people made such a fuss over things.

EmilyLitella

In 2015, I think Emily would be asking what all the fuss is about remote working (or maybe she’d ask what the fuss is about demote twerking…hint: you need to watch those episodes to understand).

Distributed teams really got their legs with the advent of open source projects and are becoming increasingly mainstream…but are not without their drama. My short presentation at yesterday’s always-awesome Forward 2 conference dispels some common fears and myths about remote work, and provides some tips on making distributed teams awesome. Enjoy!

What is Developer Evangelism?

“Developers hate being marketed or sold to” per the muse of common knowledge. It’s not surprising, then, that those charged with doing just that have a job title that explicitly omits any mention of this kind of activity. Oddly, stirring up images of religious zealotry was more palatable for those in the tech world when Apple Computer kicked off the idea of technical ‘evangelism’ in the last century.

Of course, things have changed since the Mac SE. ‘Developers as customers’ is becoming increasingly mainstream, no longer confined to the stodgy enterprise with long sales cycles and formal necktie cultures. D2D has gone indie along with the web and mobile devs it targets.

I’ve had the fortunate opportunity to attend a few events at the developer-centric accelerator (or more precisely, “community for developer-focused entrepreneurs”) HeavyBit this year thanks to my brilliant developer marketer content strategist journalist friend Dana (us biz people deal with job title complexities as well). Today they helped produce DevGuild, an unconference dedicated to unpacking what in the heck this “developer evangelism” thing really is.

So what happened? First, the introductory talks:

  • Josh Dzielak of HeavyBit alumni team Keen.io kicked the day kicked off, challenging attendees to remember that as important software is, the people behind it are what makes it live (exact quote: “software may be eating the world, but community is feeding it”).
  • Github’s KC Shearon shared more of her signature awesome slides to parse out the reasons the term ‘evangelism’ is so problematic for her; specifically, she believes the term implies religious zealotry, emotionalism, and manipulation (see first paragraph above ^^). Interestingly some discussions later in the day talked about how evangelism is often most credible when the evangelist simply “tells their story” with the technology. That sounds like “evangelical witnessing” to me, of course absent any call to action (buy this product, or come to the front of the church).
  • Returning to the people-trump-software theme, Heroku’s Leigh Honeywell talked about how dev communities organize and intentionally choose to dis-organize with poor results. The message to people in the developer world is to be intentional about the environments they create (she assigned us some required reading).
  • Expanding on community was Electric Imp‘s Matt Haines, reminding us that it’s not the “things” we build (particularly relevant reminder for an IoT company), but rather the people we empower, that matters.
  • As a metrics geek, I particularly enjoyed another Keen.io-er, Tim Falls, who admonished us to not go nuts on the numbers. Basically just because you can (measure something) doesn’t mean you should (measure whatever you can measure). Tim also quoted some people you just can’t question, like Albert Einstein (“Many of the things you can count, don’t count. Many of the things you can’t count, really do count”) and Oscar Wilde (“People know the price of everything and the value of nothing”). But my favorite quote from him was his own, captured by Mashery’s Sarah Jane Morris: “You can’t track a handshake to a hug to a $500 subscription two weeks later.” Yes yes yes.
  • Finishing the theme of the “nots” of Developer Evangelism was a summary of “The 7 Deadly Sins of Evangelism” outlined by Salesforce’s James Ward (big thanks to Laurel Kline for the tweet summary:
    1. Not fully knowing your product
    2. Not creating a feedback loop between your audiences and your product teams
    3. Too much coffee (I totally don’t understand this one but apparently it can make you a jittery presenter 😉 )
    4. Not practicing enough (you must know your code inside and out before demoing it)
    5. Not allowing your audience to help you answer objections
    6. Not venturing out of your comfortable social circle
    7. Not being a good host aka BUY THE BEER

    Next we shifted into our Unconference segment. Here are some of my takeaways from both the two breakout sessions I attended (metrics + using “non-marketing speak”) as well as the whole day:

  • Always put the developer first. Otherwise you look like a corporate hack (which may be what you are, but you won’t be effective 😉
  • It’s not sales engineering. Evangelism is really advocacy – advocating for the needs of the developer over the needs of the company.
  • Examples of good metrics include the trust level among developers with the resources and talks you give; the level, quantity and quality of your engagement with them; and (if possible) nirvana metric would be “DLTV“.
  • Your org structure matters. Who you report to often defines how you are measured (and thus, what you do and how you do it). If your manager doesn’t support the two immediately-above points, you should consider proposing a totally different measure of success, a reorg, or look for a new org.
  • At Mozilla, we think of much of our work (and certainly our evangelism work) in terms of “quality relationships.” This definitely syncs up with the thinking at DevGuild. And we can always do better. Thankfully as social media becomes woven into the fabric of all kinds of corporate outreach, the job of evangelizing in ways outlined above grows easier, as evangelists become less broadcast mouthpieces or talking heads, and emerge instead as accessible individuals who struggle themselves with the tech and engage in conversations rather than marketingspeak.

    I like how my colleague and now-Microsoftie Christian Heilmann expresses this:

    In German, there is a distinction: “Werbung” could mean advertising, but also trying to get someone on your side. “Reklame” means pure advertising. We should do more Werbung and less Reklame.

    Thanks to HeavyBit for putting on a great event. If you want to see others’ Tweets, check out the Eventify tweet summary (great tool, not because I’m listed as top contributor ;).