Talk notes: The only thing that matters is you

The following are my speaking notes from the talk I gave at the December 4th DevOpsTO meetup, titled 'The only thing that matters is you'. I elected to put them up as-is, with minimal editing, because I plan on refining the contents for a future talk - there was just too much content in this one. The abuse of bullet points is because I can't for the life of me figure out indentation in blogger.  The italics, etc are meant to help me emphasize words and phrases, remind me of points, and so forth. 

The Q&A section is interactive, actually getting folks to participate, respond, and think about things.


The following presentation is a compilation of everything I’ve learned on my journey so far - for brevity I’ll be paraphrasing quotes, but the books in the intro slide are my primary source.
Q&A starterLet’s start by setting the stage in your own minds...
(Point: people matter more than tools or process)

You’ve lost your credit card, maybe it was stolen?...…

My notes from reading 'Better: A surgeon's notes on performance'

First off, this was a great read - a great window into the literal and figurative world of medicine.  Highly recommend it not just as a well-written book, but as it also has a lot of readily transposable ideas.  I read this at the recommendation of:  and under the contextual influence of "how do OKRs work, anyhow?".
My own analysis & thoughtsBig theme of the systems principle 'make information visible' - publish results, don't hide results anywhere! (e.g. org-public OKRs)Measuring "intangibles" can be a powerful innovation (e.g. How to measure anything, Hubbard)Balanced KRs important everywhere (point/counterpoint)"What the best may have, above all, is a capacity to learn and change - and to do so faster than everyone else."Change is possible with just one person - be a positive deviant!  Note how a number of individuals were referenced below.Diligence rang out loud and clear to me - Personal mastery (Fifth Disciplin…

Team health checks - now with more teams!

I had the chance to help out with team (squad) health checks again, this time with eight dev teams (last occasion wasjust two) - seven of which happened in a single week!  One of the teams had done a few health checks in the years prior, and it was really cool to see their responses and approaches mature over time.

As before, a ton of learning and a great experience all around, with some really cool insight from the folks participating:
On the topic of 'delivering value', one team member raised his hand after the team had said their piece and noted: "You [the team] have been describing delivering quality.  Delivering value is something else."  (which of course spurred other discussions and thoughts)Success metrics/OKRs have the power of crystallizing the organizational mission as resultsLegacy code/platforms constrain present/future options (i.e. tech debt doesn't just require recoup work in future, it prevents you from doing some things in future - as if to say, …

Packer, WinRM, AMIs - making it work

This has been a pretty frustrating task for me, so it felt like a good thing to write about.  Pretty much every source had one thing or another wrong, and I'd ended up just mashing it all into one big huge WinRM script glob.

I would preface this with 'it's a packer build, not concerned with security and encryption', which is not terribly security-conscious of me, but here we are.  One of the articles I found whilst googling had a basic SSL setup, but I opted to start with the Packer documentation after many many failures.

If you start with said documentation here ( you will (possibly) discover that you are still blocked by 'waiting for winrm'.  So add this to your user-data WinRM setup portion:
set-item WSMan:\localhost\Client\AllowUnencrypted -Value True -Force set-item WSMan:\localhost\Client\Auth\Basic -Value True -Force set-item WSMan:\localhost\Client\TrustedHosts -Value * -Force E…

My roadmap learning experience so far

This is now my second year having to come up with a roadmap for what we call 'release', so while I'm not old hat, I am definitely learning and getting a little better!  One of the fun aspects of this is looking at the 'how you go about roadmapping', as in, if you are starting from scratch or not, what are the exercises you can go through to help you develop a plan for the coming year?

We're fortunate enough to have a CTO who pushes things like value proposition design (pain-gain diagrams), and encourages us to really think through what it is we are trying to do - plus takes the time to guide us himself.  Last year's roadmap started with a fresh canvas and the question 'if you could only work on one thing, what would it be?'.  This was to help focus my scattered brain, and I found it a great starting point.  As I am also a visual person, was used extensively to sketch out my thoughts (also used my whiteboard, but is portable).

What fo…

Application-generated metrics - Part1: What is the difference between Metrics, Events, and Logs?

We're working on making 'application-generated metrics' an accessible thing through some sort of metrics framework.  The subtle goal is that we'd like to provide the ability for metrics-driven decisions to become a viable option, and to gently push back on "sales-driven development".

Given that I spent an entire day trying to figure out the answer to this question of 'how are metrics/events/logs different', it's probably worth taking the time to write it down.

DISCLAIMER: This is not a scientific paper, so do your own research to refute or support the following...
Backstory What is 'application-generated metrics'?  An old concept that I'm probably wording poorly.  Essentially, as your code does stuff, it should tell you about it.  Keeping track of important flows like registration and payments should be boosted by having dashboards/monitoring that tracks 'registration failure' or 'payment failure'.  This was my original …

Update on canary - how has our release impact changed?

We had two primary targets for our canary process - our monolith has a main web app and a main api - deployments to those two using normal deploy processes cause 'release impact'.  Namely, all our systems go wonky and the scope of 'what gets disrupted' is sometimes even kinda unknown (or rather, has never been tabulated).
For the backstory, check out the other two posts on this topic:
TL;DRCustomer impact with canary is now 0 (barring a broken deploy)We can now release at will instead of inside low-throughput release windowsWe have fast feedback via metrics that will automatically revert a failed deploymentThe actual deploy process is longer, but that's ok - because we don't have a time restriction Some definitions...Impact window (length of release impact) - how long are users and systems impacted negat…