I'm torn about this article, I love the part about feedback loops and optimizing the parts of your day where you are in a tight loop for a long time; but for most of the article it seems he is _almost_ saying something profound, but there is too much clutter and buzzwords around it. I know these abstract consultancies have a use, but they seem to target what managers and executives _want_ to hear instead of the truth.

e.g.: "The promises that were made to executive leadership about the latest technology are not coming to fruition quickly enough."

It feels like he then proceeds to talk about how management can get the developers "organized" to make sure they get the job done. Having a developer doing support for the day kinda sorta seems like a nice idea until you realize that "Isn't that what the manager is supposed to do? Understand his team and get what they need/negotiate with other teams so that they can just get their work done?" It's kinda like he's telling managers how to outsource their work to someone else. Pass the buck and live in a fairyland.

I know people who idolize Thought Works, Martin Fowler, Uncle Bob, and others in the "consulting set"-- but it seems like they fill a particular niche, and it isn't the phenomenal tech experts, it is more of the "how management views tech from an academic level and how we can get these interchangeable programmer cogs to get our project done w/ the least amount of effort". They rarely give hard advice, it is more of soft exposure to "new tech" and "here's something that works for some people, you might be that person". "We'd love to sell you on new tech that will be a silver bullet for all your problems"

In any case, I learned some interesting stuff from the article, and I do think it is a valuable read.

In my current team (and my previous one from another company) we have what we call "goalie" duties. Each week one engineer from the team is responsible for answering inquiries, not necessarily they have to know the answer but they are the ones to be interrupted and handle accordingly.

It works pretty well, our devs are capable of assessing urgency to either bring it up on Slack, wait for the next stand-up or call to arms if it's something critical.

It improves rapport with stakeholders and other teams; it improves morale, it's predictable who will be interrupted during the week, alleviating that from the rest of the engineers. And as a side-effect it helps to force knowledge sharing over time.

In my current company we have a daily devops and dev duty. With current dev team size each gets around 3 duties per year.

Dev duty takes care of rollouts, crises, rollbacks, keeping an eye on performance and error monitoring. It's a great approach that works for us and allows every developer to get familiar with rollout process eventually, but I don't know if there are downsides for smaller teams or for projects that are split into several independent services instead of one monolith.