“This may surprise you, but continuous deployment is far and away the easiest way to write, ship, and run code in production. This is the counterintuitive truth about software: making lots of little changes swiftly is infinitely easier than making a few bulky changes slowly.”
Lots of great ways to manage change in organizations. It’s a bunch of work to do this, but if you skip these steps, the results can and will backfire. I particularly like the guiding policy strategy where even if I don’t know something I can usually spitball the values and invariants of the situation that will fit the result.
Seeing that Gitlab had published their TeamOps framework, I stayed up late to get my certification. I especially liked the recorded meetings with Sid Sijbrand and other Gitlab senior staff that they have published on YouTube.
Running multiple strategic tracks will set you up to dominate at a large scale, but many organizations can’t run one let alone run multiple at the same time. The visualization and plays as described here by Itamar Gilad look a lot like Wardley mapping.
A short guide of how a team can turn around the work they need to do on a legacy system and come out the better for it. I’ve seen lots of teams struggle with this but as described here a lot of it is in the approach and the praxis of doing it and working together.
People see this kind of talk about self-governance and think there is no process or management in such a setup while usually there is more (and higher quality) than in a traditional organization. It’s also some of the best work you will ever do.
A lot of very uncomfortable questions in this list of staff engineering program dysfunctions. It seems this is quite widespread and we’re collectively figuring out how to shape this path.
We witnessed something very interesting: the United States had a quota for imported tuna. Once Peru’s quota had been filled, a biological miracle occurred right there on the canning line. What had been tuna was now pilchard, a member of the herring family, on which there was no quota.
Working in the Spotify organizational structure can be a bit tiresome but I’m glad we’re getting the important stuff from their product development culture, listed here by Jason Yip, right as well: aligned autonomy, trust and decoupling. Without those the structure indeed does not matter.
People leaving your team have a cost that is far far larger than what you can directly see (and we know what a challenge directing stuff that you can’t see is). These visualizations
by Benji Weber put forth a strong argument especially against people working as isolated individuals on things.
I agree with this take by Jacob Kaplan-Moss that you should be able to estimate very accurately and then just not do it most of the time. Learning how to estimate is a non-negotiable part of building an intuition for software engineering. It’s not the estimation that we need, it’s the intuition.
Improving the way we do posts is something I’ll be spending a bunch of attention on in the next months and here is an excellent guide of how to improve that part of the incident process.
We’ve worked remotely like this ten years ago with Hubbub and had to come up with a lot of these tactics and tricks just to be able to get work done. In the meantime, it seems the tools have come a long way (imagine the things we could have done if we had a tool like this back then!) but people’s thinking is still stuck in the past.
One of the things I have to fight the most for and that I think is what allows me to work well: “Regularly get in your team’s shoes”. Call it Genba, or Fingerspitzengefühl but the most important thing is to stay in touch with your team’s day to day reality.
“I see operationally-minded engineers working cross-functionally with software development teams to help them grow in a few key areas: making outsourcing successful, speeding up time to value, and up-leveling their production chops.”
A lot of the stuff here is our common sense when running projects and also our unique problem as a platform team trying to get stuff done with/for other teams. One thing that engineers tend to forget is how much agency they have: “Although you can’t control what other teams can do, you can influence them.”
A field report from doing incident management by John Allspaw that I can very much relate to with lots of learnings that need to be disseminated: “Focus less on incident metrics and more on signals that people are learning”
I keep referring back to this distinction which though coarse remains extremely useful. The barrel-like qualities of Understand, Ideate, Take Initiative, Recruit Others, Deliver Results can definitely be nurtured in people.
If you are looking around during the great resignation, I can tell you that things like 4-day work weeks, mission driven companies and excellent colleagues are out there to be found. For instance where I’m working now.
One, they must build psychological safety to spur learning and avoid preventable failures; two, they must set high standards and inspire and enable people to reach them.
A good counter-point by Camille Fournier about how being a hands-off manager can turn into being an absent manager. Making sure these kind of meetings are held is the most important leverage you have as senior leadership.
It’s a bit counterintuitive but I think it’s a good point that all the efforts to more and better coordination are harmful. We should have less coordination which will inevitably lead to more work between teams, but that is work you should be doing anyway. I think teams are in general very heavily underfacilitated.
I feel this list by Dan Na of what it means to switch to the management track and this point in particular is more or less what my days consist of (intensity, attention, feeling): “Management forces you to care more about everything.”
I think this is a leveling definition that I can live with: “Managers are paid to drive results with some support. Directors are paid to drive results with little or no supervision (‘set and forget’). VPs are paid to make the plan.”
I’ve been thinking along these lines and a DNA type meeting as an informal place of leadership and sparring sound great. In our case, I think I’ll call it “Debt and Architecture”.
Slack has an interesting S-Curve based approach to adopting new technologies where they mention that getting through the trough of adoption is more like product-work than anything else.
This point by Charity Majors is well worth repeating: you should not take on additional responsibilities if you’re not delivering at and excelling in your core job. All of the other stuff seems like it matters a lot, but it really doesn’t.
The organizational debt listed here is more the norm than the exception and a lot of management is dealing with unnecessarily suboptimal circumstances.
De organisatiestructuur is sowieso een kwetsbaarheid van Nederland crisisland, verzucht Arjen Boin. Allereerst is het probleem dat onze ministeries niet meer de capaciteiten in huis hebben om zelf het heft in handen te nemen. Den Haag heeft steeds meer een monitorende en coördinerende functie gekregen. Ambtenaren zijn in veel gevallen geen specialisten meer op de dossiers die ze beheren — hun specialiteit is vergaderen en managen en ze rouleren door de organisatie.Grofweg kun je als bestuur in tijden van crisis twee dingen doen: optie één is overschakelen op een crisisstructuur, zegt Boin. Daarbij centraliseer je de macht en breng je het aantal mensen dat mag meepraten terug. Dan kiezen we de mensen die namens ons de belangrijkste beslissingen nemen. Na afloop rekenen we af. Een crisisorganisatie is georganiseerd in een trechter. Aan het eind van die trechter zit de persoon die zich goed laat adviseren en op een gegeven moment zegt: ‘We gaan naar links of naar rechts.’
Uiteindelijk komt het bij de aanpak van zo’n crisis voor een groot deel aan op het politiek leiderschap
And from that point on she micromanaged me, and I realized that she was fear-based, both in how she thought of her bosses and in terms of how she ran her team.
There’s going to be a need for operations in companies however much of their infrastructure they outsource and it’s going to be increasingly interesting and valuable work.
I immediately understand it but I’ve never seen it articulated as explicitly as here by the Singapore Civil Service College: “The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.”
Talking about tech debt is so unspecific and confusing that maybe it’s better not to use the term at all and instead talk about it in these terms (specific goals, business outcomes, incremental delivery).
What is weird is that organizations that purport to be against risk will often do their projects exactly in this very risky way. Within an institutional logic, it often seems like there is no alternative but that is up to a few people to change.