SPEAKER

Sri Viswanath CTO @ Atlassian

Sri Viswanath is the Chief Technology Officer (CTO) at Atlassian. Sri joined the company in January 2016 and is at the helm of Atlassian's cloud-native journey – assuming responsibility over the building and scaling Atlassian's cloud platform. Before joining Atlassian, Sri served as CTO and senior vice president of engineering at Groupon, the vice president of R&D for mobile computing at VMware, and the senior vice president of engineering at Ning – where he was instrumental in the company's acquisition by Glam.

"Put people first. Hire amazing talent and give them the resources that they need and the autonomy that they need. And let them do the best work of their lives."

<cite>- Sri Viswanath </cite>

He also led the development of a number of very successful open-source and B-to-B products at Sun Microsystems, served on the Board of Directors for SendGrid, and has a number of patents. Sri currently serves on the Board of Directors for Splunk and holds a M.S. in Management from Stanford University and a M.S. in Computer Science from Clemson University.

This Episode Is Brought To You By...

Listen to our Bonus Episode: Fundamentals of Building an AI Organization with Maia Brenner!

A great conversation covering the fundamentals to building an AI org, common challenges eng leaders face investing in AI, understanding feasibility/impact & ROI, how to break down massive AI/ML projects into small experiments and more! Listen HERE

Ready to own your AI Strategy? Learn more about Tryolabs HERE

Special thanks to our exclusive accessibility partner Mesmer!

Mesmer's AI-bots automate mobile app accessibility testing to ensure your app is always accessible to everybody.

To jump-start your accessibility and inclusion initiative, visit mesmerhq.com/ELC

Show Notes

• Sri’s people-first approach to leadership (1:50)
• Why “putting people first” is key to building autonomous teams (3:17)
• How Sri operationalizes his approach to leadership (4:35)
• What processes should you prioritize first, to build autonomous teams? (9:31)
• Common & counter-intuitive process changes for engineering leaders to assess (15:32)
• How Atlassian leverages "pre-mortems" for major projects at Atlassian (20:29)
• How Atlassian’s engineering culture creates transparency at scale (22:22)
• Where to start with building your own engineering handbook: principles, prioritization, & process (24:29)
• Atlassian’s approach to engineering career growth & “Project Pascal” (32:20)
• How Atlassian defined each role in it’s engineering career ladder (39:48)
• How Atlassian formed cross-functional working groups to define different roles (42:23)
• How different opinions were included in Project Pascal (43:38)
• How Atlassian incorporated feedback to improve it’s career framework (46:08)
• Rapid Fire Questions (48:15)
• Takeaways (54:15)

Links & Resources

• Atlassian's Engineering Handbook - a guide for autonomous teams
• Atlassian's Project Pascal - Atlassian Engineering's Journey Mapping Out Growth Profiles

Transcript

Sri’s people-first approach to leadership

Patrick Gallagher: Sri welcome to the Engineering Leadership Podcast, we're really excited to dive into this conversation with you.

Sri Viswanath: Thank you, Patrick and Jerry! I've known you for a while. I'm excited to be here!

Patrick Gallagher: I want to share with you Sri this story really quickly... because there's something really timely that's happened in the last two weeks that have made this conversation particularly relevant.

So we host a couple of different peer groups. And back to back this week, two things have come up that are very topical to our conversation.

So one group had brought up and dove in pretty deeply into "how do I build a career ladder and how do I figure out levels? And how do I develop a growth plan for my engineers and the engineers on my team?"

And then yesterday without getting too deep into some of the details of the story, the big question came up was, How do I define process or define how we do engineering here to make my teams more autonomous?"

And I was like, man, these are really great questions to come up because I know just the person who is going to be great to have some answers here!

Thank you ahead of time for sharing your insights and advice.

Sri Viswanath: You're welcome.

Patrick Gallagher: So I know we're going to get some specifics about how you typically operationalize your leadership approach. But I think to start and to kind of orient everybody here to the conversation, is there any way that you could quickly summarize your leadership strategy for us? What's sort of the high-level approach you take?

Sri Viswanath: Absolutely. My leadership strategy is to put people first. My job here is... hire amazing talent and give them the resources that they need and the autonomy that they need. And let them do the best work of their lives.

Why “putting people first” is key to building autonomous teams

Patrick Gallagher: Was there experience or a moment that really helped make that clear for you? In that like "People first and then invest in them" is the most important thing that you should do?.

Sri Viswanath: Absolutely. So, that's been the case for a long time in different companies. But even more so at Atlassian. First, let me tell you why that is. And then I'll give you a specific example.

It's first of all, important to create an open and transparent culture. Because you can only have autonomous teams if you have an awesome engineering culture.

So, you all have heard "culture eats strategy for breakfast." So I make it bigger by saying "culture eats strategy for breakfast, technology for lunch, and process for dinner."

So it's all about the culture. And culture is made up of people and how they behave. As leaders, the thing that we need to do is to figure out how we can have a closed-loop system, where you have constant learning...

What you really want is to be able to have a culture, processes, and strategy that helps you to be able to acknowledge failures and learn from them.

That's why this open, transparent culture is extremely important, to be able to create these autonomous teams.

How Sri operationalizes his approach to leadership

Sri Viswanath: I need to describe the story on what happened and how we handled it because it played over a certain period...

