Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
45
I am drafting this post at 35,000 feet flying back from Japan. I’ve entered the US about 30 times, but this will be the first time I’ll be using my shiny blue passport. No anxiety about aggressive questions, secondary inspection, or the possibility of deportation. A couple of days ago, my wife had her naturalization ceremony, and with her, our whole family is now American. This post is a reflecting on our 11-year immigration journey. My American Dream My story with technology started at 8, with my first computer. I fell in love and decided that one day I would start a computer business. And of course, it would have to be in Silicon Valley, the epicenter of innovation. I grew up influenced by the iconic Californian lifestyle of the 90s, from Tony Hawk to bands like Blink-182 and The Offspring, which only fueled my desire to call the West Coast home. As I finished my Computer Science studies, the reality of achieving my American dream seemed increasingly distant. My enthusiasm for the...
a year ago

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from Miguel Carranza

My role as a founder CTO: Year Seven

2024 has come and gone, and it’s time for my annual post. What a year for startups—like squeezing five regular years into one. Do you remember the Apple Vision Pro, the DMA regulation, founder mode, or the o1 launch? All of that happened in just the last twelve months. It’s also been wild at RevenueCat. My journal is full of stories that could fill a whole book or even a few HBO Silicon Valley seasons. Some are inspiring, some are hilarious, and others are honestly gnarly. Due to limited space, the need for context, and respecting everyone’s privacy, I’ll cover only the most interesting topics at a high level. Looking back, it was a good year for RevenueCat. Actually, a great one. Perhaps our best since 2020. We have plenty to celebrate: We accelerated again, and we hit our C10 revenue plan. We made our first acquisition and welcomed an amazing founder to the team. We signed our first multi-million-dollar contracts. We went to more than 20 events around the world… …including hosting our own conference, featuring its own award ceremony. We became the #1 payments SDK on iOS. Our swag went to 11. We launched over 80 user-facing features. We showed up in Times Square and along Highway 101. We raised a mini Series C and welcomed two new board members. We landed in Japan for the first time. Our API grew beyond 2B requests per day. We are processing nearly twice the TAM we had when we started the company. OpenAI is a friend of the cat. We continued building a winning team. We hired people who were on my to work with bucket list even before we started the company. By all the metrics, 2024 was our year of shipping and selling. We absolutely helped developers make more money. My role If you compare our progress to the goals I wrote about in last year’s blog post, it’s clear we succeeded. But the journey itself was a lot rockier than I had imagined. Many things didn’t go as planned, somes hires did not work out, and some strategy changes were really hard to push through. At the start of the year, besides my usual responsibilities, I also set four personal goals to help me scale with the company. I wanted to: Ship code more consistently. Talk to at least one customer every single day. Get more involved in areas outside of engineering. Stay very close to my co-founder Jacob, giving him my full support. I completely missed goal #1. Honestly, that hurts because I love building software. But I’m not too upset about it—our customers care that the team ships, not that I personally do. And in a way, I did help the team ship. As for the other three goals, I hit them, at least based on the company’s results. Still, my self-perception wasn’t always great. I found myself acting much more like a co-founder/executive than a CTO. Some weeks were brutal, with constant context switching across tasks and teams I didn’t always enjoy. At one point, there were over 60 people in my org, spread all around the world, which is pretty intense for an introverted computer kid. A lot of bullshit escalates to the top, making me question my entire existence some days. And then life threw serious personal emergencies at some of our team members too. Like I said last year, life is what happens when you’re busy building your startup. As we got closer to 100 people, it was statistically unavoidable that we’d face a few life-changing traumas—sometimes several all at once. As a founder, you need to be supportive and empathetic, but also protect your mental health. As a human, it’s tough. Add in a couple of two-year-olds who were often sick and not sleeping, and it felt like a ticking bomb. Did I burn out for the first time in my life? I don’t think so, but it got close. I’m confident being a founder (and having a co-founder) kept me going. I care too much and must stay resilient. If I’d been just an employee, I might have tapped out. But enough about the tough parts. Aside from being a professional BS handler, here’s how I spent most of my time: Lots of travel This was the year I traveled the most in my life—and looking back, I probably should have traveled even more. I visited customers, helped with sales, conducted executive interviews, and spoke at a few conferences. It’s hard being away from two little kids, but each trip turned out to be worth it. Support One of my biggest worries this year was our support function. Everything was fine, but our Support Engineering Manager was going on parental leave, and the bus factor was scary. I’ve seen support crises before—they’re not fun. It wouldn’t have killed the company, but at our size, it might have forced us to pull senior engineers into support and slow down our product velocity. Time was short, so we tried a few things that worked: We hired two new Developer Support Engineers who already knew our product—former customers! Their onboarding was smooth, and they hit the ground running. We split the support team into two pods with their own leads. Each pod handles certain tickets, and they collaborate with each other instead of relying too heavily on one person. We finally set up our first on-call rotation for emergencies. Sales and post-sales Reviewing sales and implementation calls, giving technical input, collecting enterprise customer feedback for product and engineering, joining calls, and even doing some in-person visits. Writing more As our team continues to grow across the globe, not everyone has the same direct interaction with me or Jacob as before. A lot of our culture and collaboration style was once passed through observation, but now needs to be written down to reach everyone faster. These days, my code editor is basically replaced by Google Docs. I’ve been publishing more internal and external documents—like our Engineering Strategy and an updated How to Work with Miguel. Product delivery We still have a few details to refine, but our founder Shipping and Timeline reviews have been valuable. It gives Jacob and me a high-level view of everything in progress, lets us offer feedback, and helps us dig deeper where needed. It’s a great way to see each team’s capacity, find bottlenecks, keep a sense of urgency, and deflate anything that’s not truly important for the customers. Re-orgs This year brought a couple of big reorgs in product and engineering. Overall, they went well, but the puzzle gets more complex with each new piece. We created sub-teams to narrow their focus and keep things running smoothly. For the first time, we had a couple of management layers between me and our ICs. One major change was shutting down our Enterprise/Reactive team. The idea was solid at first, and they delivered plenty of value, but eventually they became the random tasks team. Our new plan is to reinforce the rest of the teams: quick enterprise requests go to the right team to handle them reactively, while bigger projects move to the main roadmap (which keeps us disciplined). The engineers from that old team will help bootstrap new teams as we hire in 2025. Hiring Our engineering hiring goals weren’t super ambitious, but we still reached them. The pace was a bit uneven, and some roles took longer to fill than desired. However, when Hiring Managers took ownership of the process (with recruiting as a support) it made a huge difference in the quality of our candidates. We also brought back the founder interview stage: Jacob or I spoke with every single candidate before making an offer, and we plan to keep doing this for the foreseeable future. Random founder stuff Not my main focus, but I still spent a fair amount of time handling people-related topics, operations, investor, customers and partners relations, fundraising, company policies, planning, etc. Learnings: deepened insights On culture Shipping is king. Yes, deadlines are stressful, but failing to ship and getting stuck in endless debates is far worse. It’s depressing. If someone isn’t a good culture fit, it will be more than a single incident. Over time, it becomes pretty clear to everyone. Top performers tend to measure themselves against the very best in the company. Reassure them they are doing a great job. On the other hand, those who underperform will look to other underperformers to gauge their own progress. Even top performers will struggle if they don’t fully align with the vision. Nothing beats talking to customers. Encourage everyone to do it. Better in person. Most managers don’t have a strong incentive to be strict, so finding the right balance takes a lot of calibration. Only once everyone is aligned, you can truly delegate. On hiring Managers hate hiring because it’s binary: a lot of “no”, but eventually one “yes” can change everything. Staying consistent really helps. Simple things, such as weekly updates keep everyone accountable. People management sucks. If someone’s main motivation is to be a manager for the title, or so they can “lead,” that’s a red flag for me. Best managers end up being those who never planned on becoming one in the first place. They actually roll up their sleeves and can do the work. Big ideas are great, but they need to be executed. This matters even more when it comes to executives. A truly great exec can change your life and it will feel like a brand new company. Given their influence, anything less than great will eventually turn into a big mess. Spend time with executive candidates in person. Watch how they work and make sure they’re real builders. Previous founders and true engineers are usually a little bit de-risked, but they’re still not guaranteed. I also like to write a very detailed onboarding doc, clarifying context, expectations, and what success or failure looks like. Having them write a 30/60/90-day plan helps us all align. I’ve learned not to rely on their past pedigree. The real key is their glass eating endurance. On company building Re-orgs are inevitable at a growing startup, and they will feel scary or emotional for people who aren’t used to them. I find it helpful to be super clear about why we’re doing it, and to share the fallback plan if things don’t work out. But I’ve learned that by the time you think you need a re-org, you’re already behind. We now plan to reassess our team structure twice a year for optimal shipping. A numeric goal (like an SLA or revenue target) is just a proxy. Missing it isn’t the end of the world if you learn in the process. But if you surpass it without recognizing what’s broken underneath, you’ll be masking critical issues. Perfectionists are great, but can have a tough time at startups. Some do fine if they’re focused on one specific thing or working as an IC. But as soon as they have to juggle multiple tasks, the chaos can feel overwhelming. Help them embrace it. Things will break. It’s about continuously reprioritizing, and stopping small cracks from becoming big fires. No agenda == no meeting. Synchronous time is expensive. The only exception is the occasional unscheduled call. After you reach around 50 people (especially in a remote setup), documenting every process change becomes crucial. I’ve learned the hard way that simply talking about a new process isn’t enough. Founders can’t talk to everyone all the time anymore, and misunderstandings or gossip can spread fast. Not everyone will read everything, but at least there’s a single source of truth to reference. Best people can stretch quite a bit—they’ll often rise to the challenge. But it’s wise to keep an eye on their limits before they burn out or become a bottleneck. On scaling as a founder A great EA is life-changing. Family will be supportive, but it’s not fair to offload all the stress on them. They will end up feeling helpless. Having a solid co-founder, a network of peers, or a good executive coach makes a world of difference. Founders are the ultimate guardians of the culture. It’s constant work, and it will feel relentless—especially when things are going well and it’s easy to get entitled. The best team members will help uphold the standard, but you cannot expect them to do all the policing. At this stage, it’s stupid not to level up your lifestyle in ways that reduce stress or save time. This might include childcare support, having a second car, investing in a better mattress, or hiring help with housekeeping. The startup is bigger than its founders, and the goal is to continuously remove yourself from the critical path. Still, it’s easy to forget that, as a founder, you literally brought everything into existence from thin air. Imposter syndrome often creeps in when you step outside your core expertise, but if your gut feeling is strong, it’s worth paying attention to. Stay open-minded, yet remember that no one knows the company quite like you do. The future Next year is going to be another big one. We’ll keep shipping and selling, while finally tackling our design and UX debt. We’ll keep investing heavily in our infrastructure. Not just for reliability, but also for real-time data. We want RevenueCat to feel fast, accurate, and easy to use. We’re also upgrading our self-serve and enterprise support, aiming for a truly world-class experience. In many ways, we’re finally seeing the original vision Jacob and I had back in 2017 come to life. We’ll be launching new product lines too, and if we execute well, we will be just a couple of years away from hitting $100M in revenue. We’ll keep building a winning team. We’ll hire about 45 people, 30 in Engineering, Product, and Design. It’s a challenge, but totally doable. As for me, my personal goals haven’t changed much, but my perspective has. Jacob and I used to joke that being happy and winning can’t happen at the same time. But why not? We’re in a privileged position to shape our own path and change anything we don’t like. After a lot of reflection and coaching, I realized I was simply too hard on myself. I was feeling depressed by the constant BS even though we were winning. A hack that helped was working with my EA to set weekly goals and then sending a public update to the full team. It let me see the real progress behind all the drama and back-to-back meetings and stay transparent with everyone. Next year, I’ll avoid meetings before 9 AM, keep an eye on calendar creep, and hold myself accountable to exercise and doing what helps me decompress. I know, it’s obvious. I also plan to travel more. Especially to the Bay Area, which is clearly back again. Meeting up with other founders and customers is always worthwhile. Another thing that made last year tough was having half my direct reports on parental leave for about half of the year. Now they’re back, and I can feel the momentum returning. Jacob has also taken over product again, now that he’s stepped away from directly owning operations and people. Increased shipping velocity has been noticeable. We have all the pieces in place. All that’s left is to keep pushing forward: shipping, selling and enjoying the ride. If there’s one thing I learned in Silicon Valley, it’s that no goal is too crazy if you refuse to give up. I really hope you enjoyed reading this post. As always, my intention was to share it with complete honesty and transparency, avoiding the hype that often surrounds startups. If you are facing similar challenges and want to connect and share experiences, please do not hesitate to reach out on Twitter or shoot me an email! Special thanks to my co-founder Jacob, my EA Susannah, the whole RevenueCat team, and our valuable customers. I also need to express my eternal gratitude to all the CTOs and leaders who have been kind enough to share their experiences over these years. Shoutout to Dani Lopez, Peter Silberman, Alex Plugaru, Kwindla Hultman Kramer, João Batalha, Karri Saarinen, Miguel Martinez Triviño, Javi Santana, Matias Woloski, Tobias Balling, Jason Warner, and Will Larson. Our investors and early believers Jason Lemkin, Anu Hariharan, Mark Fiorentino, Mark Goldberg, Andrew Maguire, Gustaf Alströmer, Sofia Dolfie, and Nico Wittenborn. I want to convey my deep gratitude to my amazing wife, Marina, who has been my unwavering source of inspiration and support from the very beginning, and for blessing us with our two precious daughters. I cannot close this post without thanking my mom, who made countless sacrifices to mold me into the person I am today. I promise you will look down on us with pride the day we ring the bell in New York. I love you dearly.

