Martin Spier on the Art of Performance Engineering

Resilient engineering teams are forged through trust, technical depth, and a culture that adapts to constant challenges. Martin Spier, VP of Engineering at PicPay and former Netflix performance engineer, has spent his career mastering this balance. From scaling Netflix’s cloud infrastructure to leading innovation at one of Latin America’s largest digital wallets, Martin’s experiences reveal what it takes to build teams that thrive in complexity and deliver exceptional results.

In this episode of Keep Moving Forward, Martin shares his approach to fostering a high-performance engineering culture, empowering teams through ownership, and prioritizing computer science fundamentals. His insights offer a practical roadmap for engineering leaders looking to build adaptable, high-performing teams in today’s fast-paced tech landscape.

Engineering Culture Is Built Through Action, Not Policy

Martin views culture as the backbone of every successful engineering team. For him, culture isn’t about slogans or written values but about the behaviors and interactions that define a team’s daily work. “Culture itself is not really what you write in a document or put in your mission and values and all of that. It’s what actually happens during the day-to-day when you look around and how everyone around is acting,” he explains.

To foster this kind of culture, Martin focuses on leading by example. By embodying the values of trust, collaboration, and creativity, he ensures that his teams internalize these principles. Martin also organizes annual summits to clarify team priorities and reinforce cultural expectations. These summits serve as touchpoints for new and existing team members, creating an environment where shared values and goals take root naturally.

Freedom and Ownership: Keys to Empowering Engineers

Martin’s leadership style prioritizes trust and autonomy, enabling engineers to take ownership of their work and solve problems creatively. Drawing on his experiences at Netflix, he explains that “It was a very rigorous process to get there and it makes no sense for me to hire a really great person and try to control everything they do.”

At PicPay, Martin applies this philosophy by delegating responsibilities to senior engineers and providing them with the support they need to lead. This approach empowers his team to tackle challenges with confidence while fostering a sense of accountability. By balancing autonomy with structured support, Martin creates an environment where engineers are motivated to innovate and take bold risks.

Reclaiming the Fundamentals of Computer Science

As the tech industry increasingly relies on high-level abstractions and AI-driven tools, Martin warns of a growing skills gap in core computer science knowledge. “I’m really afraid today… for future developers because I think we’ll have a huge shortage of engineers with deep knowledge about something in the future,” he says.

Martin advocates for reinvesting in computer science fundamentals within teams. By encouraging engineers to engage with low-level problems and sharing his own “war stories” from tackling foundational challenges, he fosters a renewed enthusiasm for the craft of engineering. “A lot of people are really attracted by the salaries and the comps instead of the proper engineering side of things,” he explains.

Martin’s leadership philosophy offers a powerful framework for engineering teams navigating growth, innovation, and change. By grounding teams in cultural alignment and technical expertise, Martin demonstrates how to create engineering environments that are both adaptable and forward-thinking. His perspective serves as a reminder that the best teams aren’t just built—they’re nurtured.

Looking for more stories from tech leaders who embody the Keep Moving Forward ethos? Subscribe wherever you listen to podcasts and never miss an episode.

Transcript

Martin Spier:

I do at least a yearly summit, I call it "summit," with my team. To go over, of course, priorities and things we're planning for this year, but also to make sure the way we work is clear to everyone, especially for folks who join. But the idea is if I'm behaving that way and I'm making sure everyone knows at least that my direct reports are behaving that way and I'm observing everyone who joins, we'll look around and see, yes, that person has a really high bar to review PRs. And you'll start doing the same. It's just natural.

Caleb Brown:

Hey everyone and welcome to Keep Moving Forward, the podcast from X-Team for tech professionals who are passionate about growth, leadership, and innovation. I'm your host, Caleb Brown, and in each episode we'll dive into candid conversations with the tech industry's brightest minds, seasoned leaders, forward-thinking engineers and visionary experts.

