The Python Platform Startup: Building From the Ground Up

A little over a year ago, I found myself taking on a unique and exciting opportunity: Building a Python Platform team from the ground up. Despite its size, Wayfair gives teams a large degree of autonomy in deciding how they operate, which meant we had a true blank slate to start with. Most of my experience has been on product-oriented teams, and this was my first time leading a platform team with purely internal customers.  I want to share that journey with you, but first let me give some context around why we needed this team in the first place.

Python was first introduced at Wayfair in 2011 as a way to provide product recommendations within the Storefront experience. Over the years, Python's footprint grew to include automation and tooling, Data Science, distributed systems, and multiple web services running at impressive scale.

The infrastructure for running Python in development and production environments, along with the shared internal libraries, were largely contributed and maintained by volunteer efforts from multiple teams. While everyone involved was extremely supportive and generous with their contributions, the size and scale of Python needed a dedicated team to iterate and own the infrastructure. We needed a team that could offer guidance to Wayfair’s Python Engineering community.

When the Python Platform team was formed, we had over 100 people writing Python, spread across more than 15 distinct teams. Our task? To figure out what our best opportunities were for improving the quality of our Python systems and to maximize the effectiveness of those who contribute software to it.

How to Turn a Blank Slate into a Team

Blank slates can be exhilarating, and I believe it's a part of what draws people to the startup ecosystem – even when faced with statistically high failure rates. It's exactly what we were faced with at the team’s inception. To start with, we needed to address the following:

• How do we deliver value to our customers quickly?
• How do we structure our own processes?
• How do we build an overwhelming sense of clarity on our team’s purpose?

All of these have to be decided when you're starting from scratch, and subtle decisions can define what your team grows into, how it’s culture is formed, and possibly, the team’s success. This is why we wanted to be very deliberate with our initial approach.

We opted to leverage the startup experience the team had, and essentially run the team as such. We adopted a mindset that our team was running on borrowed time, trying to find product market fit, provide immense value to our customers, and gain sufficient traction to flourish.

We made a point to create and document three important things from the onset which would give clarity on the team’s purpose and culture:

• A single overarching purpose for the team
• Strategic pillars to define distinct areas of focus for realizing our vision
• Core values to guide how we work and engage each other, as well as our customers

To start, we iterated on a few mission statements, and the underlying theme to all of them is as follows: Make Python at Wayfair incredibly accessible, low effort, and high output.

This aligns well with Python’s strengths as a language with low barriers to entry and a focus on developer effectiveness. Achieving this goal translates to improved velocity for the teams we support.

While the vision establishes a common point of convergence for our efforts, it doesn’t do much to help determine what we do to get there, which is precisely the role of our strategic pillars. We have three of them, and each one represents a distinct area for us to focus on.

• Create intuitive and accessible self-service infrastructure
• Partner with engineering teams to increase their velocity and build a lasting culture of quality
• Grow a community focused on knowledge sharing, support, and excellence

Finally came the core values. We documented them and agreed to hold them sacred. These values will be tested over time, and we want everyone on the team to keep each other accountable to upholding them:

• Take the time to make it intuitive
• Be valuable without being a dependency
• Embrace your beginner’s mind
• Have strong opinions weakly held

So far, this was all fairly straightforward, but then we hit a snag. How would we measure our success or lack thereof? If we were a real startup, our customers would only pay for what we were selling if it was sufficiently valuable to them. Here, all our customers have limited choices. We essentially have a monopoly on their workflows and tools, making it extra challenging to know when we’re on the right track.

Finding our Revenue Equivalent

Revenue is an exceptional feedback loop because it lets you know when you’re delivering the right kind of value to your audience, which is indicated by them paying for it. For our internal team, this is a brutally honest feedback loop which we will never have access to.

Since no one pays for our services, it makes it significantly more challenging to know when we’re straying off the good path – generally, there’s no competitors coming to eat our lunch if we get complacent. For our platform team, the result of this isn’t (at least in the short term) a dissolution of our team, but it’s equally as disastrous: We would become an Ivory Tower, pontificating on "what ought to be", solving the wrong problems, and potentially failing to deliver actual value.

To supplement the lack of the reality check we get from revenue, we approached this in a few different ways:

• Embed with teams. Feel the pains we’re trying to solve first hand, and let emergent opportunities from those experiences drive at least 20% of our efforts. Make sure we’re “eating our own dogfood”. We aim to use the same tools, workflows, and systems as our customers. When something sucks, we want to feel it too.
• Constantly solicit feedback. Welcome critical feedback in particular. There’s a real benefit to having our customers accessible via Slack, and we absolutely leverage that. We engage them 1-on-1 over coffee, attend their meetings, and generally try to maintain an open and transparent relationship. We recognize that many engineers won’t feel comfortable voicing their concerns, and sometimes need extra encouragement to do so.
• Measure everything we can. We look for proxies for the economic impact of our work. For example, we may measure how often a particular system is used, and know that each time it’s used it saves someone 30 minutes of work. Combine that with a bit of hand-waving, and we can back into an approximate dollar value that system provides.

This has helped us identify many opportunities for improvement, and equally as important, has also given us the confidence to under-invest or ignore certain issues where the return doesn’t justify the investment.

Transactional and Recurring Value

Not all revenue is the same. Transactional revenue is when you spend a comparably small amount of effort on acquiring a single, one-time sale. Recurring revenue generally requires a larger upfront investment but a single sale continues to bring revenue in the door at regular intervals, and hopefully for a long time.

We talk about this a lot on the Python Platform team but in terms of value rather than revenue. Our team is fairly small compared to the number of people we support, and this means we need to be very deliberate about where we invest our own efforts.

To illustrate this point, here are some examples of transactional vs recurring value approaches to situations we’ve encountered:

If we spend too much effort producing transactional value, we’ll never be able to scale effectively. On the flip side, over-investing in long-term initiatives (e.g. automation systems that produce recurring value every time they’re used) runs the risk of taking too long to deliver value by not solving certain immediate problems quickly. We believe the right mix is a delicate balance of the two.

One thing we like to make sure we keep in mind: Transactional value generally translates to helping individuals, which simply “feels good”. It is a fundamentally rewarding experience at a very human level, and if you’re not careful it will suck up a very large percentage of your time. One example we caught ourselves in was answering similar questions multiple times, a very manual process, instead of writing documentation and linking people to it, making it easily discoverable by those in need of help.

Finding the right balance of transactional and recurring value investments has allowed our new team to provide immediate value in its first few months. This all took place while we were simultaneously investing in the long term projects that would be critical for scaling the team.

Next Steps

At the time of writing, we're 1.5 years into the team’s existence, and it's been an incredible journey so far! We're still learning and iterating on many aspects of our team, and making plenty of changes as we go – I'd be concerned if we weren't.

Adopting a startup mindset has positively shaped our platform team's focus, execution, and culture. If you are on an infrastructure team or leading one, I would strongly encourage you to introspect on this:

• Do you have clarity on your team’s mission, strategic pillars, and values? Does everyone understand how the success of that mission helps the entire organization succeed?
• Do you have a way of knowing if you’re delivering the right kind of value to your customers? Would your team survive if it were a literal startup within the organization?
• Do you know if you’re striking the right balance between transactional and recurring value? Are you falling victim to the deceptively rewarding Transactional Value Trap?
• Do you have the right mechanisms in place to measure the value you provide?

And of course, if you are a Senior Pythonista, and any of this sounds intriguing, we would love to chat! We are always hiring people who get excited about these things.