3 months ago 53 votes
Full Circle

I’m back in Spain for my brother’s wedding. I rarely visit during the summer. The heat in my hometown is brutal, around 40 degrees Celsius (over 100 Fahrenheit for my imperial friends). Most people escape to the coast, just like my family did when I was a kid. I haven’t been here in years. As I drive along the coast, I find myself reflecting on a tweet about money and happiness, a vivid memory pulls me back in time. It’s August 22nd, 2007. The iPhone, the first real smartphone, has just been announced. It’s so cool, but of course I cannot afford it. It’s not even going to be released in Spain. I’ve just gotten my driver’s license, and I’m about to dive into my third year of Computer Science. I set up my clunky TomTom navigator knockoff, and hit the road. I’m on my way to meet Marina for our first real date. She’s cool, pretty, and kind. She likes the same music as I do, and even has distant relatives in California, the place we jokingly plan to visit someday (if I ever get enough cash). I’m listening to a pirated Blink-182’s self-titled CD. Pop-punk is pretty niche in the south of Spain, and it’s dying. Blink-182 has split up, and I missed my window to see my favorite band live. The Atlantic Ocean is as flat as a lake. This corner of Huelva’s coast is sheltered from any real waves, a stark contrast to the world-class surf breaks I drool over in magazines. And suddenly, reality hits: my childhood dreams of building a tech company in Silicon Valley, while vacationing in Southern California feel impossibly far. Even getting through my degree feels like a pipe dream. School isn’t fun anymore. It’s grueling, especially the parts I thought I’d enjoy, like algorithms and Data Structures. I might never become a Software Engineer. I feel stuck, trapped by my lack of direction. I am seriously considering quitting. But no degree means no job in the US, and good tech gigs are rare here in Spain. The only cool company is Tuenti, a new startup that is cloning Facebook. I’m nowhere near smart enough to land a job there though. Flash forward to today, 17 years later. It’s almost laughable to think about how hopeless things once seemed. Even now, it doesn’t feel like I’ve “made it.” The path and the results look nothing like what teenage me envisioned, but somehow, I’m realizing I’ve kind of checked off every box. I married Marina, and we live in Southern California with our two beautiful identical kids. We’ve become American citizens, and I’ve lived in the Golden State for nearly a third of my life. I’ve worked as a Software Engineer at a Silicon Valley startup, learned from the best, and found the best co-founder I could ask for. We launched our own company. Smartphones? They’re in everyone’s pockets now. Our product is in a third of all new apps shipped in the US. We’ve helped developers reach millionaire status, and we’ve made more money than I ever thought possible. But I’ve learned that a lot of money is a relative term. Somehow, I managed to hire insanely talented engineers—a bunch of them, ironically, from Tuenti. Blink-182 is back together, and I’ve been fortunate enough to see them live five times. I’ve even bumped into Tom Delonge after surfing world-class waves a few times. I’m literally just realizing how surreal all of this is. I tend to get caught up in the chaos of what’s next—the next big fire, the next goal—but sometimes you’ve got to stop, be present, and reflect on how far you’ve come. It wasn’t easy. It wasn’t without loss, sacrifice, and a fair share of doubts. Am I truly happy? Maybe not in a perfect, all-the-time kind of way. There are external things humans cannot control. But when I look at my life, I realize there’s no real reason not to be. The journey has been was worth it so far: the ups, the downs, the unexpected turns. So, here’s to your journey, whatever it looks like. Keep going, keep dreaming. It might not turn out the way you envisioned it, but it’s only impossible if you quit.

