Product and Platform Engineers
Recently, I read a post by LeeRob, VP of Product at Vercel, on Product and Platform Engineers . Several of his comments about the diminishing relevance of Frontend and Backend roles resonated with me.
So I decided to write a post about it as well, focusing on the utility of these roles and offering perspectives that could aid individuals in career development or team builders in understanding their needs.
Most of my work experience involves launching projects for startups with limited resources and only a few engineers to handle all tasks. I’ve found it disappointing and frustrating that a frontend engineer might be unable to modify an API query to retrieve a needed UI field, or a backend engineer might refuse to adjust a simple style, citing it as ‘not their job,’ especially when time is critical for a startup client. Sometimes, I was that person.
This is not to play down backend or frontend developers, as these roles are complex and deep, with much to learn and accomplish. Taking on additional tasks might not seem worthwhile, especially without extra pay or promotion prospects. However, ultimately, it’s about your skills and capabilities, which could position you for exciting job opportunities.
To me, being a Full Stack developer, even extending to mobile development with React Native, has always made more sense. But more importantly, besides roles and technologies, my focus has been on solving the business problems of my clients.
At times, the scope of my role was not within my control. In some projects, contractual obligations or assignments from tech leads restricted me to specific areas. As a Frontend developer, this sometimes meant making numerous calls to render a single view due to ‘good’ REST practices. Other times, I faced days-long blocks or other challenges associated with being confined to a single role. The point is, flexibility and a broader skill set can be invaluable in this field.
Roles and Definitions
Let’s dig into comparing these roles and their utility. To ensure we’re all on the same page, I will first briefly outline the roles and their responsibilities
Frontend Engineers are responsible for implementing the visual and interactive elements of a web application that users engage with directly.
Backend Engineers are responsible for server-side web application logic and integration with databases, cloud services, and third-party services.
Product Engineers are responsible for the end-to-end development of software products translating business requirements to technical solutions.
Platform Engineers are responsible for building and maintaining the underlying system and infrastructure that support software applications. This often involves cloud services and system architecture/design enabling other engineers.
Frontend and Backend vs Product and Platform Eng.
There are similarities between Product and Frontend Engineers as well as Backend and Platform Engineers, but the areas of web development they focus on are pretty different. Let’s look at some real-world examples to compare.
Frontend vs Product Engineers.
Imagine we need to create a new email with a link, which will open a new UI in the app and display some info. This involves grabbing data from the URL and making dynamic queries.
A Product Engineer could handle the whole thing. They’d set up the endpoint for sending the email, make sure the email looks smooth, tweak the link to include the right info, build up the new UI, and set up and use extra endpoints for the page’s functionality, considering the URL info. Plus, they’d take any extra steps to meet the business needs. If anything changes along the way, they can dive into any part of the process and sort it out.
A Frontend Engineer, on the other hand, would likely ask the backend team to create the new endpoint for the email, maybe collaborate on the email’s design, request specific info for the link, and ask for new endpoints to pull the dynamic info. They’d also push forward with the UI as much as they can. Not to downplay their work as dealing with forms can be annoying, and stopping users from messing up stuff is like taking care of a child sometimes. But often, they end up waiting on the backend team to finish their part.
When things change, which they often do, even if it’s something simple like adding another property to the email link’s query parameters or a few fields in the endpoint, no matter what, there’s a good chance they’ll end up waiting around, especially if the backend team has moved on to other high-priority tasks.
This situation can be a headache for everyone including managers, product owners, clients, stakeholders, and your mom. Sure, you could argue that with well-defined requirements and resource management, there wouldn’t be any downtime. But let’s face it, in the real world, unexpected things pop up, or there are misunderstandings in the team, especially with complex features, due to not fully grasping what the other role needs or does.
This isn’t to say that frontend teams can’t work well together, but coordinating with a product engineer can be a whole lot smoother. Their wider range of skills comes in handy, especially when there’s a lot going on in a specific area of the app.”
Backends vs Platform Engineers.
These roles actually have a lot in common. The key difference, though, is that platform engineers often end up doing some frontend work as well.
Take, for example, setting up a feature flag system. A backend-only person and a platform engineer might approach this differently. I can picture the backend folks either spinning up an in-house solution or hooking up a third-party service, but just on the backend side. They’d probably set up some endpoints for the frontend team to use.
Now, that approach isn’t bad, but it might not be the best or the most complete solution. There could be a bunch of requests hitting those endpoints, which adds unnecessary latency. The frontend could, instead, directly fetch those values from the third-party system. Plus, if the functionality is built into the frontend, future developers could simply use a ‘key’ for that function. This way, they avoid the headache of dealing with parsing/querying, default values, and other such issues every time they would consume the endpoints.
Here’s another example to consider. Let’s say there’s a need to boost a website’s performance, particularly its loading time. To a backend engineer, this might seem like a frontend issue. They might suggest making the JS or CSS bundles lighter or offer to improve image optimization during storage, or suggest other backend enhancements.
A Platform engineer, however, might look at this challenge from a different angle. They’d think about the entire system. Maybe they’d set up a CDN to speed up load times, cut down on load-balancing costs, and get some SEO benefits. Or they could switch to a different bundler or minifier to deliver the frontend more efficiently.
I’ve chosen examples that might be outside a typical backend engineer’s comfort zone, but that’s not to say they couldn’t handle them if needed.
The distinction between backend and platform engineering is more subtle than that between frontend and product engineering. Backend engineers are already in the system mindset, thinking about databases, reliability, etc. At first glance, the roles might seem similar, but platform engineers include the frontend in their solution strategies.
A backend engineer could quickly evolve into a platform engineer. They’re already clued into the complexities of backend work, like business logic, databases, system design, cloud services, and more. They just need to be open to occasionally stepping into frontend tasks when necessary.
Comparison Overview
My stance is pretty straightforward: I view frontend and backend roles as somewhat limited in their ability to significantly impact the business. You might be wondering, ‘Isn’t there already a role that covers all these bases, like a Full Stack Engineer? Full Stack Engineers indeed appear to manage both sides of the coin, but here’s the thing: the label ‘Full Stack’ is quite broad and a bit ambiguous. It doesn’t really spell out the specific focus of the job. And that clarity is crucial, whether you’re on the hunt for a job or looking to fill a position in your team.
I believe Full Stacks are often oriented to either the product or the platform, but when trying to understand the responsibilities to fit the area of interest it’s complicated. If you are a Full Stack trying to decide which of these roles you like, think of the following:
Product Engineers are the ones who dive deep into user experience, working alongside designers, and product owners, and responding directly to customer feedback. They’re constantly shipping features and focusing on functional requirements from beginning to end.
Platform Engineers, meanwhile, are the guardians of the system’s health. They’re focused on making everything reliable, scalable, and efficient – the kind of work that underpins the system’s features, mostly tackling non-functional requirements.
Having these would help engineers find the position they are actually looking for, most Full Stacks I know complain either because Full Stack positions on LinkedIn or any other platform require cloud services understanding, like what a platform eng would do, or because the work is mainly frontend with some crud endpoints like the product eng would do.
Where do you fit in all of this?
You might be thinking that mastering every area of web development is overwhelming – too much to learn for a job that might just need you to sping up some new crud UI, or craft a few endpoints. But I believe we should all aim higher. Strive to be a more well-rounded software engineer and view software development as the versatile tool it is.
Don’t get too attached to a single framework, language, or a role that’s only partially defined by your current job. Instead, dive into the vast world of web development. Familiarize yourself with the wide array of tools out there. This knowledge will empower you to find the best solutions for any problem you face.
Playing devil’s advocate, though, it’s true that we can’t learn every technology, framework, and language out there. And yes, some tools are better than others for certain tasks. So, it’s crucial to navigate this landscape with care. But don’t get trapped down in too much research. Instead, experiment, build things, and gain new perspectives. And if you can, share your experiences and discoveries. It’s always beneficial to share the technologies you’ve explored and the lessons you’ve learned.
The rise of “meta-frameworks” is changing the game. They offer a playground that blurs the lines between frontend and backend, pushing us to understand how the web works as a whole. If you haven’t yet branched out into new areas, now’s a great time to start and fill those gaps in your knowledge.
For those just starting in web development, this might seem challenging and intimidating. It’s totally fine to begin with frontend work and gradually move towards backend, system design, cloud technologies, and beyond. Tackle them in whatever order makes sense for you or adds value to your work. Remember, every step forward is progress.
Final Words
I knew for a while about these different roles, but they didn’t really click for me until recently. I got this great opportunity at Drata to join the Platform team. We’ve been building internal tools that help developers work locally and manage deployment operations. Plus, I’ve had a hand in developing an internal framework for the rest of the company. It’s been a blast – seriously, I can’t remember the last time I had this much fun coding and thinking about the system as a whole.
At the end of the day, every role is crucial, and there’s a lot of work that needs to get done. Whatever you bring to the table can have a positive impact on the project.
I’m sharing this in the hopes that it offers some insight into the direction you might want to take. For me, it’s tough to pick a favorite role. I love being involved in the entire software development process – from the user experience to the nitty-gritty of system communication, data storage, and ensuring the system’s reliability and scalability. It’s all about tying everything together to create an amazing experience.
So, what about you? What kind of problems are you itching to solve? Which technologies get you excited? Think about how expanding your knowledge could impact your current project and your team.
Consider how you want to navigate this constantly evolving field. Position yourself to tackle big, challenging problems. Happy Coding!