The Software Architect's Path: Insights from Sid Anand

Transcript

Michael Stiefel: Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job. Today's guest is Sid Anand, the chief architect and head of engineering for Datazoom. He's also worked at PayPal, Netflix, LinkedIn, eBay, and Etsy. 

How did you become an architect? [01:10]

It's great to have you here on the podcast, and I'd like to start out by asking you, were you trained as an architect? How did you become an architect? It's not something you decided one morning you woke up and said, "Today I'm going to be an architect."

Sid Anand: Yes, that's a great question. And by the way, thank you for having me. I would say it happened organically. I think the title of architect was a bit aspirational for me, and I think it is for many other people. As a software developer starting out, I think there are phases of one's career. In the beginning it's all about gaining knowledge and learning from your peers and seniors. And part of that learning experience is getting exposure to different problems. And I was lucky enough to start my career around the birth of the internet. I graduated in '97 or so. I started off in electrical engineering and then moved into computer science. And at that time the internet was taking off, I would say like '98, '99, and I had an opportunity to work as a software developer in a team in Motorola, which didn't do a lot of software. It was mostly a hardware company.

And as I began learning, at some point I decided to go back and get a master's and formalize a lot of the knowledge I needed to be successful in that job. I came out, I had a good foundation. I started working in Silicon Valley. I started working for a company that built CRM software and I was in the systems team and I focused on performance. I learned that there was so much to learn, especially at that time as so many new technologies were being developed, that I realized I was in the first phase of this career and I didn't know how long it would last. And it turned out to last maybe 15 to 20 years of drinking from the fire hose. I would just say I extended my college education by 20 years, and every few years when I felt the learning rate was dropping off, I would switch jobs.

And at that time, the cloud didn't exist and a lot of the software packages that we used didn't exist, and a lot of things had to be configured manually, and a lot of the sophistication in our systems didn't exist or in the software development lifecycle. So I got to learn a lot about how systems work and how software's developed, how to ensure reliability and all the other ilities, and I gained an appreciation for that and I learned from those around me and definitely from those more senior to me. And I would consider that the first phase of my career of just learning.

At some point in my career I decided, or wanted, or I aspired to be the person leading others, because I felt I had gained enough knowledge about these systems that I aspired to be in a role where I could lead others and own the entire system. And very early on in my career, I had this goal that I wanted to be a CTO. And in order to be a CTO, I had to see how three different companies build systems. And I felt like if I had at least three companies, and for me those were eBay, Netflix, and LinkedIn, I felt at that point I could solve any problem, because I would know how each of these worked in all aspects.

Michael Stiefel: And they were diverging companies focusing on different things.

Sid Anand: They had different verticals, they were in totally different verticals, but in the end they were web companies. They all had different stacks to a large extent, and they had different ways of dealing with things or they had different approaches to solving technical problems. And in each company I actually rotated through at least three teams. So in each of those companies I rotated teams to understand how the entire company worked. So after leaving LinkedIn, I joined a startup and I thought, "Okay, now I've got pretty good knowledge of how things work." And then I ended up going back to PayPal and finding out how a fourth company worked.

But I think it's organic in the sense that there's this learning phase. And then for me it was an aspirational phase to say, "Okay, at what point do people consider me the person who has enough knowledge to guide that company in their endeavors?" And after at least being at two or three of them, I felt, "Let me attach this title to myself," because that's what LinkedIn allows you to do. And then I learned that different companies have different expectations of what an architect does. And yes, that's been my journey.

How do you learn about what is needed to be an architect? [05:14]

Michael Stiefel: Okay, so let's step back for a moment because you said several interesting things about your organic growth as an architect. If somebody came to you, said, "You seem to be a successful architect. I'm interested in being an architect." How would you tell them to learn about being an architect? In other words, to short circuit the process for them, or you've given some idea about your career path, but how would you steer them to their career path to benefit from your experience?

Sid Anand: That's a great question. I think I would ask them what they want to achieve in the next five years. Where do they see their career going? What is it about their current role or set of responsibilities or their own view of the career that they're not happy with? What is it that they want to change? And companies have two formal paths. You start off as a software engineer and then you become maybe a senior software engineer, and then you get to something called a staff software engineer where paths diverge. At that point, you can be a manager and you can go up the managerial track or you can stay technical and go up the technical track. And if you stay on the technical track, then you can get to something called a senior staff engineer, principal staff engineer, distinguished engineer, and then some companies divert, there might be a fellow or there might be things between fellow.

