SaaS Sprawl and Transparency: Scaling Internal Employee Directories with Alex Solomon, CTO and Co-founder at PagerDuty

Alex Solomon on Founding PagerDuty, Building Engineering Culture, and Scaling to Product-Market Fit

Alex Solomon, Co-Founder and CTO of PagerDuty | Interviewed by Luke Alie of Atolio

Alex Solomon co-founded PagerDuty in 2009 and served as its first CEO through 2016. Today he is CTO. In this episode, he shares the origin story of PagerDuty, the lessons learned from launching before the product felt ready, how the company built a culture of transparency and documentation from day one, and the advice he would give founders starting out today.

From Amazon Engineer to PagerDuty Co-Founder: The Origin Story

Luke Alie (LA):  Let's start with your background, founding PagerDuty, and where you are today.

Alex Solomon (AS):  I studied software engineering and went straight to Amazon after graduating. Amazon was one of the early pioneers of DevOps: small, autonomous teams responsible not just for writing code, but for testing and deploying it to production. That "you build it, you own it" mentality was ahead of its time. We were also on call for the systems we built. I actually carried a physical pager. This was 2006 to 2008, before smartphones were ubiquitous.

That experience directly inspired PagerDuty. I left Amazon along with my two co-founders, and we spent our first month together researching problems worth solving. We kept coming back to one question: what internal tools had Amazon built out of necessity that other companies would also benefit from? The on-call paging system was the obvious answer. Amazon had built an in-house tool to handle on-call rotations, scheduling, paging, and escalations. If you didn't respond within 30 minutes, it escalated to your manager. We decided to build that as a product for everyone. We started the company in February 2009.

The initial concept was a system that sits on top of all your monitoring tools, aggregates your alerts from Nagios, New Relic, Datadog, AWS CloudWatch, and others, and routes them to the right on-call team so nothing falls through the cracks. The three of us started this in Toronto, and about a year in we applied to Y Combinator. We had early traction, early revenue, and were close to ramen profitable. We got in, moved to the Bay Area, and the rest is history.

We launched a beta in the summer of 2009 and the paid version in December of that year. After YC, we raised a seed round. A huge benefit of the program for three engineers who had never dealt with investors was learning how to pitch, negotiate, and get people excited about what we were building. By 2012, we were growing about 10% month over month, had crossed two to three million in ARR, and raised our Series A with Andreessen Horowitz. That is when we started building out sales, marketing, and HR properly.

When to Launch a SaaS Product: Shipping Before You Feel Ready

LA:  Back in 2009 and 2010, when did you know the product was ready to put in customers' hands?

AS:  We definitely launched before we thought it was ready. Twilio was running a contest for startups building on their platform, and they launched a category specifically for IT notifications and alerting. We thought: that is perfect. We had a week or two to clean things up and get an MVP out. We rushed, finished it, submitted it, and won. That gave us our first real public exposure and our first batch of beta users.

As engineers, there is a perfectionist streak that makes you want to add one more feature before launching. Winning that contest forced us to ship before we felt truly ready, and it was the right call. Those beta users became paying customers.

The same dynamic played out when we launched the paid version. Our advisors pushed us hard: go implement a billing system and launch it today. Back then, Stripe did not exist yet, so we had to build our own payment gateway and billing system. We did it in under a month. Our initial plans ran from $10 to $300 per month, scaling with number of users. But even at those modest price points, something important happened: customer trust increased immediately.

When it was a free beta, potential customers would ask, "How are you making money? If I start relying on you, are you going to be around tomorrow?" Once we put a price on it, that objection disappeared. Charging something, even a small amount, signals commitment. And paying customers gave us far better feedback than free users ever did. The version I felt genuinely proud of came out in the summer of 2010, right around when we were going through Y Combinator.

Startup Onboarding and Employee Experience: What PagerDuty Got Right Early

LA:  I've heard you were thoughtful about documentation and scalable internal practices from early on, and that you built an internal tool called Deutonium. What were the early employee experience challenges at PagerDuty, and how did you approach them?

AS:  Early on we had nothing in place, and honestly when you are tiny you do not need formal processes. Our first employee, John Laban, assembled his own IKEA desk on his first day. That is startup life. But we were always thinking about how to make things more efficient and scalable as we grew.

I had heard stories of engineers joining companies and not having a laptop for a week or two. That is a real cost: someone who cannot be productive on day one is a problem. So we invested early in making onboarding genuinely good: the right equipment ready before day one, a proper monitor, a good chair. It was partly a reaction to my time at Amazon, which was famously frugal. You had to fight to get an extra monitor. We wanted to do the opposite.

