Thinking in platform

In our company, we have different engineering teams. Some work on specific applications; some work on certain features shared by all applications, like creating reports, authentication. Our team is UI Platform team. I had a hard time wrapping my head around with this concept. Taking a supermarket as an example, other teams are like the deli department, vegetable section, and we are ... uh ... the edible section? Other teams are defined by clear responsibilities, but our team is named after the technology. UI Platform? do other teams not do UI? they certainly do.

I have been working on the UI Platform team for one and a half year. Looking back at 2018, I want to understand what exactly my role is. What makes a platform team different from an application team. My manager describes UI Platform's objective as "providing UI building blocks for application developers". What are building blocks?

I did some research on the job market. Not many companies have the concept of UI Platform. The closest I could find was Uber. Uber calls it Web Frontend Platform:

As a Web Platform engineer at Uber, you’ll help build the foundation for all web applications at Uber. This team focuses on providing a high-performance, secure and reliable web ecosystem for all of our users (riders, drivers, eaters and our internal operations & logistics teams) through the creation and support of developer tools, systems and frameworks. The team’s main goal is to make Uber’s web engineers productive and its web applications high quality utilizing a modern tech stack

AdRoll has a nice post about building a Front-end core team, in which it describes the team as

(Front-end core team) works closely with our front-end engineers, UI designers and product leaders to make sure our web applications are built consistently across all teams. Most importantly, the Frontend Core team oversees and maintains all of our collaborative front-end projects.

I feel both these two descriptions match what we do in the UI Platform.

I once wonder, are we the most front-end people in the company? We deal with mostly front-end technologies, JavaScript, HTML, CSS. Recently one coworker asked for my help implementing a server endpoint for a POST request in Spring. I realized I haven't implemented a single Spring endpoint!

But what exactly did we do last year in UI Platform team?

We built a reusable React component library. More and more teams start using it to build new pages instead of rolling out their own widgets.

We built a layout engine for a most trafficked and highly dynamic page, so other teams can build their custom section and add to the page easily.

We hosted a week-long UI boot camp, teaching engineers from different teams the best practice of UI engineering.

We migrated about 17000 JavaScript unit tests from Jasmine to Jest for performance and reliability.

We upgraded all the icons used in the product from images to SVGs.

There are a lot more.

But we built almost no customer-facing features.

Sometimes I feel, our job is to take things no one owns, and make it our responsibility. I did not join the team since it started, but my general impression is, we are not the first team to create a dialog widget. We are not the first team to added front-end routing. But as we see a general pattern being used in the system and different teams are struggling to not step on each other's toes, we will build a shareable approach and migrates existing code to use this approach.

On the other way, we are also pioneers. As we are designing the building blocks for application teams to use, we are not just creating something usable. We are doing a lot of research on best practices and trying to make our API performant and intuitive. Dan Abramov wrote in his blog post:

The best API designers I know don’t stop at the “first order” aspects like readability. They dedicate just as much, if not more effort to what I call the “second order” API design: how code using this API would evolve over time.

Working in UI Platform team, I feel many decisions are made with consideration for how our code will enable other teams to ship features to customers. This is fascinating to me, it's like playing a game of chess and we have to think two steps ahead of our opponent (forgive me for bad analogy). The point is, something as mundane as creating a button can be very intriguing to us because we have a lot more to think about. Also, we have the freedom to spend a whole afternoon discussing one small technical decision because, hey, it's important.

I think another reason why our team exists is to bridge the communication. Engineers' job is solving customer's pain. While our customers are other engineers. As we are talking with different teams on their request for some platform improvement, we heard everyone's problem, and sometimes, a problem is already solved by another team.

We feel the need for better internal communication among engineers from different teams. We value documentation. We promote Slack as a replacement for Google Hangout. We are trying to foster a culture of learning and sharing, so we introduced a question and answer site. A good answer to a question won't just be kept between two people but shared with everyone who might have the same question.

It sounds so good to be in UI Platform team right? Yes, it indeed is. But don't forget the drawback though:

We usually don't ship any customer facing feature. Our product is code.

We can't just pick up the best and newest technologies and start using it, and we are in the constant grilling of wanting to apply the next big thing in our project. Whatever we use will be an example to other developers.

We have to keep a very high standard of code quality (this might be a good thing)

Our changes are risky because they might affect all other teams.

---

Those are my thoughts on what it means to work in a UI Platform team. Before I started my current role, I wasn't aware of the difference of platform vs. application. So hopefully this answers some question for aspiring UI engineers. Hey, it might be fun to work in the platform?