7 months ago 65 votes
Working with Miguel: A Practical Guide

Since reading ‘High Growth Handbook’ by Elad Gil, the value of writing a ‘Working with’ document became crystal clear to me. I am sharing mine externally to inspire other founders and leaders to reflect and write down their own working styles. These documents are incredibly beneficial, especially in a multi-timezone, remote setting like we have at RevenueCat. I’ve spent some time fine-tuning mine, and this is the updated version. Welcome to your go-to manual for understanding how to collaborate effectively with me. My Mindset: Logic-Driven, Plan-Oriented I’m a logical thinker, much like a computer. If A implies B and we have A, I’ll typically conclude B. Sticking to plans and predictability is my comfort zone, yet I value reactivity, especially when customer-related issues arise and are solvable. This company isn’t just a job for me; it’s my life’s work. I’m deeply invested in everything here — our technology, culture, team, and customers. I get inspired and energized by hard-working coworkers who believe in our mission even more than me. As a co-founder, I can offer a wealth of institutional knowledge and guidance. While I may not have all the answers, I’m usually good at pointing you in the right direction. RevenueCat is only a sum of it’s parts. Our teammates drive our culture and I want to make sure we are building a place that people want to be. If you have a suggestion on how to make RevenueCat an even cooler place to work for our teammates I’m always here to talk about it. How We’ll Operate Regular Check-ins: For my direct reports, expect weekly or bi-weekly one-on-one meetings. To make our discussions more focused, I prefer that we establish an agenda before our scheduled time together. Communication Protocols: My schedule doesn’t allow much room for impromptu calls. If something urgent pops up, message me on Slack first. Should it require a call, schedule it through Susannah, please never bypass her. Meeting Preparation: Come to meetings with an agenda to ensure productivity. Without one, I might dominate the conversation, potentially missing your crucial points. Let’s both be responsible for following up on action items. Team Support: I’m open to joining other team meetings, but please share the agenda in advance and mark my attendance as optional unless crucial. Problem-Solving Approach: My engineering background means I love tackling complex problems using a divide and conquer approach: by breaking them down into smaller, manageable chunks, solving each piece, and then combining them for a final solution. If we can improve a completely broken system to 90% functionality, that’s significant progress in my book! Communication Style Note-Taking: While I take meticulous notes, my current preferred tool doesn’t support sharing. If you wish to access these notes, it’s on you to set up a shared document in Google Docs, Notion, or Lattice. Information Filtering: I prefer having complete transparency and the ability to filter out unnecessary details myself. Always explicitly state if you need input from me, or else I’ll assume it’s for my information only. Feedback Style: Expect direct feedback from me. I’ll clearly differentiate between areas for improvement and significant performance concerns. Trust Dynamics: Consider my trust like a metaphorical ‘bucket’ that starts half-full for everyone and adjusts based on your actions. The more you fill this bucket, the more autonomy you’ll have. For Managers Transparency in Challenges: Startups are always broken one way or another. I prefer to hear any bad news about a project or a team member directly from you. Working together through challenges can strengthen our trust and working relationship. Progress and Concerns: During our 1:1’s, I’ll inquire about your team dynamics and direct reports’ progress. I encourage you to include any details in our 1:1 agenda and lead the conversation to address any performance concerns, project delays or notable achievements . Feedback Dynamics: I recognize the weight of my title. To avoid unnecessary tension, I prefer to provide critical feedback about your reports directly to you so you can address privately. On the other hand, if there is any commendable achievement by your team I will do my best to praise publicly. If you feel there is someone on your team that I should connect with or praise, please let me know. Encouraging our team and recognizing their strengths is something that is very important to me. Preferences and Pet Peeves What I like Doing your homework: No question is stupid, but always do your initial research before distracting the team. Being resolutive: Getting things done, unblocking yourself. Readable and consistent code. Proven, boring technology over unproven open source projects that is trending on Hacker News. Proactivity: See a problem? Fix it right away before anyone notices. Made a mistake? Build systems to prevent anyone else making the same one again. Double checking your work: Give your work (documents, presentations, pull requests) a quick self-review before presenting it to the team. Transparency: In a multi-tz, remote environment, over-communication is better than miscommunication. Healthy discussions. When there is a decision to make that is not clear, it’s because all the different approaches have pros and cons. Together we will be able to calibrate and choose the lesser evil. A short call (or loom) is preferred over constant Slack interruptions. What I don’t like Gossip and rumors: They destroy the culture. Be upfront. Cargo cult: Let’s not do something just because BIG CO does it. That’s the beauty of building something from scratch. Unnecessary blockers. You’re all pretty smart here! Always try to unblock yourself first. Lack of context in questions, emails, and discussions. Not speaking up when something isn’t clear. Recurrent mistakes or questions: One time, it’s totally expected. Two times, hmm. Three times, nah. Learn, document, and build systems. Complaining without taking any action to improve the situation. Sarcasm or other ways of communication violence during disagreements: When somebody wins an argument, most of the time, the whole team loses. Acknowledging My Flaws Overcommitment: I tend to take on more than I should, which inevitably affects my focus. While I’m working on this, please understand if I occasionally get sidetracked by emergencies. Communication while Debugging: When addressing issues, I might share unvalidated hypotheses, which can be confusing. I’m learning to communicate more clearly and only after verifying my thoughts. Problem-Solving Obsession: Unsolved problems keep me up at night, which isn’t ideal for my well-being. It’s a habit I’m aware of and trying to balance. Pessimistic Tendencies: In evaluating problems, I often veer towards catastrophic thinking rather than optimism, a trait I’m mindful of and trying to moderate. Office Hours To maximize my availability given my tight schedule, I’ve introduced ‘office hours.’ This time is open for anyone to schedule a 15-minute chat with me about any concerns or ideas you might have. Reach out to Susannah for scheduling details. Thanks for sticking with me till the end! These are my personal preferences, not commandments carved in stone. I’m stoked to collaborate, build awesome stuff, and, above all, have fun together!