So this was about three years ago and we had finished a major project called Vertigo. I won't go into the details right now. But we had finished a major project called Vertigo. We had multi-cloud and after that for a year, we had started developing features on this new cloud platform.

And three years ago our SEV 1, SEV 2 incidents started going up like creeping up and it was not good enough for us as a company. Especially for our customers, incidents are really bad. Like it's hard on people internally, but even worse with customers, which you don't want to have incidents.

But it's a gray zone, right. You're having one incident per week maybe, or maybe once a month. And then it creeps down to three weeks. Then it comes to two weeks. There needs to be a moment where you have to figure out, "Oh wow, that's not good enough."

So what happened three years ago was we had this uptick in SEV 1 SEV 2 incidents, and we called a five-alarm fire. And when we call it the five-alarm fire, we knew something was wrong and we had to fix it. But we really didn't know exactly all the things we needed to do.

It was a moment as the saying goes... "never waste a crisis" because you can do things that you can't do in status quo mode. So what we did was, we went back and we did a number of things to be able to set us up for the long-term better trajectory in terms of things.

And all the things that we did... and I'll describe to you the number of things that we went through... would only be possible if we could create an open, transparent culture. And also, I guess the process that we chose led to autonomous teams. The very first thing that we did was we had to define the priority, right? It's extremely important for the teams to understand... there's always 10 things coming to the teams and they need to know, "Oh, there's like 10 things, which one is higher priority."

So the first thing we did was to clarify the priority for teams. And we said, security is number one, reliability is number two, and then everything else.

And every single person in the organization knew this, including not just in engineering, right. It's important to have everybody in the company bought in. Right? When you think about a technology company, literally the whole company needs to be aligned with the priority order.

So if you had asked the executive team, our marketing team, they would have all said for the technology side of the house, it's security number one, reliability number two, and everything else after that.

So that was important. So we defined the priority.

Second, was to go back and figure out the process changes. So we did a number of process changes. And the process changes, we didn't want to have processes that are mandated top-down. "This is what you need to do. And otherwise you get fired." Right? That's a bad way to approach a problem.

What we did was we wanted each team to disclose themselves and to be able to self-correct themselves. So we started these tech ops meetings that happen in every team, every service that runs.

And each of those services, they meet And they all discuss "What went wrong, what incidents, how do they improve? What are the SLO's are they trending towards it? So there's a specific focus on reliability in those tech ops meetings."

And we made that a cultural thing across the board that it's the right thing to do. And we also have an aggregate tech ops meeting, we call it World.

And the goal for that was learning, right. It was to learn between different teams. And we also encouraged teams that if they had an incident and they learned from the post-mortem to be able to blog.

And we use, of course, at Atlassian, we use all our tools. So Confluence works extremely well. So we blog every single learning across the board. And that's been huge for us to go from, we were an on-prem company before I started and we had to go " you build it you run it" model to microservices and cloud-native platform. Having this Confluence as a blogging platform and having an open culture has been amazing.

Today, if you zoom forward, the five-alarm fire has morphed itself into a... we call it the X-alarm fire, which is like every team, if they see that they get into this gray zone where their SLOs are not trending at the right direction, and they're not hitting the goal... they're hitting the goals, but they really want to be better. They themselves declare a two-alarm fire, or a three-alarm fire, pause feature development for a week or two and then work on these improvements where they can reduce the debt. And then they continue with their feature set.

And that's not something that's top-down, each team's doing it themselves. And that's been pretty awesome to scale up the organization.

What processes should you prioritize first to build autonomous teams?

Patrick Gallagher: There are a lot of follow-up questions here Sri, to begin... so I wanted to recap really quickly... I think you painted a really beautiful picture of the objective here is to create autonomous teams. And to be able to develop a process that can help lead to that. And to create the system that allows for teams to operate autonomously.

And so I want to go back to what you talked about, prioritization. That was the first thing that you decided that you needed to focus on.

What was the framework for how you thought about what to prioritize first? Like why did you choose certain things first?

And then I think the other part that I think is really interesting is how did you create that alignment for that priority across the entire engineering organization?

Can you tell us a little more about that?

Sri Viswanath: Yeah, absolutely. We'll talk about what we chose for priority. But in general, as engineering managers, as product leaders, as technology leaders... the thing that you need to start with is the highest level, right?

So what principles are you operating in, and what priorities do you have for the organization? Because if you are very specific in terms of these are the only three things that you do. Then people only do those three things. That may or may not be the right thing to do. So start with principles.

So what we did several years ago, before this happened we defined four principles for us as an organization. And I'll describe a couple of them. But I blogged about this in the engineering overview blog And there's also a handbook that describes some of these processes.

So we chose a couple of things, but it all depends on the context of different companies. As a leader, you need to figure out what's most important for you. What principles do you stand for?

There's always going to be company values, which is always the thing that you need to follow. And then are there other things that you layer on as part of your organization that makes you more effective?

For us, we chose four things and I'll describe a couple of things. One is customers. So we said, "customers are our lifeblood and we act accordingly.

And what this meant was, we have a company value for customers, but we want it to go one step further. Because you want engineers to be close to customers. And there are always cases where, oh, "I have this feature to work on. I have this other thing to do, which one is better."

And if the thing is, oh, if your product is down or if it's hacked... Then there is like huge pain for customers. Then it's the priority becomes easier. So these principles actually help guide the prioritization.