And typically the definition of these things is scope. So a senior software engineer owns a component, is a subject matter expert in some component of the entire system. A staff engineer is an expert typically in multiple components, and therefore might run a scrum team, might be the lead for scrum team, might also be a lead of multiple scrum teams, because under a manager typically there might be more than one scrum team, there might be more than one staff engineer, but if there's a single staff engineer, then that staff engineer is the person that runs all the scrum teams for that manager. But if there are two staff engineers for organizational sanity, typically they'll divide up the scrum teams by this number of staff engineers. When they want to get to senior staff, usually at that point they're collaborating across multiple scrum teams, multiple groups, and they're at the level of a senior manager. So that typically is what a senior staff is.

And when they get to principal, they're kind of at the director level. So they would be attached to a director and help overseeing multiple scrum teams, maybe around six or seven depending on the company, under the direction of a director. So a director might have seven. Typically that's a span of control. Five to seven is what is advisable. So that director might have five to seven direct reports. Again, if they have a single principal staff, then that principal staff is probably spread out over five to seven managers and all their scrum teams. If they're multiple, they're divided. And then you keep going higher. If you go above the principle, you're what called a distinguished, and at that point you're attached to a senior director, maybe a vice president, depending how big your company is, and you are now overseeing 10 to 20 scrum teams.

And then all of these people are still in the line of delivery. They're still responsible for executing a roadmap. So if you look at an organization, typically at the top you have a CTO and an SVP or a VP of engineering, the VP of engineering is responsible for executing a roadmap. That roadmap is usually owned by the head of product. And then the CTO sometimes is customer facing, but very much industry facing. It's deciding what should the roadmap be for next year. That's typically the CTO office. And when you're in this path of being an IC, you're still in the SVP/VP of engineering organization, still responsible for delivery.

But then what ends up happening is there are things that are outside of the path of delivery. They're not defined by product. And those are typically called the ilities, the non-functional requirements. And those are beholden to other groups within the company, like compliance and governance and other things. So if you're in the financial or medical industry, you have to abide by certain governmental compliance rules. So that will fall under architects. Security would fall under architects. Cost control would fall under architects. So there'd be a bunch of things that are not customer-facing features that need to be owned by somebody technical, and that's typically what architects would do. Sometimes architects are in their own organization, sometimes they're distributed across all of these directors. Typically that's what I would call it.

How is the career path of an architect different from a developer? [09:51]

Michael Stiefel: Okay. So that raises a very interesting question. In fact, it raises two questions in my mind, because when you use the word oversee, that's a loaded word, because let's say you're a developer and you have a use case in front of you, how do you interact with that architect? How do you conform to the architect saying that you have to make this secure or setting up the security system or defining these things that are important, but they're not like someone can write a use case and say, this happens, this happens, this happens. How does that engagement happen between the two?

And that also leads to the second question, is if there's an imbalance there, very often developers think, "I want to be an architect because that's the next thing for me to do. That's how I get this control. This is how I can oversee things." But aren't really the roles very different with different skillsets? And just because you're very good as a developer, that doesn't mean you'd be good architect, because architect clearly has to have people skills that a developer does not necessarily have, for example. So how do you see those roles, developer, architect, developing? I asked you two things at once so you can answer them in any order that comes to mind.

Sid Anand: One thing you mentioned is does a developer naturally progress through his or her career to become an architect or is there a path in the IC chain that avoids being an architect altogether? That is true. If they do keep going up, they'll end up becoming a staff, senior staff or principal staff, distinguished, fellow, whatnot. And that is a completely different path from the perspective of being an architect. The architecture group and the group is typically off of this path, and to join that group of architects, you can join typically from anything after staff. If you're one of these other levels, you could join the architecture group and typically you'd be picked based on your expertise in an area because you need to be a subject matter expert, an SME.

But as I mentioned, the areas that the architects cover tend to be broad areas. Like for example, you could have somebody in charge of the data architecture for the entire company. The company have 10 different databases. Should there be just one database? So there'd be one architect that owns let's say all the data stores. And there could be another architect that owns AI and what does it mean to be an AI architect? That architect would say, are we using TensorFlow or some other package across the board? Are we using both? Do we need GPUs? So the architect that owns a specific area would have to be good at communicating, good at listening, and would have to keep abreast of all trends that are occurring and eventually has to make some decisions and then sell the organization on those decisions. And then needs to find a way to start aligning developers and development to follow a new path.

And that path that the developers must follow does not lead to quicker delivery of whatever feature is demanded by the roadmap. It's a distraction. So the architect has to find a way to plan, let's see, for the next three years that we're going to move in this direction, and it's going to take three years and I have to cajole all of these orgs and convince them to move in this direction, so they do need to find a path of least resistance that will achieve the overall goal and be flexible in changing that, because what they're essentially doing is a distraction with respect to revenue and other things that are driving revenue or lowering costs. They're doing something that needs to be done to set the company up for success in that three to five years, but is a little bit painful and it requires extra work from everybody.

An architect then needs people skills as much as technical skills?

Michael Stiefel: Sometimes I like to point out to people what I like to call the Wall Street Journal effect. When things go wrong, you don't want your name on the front page of the Wall Street Journal because you had a security failure or something like that. And I guess you have to motivate people in all kinds of different ways. It sounds very, very difficult to do, because again, you have to somehow come to an overlap between that use case and the direction that you see the company goes. So it almost seems to be like you have to be as much an advocate as a technical person, as you have to communicate the technical stuff to the management team to convince them that this is worth doing, and then you have to turn around and explain to the development side of things, "Why should we do this?" It's a tremendous responsibility.

Sid Anand: Yes. And typically they don't do it on their own. A lot of companies have something called program management, and there'll be a set of initiatives for very large companies. The head of that business unit, let's call it a GM, or whoever the head of engineering for a business unit in a large company, would have a set of initiatives. And there might be 20 initiatives across the company that engineering need to deliver. Some of those will be new features and capabilities, things that customers would see, and other things would be things customers don't see. Move to the cloud is an initiative. Cut costs by 10% would be an initiative. Modernization is a big initiative every year. Modernize hardware systems, whatnot, to be compliant with security and other policies.

There'd be a set of initiatives and then architects would be assigned to some of those initiatives. Other initiatives would fall under directors, like a delivery group would own it. And then you'd have program managers that own many of these and are tracking progress. And the program managers are the project managers or leaders that are making sure progress is being made, but how is what's owned by the architect or the delivery people. That's the how. The why has been decided when the initiatives were prioritized. The what is also decided at that time, what is our end goal? The “how” is the domain of the architects and “when” is the domain of the program managers?

How do you stay current with what an architect needs to know? [16:04]

Michael Stiefel: You mentioned of course all these initiatives, and this obviously evolves over time. So how do you stay current with all the things that the architect needs to know or you guess that they might need to know? Because presumably when your director or vice president comes to you and says, "What do you think of X?" You don't want it to be that's the first time you ever heard of X. So how do you develop this expertise of not only understanding what you need to know now, but to think about where you want to be in the future, what you need to know in the future?

Sid Anand: Right, that's a great question. I think the concept with servant leadership is very important for anybody who's in any type of leadership role. The higher up you go in an org, or at least in terms of visibility, the greater your visibility, the more you need to listen. And there's the wisdom of the anthill. There's some engineer in some delivery team, scrum team, that is working hard on a problem and he or she have done research, they might have expertise in the field, and they're going to have more informed opinion about how something should be built. They may not have the confidence to convey their opinion. They don't have the podium where they can convey to a large audience. And I think that's the biggest problem in most large companies. Sometimes they try to fix this by having internal architecture summits. Then there's this bias there where the architecture group invites people to speak at the summits. So there's already a bias of who people already know. And sometimes people are invited based on other reasons that are not purely meritorious.

I feel like architects have to spend time with delivery teams. They have to listen, they have to learn, and then they have to aggregate this knowledge, take whatever additional context they have, and then write it up in some sort of strategy document or position paper, share it widely with the leaves, and encourage the leaves to comment, not the managers and not the directors. Because unfortunately what happens in large companies is that people think about their bonus and their promotion and maybe even keeping their job, and typically their circle of peers are the ones that rate them.

Isn’t this a problem in small companies as well? [18:24]

Michael Stiefel: I think that even happens in smaller companies because once you get beyond a certain core, you have this problem even in small companies.

Sid Anand: Yes. And the mistake is that the greater visibility higher up you go, your peers are as uninformed as you are about on the ground technical issues, and then you're unfortunately checking with them and keeping them informed so that when review time comes up, everything's fine. But really to do your job effectively, you should be listening all the way at the leaves and spending a lot of time with people and understanding what they're doing and giving them the credit. Because that's what the credit is due for the ideas and knowledge you gain. And outside of this, of course there are conferences and there's social media that teaches you about a lot of things.

But in that space, there is a lot of marketing reverb, a lot of marketing amplification. You could have a new open source package, they're going to be proponents of that package, they're going to be reactive on Twitter. You may get the sense that there's a large community around it that might be ill-informed. Really what the architect should do is gain their knowledge from the anthill itself. And it's fine if they get other sources, but they should always check that with the people who know the systems.

How do you balance the internal wisdom with disruptive technologies? [19:44]

Michael Stiefel: Of course, there are certain disruptive technologies like the cloud for one, client server was another, and organizations may be very resistant to this type of change. So it would seem that you need to balance what you hear internally with what you hear from the outside, and I presume the architect has to develop some reliable outside channels, whether it's plug for QCon or whatever technology they want to find out about. They have to find these neutral sources outside.

Sid Anand: That's true. You can always find out emerging trends, like QCon and other practitioner centric conferences provide a way to learn about emerging trends. But the larger your company, the greater the possibility that they're way behind anywhere near the emerging trends. And if the architect solely focuses on what's shiny and cool, because maybe he or she wants to put their stamp on having brought that capability or technology to a company, they also have to think about what's right for the company and how does that impact the engineers who have to migrate to this and to build it?

Of course, everyone wants to be in the cloud. Everyone will be very happy and productive on the cloud. There's a certain set of people at the company that have to manage costs, and that's a big concern. And typically maybe that generates FUD in the company. Well, it's going to cost too much and how much will it cost, and that's a deterrent. And then you can do an endless cycle of who actually makes this decision and owns it, and it never moves. And some companies say, "We're going to move. Here's a timeline, we're just going to do it, and we'll manage costs as we move forward." And I think that's a more progressive way of making a very big change at a company.

What are you responsible for as an architect? [21:33]

Michael Stiefel: Right, because the history is littered with companies, some of which will be able to adapt, and some of them who are not willing to adapt, and the end they go out of business. So it's clearly a very delicate balancing act, and based on what you're saying, it seems like the architect is at the center of that, because the architect can see further and is responsible for more things than a developer or even a manager that's focused on their day-to-day responsibilities.

Sid Anand: And while the term architect is glamorous, I feel like the job is definitely not. It is very much, what do you call it, when you do something, it's very painful, but it's like a labor of love. It's a labor of love because when you are a staff, you're in the delivery chain, you have resources, you're attached to a manager. You can convince that manager or that director that this is important, and then he or she will corral the resources and marshal what you need to get to achieve it. An architect sits outside of this chain, has no dedicated resources, has to gain the trust of a lot of people, starting at the leaf level, has to start a whisper campaign, that enough people have to be excited about something for it to change.

That is a very tough job. It's a labor of love. And ideally, I think this also happens, there is no fame or gratitude attached to getting it done because at the end of the day, the team that delivers it will gain the promotions. So the architect is doing something he or she believes in is good for the company and also good for all the teams that are adopting it and can somehow corral them in some way, urge them and convince them and influence them to join them on this journey.

Michael Stiefel: Well, it is an old saying that it's amazing what you can accomplish if you don't insist on taking credit.

Sid Anand: Yes, that's actually very true. An idea that is popular is an idea owned by many people, and I think the more people you hear talking about something and maybe taking credit for it, that's how you know your idea will take hold. And then you're being a successful architect. Not even being the voice behind it, enabling others to be the voice behind it.

Architect’s Questionnaire:

What is your favorite part of being an architect? [23:20]

