Learning from Giants #14
Marty Cagan's Product vs. Feature Teams, Introduction to columnar storage, Reference checks when hiring, The unbundling of React state management, and Shopify's Oxygen platform.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
Product vs. Feature Teams
It is common for most product teams, or squads, to consider themselves product teams once they get rid of scrum, product owners, and infinite backlogs.
But in reality, they're falling into the next trap waiting for them, and become feature teams.
"In the tech world, there are really three distinct types of, loosely speaking, "product teams." Delivery teams, feature teams, and product teams."
If you're still doing scrum, this article may not (yet) be for you; otherwise, read on 👇.
"While feature teams and product teams look very similar on the surface, they are dramatically different in how they operate, the level of empowerment and accountability, and especially the responsibilities of the product manager."
📗 Marty Cagan's Product vs. Feature Teams is a bit extreme in wording, but it gives a much-needed vision of an ideal product team. I would advise taking it as it is: a vision towards which most teams in product-led companies should all be moving. Some are closer than others, but wherever you are on the scale, it makes an excellent point: you're probably still a little feature-team-like.
The design and implementation of modern column-oriented database systems
Have you ever wondered why some queries take 30 seconds on your MySQL instance and 0.1s on BigQuery, Redshift, or Snowflake? Columnar Storage.
“Column stores are relational databases that store data by column rather than by row.”
“The column-oriented layout makes it efficient to read just the columns you need for a query, without pulling in lots of redundant data.”
Emphasis on “some” queries. Columnar storage is optimized for analytics queries, like a statistical aggregation of a large part of your database.
It achieves such performance by doing aggressive tradeoffs that transactional databases can’t do. For instance, random row reads and writes are extremely inefficient on column stores. Moreover, like row stores, there’s much more to the performance of columnar storage than its data layout:
“Simply storing data in columns isn’t sufficient to get the full performance out of column-based stores. [...] But by the time you add in a number of the optimisations we’re about to discuss, it ends up about 5x faster than the row store.” (Note: on a specific benchmark).
📗 Adrian Colyer’s summary of the 2012 paper The design and implementation of modern column-oriented database systems is an excellent introduction to column stores that reads a lot quicker than the 90-page paper that it summarizes. The author describes the main performance optimizations that make columnar storage the go-to solution for analytics workloads. I/O is reduced with compression and maximized sequential reads, and CPU through vectorized execution and other computation optimizations.
The complete guide to checking references
“Reference checking isn’t optional; it can save you from making a big mistake.”
I’ve heard hundreds of bad excuses for not doing reference checks, from the tense hiring market to saying they’re useless because the chance of rejecting the candidate is minimal.
But to me, reference checks are like very cheap insurance. Most of the time, you’re paying for nothing, but it can save you that one time.
1. Reference checks help detect jerks
▶︎ “Good interview questions [...] can miss a certain class of smooth-talkers – people who can bluff their way a question about conflict resolution but in reality behave like a jerk. Reference checks are how you catch this kind of smooth-talking, competent jerk.”
2. Reference checks give valuable information on the candidate that can lead to clarification or discussions.
3. When none of the above applies, you will still get context.
“In the best case, reference checks can turn up some additional context that can help you become a better manager for this person more quickly.”
📗 Jacob Kaplan-Moss’s Checking References is a series of posts that explains the value of such an interview step and dissects how to get the most value out of references. If you’re hiring, I don’t think you’ll find a better article on the topic.
The Unbundling of React State Management
If you have ever touched React, you've probably heard of Redux.
"Redux was originally created as an implementation of the "Flux Architecture", which was a pattern first suggested by Facebook in 2014. Redux came out in 2015 and quickly became the most popular of many Flux-inspired libraries."
Redux was built as the catch-all solution for front-end state management. As the ecosystem matured, alternatives appeared, and the catch-all solution started to show limits.
1. It became clearer what problems state management had to solve.
Routing state
Application data state
UI state
Form state
2. For each of these problems, multiple specialized state management libraries appeared and became popular.
3. Some private Redux dependencies like the Context API became public and enabled to build moderately complex state management without third-party libs.
📗 Lee Robinson's Past, Present, and Future of React State Management could hardly qualify as timeless considering how fast the React ecosystem moves from one tool to the other. Still, history can teach us a lot about the present and the future, which is why that article is a must-read.
"Having complex state doesn't necessarily mean you have to pull for a third-party library. You can start with React and JavaScript and see how far it takes you. If optimizing requires a state management library, you can track that metric (e.g. frame rate), measure it, and verify it solves a real problem."
How Shopify built a serverless storefront hosting platform
Oxygen is Shopify’s latest server-side rendered storefront hosting platform. It was built in-house to make deploying such a Shopify-native storefront fast, frictionless, and secure.
“Oxygen guarantees fast and globally available storefronts that securely integrate with the Shopify ecosystem while eliminating additional costs of setting up third-party hosting tools.”
The first question the team faced was whether to build or buy the core hosting product.
“We could leverage over a decade’s experience at Shopify in building infrastructure solutions that keep the entire Shopify platform up and running to build an infrastructure layer, control plane, and proprietary V8 isolates.”
Yet they didn’t.
Instead, Oxygen is based on Cloudflare’s Workers for Platforms product, a programmatic edge computing service to deploy the merchants’ custom storefronts. This accelerated their time-to-market, reduced their costs, and opened a world of possibilities for the future of Oxygen.
📗 Shopify’s How We Built Oxygen is the story of how a small team leveraged Cloudflare Workers to architecture this global rendering and hosting solution. My takeaway is that you don’t need Shopify’s 2000 software engineers to build Oxygen, but you need to have an open mind and be constantly on the lookout for 10x technology.