I'm incredibly excited about this episode's guest, Martin Spier, who's leading foundational engineering as VP at PicPay Latin America's largest digital wallet. Before PicPay, Martin spent nearly a decade at Netflix, where he helped build the cloud infrastructure that changed how we all watch TV. Now he's bringing the same innovative spirit to democratize financial services across Latin America.

In our conversation, Martin opens up about something really fascinating, how to build engineering culture where freedom and accountability go hand in hand. You'll hear how he brings his team's values to life through authentic leadership and open dialogue and his unique take on finding those rare talents who truly thrive in high-growth environments. What I really love about Martin's approach is his perspective on performance engineering. He shares how his team balances structured goals with creative freedom to experiment and innovate. Whether you're leading a team or deep in the technical trenches, I think you'll find his insights truly energizing. Let's jump into this conversation.

Well, Martin, thank you so much for joining. Excited to be your introduction, a little bit about how you jumped into your career and your focus on performance engineering.

Martin Spier:

Yeah, sure. I mean, first, really thank you for the invitation here. And I'm super, super glad to be sharing a bit of my experiences, opinions and all that. My background is properly pure tech. I study computer science and all that, which is rare these days I would say. So I got a lot of interesting opportunities. I moved to the US right after the housing crisis, like 2009 I think. I went to Expedia, which is really cool. Worked on their flights, hotels and cars, lines of business. Again tuning, trying to improve things. And then out of nowhere I got a cold email from a company I barely heard of before, back then at least, called Netflix. I was a subscriber, that's why I kind of knew Netflix. But I was a DVD subscriber and they were still renting DVDs. That was still the main business.

But this was super early cloud days. Amazon had just launched and Netflix was the first company to be... They decided to go full on in the cloud. And I found it really exciting because they built a lot of open source tools. Because those things didn't really exist yet, so you had to build your own. Came, interviewed in California, and basically joined. I was the first perf engineer at Netflix. I was just starting the team and spent almost 10 years there. It was a really amazing experience because I got to experience the early days of cloud-based architecture, like microservices and stateless architectures and different types of databases. But I sort of roamed about a bunch of different areas.

And then about two and a half years ago, maybe almost three years ago, I heard from a company I do advisory for, a lot of startups, and I started chatting with a founder of a Brazilian startup called PicPay. It's short for picture payment. They started with QR goal, QR code base payment, peer-to-peer payments, which is something instantaneous, really cool. And they were growing so fast during the pandemic, from I think it was 15 million accounts to seventy-something million accounts. And obviously when you grow really fast, your engineering needs to evolve even faster. So there was a lot of technical being accumulated and things to fix. And there was a really interesting opportunity to take over a larger portion of engineering, not just performance and resilience, but also infrastructure, developer experience, architecture, overall architecture, and mobile data. I actually was leading data for quite a while.

But all core engineering functions, things that were not directly related to a business feature, which was sort of my team, in my career. I always liked the agnostic engineering subject versus features for banks and things like that. Then I'm still here at PicPay. Still trying to make things better.

Caleb Brown:

Yeah, absolutely. And there's a lot of that that I definitely want to get into in this talk. But I actually do want to go back to Netflix because like you said, you spent almost 10 years there. But I'm just interested, what are some of the most impactful lessons and principles you took away from that overall experience in Netflix?

Martin Spier:

So few different aspects of that. I mean there's also the cultural aspect or aspects, which I would say based my leadership style. I took a lot from the culture itself and also the leaders I had over there. Things worked really well. It was sort of a really well-oiled machine and I tried to borrow a lot of that. But on the perf side itself, the theory is exactly the same. If you have a small environment, if you have a big environment, it's all a curing system. And what changes really is the tools and the processes you available at different scales. Because everything will break at a certain scale. You have a pipe and you have bottleneck, and at some point you just have too much throughput and that bottleneck will be a problem.

