“Let’s be more lean so we can ship faster, can you do that for me”? That’s what a manager told a platform engineer I had the pleasure of speaking with yesterday. She loved it. We’re often confronted with impossible expectations from managers and developers alike. Internal tooling can play a vital role in meeting those - if done well. If not however, it can have disastrous outcomes. Our deployment frequency increases, and our change failure rate increases along with it. You win nothing. There are actually a few tricks you can use to balance the risks and reap the benefits. I’ll discuss them in an upcoming webinar I’m organizing. But let’s look at some here:

• Internal Tools are products. Treat them as such. A product reacts iteratively to the demand of its consumers (your developers).
• Have a product manager
• Manage in sprints
• Test (!)
• Measure. (As Gene Kim said at Kubecon this year: Measure the amount of thank you’s you get from your devs.). So NPS matters, deployment frequency does too.
• Identify what tools to focus on in internal hackathons.
• Nigel Simpson (Director Enterprise Tech at a Fortune 100) explained this idea in a recorded conversation I had with him last year.
• Get together once a quarter and actually “hack” something that improves your workflow. The ideas the dev team comes up with will blow your mind. And because it’s their idea, the acceptance rate is much higher.
• We’ve been doing this at Humanitec ever since with amazing outcomes.
• 50% of the ideas actually make it to “production”.

A great article on this (in prep for the webinar) is this one by Adevinta — not associated with them and literally found it on Twitter last week. It explains in detail how they’re building their platform.

Looking forward to seeing you at the webinar on Internal Tooling!

On a different note: Controversial-Kaspar is back with a piece on GitOps (or should I say GitOops?) I was fascinated by the fact that many larger clients that adopted GitOops were in huge trouble and super frustrated while the people just jumping on that train were so positive. I thought about this from a statistical perspective. The phenomenon can likely be described with the following formula: P(Gitopsfail)=1-p^n; Check it out! Not everyone is of this opinion and we’ve sparked quite some debate around the topic on Reddit and other places. So we’re organizing another community debate around GitOps with several speakers, discussing oops and downs of using this approach.

That’s it for now, stay safe and deploy away!

Kaspar

‍