This perspective is wrong because it assumes that there are platform engineers and product engineers and that they need to negotiate with each other as equals in the absence of an arbiter that can set priorities and explain the long term consequences of unreleased product to platform or the consequences of unmaintainable code to product. The absence of the big picture creates agitation rather than alignment.<p>This blog post is an indicator of extremely weak leadership. Lack of a leader with both authority (from the org chart) and legitimacy (because people believe in their technical expertise) is exactly the situation that results in this kind of blog post being written.<p>Full disclosure: I am a platform engineer.<p>My take:<p><pre><code> * Product engineers overestimate their ability and expertise
* Product engineers underestimate the damage they cause with several classes of errors, especially dependency errors
* Organizations generally prioritize product engineers concerns over platform engineers concerns, product = money, platform = cost
* Organizations under-invest in platform headcount, even when all product teams complain about the dev experience.
* Platform engineers fail to create pleasant frameworks
* Platform teams repeatedly fail to make the right choice the easiest/only choice
* Product wants more from platform, but won't give up their headcount
* Product is more than happy to spend platforms money (they should be oncall/do maintenance), but isn't happy when platform spends products money (we don't have time to refactor/migrate).
</code></pre>
Here is a list of things product teams might do that would make platform engineers lives hell:<p><pre><code> * add new dependencies, especially without consulting anyone
* create circular dependencies/inline imports/other dependency abominations
* use the global scope
* change how the server works in the wrong location
* fail to or completely ignore dependency injection
* implement a solution to a problem they haven't yet understood
* HOPE a short cut solution will work because they don't want to solve the problem the hard direct way
* try to solve a performance problem by adding complexity, rather than reducing complexity
* demand specific infrastructure changes in an area they don't maintain
* make significant changes for a service they are not on call for
* write crazy complicated tests that take forever and completely fail to unit test
* contract out features to other companies without consulting platform
* ask for new languages/paradigms to be supported (which also means maintained)
* not do napkin math to determine how much space their new data will take
* not do napkin math to determine how much a new feature will increase utilization
* not warn platform teams of new/impending load
* not consulting platform teams about complex new features BEFORE implementation
* abandoning services/code they don't want to maintain, but can still break
* failing to migrate or finish a migration
* failing to actively or passively monitor the capacity/health of their own features
* create product that someone else will be on the hook to maintain
* implement the same behavior another team needs in their own way because coordinating is too hard
* implement the same behavior another team is responsible for providing because they need it now
* creating a new system without first understanding what was bad or refactoring the old system
* failing to quarantine business logic, especially from infra logic.
</code></pre>
All the product, platform, and infra engineers in these toxic environments sit down trying to diagnose the key problems about why the dev experience sucks. Then ask themselves "how are we failing so bad? Why does product do such insane things? Why does oncall suck so much? Why is the platform so hard to use? What is infra even doing? Who is solving these problems?" It's clear something is wrong, but nobody knows exactly what it is.<p>The problem is a lack of leadership. When people write posts about product and platform being at each other's throats, that is an abject failure of senior leadership at a company.<p>A leadership that fails to interface with or solicit feedback from line workers is a failed leadership. A leadership that fails to see the bigger picture is a failed leadership. A leadership that fails to see long term costs is a failed leadership. A leadership that promotes short term prolific product devs that squirt out product rather than foundational, do the hard thing because its necessary even if it takes more time, product devs is doomed.<p>If you go around and all the people in your technical leadership positions can't tell you what the real architectural problems are because they are too busy plopping out features, that means leadership has failed.<p>And guess what! All the senior engineers are avoiding these problems like the plague because sane solutions require a lot of really unpleasant, really unsexy work that is not guaranteed to succeed. Why would a senior engineer work on a hard problem when they can write a horribly complex feature, get a promotion, a 20% bonus, and quit the instant there are any repercussions for their bad decisions with a resume that talks about the amazing features they created? I'm not asking that facetiously. Is hard grunty refactoring work valued by the companies reward system/authority system? Do platform engineers get to write performance reviews for the senior engineers that cause them pain? Where/how does quality/architecture feedback even get considered systematically?<p>How many kids out of college even know what dependency injection or the global scope is? How many of them can mock a canonical easily understood teaching example on the white board of a global scope violation or dependency that was not injected? How many senior engineers can do that? How many onboardings, documentations, or classes exist that explain these concepts and the long term consequences of ignoring them? What do you do if your senior engineers are leading by example by taking those shortcuts if it gets their feature out faster?<p>What every product engineer needs to understand is that a platform is a commons, like the tragedy of the commons. A grassy meadow with a bunch of cattle ranchers might let the cattle eat their fill, but if all the cattle eat all the grass, the cattle will starve or the ranchers will fight. In the same way, if a bunch of devs are allowed to create as much complexity as they want, the server will starve (tests will take to long, build will always be broken, pages will always be sent) or engineers will start to fight.<p>Every individual dev is incentivized to create as much complexity as quickly as they can because they want to meet their goals. With no force regulating the complexity it is not a stable system and will definitely collapse. So the platform team comes in and says "no" because that's the only way to really limit complexity. Leaderships job is to regulate this relationship and ensure that everyone is aligned and properly incentivized, so that "the cattle ranchers can have as many cattle as the fields can sustain."