Through the Stack 2-07 (Week 12)

This is "Through the Stack," a weekly focus on a topic and links relevant to Lead developers (actual or aspiring) working with an internet-related product.

Many lead developers, tech lead, and staff engineers have their hands in many projects and influence many layers in their organizations. As such, they work Through the Stack: from Strategy, through Operational to Tactical work. This newsletter reflects those dimensions.
If you have comments or content to suggest, please reach out to us by email.

This week ...

We focus on one big topic: entrusting your team with responsibilities. Through our "failure factory" post and the review of Capt. Abrashoff's book "It's your ship". There are a few points to unpack.

There was also the interesting "Disagree and commit".

And I cannot let Josh Comeau's article pass without a reference—food for thoughts in those uncertain times.

Ownership

I had the opportunity to spend some time on a video call with a talented french CTPO this week. We covered quite a bit of ground but we talked a lot about ownership and moving away from feature factories.

The chat reminded me of the readings I have done recently (from "It's your ship" to the DORA's research papers and recommendations). For example, there should be no surprise that we talked about trunk-based development.

Just as the research has shown, there seems to be a clear sign in how turning to small iterations made their organization more productive. And just as the State of DevOps report points out: this cannot happen in a vacuum. To be able to do small iterations, there was a need for preparations and proper change management done upstream (business and other stakeholders) and downstream (CI, CD, monitoring).

Ultimately, the whole approach described in the report or through our chat relies on the team's sense of ownership and purpose. R. Onfroy worded it mainly from the perspective of the Lean Startup approach. We can also link to Capt. Abrashoff's "It's your ship" and how his approach was very similar. Once the team considers the company its own, feels part of the journey to the North Star and takes an active part in that journey, I think the actual work can start.

You don't have to agree

That's probably where articles such as "Disagree and commit" also come into play. Even when aligned on the destination, we might not be on the exact details of some steps. That's ok, as long as the team understands why we don't follow such or such a solution and that we will carefully monitor the result of our work and then judge if yes or no it was a good choice.

And that's also one of the interests of doing small iterations with proper tooling to measure the impact of each and compare against our expectations. That way, you don't have to disagree for long. You can run an experiment by rolling out a minimal change and see how it works against your expectations.

Mind the context

Yet, let's remember that frameworks are never silver bullets, especially if we try to integrate them into very different business contexts.

R. Onfroy and I compared their business and engineering context with others we have worked in. All choices in practices must be made with our context in mind. Contexts are often about cost, time, and compliance. It's rare to find the exact three cost, time, and compliance contexts in two different companies.

In short: what might be acceptable to do in one context might not be in another. If a low cost is attached to an issue being released and online for a couple of minutes, then we can risk releasing every 30 minutes with automated rollback in case of an issue. Suppose there is a high cost attached to any degradation in the quality of service, even for a couple of minutes. In that case, we cannot risk releasing every 30 minutes without having several layers of checks and tests.

Simply put, an e-commerce site cannot be worked the same way a banking system. And vice-versa.

Looping back through

These three points: fostering a sense of ownership, learning to disagree (while still committing), and minding the context, are essential in any group and project.

An intern might not see those, but any other level should get acquainted. And, surprise, it's on the leaders to show the lead and talk about it.

In that respect, I would warmly encourage anyone who is or will be in a leadership role to read Capt. Abrashoff's book. Read my review, and you'll understand why.

On the tactical level

A few links have hit our radar this week:

• Ruby and Rails.info: a great source of content in all forms about Ruby.
• Ruby Conferences: a source of dates and places for conferences about Ruby
• One Ruby Thing: a newsletter about Ruby
• First Ruby Friend: mentoring line for the Ruby community
• A bit of a long thread but a great Ruby tip

A quick reminder: our RSpec ebook is free until the 4th of April, and our upcoming RSpec course still has a few seats available!

Who are we, by the way?

This content is written and published by Imfiny/Pier22, a consulting company based in France. We help CTOs and Tech Leads grow their engineering team and stack.