Shaun Abram
Technology and Leadership Blog
Subscribe to RSS FeedSearching in Twitter
I’ve lost count of the number of times when I have read a tweet, and later wanted to refer back to it but struggled to find it. So, mainly for own benefit, I am adding some notes here on how to search Twitter.
The best starting place is usually https://twitter.com/search-advanced
But you can also search directly in the main Twitter app using syntax like this
“good read” (from:shaunabram)
to return all tweets (from me, in this case) with the exact phrase, “good read”
or
good read (from:shaunabram)
to return all tweets from me with either the words “good” or “read” in them.
Tags: twitter
How much is your slow lead time costing you?
In a previous blog post, I discussed slow build times and estimated the associated costs. The build process is only one part of getting software out the door however.
Lead time is the time it takes to go from code committed to successfully running in production. This will include the build time we covered in the previous blog post, as well as all the other things required to get your code into users hands such as testing & deployments. This article focuses on the costs of that lead time.
Using the example of a team of 10 engineers, I estimate that the costs of a slow (one week) lead time could be the approximate equivalent of more than 3 engineers, or $400,000 per year. And I think it’s entirely possible that is on the low side since there are other costs that are just difficult to estimate. Imagine how much more you could achieve with 3+ extra engineers on the team.
Charity Majors goes further (discussed below) and suggests that reducing the lead time to hours could save the cost of 5 engineers on such a team. I was initially skeptical on that claim, but after trying out these estimates, she think may well be more accurate that my possibly over-conservative math.
Thanks
A big thank you to my former colleagues Dave Taubler, Abhijit Karpe, Josh Outwater and Steve Mauro for providing feedback and input on this article.
Most of the feedback took issue with some aspect of the estimates, which is fair, but the common theme seemed to be that everyone agreed that there is a very real cost to slow lead times, that it is high, and that using data where you can and estimates where needed is a good way to surface and highlight that cost.
Tags: accelerate, ci, cicd, continuousdelivery, continuousdeployment, continuousintegration, deliverypipeline, devops, metrics, stateofdevops
How much is your slow build costing you?
Slow builds are a pain, but how much do they really cost? How do you compare the benefits of reducing your build times against a new user-facing feature that generates real revenue, for example?
Your slow build could be costing you up to $1 per minute per build per engineer, based on the estimates shown below. So, even before you factor in CI infrastructure costs, slow build times can very quickly add up. In the example below, a team size of 10, each doing 5 builds a day, and each with a 30 minute build time, we calculate the cost could be up to $375,000 per year in waste.
This post and the calculations used in it are based on the approach taken by “Prioritizing with Cost of Delay” by Jeff Palmer. “Quantifying the Costs of Builds“, by Hans Dockter @ Gradle, also covers some of the same ground in similar and more comprehensive ways.
Tags: build, ci, cicd, continuousdelivery, continuousdeployment, continuousintegration, devops, metrics
Book summary: Shape Up
“Shape Up: Stop Running in Circles and Ship Work that Matters” is a book from Ryan Singer about how Basecamp do product development.
The following is mostly just copy & pastes of the parts I found most interesting. Typically, the more detailed the notes, the more useful I found the chapter. The original book itself though isn’t a difficult read (and it’s free online), so I recommend checking it out directly.
Tags: basecamp, planning, productmanagement, projectmanagement, shapeup, summary
Blog post summary: Prioritizing with Cost of Delay
Prioritizing with Cost of Delay is an article by Jeff Palmer (web, twitter, linkedin).
This article had me engrossed with the opening paragraph. It is a short article (6 minute) read, so I suggest reading it directly, but find a summary below, mainly for my own benefit.
Tags: costofdelay, summary
Git Branching Strategies
Some quick notes on different Git Branching strategies.
I am covering the 3 main strategies, and discussing them in increasing order of complexity: GitHub Flow, GitLab Flow and Git Flow.
Tags: branching, git, gitflow, github, githubflow, gitlabflow
How to create a password protected zip file
Because I forget every single time…
$ zip -rP yourpassword newzipname.zip foldername
Book chapter summary: Managing Incidents
This is a slight abridged version of Chapter 14, “Managing Incidents, by Andrew Stribblehill from the excellent “SRE Book“. (Original is 2200 words, this is 1200)
Tags: sitereliabilityengineering, sre, summary, thesrebook
An introduction to OKRs
Some quick notes on OKRs (Objectives and Key Results). Much of this is taken from these (better!) sources, so I’d recommend checking these out first:
- What is an OKR? Here are the basics
- John Doerr on OKRs (youtube.com)
- The OKR Origin Story
- Engineering OKR examples
Tags: objectives, okr
Book Summary: Accelerate
Accelerate: Building and Scaling High Performing Technology Organizations is a book by by Nicole Forsgren, Jez Humble and Gene Kim. It is a follow on from the State of DevOps Reports that Forsgren and Humble used to publish (and which I wrote about before in Development and delivery practices for team success). I highly recommend buying the book, but here are some chapter summaries for the highlights.
Tags: accelerate, books, cicd, devops, metrics, mttr, stateofdevops, summary
Article summary: The future of work is written
“The future of work is written” is an article from Juan Pablo Buriticá from Stripe published on increment.com.
This is a summary of the keys points from the article, but the original is definitely worth reading, and not long itself (the original is 2300 words; this is 250).
Tags: communication, documentation, summary
What is an Engineering Manager?
The role of an Engineering Manager (aka Development Manager) will vary from company to company, but this post covers what, in my humble opinion, the core expectations, duties and deliverables of an EM are.
It is intended primarily as a guide to engineers who are starting down the path of Engineering Management.
At its essence, the role of an EM is about:
Building, leading and retaining high performance teams that regularly ship software to meet business requirements.
Let’s break that down into 5 key areas…
Tags: engineeringmanager, leadership, management, newmanager
How to give difficult feedback
Giving difficult feedback is a critical part of being a manager, and often the part that comes hardest to many. This post covers some strategies for handling that, and dealing with underperformance.
The vast majority of this material (or the good parts, at least) came directly from a great talk by Claire Lew at Know Your Team, and you can find a related post from her in this 4 tips to give tough feedback post. I recently signed up to the Know Your Team annual plan and it has been well worth it.
Tags: knowyourteam, management
Blog post summary: What is an Engineering Manager?
I liked the short What is an Engineering Manager? post on the AWS blog (from David Ives @ Pusher). This is a summary, but the original is worth reading and not much longer…
Tags: developmentmanager, devmanager, leadership, management, summary
Engineering Growth Framework from Medium
I recently started a new role, and one of the first things I’ve been looking at is career ladders (aka job rubrics), org structure, and performance reviews (a.k.a. talent reviews or growth frameworks).
In that vein, the Medium Engineering team’s “Growth Framework” was recommended to me, so this is a quick summary of it.
TLDR; Medium have a “Growth Framework” for recognizing and developing their team that uses 4 categories (Building, Executing, Supporting, Strengthening) each with 4 tracks. Each track has 5 increasingly difficult to achieve milestones, and each level of milestone has points associated with it. The more points you have, the higher your level, which translates into job titles. Whew! It is a complex system, and while perhaps more complex than many (especially smaller) organizations need, it is none a very interesting framework which many might use as a reference. The tracks, milestones and examples in particular can be useful inspiration when putting together your own career guides.
Tags: management, medium, people, rubrics