So we said customers are our lifeblood so even for innovation and to have a non-linear kind of impact on our customers, you need to have every single person in the organization "think customers." So we chose customers as our number one principle.

The second thing we wanted to do was to be able to create these autonomous teams, right, that was an explicit, intentional goal. So our second principle was we have a "radically autonomous and aligned teams."

And there's a lot packed in this. The obvious thing that comes to people's mind is we are loosely coupled, highly aligned. We want to have these because we are in this microservices architecture, each of the teams needs to be highly autonomous so they can run on its own. So that's the first level of autonomous, right? So that is straightforward, understood.

We went one step further to have the practices. The radical part of "we want to be radically autonomous" is each team wants to be autonomous and their job is also to make the dependent teams autonomous.

If you think about it that way, then what they have to do is not just say, "Oh yeah, I don't want to talk to anybody else. I want to run on my own." Where you have this chaos in the system where everybody starts running off in different directions. Like you don't want that. What you really want is you want these teams to enable other teams to be autonomous.

So, what we did was, that's why we define it as radically autonomous. Which means your job is to make sure as a team... let's say you're a 10 person team to make other dependent teams to be fully autonomous. So they don't bother you.

So you are actually autonomous because they are not bothering you. You write your documentation. You make your APIs better. You make sure that your tests are run so that you don't fail, so they don't bug you.

That actually helps to be able to scale much better.

Patrick Gallagher: Jerry. Do you have follow-up questions or other comments? Cause I saw you shaking your head like in earnest excitement throughout the entire response.

Jerry Li: I'm just so excited to hear all of that. And because we've been thinking about it for our own team, I feel like this is an approach that almost any organization can take it and implement. And this is really new in terms of new perspectives not only make your own teams but your dependent teams autonomous. So that's a very good constraint to think about.

And also the thing you mentioned earlier " highly aligned, but loosely coupled."

Those are the quotes that we'll be writing down.

Sri Viswanath: Yeah. And the other thing to notice is like, it's easy to say certain things... right, like the "DNA change" "culture change." If you just type in an email and say "Yeah, you have to do it this way."

It just doesn't work that way. It's not effective. Not because people are trying to avoid the things that you want to do as a leader. You tell them, "Oh, this is the direction we want to go...

As a leader, what you need to do is to be able to unblock how they operate. So that's where the system comes into picture. Right? So you want to make sure that they have the right processes in place and systems in place so that if they're like, "Oh yeah, of course, I want to do this, but I have this other priority"

They need to have the priorities sorted out. They might be like, "I want to do this, but I don't know how to do this."

So you need to have processes laid out or automation done so that it's easier. And the friction for doing a new thing, you need to automate that and tool it so that it's much lower. So that you can actually steer in a different direction, not status quo that you had.

Jerry Li: Yeah, I really liked the approach I just solving a problem by tackling the core of the problem, Sri, I wanted to go back. So the point you brought up was "process changes." And you shared a couple about the different tech ops meetings that helped with some of the areas of process changing.

Patrick Gallagher: So I want to bring this up because one of the engineering leaders we're working with, one of the questions that he brought up was, you know, "how do we improve process?"

So the sort of the simple summary is CEO says we're not shipping or as productive as we need to be. It's a smaller stage company. So the engineering leader's like, "Okay, let's look at our process to figure out how we can better develop and be efficient."

And in his mind, he's like, "Oh man, I know the goal is to be able to bring in any engineer who's new. And so that they're autonomous right away. And how do I do that? But he's like, "I don't know where to look or where to begin looking at process."

So when you think about process changes; so you mentioned some of the tech ops meetings; are there certain ones that you would prioritize or certain process elements that you would say you could probably look into this and find some inefficiencies or better ways to work?

Or an area in the process where you could probably better empower somebody to make an autonomous team? Is there anything that kind of comes to mind for you there?

Sri Viswanath: Yeah, there is a lot in your question, right? We could spend hours talking And the reason is... If you ask a higher level of question on... "is your team, highly effective?"

Right. That's a pretty complicated question. There's a lot of dimensions to make it right to become effective.

There are some common things that happen in engineering that managers can actually look at. One of the things that we have done at Atlassian that probably is unique, is to be able to measure KTLO, right? "Keeping The Lights On," the debt that you have, and how much time do you spend on working on things that don't move you forward versus the things that can move you forward.

Right?

So we explicitly measure that for every team. And that's been huge in terms of... and this is not direct answer to this. The reason I'm saying this is... these kinds of measures and having measures for the team helps you to make those decisions. Because first of all, as a manager, as a leader, you need to understand where the bottlenecks are and for that you need visibility and you need the teams to tell you what's wrong. And that's where the open transparent culture helps.

And for me, Atlassian has an amazing culture. And in fact, I talked about failures and failures are okay. And that's not an easy thing for anybody, right? So, because many of us, definitely for me, I was brought up in a school system where it's like, you can't fail. You need to get more marks, more grades to be able to get the better school and better jobs.

So in the work environment to understand that, "actually I should be okay with the failure and let's figure out how to learn from it."

And it's also okay to disclose it to other people and having a culture where other people respect that, "Oh wow, let's figure out, how to get better as a team, as an organization."

That closed loop is extremely important. Right? So that's step number one.

If you have that and you have the visibility of what you want to improve, then it helps you to make those things better.

