Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


If you have developers doing everything I don't buy the scale claim.


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.


I don't doubt their title is developer, what I doubt is that their primary function isn't devops, etc.


>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..


So then concentrate on the idea behind the word and stop wasting peoples time.


Whether it is lanes or 'roles and responsibilities' I think everyone benefits when they have a good sense of what they are signing up for. But, in the real world, sometimes you just can't get that kind of clarity. I will get responsibilities throughout the year that I clearly think "I don't really know how to do this"...and then I evaluate whether I can learn to do that thing well enough or if I should defer to somebody else.

In regards to culture and scale and lanes...what I was referring to was having a culture of people who are accepting when others ask if they can help, rather than telling those people to go mind their own business. If employees want to do what they are specialized in...totally fine...but if I am interested in a topic that someone else specializes in, I would like to have an opportunity to explore that(without being a PITA obviously).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: