Servant leader

Operating a Platform team

My journey of managing a Platform team has finally come to an end. Slightly more than one and half year the company on #battlemode, we are finally have to give into the reducing head count through natural attrition to cut cost.

Still, I wasn’t a platform manager for very long tbh — less than a year to be exact. Still, there is so much to learn that I really want to take the time here to write down my thoughts about this journey.

What is a Platform Team

As far as I recall, platform team was made popular by Team Topology. There are many concept in the book that we borrowed to jumpstart the team. Eventually, we managed to find our own grooves that make the Platform ticks in my company. Mainly due to the type of work and culture of the stream aligned team.

Nuff said…

The platform team is a highly specialized team that is focused on developer experience aka DevEx. For that, their purpose is mainly to solve the following:

  • Removing squad cognitive load
  • Addressing engineering best practices and compliance
  • Addressing engineering hygiene

There are many interpretations of what a Platform team should be. Without all the flashy words, it all boils down to the 3 above intending to improve engineering excellence in general.

The culture and mindset

Before we dive deeper. Let’s address the culture of engineering.

First and foremost, is the continuous improvement (kaizen) mindset. A team should always want to seek improvement with or without resource constraints. Be good at engineering, we need to be able to identify and streamline the engineering process.

Stream-align is our customer. It is a team effort whereby everyone on the team should take part in continuously engaging with stream-align engineers – not just the managers. Focus on the problem, not doing what is fun doing.

Reduced toil, instead of adding work for steam-align. Quite often, we face a sticky situation that needs engineers for feedback or make changes. These are work. Make the process for them effortless (less than half a day effort) and summon the ENG epic for the rollout. It has to justify the value and impact of the stream-aligned.

Not a kitchen sink. Instead of seeing it as a kitchen sink, think of it as an opportunity to make things right – the platform way. After all, it is our job to gel the engineering into a well-orchestrated system.

Removing squad cognitive load

Usually categorized as improvement of repetitive work. Eg. quarterly key-rotation, quarterly BC/DR drill, etc What are the opportunities we have to simplify or remove the whole process such that the stream-aligned can solely focus on their core duty?

Think about a frictionless self-servicing machine. How to make something that has a no-brainer in value, and easy to transition out of their existing process and set up?

Identifying cognitive load requires continuous effort to stay in the loop with engineers. Leverage the channel such as planning sessions, chapter meetings, or any shared engineering discussion to get involved. It can’t be a one-man show to do this.

Engineering compliance

Our work in the platform often overlaps with departments outside of engineering (eg, the IT and GRC). The policy written has to be respected for us to maintain the compliance status of the company. This is extremely crucial to build trust for the customer and securing bigger deals.

The need to study and understand policies that may impact engineering/infrastructure quite often can be set up and secure from the platform level.

Be the expert in this domain to assist and support the stream-align, so that we can achieve the engineering excellence of what we claim to be.

Engineering hygiene

This is hard to control especially if we want to empower the team with the freedom to choose their implementation. For example, we do this by having a lab account to give engineers the space to explore and test things. Often, it goes unnoticed when some resources isn’t cleaned up properly once is not in used anymore. Be it forget about it or might be using it again in the future.

Do not think of this as low-value work. Leaving it may cost money or security risk. Like it or not, it has to be addressed for sanity sake.

Roles in the squad

Engineers

  • Socialize and network – be the developer advocate by actively participating in stream-aligned discussions.
    • Be the go-to person for technical expertise.
    • Identify gaps that can be filled to reduce cognitive load, compliance, or hygiene.
  • Engineering work – implement the technical solutions.
  • Maintaining the services – maintenance and continuous improvement of the existing solutions.

Technical product manager (TPM)

  • Stakeholder management – to look for opportunities to create significant impact and value, and manage their expectations.
  • Set ambitious goals and roadmaps – set the outcome, and let the team decide how to do it.
  • Socialize and network – advocate and promote the solution developed by the team.

Engineering manager (EM)

  • Focus on people and process – like a typical EM, make the team shine.
  • Work on the right things – making sure the work is feasible and working on an actual problem.
    • tips: Spikes and RFCs are not a real outcome.
  • Room for mistake and failure – establishing and providing a safe zone for experimenting. Because making changes on the platform is risky work.

Lesson

I was tasked to take on 2 roles here – TPM and EM. Which is an anti-pattern for running a team. The biggest reason for this is trying to balance two separate personalities. One is striving to find balance for the team, and the other is pushing for excellent products.

Let me explain, TPM’s goal is to prioritize and groom the priority of the backlog. Therefore the role here is if the output isn’t meeting the standard, we reject the deliverable. The other is focusing on productivity, ensuring that what needs to be worked on is feasible – to some extent, cutting some corners when necessary. A TPM that wears the hat of EM leads to a sub-par output cause there is no accountability for the deliverables now.

Secondly, while grooming the requirement, I tend to have a solution in mind and design it in such a way that there isn’t much room for the engineer’s creativity. The right way to do it is to just let the engineer figure out the solution. Instead of solving, lead the problem. To do this, highlight the problem without actually solving it, and let the team ask question if they need clarification or directly connect with the stream-align team.

Lastly, about identifying steam-aligned gaps. As mentioned, filling in the gap of the stream-aligned is vital to the success of this team. It should never be a one-man joining all the cross-squad calls. You’ll end up with meeting fatigue at the end of the day (Like me). Like it or not, we have to force the engineers to take part in this. Excuse should not be tolerated, I should have stood firm. This is super important.