For example, one of the things that most people talk about is a post-mortem right? So you always talk about, "Oh yeah. When an incident happens or when you finish a project, do we post-mortem so you can learn from it." That's a great thing. You should do it.

But the counter-intuitive thing that most people don't think about is when you start a project. When you start a project, most people are... let's say it's an awesome project. It's exciting. People always jump into it. And they're like, "Oh wow... We absolutely have to. Everybody's rallying. They're all running towards direction. But nobody stops to think, is the project really going to be successful? Will it be effective?"

So to the open, transparent culture, we have published all our playbooks Atlassian playbook.

One of the place One of the plays that we really like, and I personally like is what is called the "pre-mortem." Before the project starts, you collect in a group and you figure out what might actually go wrong in the project.

So that actually helps you to figure out, "Oh wow, we can fail this way. We can fail that way to add countermeasures and counterbalances to not fail the way that you want."

There are a number of places where as a leader, as an organization, you can figure out how to change things or change processes. It's good to think about early in the process, not just later in the process. Which is normally what happens.

And that's why I like this pre-mortem and the principles, which are at the head, at the start of the cycle. So that, that helps you to steer in the right direction from day one, not panic towards the end.

Patrick Gallagher: I love the playbooks that you mentioned. This is a side story about me. My favorite place in the world are workshops. So when there's the playbook to spell out like how to address common challenges in the team, and here's some workshop style tools that you can introduce into your teams, including the pre-mortem...

And I know that there's a few other sort of facilitated conversations you can create with folks that are really effective... So that was just a side comment that the engineering playbook is incredible for helping facilitate productive conversations with engineering teams.

How Atlassian leverages pre-mortems for major projects

Jerry Li: I have a follow-up question about the "pre mortem." I'm curious to know to what extent at Atlassian, people leverage that approach?

Sri Viswanath: Yeah, good question. The "pre-mortem" is most useful for large projects that are cross-functional. And that's where people are like not thinking the whole big picture on all the things that might go wrong.

They're looking at their SLA like, "Wow, I need to build this amazing service that scales to like 10 million users or whatever."

And it feels really exciting and they're like full on going to build it. But you step one level higher and say, "Would actually customers use this service or what's the value that we are bringing? What happens? What are the failure scenarios?"

You might uncover that it's actually not the right thing to do. You might want to change direction. So it's important and not get caught in the moment of excitement. So it helps in large projects.

For smaller projects or sprints, that's a different thing, right. There are other checks and balances.

The thing that I really liked is the product managers, engineers, and designers need to work well together.

It's not like a product manager write some specs somewhere and designers write some marks and ship it over...

If they really operate as a team... because they come with different perspectives and you won't have a group thing to all the engineers sitting in they all get excited, but product managers may be like, "No, our customers are asking like this."

So the team, when I say a team, it's not just the engineers, right. It needs to have everybody that needs to make the project successful. And that's the team I am saying like for smaller execution cycles, that team needs to meet every so often. It's whether it's the sprint cycle or however different teams do it.

And that's something that happens all the time in Atlassian.

How Atlassian's engineering culture creates transparency at scale

Patrick Gallagher: You mentioned a couple of times to the conversation Sri about transparency and transparency at scale. And you've mentioned Confluence and a lot of the ways that your teams have leveraged that as a way to sort of create transparency at scale.

Can you tell us a little more about some of the stories and examples of how you use that tool to, create that transparency across all of the different team members.

I'm just curious, because as a communication tool for the amount of people on the engineering team at Atlassian, it seems like it'd be really hard to engage all of those folks in a decision or...

Sri Viswanath: Yeah, no, It's other way around! In fact, Confluence is used by every single person across Atlassian. And the beauty of this is you can ask me what happened? Why did that thing fail? Or what is happening?

I can go look up and tell you right now about all the things... Like I talked about, this five-alarm fire, I can show you blogs the different teams stored. And I talked about x-alarm fire. I can pull up the blogs on what their learnings are.

So the beauty of this is because we have all these different teams blogging about their learnings. It's all in one knowledge management. It's in our Confluence. And the new person coming in when somebody says, "Oh, we have this two-alarm fire."

And they're like, "Should I ask 10 people?"

They can just go into Confluence and search. And they actually get these blocks where they can look, "Ah there's this context!"

And that blogging culture internally and being open and transparent...

And it's not just about technology, right? It's about technology. It's about strategy.

I have a blog that I blog every so often for all the things that we decided at the company level and at the team levels. And that's extremely good communication in terms of it's there and if somebody joins tomorrow, they can come back and look at all of the things that we have done in the recent past so that they know what the trajectory is and how we are as a culture.

So it's great for technology things and just architecture and connecting different people across different silos. It's also a good on the people side of things. It's great in terms of strategy and communications. I would say it's like a communication spine across Atlassian and lots of our customers use that too. And that's been super powerful.

Where to start with building your own engineering handbook: principles, prioritization, & process

Patrick Gallagher: I had one other, question, and this was sort of my reaction in diving into Atlassian's engineering handbook because I'm a total resource nut. I've written a number of different guides for different programs and things.

So when you stumble across a very well-written guide that operationalizes really great culture, you pay attention.

And so when I was looking at the categories of the things that ya'll talk about. You define how you work at Atlassian. How everybody stays informed and the communication protocols. The software development process, and how things are shipped. And then all the way towards like the, how the things are operated and maintained.