At a smaller scale, you have a lot more options. I can go and read log lines. If I have small server with a fuel of a hundreds accesses, that's fine. But once you have a massive system, a lot of those things are not available. They're just not computationally available to you. I can't scan and index a bunch of log lines, or I can't just log into a server and do things manually. I need to create new things, new tools, new ways of analyzing data. And that's what I learned over there. As you grow, as you keep scaling up, you need to find new ways of solving the problems, especially if you're in a position like Netflix. I always joke that the problems we're solving is not the kind of thing most devs have to deal with. I can't go to Stack Overflow, or there's some co-pilot and ask how someone else solved that problem before.

We were probably facing those problems firsthand. No one faced those problems before us, so we had to be a bit creative. And having a really strong computer theory foundation was really helpful with that, because you can always go back to that and try to understand how things work. So that was really key. And on the culture side, things work really well for us. Freedom was a strong part of that, freedom and trust. It was really different from any other company I worked before, where your leadership really distrusted everyone and tried to control everything. Netflix had that thing where, "Hey, I hired you to do something. It was a very rigorous process to get there and it makes no sense for me to hire a really great person and try to control everything they do." And that allowed us to move so much faster. Of course, there's the responsibility part. If I make a bad decision or if I'm not really acting according to what needs to be done in a company, or I'm being reckless, of course there are consequences to those things.

But since I had the freedom to make the decision, it generates a lot of ownership. It's a sense of ownership. Since I can make the decisions, I am not relying on my managers to make a decision. That empowers people and everyone really helped with motivation, I would say. And that's something I try to foster at PicPay today. It's something I do. Same thing on process. I mean, I'm a big fan of process. If the process helps the developers deliver a goal faster. If it's just process to make managers happy, I'm generally against it. Or try to control something, or try to avoid risk. It depends on the kind of risk of course, especially now. I'm in a bank, so you have to manage risks well. But things that are just to make someone feel better, that they have control and they have understanding what's going on, I try to be away from that.

Caleb Brown:

You talked about culture and particularly in your case engineering culture. Curious how you go about building a strong engineering culture and setting clear expectations within your team.

Martin Spier:

So it's something I always believed in. Culture itself is not really what you write in a document or put in your mission and values and all of that. It's what actually happens during the day-to-day when you look around and how everyone around is acting. So it helps if you can properly document that somewhere, but the important part is looking around and seeing how everyone is behaving and making sure the document reflects that and not the other way around. Just write the document so people follow that will never work. So I always believed in changing culture and maintaining culture by example. And really strong example and making sure everyone that I'm leading and my team actually, it's really aligned with the culture and the way things work. So I try to do that all the time. I do keep an eye on that all the time, and I immediately take action if something is sort of out of the ordinary. "Hey, someone said something that it's not really what we believe in the way we work here. Hey, let's have coffee, let's have a chat and see what's going on here." And provide feedback, constant feedback to everyone. And around setting expectations. There's expectations in performance like deliverables, we can chat about that.

But in culture, I try to really state that. "This is how I work. This is how we should approach this problem." I do at least a yearly summit, I call it "summit," with my team. To go over of course priorities and things we're planning for this year, but also to make sure the way we work is clear to everyone, especially for folks who join. But the idea is if I'm behaving that way and I'm making sure everyone knows at least that my direct reports are behaving that way and I'm observing, everyone who joins will look around and see, "Yes, that person has a really high bar to review PRs." And you'll start doing the same.

It's just natural. I like to use the example of when I was a kid, a teenager, I was an exchange student. I moved to a different country and it's natural. You move to a new country and soon enough you start observing everyone and you start copying that. It's just, it's natural human behavior and that's what I'm trying to do. I'm making sure everyone's behaving a certain way so everyone who joins just looks around and behaves the same way. And that's how I try to foster culture and change it whenever necessary.

Caleb Brown:

Absolutely. I think that's definitely the right approach. And you touched on it a little bit, but I'm interested in your thoughts on things like performance reviews for engineers and how you approach evaluating individual contributions.

Martin Spier:

