The Good, Bad, and Ugly of Being Part of the Platform Team

Starting my career as a backend developer and then transitioning into Platform engineering, I consider myself fortunate to work on a stack that influences the entire engineering landscape.

Having collaborated closely with Platform teams early in my career and subsequently joining a platform team, I consistently strive to align the incentives of both teams, aiming to foster a more cohesive engineering culture overall. Here are few of my observations about working in a Platform engineering team.

The Good

1. No product managers! 
   Seriously, the absence of a product manager is truly a blessing. Picture a team entirely driven by engineers, able to focus on long-term, high-value projects without being encumbered by the outcomes of daily A/B tests.
   
   
2. Continuous Learning
   Given the rapidly evolving nature of technologies like cloud computing, containerisation, and orchestration tools (e.g., Kubernetes), platform engineers are often at the forefront of new developments, leading to continuous learning opportunities.


3. Influence and Impact
   Another significant reason I transitioned to the Platform domain is the profound impact one can make with a relatively lower effort. The contributions of Platform Engineers carry substantial weight, even at the junior or mid-level positions.
   This factor often prompts many Staff+ engineers to concentrate on Platform initiatives. They find it easier to influence organisation engineering decisions without getting entangled in product-related politics.

The Bad

1. You are a Cost-Center
   As the Platform team is not directly contributing to the revenue, it is almost considered as the cost of doing business. 
   
   
2. Complexity and Responsibility
   
   While the role of a platform engineer is rewarding, it's not without its challenges. Managing critical infrastructure demands meticulous attention to detail, comprehensive knowledge, and a proactive approach to mitigating risks. The stakes are high, with potential repercussions ranging from system outages to compromised security.
   
   
3. The "it will only take 2 minutes" tasks
   Often, platform teams receive ad-hoc requests that are described as 'only taking 2 minutes.' However, the sheer volume of these requests distracts from deep work. The time and effort required for such tasks are challenging for management to appreciate during evaluations. A highly experienced engineer once advised me that the best way to avoid such distractions is to automate repetitive tasks as much as possible.

The Ugly

1. Lack of Recognition and Appreciation
   

One of the most disheartening aspects of being part of the platform team is the minimal recognition and appreciation received, especially when systems are functioning correctly. 

Many CXOs and even Engineering VPs don't truly understand the effort required to manage dozens, if not hundreds, of Kubernetes clusters, CI/CD processes, networking, and more to maintain a functional system. 

In some organisations, product managers (PMs) tend to attribute the success of specific features or initiatives solely to themselves, Backend/Frontend Developers, and the Q/A team. However, these PMs often approach platform teams just days before a launch, seeking various permissions and configurations for the release.

    2.  Challenges of On-Call Responsibilities:

While on-calls are generally stressful, platform on-calls are particularly taxing. This experience can vary depending on the organisation, but you're essentially expected to join calls "just in case." We joked within our team that if an S1 outage was announced, all platform members would join the call by default, only to drop off later when they had little to contribute.