So when I'm reading this, I'm like, "Man, everybody should have this type of documentation that defines all of these things!"

Because oftentimes they're implicit and not described. And it makes it really hard for people to figure out, "well, how do I work effectively within this group?"

So when you're looking at all that, I think like the big question I think I'm trying to figure out is if I'm working with somebody who has, you know, maybe a 50 person team and they're like, "Shoot, we need to reinvent everything. Nobody knows what's going on. We need to define this..."

Is there an MVP of those categories? Or like the most critical information you would include to help empower people to move towards more autonomous teams? Like, I guess what's the most critical information that you want to make sure they answer

Sri Viswanath: Yeah. So I talk about what they need to consider. Like they can take different pieces and write their own. And I have some startups who are much smaller who are thinking through and saying, "Wow, these are good categories, but we don't want to do exactly what you do."

And that's actually true, even for us! We haven't talked about our people side and we can talk about that.

We rolled out a process recently on how do we do career growth and growing people. called Project Pascal. And when we did this Project Pascal, there were lots of places where we could do everything at once or we could do incrementally and the incremental aspect of let's start with something and then grow from there is important.

So my advice for people is start with something, write something, and create a culture where people can add input to that and keep revving it up because the hardest part is to start with a starting place and then create a system and process where it can be improved over time.

You don't have to be perfect. In fact, we weren't perfect on many of these. And even today, if you ask me, there are a number of places where it's like, "Yeah, it says that, but we're actually working on the next system, which is completely different."

So that's the higher meta-level.

The other thing to also consider there is, not to make it top-down. Because it's easy when you think about processes to make it top-down.

And if you read the handbook, many of the things that we do at Atlassian is at the team level and for the teams. We don't have check-ins where they can't ship without talking to architects or without talking to somebody.

There are those reviews, but mostly to help them learn and not as a, "Oh, here's a gate, you can't pass through the gate if you don't have this criteria."

And that's true, even for SLO's and the reliability and security things. We have different teams own the security scorecards, and it's their goal to improve that to a higher number. But it's not like somebody is going to stop them shipping anything if they don't hit that number.

Patrick Gallagher: You brought up Project Pascal. And so we're definitely going to get into that in one second...

Just one more quick follow-up question. So, you said principals and prioritization as like the first place makes it really easy to build off of, in alignment with your company values.

Is there another section you'd have somebody start with to do this, to start with something outside of defining your prioritization and principles first? Is there another part that you found more helpful than, you know, more helpful, but like, you'd say that's probably the next thing you'd look at?

Sri Viswanath: Yeah. When you talk about process, there are places where you want the process to be well buttoned. And the areas where you want the process to be really well-oiled is in security and reliability.

The security incident management process, or the, just the incident management process... you want that to be highly documented, prescriptive and teams to be having the muscle and having these desktop things and trainings and making sure that they understand what happens when an incident comes because that's how you start reducing time to recover and time to detect. And you want to make sure that that process is highly structured and is in place. Especially for all the cloud companies that want to operate at a pretty high scale.

Atlassian's approach to engineering career growth & "Project Pascal"

Patrick Gallagher: let's get into Project Pascal because this is something, you know, Jerry and I were looking into this and it was like, finally, you know, something that is well-documented that helps us. Cause this is a question that's come up at least twice a month in these different peer groups is I need to build my career ladder, I need to help support the growth path for the engineers and engineering leaders on our team. And this was one of the ones where we read it and we're like, oh my gosh, this is amazing!

So can you rewind a little bit Sri and tell us a little bit more about the origin story of Project Pascal and your approach and philosophy around the engineering career growth and growing the people on your teams.

Sri Viswanath: Yeah, absolutely. Yeah. So, zoom back to earlier 2017...

We were fast-growing back then too. And we were adding a number of people in the organization. And just like anybody else, if we were in a large audience and we had a thousand people in the audience, and if I asked people to raise their hands "how many people have a really good career ladder in your company?"

Like nobody would raise their hand. Like, it's really hard to build this.

So we knew it was hard to build. And even in my previous experiences, we've all had some versions and it really doesn't work as well because it doesn't answer and we'll go into the nuances and what happens.

But we knew that was the case and we were growing fast and we wanted something in place. Right.

And the reason is employees look for clarity. They want to be able to grow in their careers and they want to know "How do I get promoted? How do I change roles? And what does it mean by I get this rating? And what areas do I have to improve?"

You can't answer those questions consistently across the org as you scale unless you have some framework like this.

And as a principal, we wanted to start from there and start improving.

And the other thing that happens in many companies is you want to roll out to the whole company all at once. And there are lots of roles in the company and the company is growing... it's actually extremely hard to just plop something in and say, that's how it works for the next 10 years. Right. Which is what happens. And it really doesn't work. So we want it to not take the big bang approach. And we wanted to go incremental.

And the thing that we had in mind is we knew we had to outline these growth profiles. We wanted to have it so that it can improve on its own. We knew we would grow to 5,000 people, 10,000 people so it had to support at scale. And over time, it had to be a framework and had to have the principles that we had earlier on all the four things that I mentioned. It had to have those in it. So we started off with let's build some framework that incorporates those things into the framework.

