I’ve spent a decade working in tech as a delivery leader, from huge corporations to early-stage start-ups. I’ve loved navigating the challenges of software development, and still do. But my career took a turn for the better when I stumbled upon PagerDuty.
Prior to PagerDuty, my most recent work experience was with a large telecom provider building a complex streaming service on multiple platforms. The complexity in itself wasn’t a problem – engineers thrive on solving new challenges. What they don’t like is chaos, with no end in sight.
The structure and culture around development slowed the entire organization down. Development teams consisted of Engineers, DevOps was its own team; QA was another. We threw things over the walls that were built. People weren’t empowered to make decisions, and this lack of accountability and trust wore everyone down.
When I interviewed with PagerDuty, more than five years ago I knew it was going to be the next phase of my career, because the Engineering culture was rooted in accountability and committed to reducing blockers. It was literally built on an extremely strong infrastructure supporting continuous development and deployment where, at that time a small organization, deployed to production over 100 times a week, and by doing so Engineering teams truly owned their impact.
If you are the type of engineer who takes ownership and pride in your work, who thrives in environments built on autonomy and trust, and who embraces collaboration, then PagerDuty or a place built on similar foundations might be the next place for you.
Our culture is in our code
PagerDuty builds software that helps resolve and prevent business-impacting incidents quickly – often so fast that no one even notices an issue occurred. This requires not only agility, but a culture that both enables and supports each employee to deliver what’s needed in the moment.
Our engineers work in fully autonomous teams, from writing code and testing it to deploying out into the rold and monitoring. They own the code they create end-to-end –- you’re not going to another team and saying, “here is the code, please do your part”
And while this “full ownership” construct isn’t unique to us, the way we implement it is. It’s ingrained in the DNA of our product development and engineering organizations. Our culture is in our code.
Code It, Ship It, Own It: Why this model matters for a positive work culture
The traditional – and still common – organizational model in engineering is defined by silos. A developer would write the code, and then an operations team would deploy the code, and perhaps still another would be the first line for critical customer impacting issues (which typically means going back to the engineers to fix the source of the problem.)
That’s three different teams responsible for one unit of value. There’s no clear ownership or accountability, you’re constantly putting out fires, and people get burned out and feel isolated – hardly a recipe for success.
DevOps: a model based on trust
Fortunately, there is a better model, one where the same team that writes the code also ships the code themselves. There are no gates or barriers. It’s a model entirely based on trust.
The team and organization trusts each other to be professional and accountable. There are no hard and fast rules for how to get a job done, as long as it gets done. Code is always reviewed by peers within the same delivery team – and once it’s “shipped,” it’s that same delivery team’s responsibility to “own” the code and keep it working.
What does “owning”code really mean? It means being the one who feels confident enough to put it out to your customers, and the one who wakes up at night to address a breaking issue if one arises. If you’re a parent of a baby and you hear your child crying, you want to be the one to take care of it, because you know how, and moreover you are the one that cares the most. That is when you know you have true pride and ownership of your work. You can ask someone else to help, but they won’t know the intricate details that you do, and you would rather be the one to fix the problem.
This level of team ownership not only leads to higher performing software, it also builds stronger team collaboration and knowledge sharing. Everyone on the team needs to understand every area of ownership because the full team shares all on-call rotation duties, regardless of seniority. And when you go through the trenches together to address issues you come out stronger, you’re more confident taking risks because you know you can solve problems, and you build mutual respect.
Not everyone wants this kind of responsibility – but we hire the engineers that do! We want people who thrive on ownership and who are leaders, who are proud of their work and want to own it to the end.
Three ways to code a culture of trust
As I said earlier, the integrated model itself isn’t unique in the industry – but how we implement it comes down to three key elements:
- Ownership: we made a commitment to a vertical model of code development, code quality, deployment and response – every engineer works together and takes ownership in the final product.
- Leadership: our leaders throughout the organization lead with trust, teams have full reign to make decisions and take actions necessary to ensure success. There is some oversight but no micro-management or heavy-handed bureaucracy. The code word is trust.
- People: We hire and train full stack developers, but more importantly, we hire people who share our values and excitement, and who want opportunities for growth. Our interview process is coded to hire the right people.
If you’re an engineer, you want a job where you can flourish – where company culture comes from the bottom up. At PagerDuty, we know that when developers own their code and are well supported to do their best work, everyone wins.
We currently have engineering openings at all levels in our Portugal location. For information or to apply please visit PagerDuty Careers.