a year ago 46 votes
My role as a founder CTO: Year Six

Another year as a founder CTO, and let me tell you, it’s been one for the books. I can’t remember a time in my life that was more demanding and emotionally draining. Those early years were filled with hard work, but we were also full of energy, ambition to build, and the sense that we had absolutely nothing to lose. As my dear friend Jacob used to quip, “Worst case scenario nobody dies”. Yet, everything takes on a new perspective when you’re responsible for the monetization infrastructure of over 30,000 apps and ensuring the livelihoods of not only your team but also your own family. While I would typically begin this series of posts with an array of metrics, this year has been a whirlwind of events that has taken precedence over mere numbers. So, dear friend, take a seat and allow me to share with you a deeply personal and epic firefighting tale and the battle to restore the flame of RevenueCat’s core values. The Year of Shipping We embarked on Q1 with big intentions and an ambitious roadmap. With seven new engineering teams, my role was to lead the one responsible for serving our larger customers. My days consisted of collaborating with our (still tiny) sales team, while simultaneously overseeing our support function. While I continued to provide technical guidance to several projects, I made the conscious decision to delegate the bulk of product development to the other teams. In hindsight, this decision proved to be a mistake. The teams were still finding their footing, with a mix of new hires, and there was a disconnect between engineering and product that needed addressing — a topic we’ll get into later. Nevertheless, the team I led was firing on all cylinders, delivering enterprise-level features at a hasty pace. From implementing single-sign-on in a matter of days, to tackling gnarly bugs, this team’s momentum was inspiring. I hoped that this stride would serve as a catalyst, motivating the rest of the teams to achieve a similar velocity. On the home front, my wife’s parental leave came to an end in January, marking the start of a new era where my hours were no longer flexible. Together, we embarked on the demanding task of caring for our twin babies. Little did I know how much the lack of sleep would impact me. Fatigue began to set in and my usual escape valves, such as surfing, turned into distant memories. Caffeine became my closest friend, helping me stay awake as I navigated the demands of work and family. I would spend my entire weekends lying in bed, trying to recover. I wrongly assumed it would be a short phase. Troubles never come alone On the fateful morning of March 9th, while I was soothing one of our crying babies at 4:30 AM, my WhatsApp began buzzing with messages from concerned fellow founders. Rumors were swirling that Silicon Valley Bank, the custodian of most VC-backed startup funds, was about to collapse. Within hours these whispers escalated into a full-blown bank run and we found ourselves unable to access our funds. Without going into the nitty-gritty details, it was an intensely stressful weekend. We were on the verge of a payroll crisis and we didn’t even have a functioning bank to transact with. However, we couldn’t afford to let this situation be what killed RevenueCat. We worked to expedite the opening of new bank accounts and explored multiple liquidity alternatives. Fortunately, we were privileged enough to entertain multiple options. One investor came to help, wiring funds from their personal account, and some of our loyal customers offered to pay in advance. Just as hope seemed to dwindle, the FDIC announced that they would guarantee all deposits on that Sunday afternoon. Crisis averted. Emotionally drained from the weekend’s trauma, we received another unexpected blow just a few days later: Y Combinator was discontinuing its Continuity Fund. This created a dilemma regarding the fate of their board seat, something we would have never anticipated. Just weeks prior, we had suffered a severe outage caused by our cloud provider. We tried to console ourselves, thinking, “At least all these problems are internal; we’re not dealing with downtime”. A Crisis of Reliability Our break was short-lived. Less than a week after the Silicon Valley Bank fiasco we experienced yet another major outage, and this time, it was self-inflicted. When you’re handling hundreds of thousands of API requests per second, even a few seconds of downtime can set off a cascade of alarms and potential sales losses. Our customers were understandably frustrated, and they didn’t hesitate to make their displeasure known through every available channel. It was heartbreaking to witness and I felt a deep sense of personal failure. This marked the third user-facing issue in a matter of months. It wasn’t something to sweep under the rug: our reputation was on the line and it was time to act. By this point, I was utterly sleep-deprived and my Apple Watch had begun sending me concerning health notifications. The day after we resolved the outage, my co-founder Jacob and I came up with an action plan. It was officially wartime. We needed to act decisively. We publicly unveiled our plan: to develop a robust fallback system independent of our current infrastructure. And we promised to deliver it within a week. Simultaneously, Jacob and I embarked on an apology tour, reaching out personally to some of our most worried customers. This was a painful but humbling experience for us, but it proved beneficial on multiple fronts. It allowed us to reiterate our commitment to becoming the best in-app subscription infrastructure provider in the world while gaining invaluable insights into our customers’ pain points. RC Fortress I rallied a small crew of engineers from different teams to build the first version of what we called “RevenueCat Fortress”. This component was designed to make sure end-customers could purchase seamlessly, even when our main servers were unavailable. It was a crazy week because we set ourselves a tight deadline but it helped boost our spirits and proved we could deliver software fast. The initial version of RevenueCat Fortress was quite simple – it operated behind the scenes on the server. But we didn’t stop there. We made it even better in the next iterations by adding SDK improvements such as offline entitlements. When it finally rolled out, it did so with flying colors. We even got to put it to the test during a major Apple outage and it saved the day for RevenueCat customers, making them immune to Apple’s downtime. Turning things around Looking back, the birth of RC Fortress marked the start of a shift in our culture. It got us back to the basics of reliability, fast delivery, and customer obsession. We couldn’t afford to spend months on extensive, untested projects. We had to rapidly build the features our customers valued most and iterate from there. We also realized that keeping things rock-solid wasn’t just the infrastructure team’s job; it was a global effort. Around the same time, we faced a couple of setbacks when we parted ways with two executives – the VP of People and the VP of Engineering. We tried to find a new VP of Engineering but couldn’t find a match that really excited us. So, the board agreed it would be best if I took the reins of the entire engineering organization again. Those days gave me a chance to get closer to the product teams again. Here’s where I spent most of my energy: Performance: I clarified expectations, provided feedback, and coached managers on performance management. Hiring: We tweaked our hiring process and re-calibrated interviewers’ expectations. Reliability and Quality: We were pretty good at doing post-mortems after issues but we had too many of them. They lacked detail and they weren’t followed through with action items. We needed a little bit of a cultural reset. We introduced dedicated incident Slack channels and clearly defined roles. Customer Obsession: Taking over the support team was eye-opening. It gave me a direct line to our product’s weak spots and what confused our customers. We started categorizing support tickets and sending them straight to the right product teams for triaging. Project Management: We focused on breaking projects into smaller chunks to deliver faster, instead of getting lost in never-ending projects. Education and Best Practices: I spent time educating other departments, especially post-sales teams, to avoid recurring mistakes that were slowing down our engineering progress. On top of all that, I reconnected with our customers more than ever. I hopped on planes to visit them at their offices and even worked our booth at a few conferences. It was a refreshing change to chat with users face-to-face, and hearing their unique challenges in person after a long time. Life is what happens when you’re busy running your startup We were fortunate enough to fly in my mother-in-law to assist with our babies, which made my travel plans possible. I finally felt more rested and even managed to squeeze in a few surfing sessions. Things were looking up both personally and professionally. I was eagerly anticipating our annual company-wide offsite, especially since I had missed most of the previous one due to my wife’s high-risk pregnancy. This time around I was geared up to address the entire engineering team, sharing the exciting changes and boosting morale. We were about to start winning again. But then, the day before my flight, I received a call from my father back in Spain. My mother had been rushed to the hospital, and she had been diagnosed with an extremely aggressive form of leukemia. Time seemed to stand still. I boarded the flight as planned, chugged two Red Bulls, and delivered that motivational talk to the whole team, while my mom was in a hospital bed thousands of miles away. This was hands down the toughest thing I’ve ever done as a startup founder. I left the offsite early and headed back to my hometown. Over the following weeks, I traveled back and forth around the globe, coordinating with my family. Sadly, my mother never left the hospital, she passed away merely a few weeks after the diagnosis. These are the things that always lurk in the back of your mind when you’re living 10,000 miles away from home, but you never truly believe they’ll happen. Until they do, and they shatter you. Keep on pushing The days that followed were far from easy. We were dealing with the launch of our biggest customer’s app, something we’d been preparing for a long time. The scale was enormous and the hard work of our team truly paid off. Our systems ran incredibly smoothly. It was a monumental victory, especially after the rocky start to the year. But, mentally, I wasn’t prepared to savor the moment. Yet, the energy post-offsite was infectious. People genuinely enjoyed meeting each other in real life and were fired up to start shipping. We couldn’t let this opportunity slip through our fingers. I paid homage to my mom’s teachings by continuing to press forward. RC Paywalls One of the major product ideas that had always been on our team’s wishlist was paywalls. We hadn’t tackled it because it seemed daunting and we lacked a product team with all the necessary skills. We couldn’t even estimate how long it would take to build. But, fueled by the success of RC Fortress, we decided to take a shot at it. We assembled a small team with members borrowed from different corners of the company. We didn’t mess with any reporting structures but appointed a leader. We went back to our roots, working in a hackathon-style frenzy for a couple of weeks to build a prototype. Just like in the good old days. And, boy, did the team rise to the occasion. We gave them some extra time and, in the end, they delivered one of our biggest product wins of the year. Shipping paywalls felt like a breath of fresh air and a clear sign that we still had our mojo. We were still capable of shipping software at lightning speed and keeping our customers excited. Based on all these lessons, the Head of Product and I started cooking up a brand new way of building products at RevenueCat. Engineering/Product/Design changes The complete process overhaul would warrant a couple of blog posts, but let me highlight the key changes to our workflow: We’ve reviewed all existing teams to determine whether they should continue as is, be replaced, or undergo changes in their mission or structure. We’ve rebalanced and clarified the responsibilities across Product, Engineering, and Design: Engineering takes the lead on feasibility, delivery, and developer experience, managing Linear, and overseeing technical architecture (and debt) roadmaps. Product is dedicated to customer value, business viability, and collaboration with sales and marketing teams. They also provide support to engineering in refining project scopes. Design is responsible for usability. We’ve formalized the role of Tech Lead, assigning them as the Directly Responsible Individuals for specific projects. They’re accountable for project success, with full backing from their Engineering Manager. It’s optional and project-dependent and doesn’t entail a title or salary change. We’ve acknowledged the need for engineering-driven initiatives, where PM and Design are involved on an as-needed basis. For projects with dependencies with other teams, we’ll designate a team member from the collaborating team as a formal interface. Our existing setup of stable product teams will remain the norm for most of our work. Temporary project teams will be established only when there’s a strong need for cross-team collaboration over a limited period. We’ll conduct monthly roadmap and shipping reviews with the founders and Head of Product. These reviews will provide insights into what we’re building, offer feedback opportunities, and help identify cross-functional dependencies and misalignments. 2024: The year of shipping + selling Collaborating with the Product team showcased the immense benefits of working closely together. Traditionally, Product reported directly to our CEO, which introduced unnecessary layers of indirection. In light of this and our recent addition of a VP of Sales, we decided it was time for a reorganization. Currently, Jacob (co-founder, and CEO), is overseeing Go to Market, People, and Operations, while I’m responsible for Engineering, Product, and Customer Engineering. We’ve brought in a VP of Customer Engineering, who reports to me and is in charge of Support and Technical Account Management. With our current headcount at 73 employees, my organization consists of 48 team members. Our executive team developed the most comprehensive planning effort to date. Our goal is to accelerate growth, focusing on sales and product delivery. We will avoid distractions by being extremely strategic at hiring. The past quarter showcased the strength of our engineering and product teams. New team members have been onboarded successfully, contributing meaningfully, and our management structure is finally robust. It took a bit of time for the “year of shipping” to fully materialize, nearly a year later, but customers have taken notice and we’re capitalizing on this momentum. On the enterprise sales front, I’m extremely bullish. We’ve secured the biggest deals in the company’s history. RevenueCat has evolved beyond being a product just for indie developers. However, we acknowledge the need to continue closing the product-market fit gap for enterprise clients. We’ve gained valuable insights into enterprise needs, and we’ll keep developing new products and features tailored to them. Indie developers will also take advantage of them to make more money. In 2024, the collaboration between our go-to-market and engineering teams will be critical. Highlights This year, as you’ve probably noticed, was a tough one. However, besides the challenges, there were several remarkable achievements to celebrate: We truly shipped. Our second hackathon, spanning an entire week, was an epic success. Many of the projects launched immediately, directly benefiting our customers. We had the privilege of collaborating with prominent brands and companies, including none other than Arnold Schwarzenegger himself. We created an astonishing amount of high-quality content. Our SubClub podcast outperformed all my expectations. During the chaos of the bank run, we discovered that one of our idols was not only a RevenueCat customer but also a devoted fan. We experimented with fresh team topologies and processes, and they turned out to be successful. We fine-tuned our vision for building a winning team, offering improved feedback, clearer expectations, and timely performance management. Jacob and I are no longer the sole authorities on Apple and Google subscriptions within the company. We successfully recruited seasoned executives to join our team. Our core infrastructure team accomplished monumental feats. We now support over 1 billion API requests daily, transitioned to our own data platform, and developed our own memcached client. All while maintaining flat costs despite the increase in load. Learnings It’s impossible to achieve peak performance without attention to health, exercise, and sleep. I’m no longer in my twenties. Complexity is the root of all evil. Startups and software are inherently complex, so avoid introducing unnecessary complexity. Begin by building the simplest feature or process, debug it, and then iterate as needed. Starting a business is tough, but launching a remote startup is an even greater challenge. Scaling a remote startup while parenting two under two is a herculean effort. Building a brand takes years but its reputation can be destroyed in an instant. Protect the integrity of your brand at all costs. Every new team member should add value, and especially so in a startup. Some provide immense leverage, while others become bottlenecks. The trickiest are those in the middle, who often end up becoming bottlenecks. Founders usually spot this within the first few weeks. Letting someone go is a taxing task. Even when managers believe it’s the right thing to do, it often requires a significant amount of support and guidance. Transparency in times of crisis pays dividends. Employees want to be treated like adults, and it builds trust. The same applies externally. Early worries often become baseless. By the time they become actual problems, your company might have died, you might have gained experience, or you might have hired the right talent to tackle them. SOC 2 auditors may request unconventional supporting evidence, such as employee performance reviews. Developers love socks. I’m so fortunate to have the world’s best co-founder. At this stage, my role is much more aligned with that of a founder than a traditional CTO or VP of Engineering. I continue to address issues as if they were technical problems, but my responsibilities extend well beyond the technology area. Life keeps moving forward, with its share of highs and lows. Life is too short, so you have to ensure the journey remains fun. For me, that means working with people who inspire me, and serving customers I genuinely care about. I really hope you enjoyed reading this post. I’m aware it’s a lot longer than my previous ones, but there were so many stories to share. As always, my intention was to share it with complete honesty and transparency, avoiding the hype that often surrounds startups. If you are facing similar challenges and want to connect and share experiences, please do not hesitate to reach out on Twitter or shoot me an email! Special thanks to my co-founder Jacob, the whole RevenueCat team, and our valuable customers. I also need to express my eternal gratitude to all the CTOs and leaders who have been kind enough to share their experiences over these years. Shoutout to Dani Lopez, Peter Silberman, Alex Plugaru, Kwindla Hultman Kramer, João Batalha, Karri Saarinen, Miguel Martinez Triviño, Sam Lown, Javi Santana, Pau Ramón, Javier Maestro, Matias Woloski, Tobias Balling, Jason Warner, and Will Larson. Our investors and early believers Jason Lemkin, Anu Hariharan, Mark Fiorentino, Mark Goldberg, Andrew Maguire, Gustaf Alströmer, and Nico Wittenborn. I want to convey my deep gratitude to my amazing wife, Marina, who has been my unwavering source of inspiration and support from the very beginning, and for blessing us with our two precious daughters. I cannot close this post without thanking my mom, who made countless sacrifices to mold me into the person I am today. I promise you will look down on us with pride the day we ring the bell in New York. I love you dearly.