So when we started working on this, the first thing I say is to make sure that you have an amazing HR partnership. The best thing that we had in, when we started Project Pascal was to have an amazing HR business partner. If Ozden is hearing this, she'll be cheering and she'll be like "Yay! It was awesome!"

Cause that collaboration between HR and the team is supercritical. Otherwise, you won't get that right. Because both sides have to understand the constraints of what can and cannot be done.

And there are lots of frameworks in the market. You can take something that's generic and plop it in. That may or may not be most effective for you as an organization.

So different companies have different constraints. So we were a pretty distributed organization, even this was like before COVID and everything. We were very distributed. We had lots of people working from home. So, we had it set up where we tried to work on multiple geos and multiple levels in different scaling organizations.

So we had our own constraints. So we started off with what constraints do we have and what kind of career framework do we do?

So we started with let's build the expectations for the role. Let's figure out what it takes by going from one role to the other. We started with engineering roles.

And we knew there were other roles. There were SRE roles, there were testing roles, there were product management and designers. And we said, "Let's focus on one and get that right. Or at least workable. And then we can expand it to other things."

So we focused on those.

We also had principles on, we wanted to make sure we had a dual career ladder, which is extremely important. You don't want all ICs at some point to say, "If I have to grow, I have to become a manager."

So you want to have the levels parallel, at all levels in terms of P ladder and M ladder. Like the IC and the management ladder.

So we had those principles in place and we had to define all those. So we had working groups for each one and we had working groups for junior and for senior.

We didn't try to boil the ocean. we focused on the lower level starting with, "How do we get a new engineer coming into the organization? How do we grow them to the next level and to the next level after that?"

So we focused a lot on those lower levels of the organization.

We came up with the framework. And then there was the question of "How do we roll this out?" Because it's important for it to be successful because you might have the perfect thing that you think is perfect. But if you don't roll it out properly and you don't have this mechanism... especially given the technology organization always has opinionated people, and you want to be able to hear those concerns.

And there may be edge cases, but you need to be able to figure out what it is and to have this dialogue.

So we wrote that framework. We published it. We piloted in a small group for a quarter. And to be able to get feedback. And then we rolled it out for the larger organization. Of course, we had blogs, we had town halls and we had special AMA sessions. We did a number of things to be able to get that in place on day one.

And then we also had a couple of other things that we wanted to do after that. Which is, this happens in many companies. Like you put some strict processes in place and then people like, "Oh, it's so hard to get from this level to that level. It's actually easier to hire somebody from outside than getting promoted inside."

And you don't want that.

So you want it to have checks and balances, both for promotions and also for external hiring. And we don't want it to have a top-down process for external hiring vetoing managers and having a "bar raiser", that was Amazon's bar raiser program, which actually has lots of good qualities in it.

We tuned it a little bit to have what is called a calibrator role. And what the calibrator does is this person sits... a senior person who has done interviews, just like a bar raiser. But that person doesn't do interviews but helps with the debriefing of the candidates.

And to be able to say, these are the kinds of questions that I need to ask, and this is how you need to decide. And that helps us scale and make and train all these different managers across the board.

And that calibrator role has actually helped us a lot in terms of just getting uniformity, both for internal promotions and also for people coming outside.

So, zoom forward today, Pascal has become like the core piece of how we do performance management. We also have this manager training called AMP "Apprentice Manager Program" hiring the shape of the org and how we decide to unveil to hire. And how do we have the right mix?

It's been awesome to roll that out. And we have also expanded it for different roles.

And again, it wasn't perfect the first time. And it's not perfect now. And it keeps evolving based on the needs, but it's important to start somewhere.

How Atlassian defined each role in its engineering career ladder

Patrick Gallagher: Such a huge story. So I think the thing that stands out to me as you shared this Sri is that there's so much thought at every level to define all of the different components. I think the first question. So I wanted to make sure I got the understanding, right?

So you took the engineering principles and then essentially for each role, define what those looked like, for each role, in addition to then like expectations and things like that was that like the first place that you all started.

Sri Viswanath: Kind of, yeah. So let's pick a role, let's say M3 roll or a P5 role. For that role, we said, these are the things that we expect from that person. Right from that role. And then we wrote that as a table for every level. And there's another table that says, what does it mean by going from this role to that role?

Right. Just as an explanation, this is what it takes to go from a P3 to a P4 or a P4 to a P5. And if you look at the table, the P5 I mentioned,

It talks about, these are the kinds of things that you should know. And we didn't want you to be, if you don't do this, you can't get to the next level.

To get to the next level, they have to be doing most of the things at the next level.

And there's also any, especially in the management areas to say there needs to be an opening at that level, right? You can't just promote somebody to a Director if there's no Director scope for the roles, right. Even though they may be operating.

So it's important to have other systems in place where people need to be able to move across. So the internal mobility program is, becomes extremely important. All these other programs hinge off of this main Pascal framework that we have.

And for each of those, we had to build out certain things for internal mobility program. We had to have a process that was hanging off of Pascal for amp program that I mentioned for manager training... there are lots of IC's who wanted to be managers.

But just looking at the blog and saying, "Oh yeah, I want to be a manager. I think I can do all this." a manager role is very different from an IC role, just in terms of satisfaction and what happens every single day. It's a completely different life.

