On The Contrary
Transcript of my Q&A with Seth Kimmel of Contrary Capital
For Today’s Q&A, we have Ron Pragides.Ron is currently the VP of Engineering at Trustly. Previously he was an engineering lead at Carta, AppDirect, BigCommerce, Twitter, and Salesforce, as well as an advisor to many startups.
Welcome!
I like to get a sense of how people got to where they are today.
Can you tell us a bit about your path growing up, why you decided to study what you did in college, and how you eventually got into software?
I was born in Chicago and grew up in a town that has the largest number of Frank Lloyd Wright designed structures — a fact that I didn’t appreciate until after I moved away.
I was always interested in math & science. My first computer was a TI99/4A and first programmed on it in BASIC trying to create games that mimicked what I enjoyed playing on the Atari 2600. The only storage capability was an external tape recorder accessed by standard audio connections.
In high school, I operated an online bulletin-board system (BBS) on an Apple IIe with 128k RAM, 3 floppy drives, a RAMDisk, and a 2400 bps modem — which of course needed its own phone line. I loved interacting with people online.
This was the early days of computing when “hard drives” were relatively new, large, and expensive (a 10MB hard drive cost $1000).
So not really a surprise that I majored in Electrical Engineering at @ECEILLINOIS @UofIllinois — which gave me exposure to all things related to circuits, logic, and programming. I really enjoyed Digital Signal Processing (DSP) and had ambitions to apply that to Digital Imaging.
My first job after graduation was at @TXInstruments in their Defense Systems & Electronics Group. I wasn’t fulfilled in that role so I searched internally for a project that was a better fit.
I learned of a skunkworks R&D group called Digital Imaging Venture Projects (DIVP). I found out the name of the SVP leading that group and sent him a message saying that I was interested in Image Processing and that I thought I’d be a great fit.
That brazen outreach led to internal interviews and transferring groups within my first year out of college. Eventually the group was renamed Digital Light Processing (DLP). My responsibilities included writing VHDL to program digital circuits into FPGAs, writing embedded firmware for real-time video & graphics processing, board-level hardware design, and system integration.
What I learned from that tour of duty was: I found the software engineering (VHDL, embedded firmware) much more gratifying and iterative than hardware engineering (fabricating boards, soldering components, testing electronics).
That convinced me to “move up the stack”.
I relocated to the San Francisco Bay Area to work for Sun Microsystems in their High-Performance Graphics Division. I had started an MSEE program at @utarlington, and finished with transfer credits from @Stanford.
Fun Fact: that Sun campus is now the HQ for @Meta (née Facebook).
Another Fun Fact: I joined Sun the same year we introduced @java to the world.
You moved to the Bay Area/SV in the mid 1990’s. How has it changed since then, and what are your thoughts on the debate of whether it will remain the epicenter of technology going forward?
When I arrived in the Bay Area, all of the tech jobs were in Silicon Valley. There wasn’t really a tech scene in SF.
I chose to live in San Francisco to be in an urban setting, which meant I had to commute to Silicon Valley (first Menlo Park, then Sunnyvale) on a daily basis. At the time, nearly all of the successful tech companies were hardware-related. The tendency was for large corporate complexes where hardware testing and bring-up could occur.
With the “Dot Com Boom” in 1999, software-based Internet business were dominant. SF was ground zero. Suddenly all of the techies that wanted to live in SF could actually work there as well. I joined an e-commerce start-up called Della & James that eventually merged with its largest rival to become @WeddingChannel.
Hubris was everywhere. Sock puppets appeared in Super Bowl ads.
Then the bubble burst. Startups were folding.
My company decided to shutter its SF office and concentrate everyone in LA. I declined the offer to move and remained in SF to ride out the storm.
There was a massive exodus. No traffic on the US-101. Things looked bleak for tech. After a year, the tech industry in the Bay Area came roaring back. That was one instance when people questioned the area’s resiliency.
There are smart technologists all over the planet, and other areas have been trying to topple the SF Bay Area’s dominance for years.
Crafting great wine starts with terroir: the combination of climate, soil, and slope.
The SF Bay Area terroir consists of: great local universities, tech companies to learn & hire from, network of investors, other trades required for startup formation, entrepreneur culture.
- UNIVERSITIES: UC Berkeley, Stanford University
- TECH GIANTS: @Apple, @Google, Meta, @netflix
- INVESTORS: From Individual Angels to @a16z
Silicon Valley will always be a destination for technologists. Like Broadway for Live Theater, or Hollywood for the Film Industry.
Who were your most impactful mentors early in your career? What did they teach you?
I’ll answer this slightly differently.Who are people that I learned the most from early in my career (either patterns, or anti-patterns):
- My first manager ever: Leticia Benavides at @TXInstruments. She was very supportive, pairing me with senior engineers to learn from, giving me challenging projects, and allowing me to pursue other projects in the company. She showed me good management.
- Individuals who stayed at the same company for decades not because they loved their job, but because they were: no longer curious or learning new things, not challenged on the job, complacent doing the same thing, every day. I knew that was NOT what I wanted for myself.
- [Unnamed] Top Architect who legitimately was a genius but: reminded you he was the smartest person in the room, micromanaged people in his org, told people in other orgs how to do their job. That showed me the type of leader I never want to be.
You’ve seen several decades of changes in the way that software is built at scale.
What methods have stood the test of time, and what new developments have made you the most excited?
In my career:
- I’ve only worked at two companies that were large and public at the time I joined.
- All of the other companies I joined were privately-held startups (or scale-ups) at the time I joined.
My perspective on building software is tied to building companies. Building software at a Startup (depending on how early) should be the essence of what became the @ycombinator motto:
MAKE SOMETHING PEOPLE WANT
And at the start that means: Don’t over design, Don’t optimize prematurely, Deliver iteratively, Incorporate User Feedback.
Building Software at Scale only happens after achieving Product-Market Fit.
Build a better mousetrap, and the world will beat a path to your door.
Which I’ve seen a few times, and generally that means the code: starts as a monolith, has tech debt, needs to be optimized.
And so the tasks become: growing the Engineering team, refactoring the code, breaking-up the monolith (carefully), analyzing performance, ensuring you can scale horizontally.
Of course AWS, GCP, Azure have made a huge impact of the ability to quickly scale. But I’ll try to be technology and platform agnostic and stick to strategies that help with scale, in no particular order: test automation, infrastructure as code, typesafe languages, query optimization, leveraging Open Source, feature flags, queuing, caching.
My perspective comes from “scaling teams” in service of “scaling software”.
For scaling software:
- avoid Single Points-of-Failure (SPOFs)
- measure & reduce stress across all components
The same is true for scaling teams.
How have you managed to stay highly effective in leading engineering teams in a remote-first capacity? What are the pros and cons? Do you think it’s better or worse overall?
I’ve led geographically distributed teams across multiple countries: Argentina, Australia, Brazil, Canada, India, and Portugal.
That’s in addition to distributed U.S. teams in: Austin, Boulder, Los Angeles, New York, Palo Alto, Salt Lake City, Seattle, San Francisco.
Most of that experience has been with teams in clusters around offices.
But the issues are the same with respect to:
- managing timezones
- defining autonomous teams
- providing clear sense of ownership
- aligning with priorities
- keeping everyone well-informed
Clear communication and rapid decision making are crucial for productive teams. Co-location is the most efficient way to achieve both.
Distributed teams can approximate this with “timezone alignment” — think of teams in timezones, not offices.
“Cultural awareness” is also key. People in different cities (or countries) have their own context and values. Generally people in Sydney, SF, and Stockholm have different communication styles. The same is true for people in Mumbai vs. Montréal. That’s why companies define Values for all employees to align to.
As a result of COVID-19, tech companies have embraced “remote-first” — which is an extreme version of geographically distributed teams.
We’re relying even more on collaboration tools to keep our teams aligned, informed, and inspired.
Nothing connects people better than in-person contact. But that doesn’t have to happen every day. Companies can augment “remote-first” daily operations with occasional team gatherings to build camaraderie.
At @Trustly we’ve held in-person gatherings in Napa, Lisbon, and Vitória.
Although I’m normally based in the SF Bay Area, this week I’m in Brazil visiting with members of the team. It’s the first time I’ve met some of them in-person.
Tech talent exists all over the planet. More companies now recognize this, and are tapping into the global talent pool.
Last question: who are three people I should consider interviewing next?