Deutonium came out of a personal frustration. When we got to around 30 or 40 people, I realized I could not remember everyone's names anymore. I thought back to Amazon's internal employee directory: you could look up anyone, see their manager, navigate the org chart, and see their photo. So during one of our monthly Hack Days, I partnered with another engineer and we built a simple Rails app we called Deutonium, because we call our employees PagerDutonians. HR would take a headshot of each new hire against a green background and add them to the directory. Simple, but incredibly useful when you are scaling fast and people do not know who is who. Over the years, engineers have used Hack Days to keep adding features, so it has grown well beyond that first MVP from around 2011 or 2012.

We also overinvested in HR relative to most startups. We hired a VP of HR as our second executive hire, right after the sales VP. That let us build a real internal recruiting function and invest in what we called Vibe: employee experience, onboarding, team events, and building a sense of community. You spend a lot of time at work, and the relationships you build matter. Some of my closest friends today came from PagerDuty.

Internal Wikis, Documentation, and Building a Transparent Engineering Culture

LA:  Can you expand on how you addressed the onboarding and internal knowledge problem beyond Deutonium?

AS:  Deutonium helped with faces and names, but the other big piece was the internal wiki. We set up Confluence very early. Every team had their own page with their charter, mission, and roster, and a lot of the actual product and engineering work was documented there too: feature requirements, mockups, design decisions. When someone new joined a team, they could read through the wiki and get up to speed without interrupting everyone. That compounding knowledge matters enormously at scale.

We also overinvested in customer support. It was led by Bhaskar, one of our co-founders, which signals how seriously we took it. We hired smart, technical support people because our customers were developers. If someone had an issue integrating Nagios with PagerDuty, the support team would literally install Nagios in their own environment and debug it for the customer. That above-and-beyond standard was set early and it stuck. And the support team could only operate that way because of the documentation and the wiki keeping them in the loop.

The docs became even more important during the pandemic, when remote work made casual in-person communication impossible. You cannot walk over to someone's desk anymore. Documentation fills that gap.

Beyond documentation, we held monthly all-hands meetings and invested in transparency across the board. Revenue, goals, whether we were on track: all of it was available on dashboards open to anyone internally. We called it open by default. We did not want people just sitting in their lane. If someone was curious about how a SaaS company works, what the business metrics look like, what is driving growth, they could find out. I think that was genuinely valuable for a lot of people who later went on to start their own companies.

SaaS Tool Sprawl: The Hidden Operational Cost of Scaling Too Fast

LA:  Are there pain points from the early days that still feel unsolved or keep coming up for companies?

AS:  Tool sprawl. During our rapid growth phase, we basically let anyone buy whatever tool they needed to get their job done, within budget. Each department started buying independently. At some point, when we were around two or three hundred people, we had over a hundred SaaS tools in use.

What made it worse: a manager would buy a tool, use it for a year, then leave the company. The tool would sit there, unused, potentially full of valuable information that was now trapped and invisible. You would also end up with two or three tools doing the same thing. Asana and Jira both being used for project management across different teams, for example.

At some point you have to set standards. Email: we all use Gmail. Video: we all use Zoom. Chat: Slack. Docs: Google Docs. No second option. That discipline has to be intentional. If you do not build it early, you end up crushed under the weight of fragmented tools that do not talk to each other.

Founder Advice: Product-Market Fit, OKRs, and Setting Goals from Day One

LA:  What advice would you give to founders building companies today?

AS:  Two things. First: in the early days, be maniacally focused on getting to product-market fit. That is the only milestone that truly matters at the start. You need to be solving a real, acute problem for a specific set of people. To use the classic analogy: vitamins versus aspirin. If you are solving a nice-to-have problem, it is a tough slog. If you are solving a hair-on-fire problem that people urgently want to pay to fix, you are in the right place. It does not need to be millions of customers. Start with a smaller group and broaden over time.

Second: build the discipline of setting and reviewing goals from day one. Even if it is just three people, set a goal for this month. At the end of the month, look back honestly. Did we do what we said we would do? Where did we overachieve? Where did we fall short? Then set the next goal. Make it measurable wherever possible: revenue, customers, product engagement, shipping dates.

We did not do this from the start, and I wish we had. We implemented an OKR framework when we were around 30 or 40 people, and it was a much heavier lift to install that habit in a larger organization than it would have been from day one. The cadence compounds. When new people join, they just fit into a process that already exists. And it feeds directly into your investor updates: if you have that discipline internally, your monthly update is basically a copy-paste of your own review.

We use a V2MOM framework at PagerDuty now: Vision, Values, Methods, Obstacles, and Measures. It was pioneered by Salesforce and is similar to OKRs. Honestly, the specific framework does not matter. Just pick one and stick with it.

LA:  I love that. I do not hear that advice often enough, and it is so much more effective when it is modeled from the top from day one.

AS:  Exactly. And if you are just starting out: do it now. Why wait?

LA:  Thank you so much for your time today, Alex. Really appreciate it.

AS:  My pleasure. Thanks for having me.