<![CDATA[Reliable Engineer]]>https://reliableengineer.bloghttps://substackcdn.com/image/fetch/$s_!DMi2!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc3ebb37d-1a3d-4b65-b8ab-b3066644eff0_1024x1024.pngReliable Engineerhttps://reliableengineer.blogSubstackThu, 09 Apr 2026 15:04:16 GMT<![CDATA[Top-down simplicity]]>https://reliableengineer.blog/p/top-down-simplicityhttps://reliableengineer.blog/p/top-down-simplicityFri, 20 Feb 2026 21:10:56 GMTAs a Software Reliability Lead, my role is to build processes for others to operate and participate. If I were to describe the results of my work in one sentence, I would say: I’m building tools to make everyone else's problems appear simpler and less nuanced.

This is the motto! Software release process is a tool!

To create a successful tool that will resolve company problems, you need 2 things:

  1. High willingness from teams to engage with your process.

  2. Grant to technical stakeholders the ability to control their part of the process.

To get the first point, you need to resolve at least one day-to-day pain from every team involved in the process:

  1. Software Engineers and DevOps want to communicate with each other in their technical language while refusing to learn each other’s.

  2. Product and Project managers want CLEAR ETA’s and observability over production delivery.

  3. Tech support wants to know which tasks are delivered and which are not.

  4. etc. etc.

For the second part, the rule of thumb is: everything that makes the process live on its own, without your major involvement, is good.

When it comes to line managers, the tooling will be complex, but if (or when) you need to involve higher and higher levels of management, the tools will become simpler and simpler.

If the line management controls will be “stop release process until blocker X is done“, the CTO level will be a big red button, “FUCK, stop everything“.

This is the way.

Subscribe now

]]>