So this apprentice manager program was like a program where ICs can try out to be a manager without feeling like a failure if they went back as an IC. So we have a number of people who have tried a management role and said, "This is not for me. I don't get job satisfaction. I want to go back to an IC role. And this facilitates those.

So we built out all these different things around Pascal after we built out the core framework.

How Atlassian formed cross-functional working groups to define different roles

Patrick Gallagher: I had one other question about the working groups... to get a quick sense of who was in those groups and how'd you assemble those because I think it sounded like they played a huge role in defining the expectations for each of those rolls.

Sri Viswanath: Absolutely. So, we had a mix of people in the role. So we had HR BPs in there. if we were, let's say defining a P5 role, we had P5 engineers and P6 engineers. And some P4 engineers who have been in the company or have seen other companies. So we definitely went with a mix that had a diversity of views and thought. And we also wanted to make sure it does cover different regions, different gender, different views of things.

So it's very important and this is not just for this. Any team that you create, the diversity aspect is very important, right? So it eliminates group think but it also, the overall the results that you get at the end of it is much, much better.

So whenever you create a team, it's just not because, "Oh, we have these five people who are free they can do it next week. Let's just do this project."

You need to be intentional in figuring out "What's the best composition that we can have?"

And make sure that you get to the composition. Otherwise, you do get suboptimal results.

Patrick Gallagher: Absolutely.

How different opinions were included in Project Pascal

Patrick Gallagher: Sri, one of the things that really stood out to me, it was how thoughtful the approach was on the handling of critics throughout Project Pascal and the result of the rollout, was really, really, skillful. In that, you sort of roped people... and not maybe roped people in is the wrong term, but you sort of involve people then afterwards to help turn their criticism into helping evolve it.

Can you tell a little bit more about what happened after the launch? When people said, "I don't like the way this looked" What did you do?

Sri Viswanath: Yup. there were some hard choices that we had to make. We eliminated a management layer level. We leveled it, the P and M roles slightly different from the company because that was the right thing to do.

So there were actually some harder changes that we had to make as part of this. So there were lots of opinions.

The thing that we did, and in general, the thing you need to be proactive. And it takes a lot of time to be able to explain, because there are lots of nuances, even in our discussion. There are so many things that we could talk about, and it's easier to say the higher-level abstract thing. But when you go the next level down it's like "Oh, wow, you can't actually do this, but if you do this, those are the three things that happen."

So it's important to have the time and to be able to spend those. And these working groups and the people who are involved were amazing in terms of helping with that. So the working group actually helped us to be able to scale and explain the answers to the larger organization.

And they were being champions in terms of updating to the next round and to be able to do this. That's why, this open, transparent culture, and having these working groups that can help us, not just during forming of that, but also afterward as a sustainable framework.

I think it's important to think through and carve out time for them because that's an important thing as an organization. If people are first, we need to be able to spend time on people. And to be able to improve and have the culture so that we can make those changes afterward.

So the rollout was not easy. It was actually lots of questions and opinions. And this happens in every organization.

The thing is after let's say six months, or you run it once in terms of performance cycle year or two years from now... has it worked or not?

And if you ask people at Atlassian after a few years... we're still improving, but it definitely has become the core pillar of everything else that we do.

And if we hadn't done it, we would be doing these ad hoc programs. And would it be so hard to be able to coherently explain and for new people coming in, it's been pretty amazing.

Patrick Gallagher: I can only imagine the complexity of an ad hoc program at the scale of five to 10,000 engineers, engineering leaders and related people.

How Atlassian incorporated feedback to improve its career framework

Patrick Gallagher: I have this image in my head of somebody receives, you know, the announcement of Project Pascal and they're like, "Man, I don't quite agree with this leveling. And then they share that."

And then the image I have is somebody reaching out to them say, Hey, you have some really good constructive feedback. Would you like to join this working group and get involved in help 2.0 of this or the next evolution?

Is that sort of what happened when somebody had feedback is that you involve them then in helping construct the next evolution?

Sri Viswanath: Absolutely. So people are not shy at Atlassian to give feedback, right. That's number one, which is good because that actually helps us to get better. Second is even the rollout, we brought the people managers into the mix first and explained it to them. We took a week or two to be able to explain it to them because it's important because they'll have to explain it to their people in terms of if they are changing levels. Or if you are moving to a different system.

So the layered communication is extremely important in terms of, to be able to bring more people in and to be able to tune it and adjust it. We found out in one of the communications that we hadn't really explained it well. So it took some polishing then to be able to get those FAQs to be built out as we rolled it out.

The other thing that we also did was we did a video. Especially in this remote world, it's important to have different mediums of communication, audio, video, and text is extremely important. So we of course had all the documents. But we also did a video to be able to explain how things would work. And those all helped out. But we created Slack channels we pulled in people who had strong feedback to be able to participate in the next level of it.

So all that absolutely helped out

Patrick Gallagher: That's so great. And I think it's so in alignment with what you talked about, the beginning of like the development processes. Is it shouldn't be a top-down approach, but the more people you involve, the more buy-in that comes in. And I think that's just a really skillful approach to developing culture.

Sri Viswanath: It may be easier to say, oh yeah, this is how we do things. And it may seem efficient. But it's actually less efficient in the long-term because people are not bought in, they're doing their own thing or they leave and you have higher attrition, which means you have to hire more people. It just hurts in the longer term that you don't see immediately.

Patrick Gallagher: Absolutely.