a year ago 37 votes

More in programming

How to use “real” UART

I recently went into a deep dive on “UART” and will publish a much longer article on the topic. This is just a recap of the basics to help put things in context. Many tutorials focus on using UART over USB, which adds many layers of abstraction, hiding what it actually is. Here, I deliberately … Continue reading How to use “real” UART → The post How to use “real” UART appeared first on Quentin Santos.

23 hours ago 4 votes
Believe it's going to work even though it probably won't

To be a successful founder, you have to believe that what you're working on is going to work — despite knowing it probably won't! That sounds like an oxymoron, but it's really not. Believing that what you're building is going to work is an essential component of coming to work with the energy, fortitude, and determination it's going to require to even have a shot. Knowing it probably won't is accepting the odds of that shot. It's simply the reality that most things in business don't work out. At least not in the long run. Most businesses fail. If not right away, then eventually. Yet the world economy is full of entrepreneurs who try anyway. Not because they don't know the odds, but because they've chosen to believe they're special. The best way to balance these opposing points — the conviction that you'll make it work, the knowledge that it probably won't — is to do all your work in a manner that'll make you proud either way. If it doesn't work, you still made something you wouldn't be ashamed to put your name on. And if it does work, you'll beam with pride from making it on the basis of something solid. The deep regret from trying and failing only truly hits when you look in the mirror and see Dostoevsky staring back at you with this punch to the gut: "Your worst sin is that you have destroyed and betrayed yourself for nothing." Oof. Believe it's going to work.  Build it in a way that makes you proud to sign it. Base your worth on a human on something greater than a business outcome.

