Hacker News Reader

Comment by Aurornis | Hacker News Reader

That has been the fate of every platform team I’ve worked with in recent years.

Then they become gatekeepers, refusing to allow anything on their platform unless it conforms to their ideal vision. The catch is that their vision won’t be ready to use for 6-12 months, so you can’t deploy. Now your biggest problems aren’t engineering, it’s constant politicking to get around the platform team.

Add to this the concept of “architects” who don’t code but jump from team to team critiquing their work and you have a recipe for getting nothing done. One half of engineering is coding and trying to ship, and the other half of engineering is gate keeping and trying to prevent anyone from shipping

View on HN

> Then they become gatekeepers, refusing to allow anything on their platform unless it conforms to their ideal vision

As the owner of a platform team, this very common attitude of platform teams kills me. Yes, we have a long-term vision that we're working towards, but our main goals are two accelerate developers AND produce more robust systems. Outside of totally egregious violations of company standards, my team is expected to focus on how to get things done. That means being flexible, working side-by-side with other teams, etc. to make sure that a) they're able to deliver what they need and b) we help them build it in such a way that it can eventually be aligned with our utopian long-term vision.

That’s exactly how every platform team starts. There is inherent tension between accelerating developers and building their own systems, though.

In my experience, the platform teams developed an idea that their conceptualized system would accelerate everything once it was done, but working with product teams was a distraction from getting it done. They also didn’t like the idea of deploying something now and then having to rework it later when their ideal system was ready. So they defaulted to gate keeping, delaying, and prioritizing internal work over requests from the product teams.

The only way to get things done was to leverage management chains to put pressure on the platform team to prioritize getting your thing deployed. This was constant no matter how much headcount the platform team received because with every new hire they developed new ideas and goals to add to their internal roadmap.

It’s not supposed to work like this, but it plays out this way in many companies.

> It’s not supposed to work like this, but it plays out this way in many companies.

Absolutely, and I've been on both sides. We go much more with a carrot approach than a stick approach, and have no ability to "block" any product team from doing things. Our goal is to ship things that are useful and lower the effort required for product teams to ship their products, which is handling basically everything except product-specific features. However, product teams don't have to use the platform, but then they own the operational burden of whatever custom stuff they're using. When that happens, we still work with them to minimize that or bake that capability into the platform and eventually take it over if it's useful to the wider org.

"Success" of the platform team really depends on serving the product teams, so blocking or being a barrier goes very much against that. We try to provide opinionated golden paths, but also try to build a properly abstracted stack of capabilities so teams can also extend/consume at a lower level if that better suits their needs.

There probably isn't any middle ground in practice then. If the product teams have control, then the tech debt just keeps building as they keep prioritizing new features over longer term maintainability. I see it already happening at my startup where product has a lot more influence than engineers in terms of what goes on the roadmap (there's practically zero time devoted to lowering tech debt.)

i think this is where a large portion of the tech consulting market comes from. Someone in business gets absolutely fed up dealing with IT and trying to get something they need in production. Next, they go find a budget, call a couple firms, get some proposals, pick one, and do it themselves.

That's actually the "premise" of Google's SRE book

Reply on news.ycombinator.com