Rapid Fire Questions

Patrick Gallagher: Well, Sri, I know we're coming close to the end of our time. And so we have some rapid-fire questions we were hoping to close off with. So if you're ready we've got a couple of rapid-fire questions for you. Awesome. Okay.

So first question. What are you reading or listening to Right now?.

Sri Viswanath: Yeah. I read lots of books. Currently, I'm reading "Engines That Move Markets" by Alasdair Nairn. This is all the technology trends in tech history. So it's fascinating to see how the choices that they made and how the markets moved so that we can make the right choices moving forward as part of your strategy.

Patrick Gallagher: Wow. I love that. I'm going to, I have a gift card to a bookstore and that's going to be probably the top of the list. That's fantastic.

What tool or methodology has had a big impact on you?

Sri Viswanath: I would go back to Confluence. It's been amazing to see how Confluence actually has changed our culture. Even more to become more transparent and open. " Open company, no bullshit" is our company value, but the real way that we implement is through Confluence.

Because having Confluence and every page that you create is an open page that everybody can look at and share feedback. And anybody can share feedback. When I write a blog, anybody in the company can add feedback and I respond to those.

So that absolutely helps out. So Confluence.

Patrick Gallagher: I'm really excited for this next question, based on the book recommendation that you just shared and the comment at the beginning about NFTs... so I'm hoping something crazy is going to come out of this, but so the question what is the trend you're seeing or following that's really interesting or it hasn't hit the mainstream yet?

Sri Viswanath: Yeah. So I would say a couple of things. One is generally data is in mainstream and everybody understands that data is important. AI becoming pretty popular in terms of all the news that you see.

There are a couple of things that are key in terms of how it evolves from here. And one of the things is running an AI system is actually pretty expensive, right? So just a number of things that you do.

So the thing that I'm closely figuring out is what's the next level of architecture that can make it better in terms of actually scaling out AI to not just in Atlassian, but in general in the market and what the trend could be.

That could be edge computing, where you can offload running these models to the edge and it's faster and it's customizable, personalizable to every customer or to a user or the company.

So edge computing. Absolutely.

And in the same AI space, the other big problem that AI has today is explainability, right? It's hard for people to say, "Oh, I got this. I don't know why I got this. I don't think the system works..."

because AI can take you 90%. And the 10% is always strong. And AI would be so much more successful if you can explain why you showed the answer you show.

And the explainability aspect of AI is fascinating. And I think that's going to get traction as we build out the models.

Patrick Gallagher: Gosh, two great examples, especially under the theme of Engines that Move Markets. I can see where your head is at. I love it. Okay. Couple more quick questions. What is your favorite or most powerful question to ask or be asked?

Sri Viswanath: That's good. So the people that I work with, I generally ask this question on "what do you want to be doing in five years?"

And it's a fascinating question because there are different kinds of people. There are some people who know what they want to be doing in five years. So they are like, "Oh, I want to be a manager. I want to be a leader. I want to be a VP of Engineering" or whatever.

And then it's easy to have the next layer of discussion. So if you want to be that in five years, Then let's figure out all the skill sets, all the things. And it also helps me as a leader to facilitate those and give them opportunities that can lead to that. That's number one.

There are people who don't know what they want to do. So if I ask that question, "Oh, wow. I don't know five years seems too long and I don't know how we can..."

And I leave it at that. But what happens is they actually keep thinking even afterward. And at some points "I remember you had asked me, I think I know what I want to do!"

So they come back after like few months or maybe whenever. And personally, that has helped me too.

Because when I did my MBA, I had a class it was called global entrepreneur marketing. Like Tom Costnick and the midterm exam was to say, "What do I want to be in 10 years?"

And I wrote that paper down and it's been hugely impactful in my life in terms of how what I chose is being more intentional in terms of what I want to do.

And so what do you want to be doing in five years has been pretty powerful.

Patrick Gallagher: Man. I can't believe that was a midterm. That's like, if you talk about midterms induce panic, that would be like panic. That'd be the five-alarm alert that you were talking about earlier.

Sri Viswanath: Exactly.

Patrick Gallagher: I really admire that, question. you know, talking about Jerry and I do a debrief every Friday and about every other week, he sort of, Jerry, this is something I admire about you. So I wanna acknowledge you here for this.

But he constantly is revisiting that question to ensure that, the things that we're working on together are continuing to move forward. And so I think that's just a really meaningful way. It's also connected. It makes me feel more connected to Jerry because I know he's a huge supporter in my corner in terms of being along that path.

So, Jerry, thank you for that.

So it's our last question. Is there a quote or a mantra that you live by, or a quote that's really resonating with you right now that you could send us off with?

Sri Viswanath: Absolutely. " If you improve 1% every day, you'll be 37 times better in a year."

Patrick Gallagher: There it is.

Sri Viswanath: It ties back into continuous learning, both in terms of the organization, and also personally, I guess, just reading books and doing something that builds your knowledge goes a long way. It's like, you don't see it every day, but after some time it was like, "Wow, I've learned so many things."

And that's extremely important in terms of just curiosity and also growth.

Patrick Gallagher: Sri, this has been an incredible conversation. Thanks for sharing your insights and learnings with us, and just incredible stories about the culture at Atlassian, thank you.

Sri Viswanath: Yeah. Thank you too. This has been an amazing discussion