Perfectly reasonable people thought that maybe we should put more of a wall between designers and the css source code. […] But instead a miracle happened. There was an inspired person who decided to do the opposite. They just yolo’d giving the designer the deploy keys. […] We spent our free time building everything we needed to in terms of monitoring, test suites, et cetera to make that safe for them to do. Everyone rejoiced and got shit done. Nothing bad happened.

When this talk was first shared with me, my mind was blown because everything I had ever heard about building an organization, was that we need people to respect their lanes and learn to communicate with each other. I don’t think that value is wrong (talking cross-functionally is important in almost any organization), but this talk blurred the lines for me between what is good communication, and what is building fiefdoms.

Make your discipline more accessible This should be part of your job!

I will say, the challenges here are really, really underemphasized. (Not to say it’s not worth it, of course, but that there’s more to it.) If I don’t have the right tooling needed, making a code change, ensuring it’s safe, and deploying it to production is barely safe for an engineer, now imagine someone without the skills to debug if the flow fails half the time.

Sometimes the walls come up because people want to perpetuate those little stupid fiefdoms, but sometimes it’s just because it’s the easiest thing to do, everything is on fire, and you don’t have the time.

(The perfect retort to that, which I believe, is if you set your team and processes up to be accessible from the start, it’s pretty cheap to maintain it, and people will even help you point out failures far sooner. Looked at this way, fiefdoms are organizational debt that can be paid down easily at the start, but not much later.)