Michael Stiefel: I've asked you a couple of questions about being an architect in general, and now I would like to get a little more personal to ask you what I like to call the architect's questionnaire. For example. What is your favorite part of being an architect?

Sid Anand: I would say it's just exposure. I love learning, and as an architect, you will be exposed to everything in your domain. Assuming you're an SME architect in the domain, you'll be exposed to everything in your domain. So it's an amazing way of just learning about the capabilities. You'll be attached to some area for a period of time. So you have this view of here's what our company needs, here's what the industry offers, here's some new emerging players, here's some decisions I've made, here's a path to adoption, here's my challenges with adoption. You'll learn a lot about yourself, you'll learn a lot about organizational communication and persuasion, influence. It's a tremendous opportunity to learn. That's what I love.

What is your least favorite part of being an architect? [24:57]

Michael Stiefel: And of course, no job is perfect. What is your least favorite part of being an architect?

Sid Anand: I think one tough aspect of being an architect is possibly the feeling of isolation. As an architect, you own an area, you're expected to be an adult, a leader, you're a leader. Leaders tend to be kind of lonely. You don't have a team. You have a series of groups and organizations that you work with. That can be a little bit tough. And maybe if you're part of an architecture team, you go to lunch together, you have this camaraderie. But the more senior you get as an IC, you tend to feel this isolation.

Michael Stiefel: And that can be quite crippling if you're not prepared to deal with it.

Sid Anand: Yes, I think it's a personality thing, and I think it's... As a developer, you love to put your headphones on, listen to your favorite music, code away for four hours. As an architect, you should really enjoy working with people, walking the floor, meeting people, saying hi to them, because at the end of the day, that's what you gain. It's the happiness from meeting people. That social aspect is maybe the big positive feedback you get.

Is there anything creative, spiritual or emotional about architecture or being an architect? [26:07]

Michael Stiefel: So along those lines, is there anything creatively, spiritually, or emotionally about architecture or being an architect that really appeals to you?

Sid Anand: I'm the chief architect for a startup company that I work at right now. I'm also the head of engineering, so I wear two hats, but I started as a chief architect and when I joined, I just joined as a developer. I spent the first two, two and a half years just writing code, learning from the team and building parts of the system, teaching everyone around me. I think I have about 40 to 50 people under me, but teaching them, working with them one by one or in groups, teaching them how things would be built, hearing how they're building things, raising bars. That's a really key part.

To be successful, I have to train everyone to be developer/architect/people leader so that I'm not needed at the company. And any company I've worked at, my goal is to not be needed. That everyone should be able to do a little bit of everything and be better off. So I typically have a path for everyone. That if you started off as an operations person, you should start writing scripts. If you're a script writer, start writing applications. If you're an application writer, start writing software infrastructure. You're a software instructor person, start doing something more complex. Everyone needs to go up that path and everyone needs to be exposed to education. I will send teams off to learn things, because unless teams are improving, the company is not going to improve. So a large portion of time goes into training and people learning and pushing their boundaries, and it should feel like a fire hose. They should feel like they're extending their college experience to a large extent. And I feel a reward from seeing that.

Michael Stiefel: It almost sounds like, and perhaps... I don't want to put words in your mouth, but there was an old TV program in the United States that asked - who was that masked man? In other words, you know the architect was there, but their personality does not come through. It's the effects of what they did that matters.

Sid Anand: Is that a Lone Ranger reference?

Michael Stiefel: It may be, it may be. It may be the Lone Ranger. Who was that masked man? And that seems to be what you're describing because the effects of what you do live on, not the fact that you were the one that did. I don't know if I'm putting words in your mouth, but that's what it sounds like.

Sid Anand: Yes. I'll give you an interesting example. So I worked in Netflix for a little over four years, I think four and a half years. And when I joined, there were only a hundred people at the company. I think when I left, I had 90% seniority over the rest of the company. And the Netflix model was the following, that says manager set context. They just go to the engineers and say, "This is what's important. And it's up to that engineer to make all of the decisions about what they're doing. And the corollary to this is that any engineer can set that context for any other engineer, and each engineer designs their system. There is no architecture board, there's no one to review. They design, build, operate their systems, everything, and they're given requirements from everybody at the company. And anyone can set the context for anyone else.

So in a sense, every engineer is learning multiple skills. It's very entrepreneurial. They had these five or six company values and you were rated against them. One was something like you have to be communicative. It's very important to be communicative. Two, you had to have impact. Three, you had to have curiosity. Four, you had to be courageous. So these are the four. And I think five is just be a nice person, play well in a team. So if you think about this, what they didn't want was wallflowers. They didn't want people who are shy and quiet. Everybody had to have an entrepreneurial mindset. So they had to be curious about systems. How could this be better? They had to be courageous to take that risk. They had to communicate to everyone else what they were about to do. And in the end, whatever they did ideally had impact. They'd be judged by these four things.

And obviously along the way, they shouldn't burn bridges. And everyone were peers. There were no titles at the company. At that time, everyone was just software engineer or senior software engineer. And everyone had 10 to 12 years of experience and everyone was supposed to be a fully formed adult. These five values were how you were rated every rating cycle. So the way you were rated is anybody in the company had to write qualitative examples of how you achieve these five things. And if you were a quiet person, you didn't do much, you thought you could sail by and not do anything, unfortunately, it might've been the end of the road for you at Netflix. They said something like, "Mediocre performance gets a generous severance." And that way of thinking is how I've always thought wherever I've been. Every engineer should feel this way. This is what's important.

Michael Stiefel: So they have to be passionate. Because unless you're passionate, unless you... Again, it's almost emotionally invested, spiritually invested if you want to say, because you're not going to be able to achieve that. Because the flip side of what I remember about Netflix is they wanted you to be incredibly entrepreneurial, but on the other hand, totally responsible, because if it broke, you fixed it.

Sid Anand: Yes, yes, accountable. I forgot what the term was, but yes, exactly that, you had to be responsible. Teams were weakly coupled, tightly aligned, that's one thing, and then you had freedom and responsibility. You had full freedom, you also had full responsibility, which was a great way of thinking about things. So it forces you to make good judgments.

Michael Stiefel: So in other words, architects, sometimes they're the ones responsible, if you want to say, for keeping that culture, that religion, if you wish, alive.

Sid Anand: Could be, like a Jedi. Or it could be something that anyone in any team already does, but they don't have the podium, they don't have the voice. And I think what an architect can do, they can lend their privilege. And I think that's a big part of it. So architects tend to have visibility. What they can do is lend privilege to others in the organization to make sure not only do they get credit for their ideas, not only do they get rewarded for their hard work, but they have a voice and a way to share their experience. Because that's what you want to do, you want to build an equitable, egalitarian kind of society within a company where your title doesn't matter. Your level shouldn't matter.

So I'll give an example. When I joined PayPal, I worked in the data infra organization, I was the chief data engineer, and I helped form these 10 scrum teams. And then the scrum teams were called three in a box. So you'd have a PM, the product owners, the scrum master, and the tech lead. You have these three. Typically, the scrum master was a manager of the team of that had this scrum in it, the product owner was part of the product organization, and then the tech lead was whoever in that group knew the most about the technology and was leading by the best example, and could have been the most junior person in that team. And I enforced that. It should not be the person with the highest title or level, it's the person that everyone's following.

Michael Stiefel: That's a very tough thing to do. I mean, there are lots of ways to achieve it. I know for example, in the United States Supreme Court, the judge is supposed to state what your opinions are. It's the least senior judge that gives their opinion first, so they won't be influenced by the more senior people. And that's very tough to do. But again, as you say, somebody has to be the one to keep that spirit alive.

Sid Anand: And one of the things is I joined the team, I would join one of the teams, I would start coding, and I would not ship until I got reviews and I wanted everyone to just forget about titles and hierarchy, because how they get a voice. That's how a junior person gets a voice. Netflix also had this model where nobody had titles. Everyone was a senior software engineer for this reason. You could have 30 years of experience, 10 years of experience. If you enter a room, you shouldn't wonder who's in this room when I say what I need to say. That was a wonderful practice.

Michael Stiefel: And also in my experience, I don't know if it's yours, at some point more years of experience does not really help you.

Sid Anand: Technically, you mean?

Michael Stiefel: Yeah, technically. In other words, yes, you may have certain skills because you are around longer and exposure to more things, but in terms of judgment, you get to a certain point where 10 years, 20 years worth of experience, your judgment should be honed at that point.

