4 ms·

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic. On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actually have the required experience to teach us how to be highly effective as opposed to what we can learn directly from orginsations that are highly effective, but I do believe they have enough experience to tell us that effective development teams invest in development tooling, dev focused user experience, and a dev focused culture. Who and how you'll build this is left as an excercise for the reader, which is unfortunte because we now have a legion of consultants who've never produced a line of code making a career telling us "culture is hard" and then forcing us into scaled agile frameworks and tooling that are contradictory to the ethos. Doesn't mean the underlying point is bad though. Engineering teams need some time to work on developer experience instead of just being feature factories; bigger org can hire teams dedicated to helping with this. This is a good thing, but many orgs fail at understanding and allowing the investment.

ivandenysov 6y ago
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.
- thargor 6y ago
  How large is your team? 3 duties per year sounds incredibly low.
brobdingnagians 6y ago
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.
- ownagefool 6y ago
  Indeed. The lack of hard advice is great for them because they're essentially never wrong but you'll also never fix the problem with the advice alone. Keeps the gravy train going; if they solved our problems with hard facts in blogs, we wouldn't need them. That said, the advice itself is still pretty good if you have the chops to follow through, but I honestly don't think you can build the chops by hiring in the consultancy to tell you. In fact, it's actually a bad sign that you leadership both need obvious advice, and think they can enact change by hiring the consultancy. The reality is, you'd probably have better results changing the leadership.
  - 6y ago
piva00 6y ago
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.
- gregd 6y ago
  This is actually a great idea and something I'm likely to bring back to my own teams!
- jy2947 6y ago
  Isn't the typical responsibility of the manager or the team lead? Inquire often is followed with more requests, if each developer serves as the weekly-speaker-of-the-team, will the external partner eventually figure out "John will do anything for us and Steve is mean"?

ivandenysov 6y ago

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.

thargor 6y ago
How large is your team? 3 duties per year sounds incredibly low.

brobdingnagians 6y ago

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.

ownagefool 6y ago
Indeed. The lack of hard advice is great for them because they're essentially never wrong but you'll also never fix the problem with the advice alone. Keeps the gravy train going; if they solved our problems with hard facts in blogs, we wouldn't need them. That said, the advice itself is still pretty good if you have the chops to follow through, but I honestly don't think you can build the chops by hiring in the consultancy to tell you. In fact, it's actually a bad sign that you leadership both need obvious advice, and think they can enact change by hiring the consultancy. The reality is, you'd probably have better results changing the leadership.
- 6y ago

piva00 6y ago

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.

gregd 6y ago
This is actually a great idea and something I'm likely to bring back to my own teams!
jy2947 6y ago
Isn't the typical responsibility of the manager or the team lead? Inquire often is followed with more requests, if each developer serves as the weekly-speaker-of-the-team, will the external partner eventually figure out "John will do anything for us and Steve is mean"?