Part I, Part II, Part III. This part covers my time at Square, which I also wrote a retrospective about. Bold sentences indicate learnings or insights gleaned.
Start with the Unscalable
Y Combinator famously gives this advice: work on things that don’t scale, to force a better experience by understanding the target user better than any existing solution, while allowing for fast failure without a ton of up-front investment.
Square’s initial business certainly followed this to a degree, in that nobody really wanted anything to do with payments processing for small businesses due to the low volumes and high user acquisition cost1. It also applied some of the playbook ascribed to classical disruptive innovation theory, in that Square eventually targeted bigger customers and fleshed out the rest of its software suite.
I joined the company in the middle of 2011, when the initial software and app were built to process payments, and the company was putting its focus on productionizing the hardware reader by streamlining the manufacturing process2. Even in those early days, Square’s culture and emphasis on design was apparent in everything from the user experience to the office space, and that made a strong impression on me just as a part of the interview process. It’s cliche, but a company’s work environment reflects its cultural values, and I’ve used that as a nuanced signal for job opportunities ever since.
Between Agility and Quality
Strangely enough, Square was the first workplace in my experience at which had to find—and continually adjust—the balance between moving quickly and maintaining a high quality bar. At mature companies like FactSet and Google, adhering to best practices was always expected because there was little time pressure, and they could afford to move slowly. In contrast, at early-stage startups, there was little emphasis on code quality; we first scrambled for product-market fit, then scrambled again for growth in the face of fierce competition, which prized speed above all else.
Square’s early hires were ex-Apple, ex-Pivotal Labs engineers. The Apple ancestry ensured a well-designed end-user experience, and the Pivotal folks supplied some initial engineering tentpoles in the form of Ruby on Rails and pair programming. Over the years, systems got rewritten and isolated, and pair programming fell out of style; the balance tilted towards quality and stability as the codebase and userbase grew. It’s again obvious in retrospect, but scaling engineering systems for additional committers necessarily entails adding and modifying processes to slow down development.
The corollary here is that rapidly-growing companies actually do change how they work and that some employees aren’t going to want to stay through the entirety of that journey. A former manager of mine framed it well: As companies scale, its people have to scale along as well, and it’s alright if those who do not or cannot scale as quickly amicably part ways. There are plenty of ex-Squares who I respect who felt like 300+ people was too big for them, and others who are still there now—among 2000+ employees—who have continued to grow themselves with the company.
Square Dashboard
My legacy at Square will always be the merchant dashboard, or the Square Dashboard product. It started out as just an engineering exercise to decouple the web front end3 from the Rails backend, but we eventually added analytics, additional settings, and Square Market (now called the Online Store). By the time Square decided to augment the core payments processing business with software services for small businesses, the Dashboard became a platform for rendering the front end for most of those tools: Receipts, Invoices, Inventory, CRM, Payroll, Capital, Appointments, plus a bunch of others which have evolved since those days.
That said, building on a tech stack outside of an organization’s core competency is a huge challenge. It’s a natural corollary of the observation I had earlier about engineers at Google, applied to technologies: teams will naturally hire folks who are good at what they’re good at, and so the first couple of hires sets the technical direction and thus becomes the team’s core competency. Deviation—even if it’s the right thing to do for the product— is possible given enough time and effort, but pretty painful along the way; it’s what makes Facebook’s pivot into mobile so impressive, when the norm is more like Yahoo’s failed attempts to make the same move.
Square started as a mobile-only company via the card reader and app, and so that was lead platform, particularly when we had a tiny number of web-centric engineers4. It seems silly now, but a couple of releases saw us try really hard to cram complicated settings and toggles within a mobile interface first, and then try to turn around and replicate the tortured set of fields within Dashboard. Eventually, we wised up to the idea that this was already a solved problem: people were organizing themselves via spreadsheets, and it was much more efficient for both the merchants and our product team to just import the data format.
The Right Business Model
I forget where I read the analysis, but a tech blogger quipped recently that Square, after 2 years as a public company, is now finally understood as a B2B business masquerading as a B2C enterprise, with a valuation that better reflects that business model. It took years to convince the public markets of this reality; it took even longer to work through this internally while we were a private upstart.
Strangely enough, we had hit upon this notion in the early days: an executive had stated that the card reader amounted to a sophisticated user acquisition tool, one that grew our userbase and transactions volume + data while amplifying the Square brand. It obviously worked and got us some massive rounds of funding, but its success also gave us enough runway to make multiple attempts at consumer products which struggled to find product-market fit. I remember having a discussion with Jack specifically around the role of merchants and consumers, and ending up more confused by his description of the role and possible overlap between each user type5.
Eventually, we did end up refocusing on the right path by really building out—in parallel—a suite of small-business-centric merchant tools. It’s one of those cases where our merchants were telling us exactly what they needed, but we ignored the feedback for years to continue to chase that sexy, elusive consumer product. That said, that drive to reach end-consumers continues on to this day, but they take the form of more sustainable products in Square Cash and Caviar, and both better realize the advantage Square has in its merchant relationships.
Part V
I stayed at Square for 4.5 years, easily my longest tenure at a company and one filled with many career highlights. With my wife’s encouragement, I next went into the healthtech industry, eager to understand its problems and how technology plays—or doesn’t play—a role in its solutions.
Not to mention high rates of churn for certain categories of small businesses which themselves don’t survive; restaurants, for instance, are notoriously short-lived.↩
The first readers were hand-built and tested by early Squares.↩
Back then it was conceived as a web app counterpart to the Register app, hence I was the inaugural member of the Register Web team.↩
I was the 2nd front-end engineering hire, and I wasn’t really interviewed for that role.↩
E.g., small business merchants can also be prolific spenders.↩