Exactly. So I'm, I wouldn't say a critic. I don't call it that. But I'm a critic of how it happens in most companies that your traditional way. Why if you have a job that can be easily, I mean really easily measured in a non-subjective way, like sales for example. I would say your sales volume. Or if you're analyzing folks who work at a supermarket packaging things and you can measure how fast they can package things and so on and so forth, great. Then those things work well. But the way, and maybe engineering in the past where everyone was just executing tasks, you had projects, and then project has tasks, and you execute the tasks, and it's great. But that's not how things work today. I need folks who are creative. In engineering, the way we work engineering today, it's a creative process. We have a problem, we try to understand the problem, we go dig deeper, and we come up with a solution. Then we try it and test it, it doesn't work, we go back and try it again.

It's a sort of creative process and you need a bit of flexibility there. And at the same time, it's really hard to measure how much value an engineer is adding because they have completely different roles. I have excellent engineers that might not write a lot of code at all and not deliver anything, but they're there and they're unblocking a lot of people. Or they're setting example, or they only join when there is a really complex problem no one can solve, and then they kind of jump in and fix that. While I have other engineers are super productive in delivering features. It's so complex. That is really hard to boil that down to a simple performance evaluation, either to a metric or what sometimes people do with feedbacks. And you give me a score of how much I deliver or how much I'm close to culture.

It's really hard because it's hard to measure that, especially on the results side. And many times it also gets mixed up with feedback. Many times engineers, the only time they're actually hearing a feedback from anyone is during the performance review process and that's horrible. It's already really hard to provide a good constructive feedback, and if it happens half a year later with barely no context and it affects your bonus and how often you get promoted, everyone will really be in the defensive. And they'll not take it in and actually make the change happen like it should. Feedback is extremely important, but it should happen right after, 101. Ideally if you physical, even better. That's how I believe feedback should work. And you mix that up with performance review, it just doesn't work.

And also the grading or if you give a score to someone is just really arbitrary and it changes drastic. If you talk with different people, they might have completely different opinions of things. So I always like to rely on your direct leader. Your direct leader should be the one that has a really strong cause. And if you're delivering or if you don't have the values the rest of the team has. So I really like to trust my leaders to have that strong connection, because they're the ones that should be evaluating that. If they want to put that kind of grade on it, so be it. But sometimes it's really hard because there's different dimensions and as you try to create a strong process around it, you'll just create the wrong incentives.

Caleb Brown:

Absolutely. I'm wondering about, when hiring for leadership roles, what key characteristics and even soft skills that you prioritize?

Martin Spier:

Yeah, sure. It really depends on the role and what I'm expecting that person to do and how critical that area is and what are the priorities for that area. For example, hey, if an area is stable and I just looking to delegate a bit more to someone and I'm looking for a leader to do that, I usually want to make sure their communication skills are really good and that they have good exact communication skills, that they can translate a fairly complex technical problem to something that is easily digested by someone with not as much technical context. That they can understand and have a really good sense of priority. They can read what's important for the business and translate that to the team and make sure everyone is on the same page. In my case, hiring is really important. I want someone that has a really high bar on hiring and knows how to evaluate that. Being another leader or a technical position, different things and communication overall extremely important. Not just presentation, but communication is always really important.

But again, it depends on the type of role that I'm looking. Hey, I have a role that it's not on a hotspot right now, but needs quite a bit of restructuring. I want someone with really good discipline that is organized that can structure the team. It just depends a bit on the challenge. I try to focus a bit more or less in each of the soft skills because different positions are challenging in different ways. So I try to focus on trying to make a match. Same thing goes for technical positions. Sometimes I need someone that is really deep technical into a specific problem, but sometimes I need someone who's more of a generalist that can take different things. So it just all depends.

Caleb Brown:

Absolutely.

Martin Spier:

Tailor that and be very careful not hiring mess. Yeah. I have some interesting stories about the hiring process to you, which is something I always try to pay a lot of attention to.

Caleb Brown:

Well, I have so many questions. But I am interested in the hiring process, if you do want to expand on that.

Martin Spier:

First with a few things. Good people really are really hard to find. I just want to take as much time as I need to make sure the person I'm hiring is the perfect person for that position. It doesn't matter how long it takes. There's always a bit of fallacy, at least for me, that hey, I have a demand and I need to hire someone quickly to take care of that demand. The way I work with engineering, which is a lot of bottom-up, engineers have ideas, and then I have a bigger backlog. So I always have a bigger backlog than I'll have people, so you'll never finish with the backlog. Anyway, it's just how many things we're delivering.

So I change, I always try to change that. I want to do properly active hunting. In the Bay Area here in California, it's pretty common for the big tech companies. But more traditional companies, maybe other countries like in Brazil, it's not as common where, hey, I need that person with that skill set and that amount of experience that probably working at this three or four companies because they're the only companies that use that technology at our scale. And how cool, I'll go LinkedIn, I'll list everyone and I can find, and then you need to build your pipeline. Or GitHub, GitHub is a great source. Or Confer is a great source too, but you need to build your pipeline.

The CRM is sales for hiring. Hey, I have my leads. I go, I call, email a few folks. I ask introductions for others. "Hey, how are things going? You like your current place?" "Oh yeah, everything is great." "You're not looking for a change. Okay, cool. It's okay if I ping you again in a couple months?" And if you keep your pipeline warm and yet at some point that person is really great, you will be pissed with their manager. That's my chance. And it's just like sales, honestly. It's the same approach and you need to keep your pipeline of really great people because timing is the hard part. It's a bit more flexible. You do timing, the chances you get a better person are just increased dramatically.

Caleb Brown:

Absolutely. That makes sense. I wanted to get back a little bit to some of the performance engineering principles and things like that. I'm really interested in how different teams work together in an organization, especially a growing organization. I wanted to ask you your approach to complex performance issues that do span multiple system layers and even different teams, and just how you coordinate all those efforts.

Martin Spier:

For every initiative, every problem, anything I want to do, I always want to have one person on top of that. Your traditional problem, with dog, with many owners. No one feels they actually own that and responsible for delivery. Therefore, whatever I want to do, and that's that PicPay, Netflix was the same thing. All companies, I just want to make sure I name that person. That person is pretty clear to them that they're responsible for delivering that. Everyone's expecting them to be delivering that. But of course you don't work alone. You need to work with other people. But senior engineers, up senior staff principles, they should have the skill set of managing that deliverable and not just taking tasks. And I tend to work with more senior engineers usually, so I expect them to be leading and going, "Hey, I found a problem with Android, but I don't really have an Android development skill set."

I can profile, I can point you to where the problem is, but I need someone to help me with that. It's my responsibility as an engineer to go find the Android development team or one specific Android developer. "Hey, this is really important. Here's the impact to the business. If we don't do that, here's why is it important? What else do you have on your plate? How can we prioritize that? Can you work with me on that? Can we postpone that and negotiate that?"

So I try not to take care of everything top down myself. Of course, there's a lot of things that are really critical to the business, and I like to keep a pulse on it. It's important. But most projects I likely rely in an engineer or a senior engineer or a bit more senior leader to be taking care of that and negotiating that, which increases their capacity.

It's really hard to be on top of everything that's going on in a large team, and just trusting engineers to take lead on those things helps scale efforts and also helps with motivation. They will feel a lot more motivated if they feel they own the problem and they have everything to solve that problem. Supporting engineers, it's important too. They need to feel comfortable and in a safe space where they can make the decisions. And sometimes there'll do be mistakes. Of course it happens. They need to feel comfortable that they have the support, and if they go to an Android team, they can't really help with that, they know they can come back to me and they can help with that. And you help me. Go talk with them and kind of explain that and be open to that too, but not on a day-to-day, not controlling, but something's out of the ordinary. Can you help me?

Caleb Brown:

Absolutely. We'll see. I mean at X-Team, we have a ton of developers. We're working with a ton of different clients, and so we think a lot about developer experience. And so that very much relates to another question I wanted to ask you, and you've touched on it a little bit, but I wanted to dive in a little bit deeper. Which is just, how are you kind of approaching enhancing the sort of inner developer experience and productivity as well at PicPay. Because you have what, I think 200 developers under you, maybe more?