Sid Anand: And the interesting thing is that depending on which company you go to, the company you join, the examples I had, the average tenure of the people in the team was about 3 to 5 years of work experience. So there was a big jump. There's a big leap between maybe I have 20 plus and they have 5. So judgment played a big factor. Innovation, actually, you could say comes from the youth. They're the most innovative. They have many new ways of trying things. And then the judgment is something you gain with experience and time. But of course the scrum teams are joined where there are people with 10, 15 years, they've developed that judgment. They know the area really well. Those teams don't require a guiding hand as much, and probably... I mean, I just left them alone. They were successful on their own.

And the teams that are successful don't need an architect at all, to be honest. And it's something that you see, I think, psychologically at big companies. Like they say success has many fathers and failure has none. You see that all the time. A project that's doing really poorly is actually the one that needs the architect. And once it succeeds, you'll see a lot of people want to be a part of that team. That's time for the architect to leave because it's a success.

Michael Stiefel: And that requires the strength of character for the architect to leave and not to stay with the success because it feeds their ego.

Sid Anand: And I think it's all about safety. So as an architect, you'll have a manager at some level of company. That manager should have an appreciation for this, that your name is not coming up all the time, so how do you know what you're doing? So that you have to feel some measure of safety that I don't need to have my name. And I think the culture of the company matters a lot and definitely the culture at the top matters a lot, and that trusted relationship with the person you're reporting to matters a great deal, especially if you've worked with them in the past. But if you join a company and you don't know your manager, you have not developed this trust, how do you establish it? That's a challenge. It happens. Otherwise, for example, the company I'm at right now, I mean I work with the CTO who's also an investor at Netflix for four and a half years. He's not involved in my day-to-day at all, because we have established that trust.

What turns you off about architecture or being an architect? [37:12]

Michael Stiefel: So on a more personal note, what is it about architecture that you love and what about it that you hate?

Sid Anand: Architecture, not the role, right?

Michael Stiefel: Yes.

Sid Anand: Honestly, I love working and learning from others who build software architecture, and I think the fundamentals haven't changed at all. You always talk about performance, you talk about availability and scalability. I think those set of things have not changed. Technologies that implement them have changed, but the rule book that we use to assess whether technology is doing what it should is informed by our experience and not by the API documentation of that technology. And what I find today is people without that background will look at a technology, maybe it's in Kubernetes or some service mesh thing, and they'll say, "Here's what I can do." And I provide the insight of, "Here's what you should be able to do." And I don't need to be an expert in that technology. I just ask them, "Here's what you should be able to do." And then they will mention, "I cannot do this with this technology."

And then I say, "That's a problem because you should be able to do this. If you wrote this yourself. If you can imagine that this is how it should work, this technology should do that." Especially in distributed systems, fault detection, retries, all this stuff around this, I've come across it in my current startup where we have Amazon ALBs and they talk to some sort of ingress controller, and that ingress controller sends a request to Kubernetes services and pods. There's this whole problem about autoscaling when you do rolling retries, how is the connection and experience managed for the customer? When it's graceful you expect there to be no interruption at all to a customer. And when someone's deep in a technology and they love a technology like Kubernetes, they'll say, "Here's what Kubernetes can do."

Michael Stiefel: But presumably from the architect's point of view, your statement of this is what it should do comes from your understanding of what the customers want, what the business requirements are, as opposed to the technologists who very often... I'm sure you've heard the phrase, a technology seeking a problem to solve.

Sid Anand: And let's say we talk about the ilities, we talk about the ilities. Lifecycle management of nodes have to fit into the lifecycle of a request that passes through your service, and a customer and a PM would never say that, "When we do rollouts, we don't want... They'd never point out, "We have a rollout, the customer shouldn't see a problem." So that availability problem is a general problem, and the technologies fit in to the solution, because it's not a single technology, it's multiple, and that handoff and how everything works is a technical set of requirements of how everything should work together. The architect or senior engineer, someone with experience would outline it. It doesn't have to be an architect. It could be a senior engineer that outlines it all.

