Yeah I just heard that @DazMac - interesting take. But I might be wrong; most developers do want to upskil and be able to do Platform/Ops. By silo'ing them, they'll never learn and upskill, and probably leave your org.

I don’t think that most developers would describe learning infrastructure as “upskilling” but rather as a necessity of the current landscape - if you get closer to being “full-stack,” you earn more and have better career opportunities. The moment this becomes less relevant, people will discard learning about infrastructure. Development is such a broad and deep field on its own that you can specialize in several other directions—generalizing into infra only makes sense on the outer shell to understand the implications of your architectural decisions.

Think @Daniel Bryant’s graphic from PlatformCon a couple years back is relevant here Sure, none of us want to be stagnant but it’s definitely getting a bit out of control

Kelsey, "it's excitement that motivates them"

I think people are complex. So the truth lies somewhere in-between - Multi-competency (multi-skilled team) and Single competency (Silos) in reality I have a core competencies and over the years i have picked up some additional skills, but there are other areas i have no interest in. So slightly altering Kelsey's point i actually might want to do some self-service in my baggage check-in, but i don't want to fly the plane.

To build on that analogy, you want to do online checkin, self-service baggage handoffs and the automated passport controls because they make your lives easier and to have those procedures done in a manual in-person way as fast as the automated procedures allow you to, would simply drive up the cost of the service to an extent where youd be priced out from traveling. But you really dont want to know background specifics, or at least the golden path majority doesnt want to know anything about that (would that be the abstraction layer - a developer or another customer(controllers for cost predictability for example) has a business problem needing to be solved).

I actually hate self baggage drop-offs because I don't want to put the sticker wrong or even deal with that 😄. Anyhow, interesting discussion here. 🙂

Well im from Estonia, Tallinns airport is small, fast and mostly efficient. So youre like i cant mess this up that bad but lets say Atlanta or Amsterdam - slightly different ballgame 😄 Should include that somewhere in my feedback interviews, how to find out whether certain automation process is trusted more because someone else is responsible for solving that problem (and therefor it cant go wrong 😄 ) or if there is less trust because you loose sight of the ball

Generally air travel is commodity today so I found this a useful analogy for things where you might not want to know about the low level detail or work collaboratively. Kelsey also mentioned that collaboration is much better employed on "things we can't do yet" which is where a multi-skilled developer can really shine and add most value by working across silos. Made me wonder what the equivalent analogy for that would be. Space travel perhaps?

I believe that platforms should provide “the right level of abstraction” that is directly linked to how much developers need or want to dive into platforms/ops. What is that “right level”? It depends and varies based on factors such as platform maturity, architecture and technical stack, developers’ maturity on CI/CD practices and tools, tools (security, observability among others)… But also organisational culture, devs personal drive/interest on platform topics. I worked in organisations where the platform was allowing users to experience different levels of abstractions depending on the user group (user segmentation was 🔑): • Platform users on data and IA where the CI/CD tools and practices, and the platform capabilities were not yet there (= it was not yet “industrialised”) wanted a high level of abstraction from the platform and the platform teams. Understandable because they had enough on their plate • For platform users on web that were mature in their CI/CD practices and for whom our platform provided a mature and sensible set of capabilities, it would depend based on their interest, how demanding was their daily job… Here, platform users would range from “not wanting to do anything with the platform” to “building platform capabilities” (contributing to the platform like in an open source model) I would say the baseline for this has a lot to do with the organisation and its culture, also because it is linked to the talent it attracts and retains (developers). @Klaus Fleerkötter @Marco Pierobon would love to hear your thoughts on this 👂

Great conversation! Developers should be allowed (and encouraged) to enter the Ops space, but the Ops/Platform teams should provide them easy defaults and safety nets to allow them a quick ramp up and the possibility to make mistakes without a major production incident. Incidentally, @María Isabel Martín Serrano has a great talk on this topic.