Martin Spier:

Yeah, these days. Yeah, but I got to almost 400 at some point when I had the data team with me too. Yeah, developer experience is extremely important. Someone made a joke. Even today, we're looking at idle rates at our infrastructure and bad user experience. Bad for the developers is like an idle rate on infrastructure. We want them to focus and make sure that they're in flow state for the maximum amount of time during the day. So avoiding meetings and all those things. But tooling is something I like to always focus on. Most problems I see with productivity is when you have to depend on a lot of people to do simple things. When for everything I need to do, I need to open a ticket and wait for someone to go and do something there, it creates blocks. Same with code, same idea. So I try to understand where those things happen and how can I automate things I like to provide?

That's the project platform engineering. I want developers to be able to do everything they need to do both in the development process but also the operational side of the house themselves. You need to create infrastructure. Cool. With our guidelines, of course we have guardrails. You should be able to do that yourself. You don't need to open a ticket to do this and that. Or it's just removing that overhead and those blockages from it. And I see that happen frequently with more traditional companies, especially companies that are structured in more of a functional way. You have a development team here, maybe a test team here, maybe an SRE team here. And to deliver the full experience, deliver a feature, you need to go through all of those things. But if you just keep passing from one engineer to the other, things just take time. So I prefer to structure teams as a fully functional that owns this full problem. That I have all the knowledge, I have all the skill set within one team that can work together so that they don't have those dependencies to get something rolling.

And that's where I see most inefficiencies coming with developer experience. And of course listening to developers is important. Imagine you're building platforms, building a product. You need to listen to your clients and see where the problems are, where they're facing more problems, and engineers tend to be very vocal about the things they don't like. So focus on those things. It might be the build process. I mean, today I have a problem with the slow iOS build times. So cool. I know that's simply input for one of my teams to go and try to improve and improve the platform, improve the tooling. That's how I usually like to tackle that.

Caleb Brown:

Absolutely. So speaking about that, how do you kind of establish a clear process for things that are, I don't want to say sensitive, but things like incident response and kind of blameless post-mortems. How do you establish that base?

Martin Spier:

It's hard. But at the end of the day, if the team feels safe and comfortable, it would be a bit more natural for them to be the whole process, to be a bit more blameless. Because they're not trying to protect themselves. I think when the fighting happens, it's because everyone feels threatened that if they did something wrong, something bad will happen to them. Even if it was, I would say honest mistake sometimes happens, sometimes you don't have enough information. So post-mortems, usually I like to focus in what failed in the process and the tools. Someone clicked the wrong button because they understood that button did something different than what it did. The problem is not the person that actually clicked the button. The problem is in the tool, that it's not clear for the user what happens. Is same with you actually a B2C business and you have an app.

So I try to focus on that and then put the blame in the tools and the processes instead of the people to the point that they of course feel safe. Having said that, always keep an eye of what I call culture failures. Maybe someone made a wrong decision on purpose. I'll give a great example, what I call resume-driven development. Someone decides to use technology X because they want that in the resume instead of what's clearly maybe the best solution and what's internally supported. You have to keep an eye on that. The decisions that are, it's a mistake or not a mistake versus things that, "Hey, I don't have maybe the best interest of the company in mind."

So keep playing on that and separate those things because errors are kind of different. So try to do that. My main issue with post-mortems today is make sure I go deep enough and generalize the learning. It happened frequently for me where we learned something in a post-mortem, the service that maybe got affected got fixed and problem solved, but maybe exactly the same problem happens in the different service. So how to make it a bit more generic, and if I fix one, I fix in all. And that's one of the challenges I have today. It's kind of hard to scale that learning.

Caleb Brown:

Yeah, absolutely. I just want to know how you go about prioritizing internal tooling needs versus relying on open source and commercial solutions out there. And by the way, I know that you've written and contributed to many open-source projects, and thank you for that because I think open source is very important.

Martin Spier:

So it's always a cost-benefit analysis for everything, and I include commercial tools in this case too. The problem is that with scale, a lot of commercial tools become, they're not viable anymore. So you tend to go to the develop internally or support open source internally just because it scales a bit better. I'm a big fan of open source. I mean, I think that's, everyone who knows me knows that I love the model. I think a lot of the problems, technology problems are fairly generic and they're not a business differential. So hey, is it something that is not a business differential and we can help the community? I think it's totally valid to go to open source, to contribute, create something and make it public. Always a big fan of that.

So by analysis, it's fairly straightforward. I really try to understand what are my requirements and see what's available out there. Is there something that is open source? And of course something that it's supported enough, has good backing, has a good development team behind it. You don't want to invest a lot in a project that might get abandoned really quick. And that happens super frequently. So you want to make sure it's a viable project to invest in or build on top of. Found something interesting? Great. My first choice is always go to open source and complement and improve where I can. Either contributing back or building on top of that layer. So always try to go that direction. I think it is always a win for me.

Caleb Brown:

I do have one last question that I wanted to cover, which is more of an open-ended. Just want to know if you could wave a magic wand, what's one change you would make to positively impact software development and software development practices?

Martin Spier:

I'd love for folks to go back more to basics of computer science. I am really afraid today and I'm afraid for the future developers. Today, we still have some old gray hair people that when things get really hairy, they actually know what's in the back of everything. But I'm afraid with developing being so easy these days, with your copilots and things are right code for me and low code and languages who are fairly abstract and high level. We have fewer and fewer folks who know the deeper and more complex parts of all that abstraction.

So software building abstractions, a lot of folks really working in higher level abstraction. Which is great for developing business features, but it's getting harder and harder to find folks who really want to dig deeper into something. Hey, I have a Kubernetes team. It's extremely hard to find someone that know the inner workings of Kubernetes, especially if, Hey, I want to change something and I want to contribute back to the project. It's extremely hard. Folks who understand the OS level. It's really hard to find someone that actually knows how to tune something at the OS level. So I'd love for more people to get into that part because I think we'll have a huge shortage of engineers with deep knowledge about something in the future, something I'm concerned today.

Caleb Brown:

How do you think you get folks more interested in that? Like younger developers, how do you think you get them more interested in lower level?

Martin Spier:

I used to speak a bit more in conferences and I always like to share my war stories. And if you really have an engineer heart, I mean within you, when you're a baby, you really like to disassemble things just for fun. You will hear those things and you really want to do and dig deeper. But the part of our script, I think it's bringing more people to the higher level of abstraction is that a lot of people are really attracted by the salaries and the comps and instead of the proper engineering side of things. So I think it's getting people excited about engineering and solving problems and complex problems and engaging them in that, and I think will come with that.

Caleb Brown:

Absolutely agree with you. Martin, thank you so much. This was great. I really enjoyed this. It was really nice hearing, yeah, your war stories, your background and everything. I appreciate it so much. Thank you.

Martin Spier:

Yeah, likewise. Super, super happy to be sharing.

Caleb Brown:

What an inspiring journey Martin Spier has shared with us. From shaping Netflix's early cloud architecture to now transforming financial services at PicPay. I loved how Martin brought engineering culture to life through real examples. He showed us that great culture isn't about fancy statements. It's about living your values every day and creating spaces where teams can truly thrive. His perspective on building high performing teams really stood out. It was refreshing to hear how he looks beyond technical skills to find people with that really special spark, those who get excited about solving big challenges and aren't afraid to take ownership of their work.

The way Martin approaches performance engineering is really inspiring. He emphasized how important it is to build strong technical foundations while giving teams the freedom to innovate. It's that beautiful balance between structure and creativity that lets great ideas flourish.

Thank you, Martin, for sharing your journey with us, and thanks to you, our listeners, for being part of this conversation. These are the kinds of stories that remind us why we love working in tech. It's all about continuous growth and really making an impact.

Can't wait to bring more inspiring conversations from tech leaders who embody what it means to keep moving forward. Find us on Apple Podcasts, Spotify or YouTube music and spread the word if this episode resonated with you. Until next time.