2022 Rules of Engagement

•November 8, 2022 • Leave a Comment

Following on from 2006/2013, here’s the updated set:

  1. Be yourself
  2. Lead from the front
  3. Code == source of truth
  4. Observability from day 1
  5. Working backwards with tenets and mechanisms
  6. Customer centric UX Design (Engineers are user too)
  7. Team efficiency is important
  8. Measure and adapt
  9. Behaviour changes culture
  10. Keep the message simple, and repeat
  11. Simple over complexity
  12. Mandates often have consequences. Autonomy needs an economy

Team Productivity

•October 25, 2021 • Leave a Comment

As I read Project to Product by Mik Kersten, I’m reminded of the need for teams to remain durable and responsible as part of their journey:

Giving work to an existing high-performing team will get you results much faster than having to form a team first, then dissolve that team at the end.

The alarm in the above quote is “dissolve”. Team are so often dissolved before they perform. In my career, organisations seem to rarely discuss the impact of mobility/terminations on the team, possibly causing a cycle of forming/storing which can make it to performing. Scaling of people to aid a project, is often considered in terms of adding budget to increase headcount, forgetting about the need to consider product over project. The counter to this is that headcount doesn’t guarantee an increase in velocity. Brining us nearly to flow and value stream.

As DORA and SPACE offer a measure of engineering productivity, we need to pause and consider the customer experience of productivity rather than just the engineering, thereby offer insight into what business value you’re delivering, and how quickly. Flow of value.

This leads us to the need for organisation change to allow team to become effective, which in itself is a considerable challenge, since we are probably all aware of the ivory towers that exist. McKinsey offer some insight into the journey

how do I accomplish my 10 year plan in 6 months

SRE Workbook Notes

•April 21, 2019 • 1 Comment

A few items I found insightful, outside of an overall great book:

Engineering Company = Engineering Culture

•April 14, 2019 • Leave a Comment

Great article on Wall St vs New Order/Startup companies.  One particular statement stands out:

Engineering Company = Engineering Culture
In Wall Street, Finance is the business, and technology is merely a mechanism that exists to facilitate that business. Technology is seen as a cost center, and when it is necessary to cut costs

SRE Post Mortem Gamification

•April 8, 2019 • Leave a Comment

I really like gamification.  In some firms its in almost part of the culture.  Of particular interest around post mortem’s is Google’s gamification leaderboard.

Some individuals are incentivized by a sense of accomplishment and progress toward a larger goal, such as fixing system weaknesses and increasing reliability. For these individuals, a scoreboard or burndown of postmortem action items can be an incentive. At Google, we hold “FixIt” weeks twice a year. SREs who close the most postmortem action items receive small tokens of appreciation and (of course) bragging rights

Cyber Security – Notes

•April 5, 2019 • Leave a Comment

A few weeks ago, the Sunday Times included a CyberSecurity supplement, available online here.  What follows are a few interested pointers:

  • Human Centered Security
  • Phishing attempts is number one in terms of insider threat
  • Increase in awareness and training can lead to the biggest improvement in security
  • Cloud – understand where your sensitive data is, assess access and sharing privileges.
  • Open source vulnerabilities create serious risks.

DevSecOps – Secure Code

•March 22, 2019 • Leave a Comment

Worth a listen, Max Saltonstall and Justin McCarthy are joined by Johnathan Hunt, VP of Information Security at InVision to talk about pen testing, bug bounty programs, and secure code.

  • Pen Testing yearly cycle – “significant flaw in thinking”
  • “static analysis scanner that sits locally on all software engineers laptops, every piece of code every line of code that they write their supposed to scan this prior to committing that to the repos. Once it’s in the repos, once we get ready to deploy and merge in a master at that point that runs again, right, the same tool runs within a CI CD pipeline, after we’re doing, QA testing, and all these other things that run also is an automated tool set, it runs again, at that point, it notifies us or notifies them right of vulnerabilities resident, now we can choose to block that we can choose to say, hey, if it’s a critical vulnerability, or a high severity vulnerability, we’re going to disable or block the push right to production”

Software Productivity

•March 4, 2019 • Leave a Comment

First up, and worth a read/watch is “How Is Software Developed At Amazon?”.  Of note:

  • Automate anything manual
  • DevSecOps

Following closely are the many references called out in QA Financial keynote from Jordan Daniel, Head of Testing and Enterprise Release Management, Bank of England:

  • Boehm, B. W. (1987) Improving Software Productivity
  • Grady, R. B. (1992) Practical Software Metrics for Project Management and Process Improvement, 1st Edition Prentice Hall.
  • Henderson, P. (2006) Why Large IT Projects Fail.
  • Jones, T. C. (2012) Software Defect Origins and Removal Methods. Draft 5.0. p. 3.
  • McConnell, S. (1996) Software Quality at Top Speed.
  • McConnell, S. (1996) Rapid Development: Taming Wild Software Schedules. Microsoft Press
  • McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction, 2nd Edition Microsoft Press
  • Medina, L., Liedke, R. (2015) Defect Prevention Using Agile Techniques.
  • Patton, R. (2005) Software Testing. 2nd Edition Sams Publishing
  • Suma. V., Gopalakrishnan Nair, T. R. (2008) Effective Defect Prevention Approach in Software Process for Achieving Better Quality Levels.


•February 24, 2019 • Leave a Comment

Another day, another buzzword – DevSecOps.  Like most buzzwords, the devil is in the detail 🙂  In this particular case its a continued refinement and improvement of the DevOps tool chain, that correlates well to Accelerate capabilities, with evidencing through metrics:

  • Deployment frequency
  • Lead time
  • Test coverage
  • Detection of threats, security defects, and flaws
  • Mean time to repair
  • Mean time to recovery

You may also want to include Rotate, Repair, Repave into your practices as well when considering the Open Source library language flaws.


Fighting Cyber Vulnerability

•February 13, 2019 • Leave a Comment

This video on DiffBlue Secure offers interesting insight into how using the right tool, at the right time as part of the SDLC tool chain, could reduce the defects and incident management overhead.  Hopefully this would result in a decisive “Strict prioritisation” graph.  Food for thought