“We are ALL Remoties” (Jun2015 edition)

Since my last post on “remoties”, I’ve done several more presentations, some more consulting work for private companies, and even started writing this down more explicitly (exciting news coming here soon!). While I am always refining these slides, this latest version is the first major “refactor” of this presentation in a long time. I think this restructuring makes the slides even easier to follow – there’s a lot of material to cover here, so this is always high on my mind.

Without further ado – you can get the latest version of these slides, in handout PDF format, by clicking on the thumbnail image.

Certainly, the great responses and enthusiastic discussions every time I go through this encourages me to keep working on this. As always, if you have any questions, suggestions or good/bad stories about working remotely or as part of a geo-distributed teams, please let me know (either by email or in the comments below) – I’d love to hear them.

Thanks
John.

Mozilla’s Release Engineering now on Dr Dobbs!

Long time readers of this blog will remember when The Architecture of Open Source Applications (vol2) was published, containing a chapter describing the tools and mindsets used when re-building Mozilla’s Release Engineering infrastructure. (More details about the book, about the kindle and nook versions, and about the Russian version(!).

Dr Dobbs recently posted an article here which is an edited version of the Mozilla Release Engineering chapter. As a long time fan of Dr Dobbs, seeing this was quite an honor, even with the sad news here.

Obviously, Mozilla’s release automation continues to evolve, as new product requirements arise, or new tools help further streamline things. There is still lots of interesting work being done here – for me, top of mind is Task Cluster, and ScriptHarness (v0.1.0 and v0.2.0). Release Engineering at scale is both complex, and yet very interesting – so you should keep watching these sites for more details, and consider if they would also help in your current environment. As they are all open source, you can of course join in and help!

For today, I just re-read the Dr. Dobbs article with a fresh cup of coffee, and remembered the various different struggles we went through as we scaled Mozilla’s infrastructure up so we could quickly grow the company, and the community. And then in the middle of it all, found time with armenzg, catlee and lsblakk to write about it all. While some of the technical tools have changed since the chapter was written, and some will doubtless change again in the future, the needs of the business, the company and the community still resonate.

For anyone doing Release Engineering at scale, the article is well worth a quiet read.

The canary in the coal mine

After my recent “We are ALL Remoties” presentation at Wikimedia, I had some really great followup conversations with Arthur Richards at WikiMedia Foundation. Arthur has been paying a lot of attention to scrum and agile methodologies – both in the wider industry and also specifically in the context of his work at Wikimedia Foundation, which has people in different locations. As you can imagine, we had some great fun conversations – about remoties, about creating culture change, and about all-things-scrum – especially the rituals and mechanics of doing daily standups with a distributed team.

Next time you see a group of people standing together looking at a wall, and moving postit notes around, ask yourself: “how do remote people stay involved and contribute?” Taking photographs of the wall of postit notes, or putting the remote person on a computer-with-camera-on-wheeled-cart feels like a duct-tape workaround; a MacGyver fix done quickly, with the best of intentions, genuinely wanting to help the remote person be involved, but still not-a-great experience for remoties.

There has to be a better way.

We both strongly agree that having people in different locations is just a way to uncover the internal communication problems you didn’t know you already have… the remote person is the canary in the coal mine. Having a “we are all remoties” mindset helps everyone become more organized in their communications, which helps remote people *and* also the people sitting near each other in the office.

Arthur talked about this idea in his recent (and lively and very well attended!) presentation at the Annual Scrum Alliance “Global Scrum Gathering” event in Phoenix, Arizona. His slides are now visible here and here.

If you work in an agile / scrum style environment, especially with a geo-distributed team of humans, it’s well worth your time to read Arthur’s presentation! Thought provoking stuff, and nice slides too!

A new focus

I’ve just added two new categories (“Release Engineering” and “Startup”) to my blog. This reflects the new reality of my life.

Obviously, many of my existing posts are already about Release Engineering, an area I care deeply about, yet somehow I just never flagged them correctly – I’ll fix that. The bigger news is about “Startup”. A few months ago, I decided to take the plunge and actually do what I’ve been talking about for years – start my own startup.

Since then, every day has been really busy, exciting, scary and fun – sometimes even all on the same day! Finding a bug in some AWS API documentation. Reading legal contracts with a highlighter and having to stop to Google some of the terms. Getting phone calls from a stranger that start with “you don’t know me, but I got your name from xxx and I hope you can help…”. Saying “what could possibly go wrong” multiple times a day. Joking about “pay no attention to the man behind the green curtain” while preparing a demo. Politely declining a job offer from a cold call recruiter, hanging up, taking a deep breath, calmly reminding myself that 9 out of 10 startup fail, and then jumping back into the fray. Oddly enough, I find I’m sleeping more, and feeling less stressed!? So far. Oh, and I’m drinking even more coffee then usual (yes, that is possible!).

Things are still under wraps, but as soon as there’s something worthwhile to show or talk about, I’ll post here on my blog.

In addition to the PRODUCT of the startup, I’ll also be blogging about the PROCESS of creating the startup. Technical, business, human aspects… warts and all. I’ve found it really helpful, and encouraging, to read posts from other founders and investors who’ve gone before me, on what they learned while building a startup – not just airbrushed niceties but also the genuine good/bad/funny/horror/irreverent/snafu stories that people have posted about life while building a startup. Some I’ve nodded along with, say “that was obvious”. Some I’ve re-read multiple times carefully and made mental notes. All are honest and helpful – to me and I’m sure many many others also. In that “pay it forward” spirit, I’ll make time to blog about this, and hopefully others starting their own entrepreneurial path will find these posts helpful – in a “oh, that is clever, I should make sure to do that” way… or “oh boy, I need to make sure to *never* do that” way… or somewhere in between!

I have to say I feel incredibly lucky with the support and encouragement of friends, family, former-co-workers and others I’ve bumped into over the years. Not just generic “don’t worry – it will be fine” support. Even with best of intentions, telling people what you think they want to hear, even when you think it may not be a good idea, is not good – it can set someone up to fail. Instead, I’ve been getting really helpful, informed, constructive support and advice like “maybe if you change it to…” or “have you asked xxx, she might have an insight…” or “that was good, don’t change that” or “… ok, that didn’t go well, so how will you do better next time?” Sometimes hard to hear, but always true from the heart and totally honest. This support is priceless, and means a great deal to me, so I find myself listening very carefully and humbly thanking people a LOT.