“What Do You Think of Our Platform?”

Organizations come to Postlight with all sorts of needs — sometimes the software they’d like us to build is the fleeting edge of an idea, and sometimes they have a fully built-out platform that requires a critical eye. In this latter case, we ask our engineering leaders to take a hard look at all the code, infrastructure, and team dynamics, then report back with what they’ve found. This isn’t an easy task! 

Postlight partners with some very large organizations, and the platforms they author can be gigantic: millions of lines of code, hundreds of services, and all the cruft and band-aids that tend to emerge when software is maintained over long stretches. We’d like to share an overview of how we go about generating a holistic evaluation of large, entrenched platforms.

Start with the org structure

This may seem nonintuitive, but we don’t start with the code. Instead, we take a hard look at the teams and structures that make up the organization, which have a huge impact on how software is produced. Some organizations are structured in cross-functional squads, while others have teams focused on specific vertical areas, like frontend engineering or cloud infrastructure. Both models (and others) can work — our evaluation and advice tends to focus on how effectively these teams are operating. Do they have a clear roadmap, goals, and a reputation for delivering? How do teams interact and cross-pollinate? When you consider the organization as a whole, is there clear alignment on what matters most for the business? If an organization is facing bottlenecks or missed opportunities, we usually have a hint as to why. 

With some thoughtful changes, we typically start to see improvements immediately and help shift things in a positive direction. As a picture forms around how work is being done, we get our first lens into how the software is built and maintained. 

Identify immediate fixes

With a picture of the organization established, we start to look at the core of why we’re here: the software. Successful software companies usually have specific areas in which they excel, or specific products that drive most of their business. Starting with the most important areas, we take a look at the state of the platform. 

We look at many areas: architecture, infrastructure, languages, performance, cost, and much more. We strive for finding pragmatic improvements to problems. Is there a performance issue with a service that’s affecting the overall experience? We’ll identify what changes can be made that show a positive impact immediately. Throwing it all out typically isn’t the answer. We always look for changes that are smaller in scope but show a significant impact. Is your AWS bill three times what it should be? We’ll formulate a plan for reducing costs and keeping it that way. Every client has different needs, and we focus on the areas that are the most important for moving the needle.

Uncover hidden issues

Once these immediate fixes have been identified, it’s easier to uncover larger, structural issues that obvious pain points might have been obscuring. For example, let’s say we brought down the AWS bill to a reasonable level — and in doing so learned that some fundamental technical decisions have led to bottlenecks in the database, and engineers patched over this by scaling up RDS whenever a bottleneck was reached. Let’s reimagine the database implementation to ameliorate these issues. The same goes for solving team and process issues: Teams often form around patterns of reaction that point toward structural problems. Maybe a team doesn’t launch new code on Fridays because their CI/CD pipeline is unreliable and no one wants to work a weekend. We’ve identified a core issue — let’s address it.

Tackle specific architectural issues

When it comes to technical architecture, engineering teams have to make many decisions. What programming language or framework should we build our organization around? Monolith or microservices? There are many foundational decisions that teams make, and for established production software, changing these choices can be difficult or near impossible. It’s easy for teams to fall into the trap of thinking, “If only we could start over, we would do it differently,” but that tends to lead to large projects or rewrites that are hard to scope and make successful. 

An organization biting off a multiyear rewrite is risky. What’s typically better is to think through specific architectural issues and find solutions. If your frontend application is exhibiting poor performance, Postlight’s team may propose 10 changes that would immediately show value. If backend services are designed in a way that don’t scale well or are tightly coupled, we may suggest making improvements on one service and rolling it out in a predictable way.

There are many other areas that organizations care about. Depending on the client, we’ll look into areas like security, compliance, and reliability. In the end, Postlight is here to help clients make positive changes and not wait years to do it. We’re oriented around velocity and iteration, rather than big-bang changes. We’ve seen a lot of success with this model, and the door is always open if you have a problem you’d like to solve.

Kevin Barrett (he/him) is a Partner in Engineering at Postlight. Aaron Ortbals is a Managing Partner and Head of Engineering at Postlight. Want to talk about your platform? Reach out at hello@postlight.com.