And then maybe that engineer's in a team that has solved this problem, and it should be a general pattern applied everywhere. Architect learns about this, what can he or she do? He can start promoting this idea throughout the company. He or she didn't ideate it, but he or she does have contact points with every other team, and the lead for a delivery group is on task to deliver every two weeks. Doesn't have the cycles to do this. So that's what an architect can do.

What profession other than architect would you like to attempt? [40:33]

Michael Stiefel: So what profession, other than being an architect, would you like to attempt?

Sid Anand: That's a good question. I haven't thought about that, but I have done a few different things. I started as a chemist, then I worked in semiconductors for a bit, then I dabbled a little bit in electrical engineering, which is your field. But I'm not an expert in any of these areas. I'm just someone who dabbled along the way. And then I only found software maybe when I was 24, 25. Before that, I had done these different things and I've now been in software for over 20 years. And personally, I am a people person, so I like working with people and I love learning from all the folks around me, and I think with my level of experience and voice and knowledge with maybe how to communicate, I can be of service to people in the sense that I can help them grow.

I can help promote the voices that would not be heard otherwise. But outside of this area, I've always wanted to be a teacher. I'm always amazed by what teachers do and how little recognition they get for what they do. The teachers in my life have had a profound impact on where I am. Coming from a poor country, from a family that two generations ago didn't have an education, education was the way we got out of our situation. I would want to be a teacher. I think that's what I would want to do.

Do you ever see yourself not being an architect anymore? [41:54]

Michael Stiefel: That's a very noble profession. And given that you say you want to be a teacher, would you ever see yourself not being an architect anymore?

Sid Anand: Yes. I think being an architect is a role you have at a company, because that's the thing the company needs. In my current company, I could just be called a senior lead engineer. I need to have a title that makes some sense. But I could easily be a distinguished engineer or fellow. For a startup chief architect made sense. A fellow for a small startup maybe doesn't make as much sense. But as an architect you're a resource for others, but I'm happy to hand that off because my goal is not to stay in a place for very long, to be honest. It's to experience the world. And the world is very large. And I'll be in a place for a period of time, help grow everyone to take over my role and move on to another thing.

Michael Stiefel: But as an architect or as something else?

Sid Anand: Yeah, it could be anything else.

When a project is done what do you like to hear from the clients or your team? [42:49]

Michael Stiefel: And when a project is done, what do you like to hear from the clients or your team?

Sid Anand: I would say from the team I'd like to hear that they enjoyed working on it. So typically there should be multiple wins for hard work. And PayPal, I established a few different ways to reward people. One is promotion. So I was heavily involved in the promotions, even though none of them directly reported to me. But if they worked hard and I saw their work firsthand, of course I can give an informed opinion at the promotion reviews. I'm also letting them speak at conferences, finding a way for them. At PayPal, I owned all of technical branding, technical brand development for the CTO's organization, which was the shared services, probably a couple thousand people. But I also helped other business units promote what they were doing. And some of this was open source, some of this was blog writing, some of this was talks. And every quarter, at least in the data org, we released an open source project.

Michael Stiefel: And what about from clients?

Sid Anand: Oh, from clients. I'm usually not in the path of clients. The clients, they have their line of communication with the manager, the product owner. I am just sitting in... Yes, I think having clients co-present at quarterly reviews with the delivery team is a really good success story. It's a good way for everyone in the room to understand how it impacted the client. Just having the delivery team say, "We launched project X, Y, Z," doesn't mean much unless you have the client saying, "Here's how I use it. This is how it's made my life better." And that is a practice we adopted for our quarterly reviews.

What do I need to know that I have not asked you? [44:28]

Michael Stiefel: To wrap things up, is there anything that comes to your mind that you would like to say that I didn't ask or didn't come up?

Sid Anand: No, I think you've covered everything. I give mentoring advice to a series of people, and often people ask me, how did I become an architect, and one thing I've followed in my life is, follow your interest and your passion. Follow your interest and passion. Don't stay in a job too long because you want to be promoted, and you think that external affirmation of your effort or value means anything. Keep learning, contribute where you can, and don't worry about promotions. Don't worry about your career. As long as you follow your interest, you'll succeed eventually. That's all that matters.

Michael Stiefel: Well, this has been very interesting. I thank you for spending some time and maybe we'll get a chance to do this again sometime.

Sid Anand: Thank you for your time, Michael. I appreciate it.