4 ms·

The second you paint lanes is also the same second you're expected to stay within those lanes with ramifications if you don't. This is one of those arguments t

The second you paint lanes is also the same second you're expected to stay within those lanes with ramifications if you don't. This is one of those arguments that looks good on paper, but causes untold pain in practice.

mym1990 4y ago
Hardly. As a dev, architects around me have no problem with me getting more insight into their work, and letting me do some things that are 'outside of my lane'. On the flip side, I can say that something is above my paygrade if I want to stay in my lane. Your ramifications statement is more of a reflection on particular company culture. On the whole, lanes are created by companies to create a promotion flow so that people can always keep trying to climb the ladder. We see more flat organizations today, but as an organization grows to become huge, hierarchy is almost necessary.
- oaiey 4y ago
  We architects love engineers like you. Less work, more collaboration, less risk. And scale is exactly the point where real architects are needed. It is about culture. Which is very hard because many junior architects have a power trip over their fellow engineers.
  - mym1990 4y ago
    <3 Totally! To someone else's point, it is important that when I get involved in an alternate "lane", that I do not create more work for everyone and there is net value being created.
- P5fRxh5kUvp2th 4y ago
  I would argue you acknowledge the point when you say you know when to avoid stepping outside of your lane ("above my paygrade"). lanes are created for specialization but when you do that it's a clear indicator that if you're not specialized in that area you should be deferring to those who are. You wouldn't want a devops person telling you how to organize the controllers in your application, and that devops person wouldn't want you telling them how to organize the management of the pipelines. That's not culture, that's necessity due to scale. The point being made is that should be put off as long as possible because when you put it into place suddenly the communication becomes a lot harder and it's not obvious it's always a benefit until there's real pain from not doing so. --- I would not consider understanding the large context of things to be stepping outside your lane and I suspect most people wouldn't either.
  - closeparen 4y ago
    It may surprise you that my very high scale employer in addition to having no architects also has no devops. It has instead an infrastructure group that ships a PaaS. Engineers click their own buttons on the PaaS. Only if things have gone very wrong would you end up talking to or having actions taken on your services by the PaaS owners. Now obviously to design such a PaaS successfully you should know a thing or two about ops, but the outcome of that expertise is a reusable software platform, not per-product (or worse, per-release) labor.
    - P5fRxh5kUvp2th 4y ago
      If you have developers doing everything I don't buy the scale claim.
      - closeparen 4y ago
        I don't know what to tell you without de-anonymizing myself on the internet. It's a household name that you've probably used. Again, it is not that product engineers are "doing everything" - the road is paved by a very large platform org - but they just build the road, we have to drive on it.
        P5fRxh5kUvp2th 4y ago
        I don't doubt their title is developer, what I doubt is that their primary function isn't devops, etc.
        closeparen 4y ago
        >I don't doubt their title is developer, I don't know any companies that use that word. Normally we are called software engineers. Amazon is the closest, with "software development engineer." Nor do we use the word devops. Which is funny, because as I understand it, software engineers working on infrastructure automation in the same way that that we work on products are the closest thing to what "devops" envisions. The companies that are doing it don't use the word, and the companies that use the word are the most incredulous that anyone could be getting by without dev and (dev)ops as substantively separate roles. It would be almost as if the people who most liked to talk about Agile were the ones most invested in very long range estimation and planning. Oh wait..
Fire-Dragon-DoL 4y ago
The same could be said about the opposite. No lanes are placed, the junior developer (or intermediate) will design a system that they are not qualified for and the problem will be discovered only at pull-request time, when a huge waste has already occurred. Or worse, the PR will be reviewed by a senior developer that's not experienced in system architecture and will get approved. It's pretty common even in senior developers to not be experienced in system architecture, so the problem is not resolved with this approach (based again, uniquely on my experience. I didn't run any statistics)

mym1990 4y ago

Hardly. As a dev, architects around me have no problem with me getting more insight into their work, and letting me do some things that are 'outside of my lane'. On the flip side, I can say that something is above my paygrade if I want to stay in my lane. Your ramifications statement is more of a reflection on particular company culture. On the whole, lanes are created by companies to create a promotion flow so that people can always keep trying to climb the ladder. We see more flat organizations today, but as an organization grows to become huge, hierarchy is almost necessary.

oaiey 4y ago
We architects love engineers like you. Less work, more collaboration, less risk. And scale is exactly the point where real architects are needed. It is about culture. Which is very hard because many junior architects have a power trip over their fellow engineers.
- mym1990 4y ago
  <3 Totally! To someone else's point, it is important that when I get involved in an alternate "lane", that I do not create more work for everyone and there is net value being created.
P5fRxh5kUvp2th 4y ago
I would argue you acknowledge the point when you say you know when to avoid stepping outside of your lane ("above my paygrade"). lanes are created for specialization but when you do that it's a clear indicator that if you're not specialized in that area you should be deferring to those who are. You wouldn't want a devops person telling you how to organize the controllers in your application, and that devops person wouldn't want you telling them how to organize the management of the pipelines. That's not culture, that's necessity due to scale. The point being made is that should be put off as long as possible because when you put it into place suddenly the communication becomes a lot harder and it's not obvious it's always a benefit until there's real pain from not doing so. --- I would not consider understanding the large context of things to be stepping outside your lane and I suspect most people wouldn't either.
- closeparen 4y ago
  It may surprise you that my very high scale employer in addition to having no architects also has no devops. It has instead an infrastructure group that ships a PaaS. Engineers click their own buttons on the PaaS. Only if things have gone very wrong would you end up talking to or having actions taken on your services by the PaaS owners. Now obviously to design such a PaaS successfully you should know a thing or two about ops, but the outcome of that expertise is a reusable software platform, not per-product (or worse, per-release) labor.
  - P5fRxh5kUvp2th 4y ago
    If you have developers doing everything I don't buy the scale claim.
    - closeparen 4y ago
      I don't know what to tell you without de-anonymizing myself on the internet. It's a household name that you've probably used. Again, it is not that product engineers are "doing everything" - the road is paved by a very large platform org - but they just build the road, we have to drive on it.
      - P5fRxh5kUvp2th 4y ago
        I don't doubt their title is developer, what I doubt is that their primary function isn't devops, etc.
        closeparen 4y ago
        >I don't doubt their title is developer, I don't know any companies that use that word. Normally we are called software engineers. Amazon is the closest, with "software development engineer." Nor do we use the word devops. Which is funny, because as I understand it, software engineers working on infrastructure automation in the same way that that we work on products are the closest thing to what "devops" envisions. The companies that are doing it don't use the word, and the companies that use the word are the most incredulous that anyone could be getting by without dev and (dev)ops as substantively separate roles. It would be almost as if the people who most liked to talk about Agile were the ones most invested in very long range estimation and planning. Oh wait..

Fire-Dragon-DoL 4y ago

The same could be said about the opposite. No lanes are placed, the junior developer (or intermediate) will design a system that they are not qualified for and the problem will be discovered only at pull-request time, when a huge waste has already occurred. Or worse, the PR will be reviewed by a senior developer that's not experienced in system architecture and will get approved. It's pretty common even in senior developers to not be experienced in system architecture, so the problem is not resolved with this approach (based again, uniquely on my experience. I didn't run any statistics)