9 hours ago 2 votes
Ductility in Software

I learned a new word: ductile. Do you know it? I’m particularly interested in its usage in a physics/engineering setting when talking about materials. Here’s an answer on Quora to: “What is ductile?” Ductility is the ability of a material to be permanently deformed without cracking. In engineering we talk about elastic deformation as deformation which is reversed once the load is removed for example a spring, conversely plastic deformation isn’t reversed. Ductility is the amount (usually expressed as a ratio) of plastic deformation that a material can undergo before it cracks or tears. I read that and started thinking about the “ductility” of languages like HTML, CSS, and JS. Specifically: how much deformation can they undergo before breaking? HTML, for example, is famously forgiving. It can be stretched, drawn out, or deformed in a variety of ways without breaking. Take this short snippet of HTML: <!doctype html> <title>My site</title> <p>Hello world! <p>Nice to meet you That is valid HTML. But it can also be “drawn out” for readability without losing any of its meaning. It’ll still render the same in the browser: <!doctype html> <html> <head> <title>My site</title> </head> <body> <p>Hello world!</p> <p>Nice to meet you.</p> </body> </html> This capacity for the language to undergo a change in form without breaking is its “ductility”. HTML has some pull before it breaks. JS, on the other hand, doesn’t have the same kind of ductility. Forget a quotation mark and boom! Stretch it a little and it breaks. console.log('works!'); // -> works! console.log('works!); // Uncaught SyntaxError: Invalid or unexpected token I suppose some would say “this isn’t ductility, this is merely forgiving error-parsing”. Ok, sure. Nevertheless, I’m writing here because I learned this new word that has very practical meaning in another discipline to talk about the ability of materials to be stretched and deformed without breaking. I think we need more of that in software. More resiliency. More malleability. More ductility — prioritized in our materials (tools, languages, paradigms) so we can talk more about avoiding sudden failure. Email · Mastodon · Bluesky

21 hours ago 2 votes
Critical Trade Theory

You know about Critical Race Theory, right? It says that if there’s an imbalance in, say, income between races, it must be due to discrimination. This is what wokism seems to be, and it’s moronic and false. The right wing has invented something equally stupid. Introducing Critical Trade Theory, stolen from this tweet. If there’s an imbalance in trade between countries, it must be due to unfair practices. (not due to the obvious, like one country is 10x richer than the other) There’s really only one way the trade deficits will go away, and that’s if trade goes to zero (or maybe if all these countries become richer than America). Same thing with the race deficits, no amount of “leg up” bullshit will change them. Why are all the politicians in America anti-growth anti-reality idiots who want to drive us into the poor house? The way this tariff shit is being done is another stupid form of anti-merit benefits to chosen groups of people, with a whole lot of grift to go along with it. Makes me just not want to play.

yesterday 1 votes
How to get better at strategy?

One of the most memorable quotes in Arthur Miller’s The Death of a Salesman comes from Uncle Ben, who describes his path to becoming wealthy as, “When I was seventeen, I walked into the jungle, and when I was twenty-one I walked out. And by God I was rich.” I wish I could describe the path to learning engineering strategy in similar terms, but by all accounts it’s a much slower path. Two decades in, I am still learning more from each project I work on. This book has aimed to accelerate your learning path, but my experience is that there’s still a great deal left to learn, despite what this book has hoped to accomplish. This final chapter is focused on the remaining advice I have to give on how you can continue to improve at strategy long after reading this book’s final page. Inescapably, this chapter has become advice on writing your own strategy for improving at strategy. You are already familiar with my general suggestions on creating strategy, so this chapter provides focused advice on creating your own plan to get better at strategy. It covers: Exploring strategy creation to find strategies you can learn from via public and private resources, and through creating learning communities How to diagnose the strategies you’ve found, to ensure you learn the right lessons from each one Policies that will help you find ways to perform and practice strategy within your organization, whether or not you have organizational authority Operational mechanisms to hold yourself accountable to developing a strategy practice My final benediction to you as a strategy practitioner who has finished reading this book With that preamble, let’s write this book’s final strategy: your personal strategy for developing your strategy practice. This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts. Exploring strategy creation Ideally, we’d start our exploration of how to improve at engineering strategy by reading broadly from the many publicly available examples. Unfortunately, there simply aren’t many easily available works to learn from others’ experience. Nonetheless, resources do exist, and we’ll discuss the three categories that I’ve found most useful: Public resources on engineering strategy, such as companies’ engineering blogs Private and undocumented strategies available through your professional network Learning communities that you build together, including ongoing learning circles Each of these is explored in its own section below. Public resources While there aren’t as many public engineering strategy resources as I’d like, I’ve found that there are still a reasonable number available. This book collects a number of such resources in the appendix of engineering strategy resources. That appendix also includes some individuals’ blog posts that are adjacent to this topic. You can go a long way by searching and prompting your way into these resources. As you read them, it’s important to recognize that public strategies are often misleading, as discussed previously in evaluating strategies. Everyone writing in public has an agenda, and that agenda often means that they’ll omit important details to make themselves, or their company, come off well. Make sure you read through the lines rather than taking things too literally. Private resources Ironically, where public resources are hard to find, I’ve found it much easier to find privately held strategy resources. While private recollections are still prone to inaccuracies, the incentives to massage the truth are less pronounced. The most useful sources I’ve found are: peers’ stories – strategies are often oral histories, and they are shared freely among peers within and across companies. As you build out your professional network, you can usually get access to any company’s engineering strategy on any topic by just asking. There are brief exceptions. Even a close peer won’t share a sensitive strategy before its existence becomes obvious externally, but they’ll be glad to after it does. People tend to over-estimate how much information companies can keep private anyway: even reading recent job postings can usually expose a surprising amount about a company. internal strategy archaeologists – while surprisingly few companies formally collect their strategies into a repository, the stories are informally collected by the tenured members of the organization. These folks are the company’s strategy archaeologists, and you can learn a great deal by explicitly consulting them becoming a strategy archaeologist yourself – whether or not you’re a tenured member of your company, you can learn a tremendous amount by starting to build your own strategy repository. As you start collecting them, you’ll interest others in contributing their strategies as well. As discussed in Staff Engineer’s section on the Write five then synthesize approach to strategy, over time you can foster a culture of documentation where one didn’t exist before. Even better, building that culture doesn’t require any explicit authority, just an ongoing show of excitement. There are other sources as well, ranging from attending the hallway track in conferences to organizing dinners where stories are shared with a commitment to privacy. Working in community My final suggestion for seeing how others work on strategy is to form a learning circle. I formed a learning circle when I first moved into an executive role, and at this point have been running it for more than five years. What’s surprised me the most is how much I’ve learned from it. There are a few reasons why ongoing learning circles are exceptional for sharing strategy: Bi-directional discussion allows so much more learning and understanding than mono-directional communication like conference talks or documents. Groups allow you to learn from others’ experiences and others’ questions, rather than having to guide the entire learning yourself. Continuity allows you to see the strategy at inception, during the rollout, and after it’s been in practice for some time. Trust is built slowly, and you only get the full details about a problem when you’ve already successfully held trust about smaller things. An ongoing group makes this sort of sharing feasible where a transient group does not. Although putting one of these communities together requires a commitment, they are the best mechanism I’ve found. As a final secret, many people get stuck on how they can get invited to an existing learning circle, but that’s almost always the wrong question to be asking. If you want to join a learning circle, make one. That’s how I got invited to mine. Diagnosing your prior and current strategy work Collecting strategies to learn from is a valuable part of learning. You also have to determine what lessons to learn from each strategy. For example, you have to determine whether Calm’s approach to resourcing Engineering-driven projects is something to copy or something to avoid. What I’ve found effective is to apply the strategy rubric we developed in the “Is this strategy any good?” chapter to each of the strategies you’ve collected. Even by splitting a strategy into its various phases, you’ll learn a lot. Applying the rubric to each phase will teach you more. Each time you do this to another strategy, you’ll get a bit faster at applying the rubric, and you’ll start to see interesting, recurring patterns. As you dig into a strategy that you’ve split into phases and applied the evaluation rubric to, here are a handful of questions that I’ve found interesting to ask myself: How long did it take to determine a strategy’s initial phase could be improved? How high was the cost to fund that initial phase’s discovery? Why did the strategy reach its final stage and get repealed or replaced? How long did that take to get there? If you had to pick only one, did this strategy fail in its approach to exploration, diagnosis, policy or operations? To what extent did the strategy outlive the tenure of its primary author? Did it get repealed quickly after their departure, did it endure, or was it perhaps replaced during their tenure? Would you generally repeat this strategy, or would you strive to avoid repeating it? If you did repeat it, what conditions seem necessary to make it a success? How might you apply this strategy to your current opportunities and challenges? It’s not necessary to work through all of these questions for every strategy you’re learning from. I often try to pick the two that I think might be most interesting for a given strategy. Policy for improving at strategy At a high level, there are just a few key policies to consider for improving your strategic abilities. The first is implementing strategy, and the second is practicing implementing strategy. While those are indeed the starting points, there are a few more detailed options worth consideration: If your company has existing strategies that are not working, debug one and work to fix it. If you lack the authority to work at the company scope, then decrease altitude until you find an altitude you can work at. Perhaps setting Engineering organizational strategies is beyond your circumstances, but strategy for your team is entirely accessible. If your company has no documented strategies, document one to make it debuggable. Again, if operating at a high altitude isn’t attainable for some reason, operate at a lower altitude that is within reach. If your company’s or team’s strategies are effective but have low adoption, see if you can iterate on operational mechanisms to increase adoption. Many such mechanisms require no authority at all, such as low-noise nudges or the model-document-share approach. If existing strategies are effective and have high adoption, see if you can build excitement for a new strategy. Start by mining for which problems Staff-plus engineers and senior managers believe are important. Once you find one, you have a valuable strategy vein to start mining. If you don’t feel comfortable sharing your work internally, then try writing proposals while only sharing them to a few trusted peers. You can even go further to only share proposals with trusted external peers, perhaps within a learning circle that you create or join. Trying all of these at once would be overwhelming, so I recommend picking one in any given phase. If you aren’t able to make traction, then try another until something works. It’s particularly important to recognize in your diagnosis where things are not working–perhaps you simply don’t have the sponsorship you need to enforce strategy so you need to switch towards suggesting strategies instead–and you’ll find something that works. What if you’re not allowed to do strategy? If you’re looking to find one, you’ll always unearth a reason why it’s not possible to do strategy in your current environment. If you’ve convinced yourself that there’s simply no policy that would allow you to do strategy in your current role, then the two most useful levers I’ve found are: Lower your altitude – there’s always a scale where you can perform strategy, even if it’s just your team or even just yourself. Only you can forbid yourself from developing personal strategies. Practice rather than perform – organizations can only absorb so much strategy development at a given time, so sometimes they won’t be open to you doing more strategy. In that case, you should focus on practicing strategy work rather than directly performing it. Only you can stop yourself from practice. Don’t believe the hype: you can always do strategy work. Operating your strategy improvement policies As the refrain goes, even the best policies don’t accomplish much if they aren’t paired with operational mechanisms to ensure the policies actually happen, and debug why they aren’t happening. Although it’s tempting to ignore operations when it comes to our personal habits, I think that would be a mistake: our personal habits have the most significant long-term impact on ourselves, and are the easiest habits to ignore since others generally won’t ask about them. The mechanisms I’d recommend: Explicitly track the strategies that you’ve implemented, refined, documented, or read. This should be in a document, spreadsheet or folder where you can explicitly see if you have or haven’t done the work. Review your tracked strategies every quarter: are you working on the expected number and in the expected way? If not, why not? Ideally, your review should be done in community with a peer or a learning circle. It’s too easy to deceive yourself, it’s much harder to trick someone else. If your periodic review ever discovers that you’re simply not doing the work you expected, sit down for an hour with someone that you trust–ideally someone equally or more experienced than you–and debug what’s going wrong. Commit to doing this before your next periodic review. Tracking your personal habits can feel a bit odd, but it’s something I highly recommend. I’ve been setting and tracking personal goals for some time now—for example, in my 2024 year in review—and have benefited greatly from it. Too busy for strategy Many companies convince themselves that they’re too much in a rush to make good decisions. I’ve certainly gotten stuck in this view at times myself, although at this point in my career I find it increasingly difficult to not recognize that I have a number of tools to create time for strategy, and an obligation to do strategy rather than inflict poor decisions on the organizations I work in. Here’s my advice for creating time: If you’re not tracking how often you’re creating strategies, then start there. If you’ve not worked on a single strategy in the past six months, then start with one. If implementing a strategy has been prohibitively time consuming, then focus on practicing a strategy instead. If you do try all those things and still aren’t making progress, then accept your reality: you don’t view doing strategy as particularly important. Spend some time thinking about why that is, and if you’re comfortable with your answer, then maybe this is a practice you should come back to later. Final words At this point, you’ve read everything I have to offer on drafting engineering strategy. I hope this has refined your view on what strategy can be in your organization, and has given you the tools to draft a more thoughtful future for your corner of the software engineering industry. What I’d never ask is for you to wholly agree with my ideas here. They are my best thinking on this topic, but strategy is a topic where I’m certain Hegel’s world view is the correct one: even the best ideas here are wrong in interesting ways, and will be surpassed by better ones.

yesterday 2 votes