GitLab’s Tim Zallmann on Building Distributed Teams That Move Fast

The hardest part of distributed work isn’t distance. It’s keeping teams fast as they grow.

Tim Zallmann has been answering that question for nearly a decade at GitLab, one of the world’s largest fully remote companies. Today, he serves as their Vice President of Engineering, focusing on keeping teams agile, connected, and ready to innovate.

From startups to enterprise innovation hubs, Tim’s career has always been about building technology people can use. At GitLab, that means small, empowered teams, proof of concepts that guide strategy, and clarity that connects a global workforce.

In this episode of Keep Moving Forward, Tim shares how he leads distributed teams with trust and autonomy, why small teams deliver bigger results, and how AI will transform how engineers build software.

  • 43 min

GitLab’s Tim Zallmann on Building Distributed Teams That Move Fast

Keep Moving Forward

Play

Adapting Leadership to Context

Tim’s leadership journey has spanned startups, banks, and fully remote companies. Each environment required a different style, and he quickly learned that success depends on adaptability.

“Management needs to be adaptable to the situation,” he explains. “You need to bring in your experience, but also adapt to the certain situations and then apply the things that you want to change or build at the end of the day, but not with a constant mindset that is very binary.”

At GitLab, that means understanding how to keep teams connected and motivated even when spread across the globe. From local meetups to online games and department days, Tim looks for ways to recreate the informal connections that offices provide. These efforts are not optional extras. They are critical to building trust. And as Tim points out, “teams work 10 times better than individuals.”

Small Teams, Clear Context

Leading more than two dozen teams requires both structure and agility. For Tim, the key is to keep units small and focused, giving them the autonomy to move fast without being slowed down by dependencies.

“It’s one of the aspects that I’m very focused on — to keep units small and agile to give them enough room to make their own decisions and to steer through the day-to-day as much as they need and completely on their own,” he says.

That autonomy only works when paired with clarity. Tim emphasizes the importance of managers connecting the dots across teams, spotting overlaps, and ensuring alignment. Much like his passion for understanding the intricacies of football management, he believes leaders must anticipate what skills will be needed six to twelve months ahead and shape teams accordingly.

The result is an organization where engineers have the context to make decisions, and leaders provide the trust and alignment needed for teams to deliver consistently.

Proof of Concepts and the Future of AI

Tim is passionate about proof of concepts, calling them one of the most powerful tools in engineering leadership. For him, POCs are more than technical experiments. They are a way to surface gaps, test assumptions, and align teams around what is possible.

He sees the same principles shaping AI’s impact on software development. “The amount and the speed of innovation… that’s the last time I have seen this was a little bit like when the internet came around,” Tim notes. He views AI as a tool for removing repetitive tasks so engineers can focus on higher-order work. Whether triaging errors, managing dependencies, or accelerating testing, AI can free up teams to innovate and solve bigger problems.

For Tim, these changes reinforce a core truth: leaders must prepare teams to adapt. The future will demand speed, creativity, and resilience, and it is leadership’s job to make sure teams are ready to meet that challenge.

By grounding his leadership in trust, providing clarity across distributed teams, and championing innovation through proof of concepts and AI, Tim shows how leaders can scale both culture and technology. His approach offers a blueprint for anyone preparing teams to thrive in the evolving world of software development.

Transcript

Tim Zallmann:

This is something that of course creates teams, and teams work 10 times better than individuals. That's the mystery part where a lot of people I think underestimated think, okay, I used to pass to my remote first, or they are happy about it because they have this kind of flexibility. But as everyone knows, if you have someone who is super motivated, who really understands the mission, will be much, much, much better at their work, will be much more efficient and much more productive in my perspective.

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.

Today, I'm joined by Tim Zallman, Vice President of Engineering at GitLab. Tim has spent his career shaping engineering culture that thrives in distributed high trust environments at GitLab. He leads globally distributed teams, steering them towards sustainable delivery, operational excellence and continuous improvement.

In this episode, Tim shares his insights on leading at scale without sacrificing trust, creating environments where engineers can do their best work and the importance of clarity in both communication and execution. We talk about aligning teams around shared values, enabling autonomy through clear context and balancing innovation with operational stability. If you are a leader navigating the challenges of remote engineering teams or working to build a culture that scales, you'll find plenty of practical takeaways here. Let's get started.

Thank you so much for taking the time to join us. Obviously had a chance to go through your background and your history, so I'm really excited to jump into this one and learn a little bit more about your journey and so I thought maybe we could do that. Just have you kick us off by walking us through your early career, starting with programming I think at your parents' software company at the age of 15 and how that whole path shaped your journey into technology leadership.

Tim Zallmann:

Yeah, thanks a lot for the invitation. My name is Tim Zallman. I'm located in Vienna, Austria. I started my career at the end of the day through my parents, because my parents had a software company so I got introduced to computers and doing stuff beyond just starting some programs very early on. This really meant configuring stuff at the beginning. I still know auto execute was a big topic back then and configuring that your PC is starting up right. Yeah, in reality I started with the age of 15. I started at the company doing some basic intern, started my first programming jobs there, started getting into the world of doing commercial software development. They were very focused on POS, so point of sale development which had a lot of to do with on top of this with hardware, with card readers, so this was also one of my first projects where I completely diced into that I was targeting completely on my own, which was programming the interface between a PC and a credit card reader and C back then and it's really connecting this then to the main application and topics like that.

From there on, starting very early on, I got then also at 18, as it is when you're young, you are very naive to some extent and I was like, "Okay, I can do this now on my own," and started my own software company, which was mainly focused as a web agency. Back in the days was really the start of the whole web and internet topic. We were very focused on websites of different kinds, small businesses but also bigger companies. Then still with the connection back to my point of sale, I did also a lot of classic consulting going to customers. I spent a year in the UK basically going back and forth all the time between Vienna and the UK, working there on a couple of really large interest projects at the end of the day that were around DVLA, which was interesting projects, so really programming the tax discs for cars in the UK, which was an interesting project, and that's how I developed my career.

Then also did larger projects. For example, did my first remote job back at the days, which was for a Canadian trucking company that started a startup to do infrastructure around logistics and really getting trucking companies into the internet, which was very hard back at that time. Did then also a couple of other projects with a culture forum from Austria and New York and so on, and this is how basically this web agency developed over time.

Then at some point, a friend of mine, he was like, "Hey, I'm doing board games and I would love to hear if you think this could be something that we could also recreate with the web," and that's when we started and really started looking into getting a board game into the internet. This became one of the first browser games in the German-speaking area. Got very popular around here, which was also very fun and interesting. This is where suddenly a lot of marketing, you saw people in shops playing your game and stuff like that. We always stopped there basically at only doing it in the German-speaking area. We completely missed out on internationalization. It was also very complicated, but also around politics and how they work and democracy and bolting systems in Europe.

Based around that, we also started a game that started a project for the European Union, built a research game there and did another couple of startups around that before that time that were also focused on event scene. Did a lot of music stuff, and that's basically how my whole career developed also into more managing people to some extent and getting into rebuilding applications. Very early on, my main focus in engineering was not on the algorithmic part, but it was always about building stuff that people can use and that always excited me and got me to that transition.

Caleb Brown:

Very cool. Always love hearing the stories of building the board game into the web and things like that, so it's always interesting to hear those journeys of someone that's a creator in tech and always talking to someone like you that have been in those different environments. I always think that's interesting to hear your perspective from startups to enterprises to remote first companies. What were some of the key lessons that you learned from those different environments and how has that affected your leadership approach?

Tim Zallmann:

Great question. I think management needs to be adaptable to the situation, and this is something I learned to some extent in the hard way because if you're a startup, you're very naive. Let's build something and then you need to figure out how you also earn money at some point while project work, which is much more focused on really getting a project done and getting it done on time. And then after I did this kind of startup work, I also got completely into an innovation hub, which was in Austria around a very large bank and they were like, "Hey, we need to reinvent ourselves, we need to get into the digital age."

They got a lot of people that were quite successful around the startups and were like, "What should we change? How should we build digital?"

That's where, one, that was basically my last job before I got to GitLab and at that point of time it was like, "Yeah, let's reduce this completely. Let's start completely from scratch. Let's build an online banking that is much more targeted." The experience that people see and feel out there with their native applications, how you use search that you can search in your account, hey, when did I pay the last time this and that. And oh yeah, you paid also this differently in this month. So that is much more digital and digital native to some extent.

That was I think a huge reflection because we started their innovation hub. It was literally two, three people who were like, "Okay, let's paint this out, let's start this, let's do the prototype."

Super startup being very lean, we represented the POCs to the CEO of a huge bank and she was like, "Yeah, that's awesome. I want this, I really want this."

And then suddenly this whole transition, how to get this into the bank, how to get this established across many countries, many bank internal IT, and this whole conversation around how do you build this in a large scale team but also large scale application that has financial limits on the different compliance and security. A huge topic there of course, and that's where exactly these items are completely reflected because we went and also in and we wanted not only to change how they build an application, but we also wanted to change to some extent the culture so that the classic culture must be deployed two times a year and that's it.

We were like, "Hey, no, we are used to deploying very often three, four times a week," and that was to some extent the culture change, to some extent the culture clash, but that's also where you could see these different philosophies and how you can adapt also your management style, how to get people on board, how to adapt but also not completely say, "Okay, I'm adapting to this new part," but also bringing in some change in this culture.

That's adapting again, now I'm at GitLab almost eight years by now and at GitLab when I started was also still a very young company, a hundred plus. Now much, much, much larger, 2,000 plus people and complete different styles. Also, remote working needs different kinds of management perspectives, needs different kinds of adaptions, how you can get people on board, how you build teams, how you can transport vision and get everyone excited. I think this is something super important at the end of the day that you as a manager come into a certain situation and don't come in, this is how I did it all the time and this is how I was successful at another place.

I strongly believe that you need to bring of course in your experience, but also adapt to the certain situations and that you can react to certain situations and then apply the things that you want to change or that you want to build at the end of the day, but not with a constant mindset that is very binary. No, I do it all the time like this and this. So I think that the style, how I work now at GitLab of course I learned also a lot all the time here is very different compared to other setups companies that I worked before-

Caleb Brown:

Yeah, that's fascinating. I want to focus a little bit on that journey at GitLab. I always think it's fascinating to see how someone's experience in a career like changes when working with a company that is also evolving at the same time. What motivated that transition to GitLab at the time and how has your role evolved with, like I said, nearly I believe eight years at the company?

Tim Zallmann:

I think it was not at that point of time when I left the bank that I wanted to change to GitLab, it was clear that the environment, and I felt a little bit, I said as before, I love building products and I want to be close to that. I want to be close to the people that build products and I didn't have the feeling anymore that in this environment where I was at the bank that this was my day-to-day job. It was much more large enterprise, talking to a lot of people and figuring out things where I was very much away from building and stuff. I quit my job there and said, "Let's find something new," and with my past experience of remote work, I was very interested at that time, my first child was also on the way a couple of weeks later after I quit literally.

So I was very interested to see if the remote thing is a thing at that time and see if I can get a career also in a remote environment because the other thing that I learned also at the bank was you are very limited at the end of the day to your local area. It means one to two hours, people that can drive to the office, that's your spectrum. But I was always, when I worked for example with the company in the US, that completely changed also my personal perspective in working with other people from other cultures and other places in the world at the end of the day I think is a super interesting part.

That's where I said, okay, let's take a look for remote stuff. I stumbled classic hack and use, I'll check on the first of the month, GitLab posted, "Hey, we are hiring."

Let's try, let's apply to it. I told my wife, "Hey, here's a new job I just found online. It's a small three liner, but maybe this is something."

I applied, had a couple of interviews and what was fascinating was the more I talked to people at GitLab at the time, the more I got interested into the job, the more I felt, okay, this is a thing they really care about building the product, but also on the other hand they really care about the values. I also was fortunate enough at that time to my last interview was also with the former CEO of GitLab, Sid, and that also was quite a very interesting space to see his passion about the product but also how he wants to build teams and I thought, yeah, this is it. Let's try this out.

I started as an engineer manager with five people and then the whole company grew a lot over time. Also, I grew with that part and by now I'm VP of engineering responsible for multiple departments across the whole development part of GitLab. Yeah, I still am very honest, I can say it's up to this day there are multiple things that excite me at GitLab, which is one, the people being able to work with fantastic talent and fantastic people that go from right now California to New Zealand and everything in between. Doing this on a day to day and getting these perspectives and getting this input when you are working with them.

And on the other hand, a company that sticks to their values and really stays true to it, I think it's super easy if you, hey, these are my marketing values, let's put them in the folder, but as soon as it gets hard you throw them overboard and that is something that especially after eight years I can still sign on a day-to-day basis. GitLab is very good at living their values on a day-to-day basis.

And third, building a great product and being close to that and especially in this environment, building a product that I can understand that I can live and that I use on a day-to-day basis every day for everything that I do. I would say 80% of my day I work also in the product that we build is something that also added a completely another level. It was very interesting to build a banking product that everyone uses basically, but you just use it five minutes a week, especially if it's a good banking product, you should only use it five minutes a week. And with GitLab, a product that you use day in, day out that also can, that define how people work in the say industry that I'm working in is still something very exciting and very motivating.

Caleb Brown:

100%, that's awesome to hear. Yeah, companies that exist that long that are still so dedicated to making a good product and keeping true to their values as beautiful to see, so I'm very happy to hear that. I did want to stick around a little bit on the topic of remote work. As you mentioned, you were working remotely before it even became mainstream, and so now that we've seen so much in our world of companies moving to remote, some struggling with that, some doing a better job with it. I just want to hear a little bit about how you approach to remote leadership has evolved over the years.

Tim Zallmann:

I think remote work is great, because it gives you a lot of flexibility and there's of course a lot of people are like, "Yeah, remote work is the best thing invented ever for the working force."

I think it has its pros and cons, but you need to be very deliberate that you understand also the negative side of it and work deliberately against it. One example, it's very hard to build connections just in an async and remote environment, so you need to figure out how can you get this kind of building trust, building relationships, building teams at the end of the day also into the think world of remote work, or on the other hand try to get people into the same place for at least some time so that they can build these connections.

I think you need to be very focused on that part that you try to build also social parts, that you don't just focus on, okay, let's do, go through our agenda, but you need to also try create a social environment where people can share things, where they can feel this kind of connections. We are also having local meetups where you're not meeting at the end of the day, you are specific team, but you're able to meet at least other Git levels in your area. It also helps a lot to get this kind of connection.

We have also online games that we do. We have developed department days at the end of the day that where the team meets and does some online activities from playing GeoGuessr to other games online so that they can build up these connections. They're able do cooking classes together online, and I think this is something really important that you have this understanding how can you get them on board, but there are also parts that are very hard to manage and you need to figure them out over time, especially the remote environment, especially getting people excited about your vision, getting them excited about certain targets, especially if everyone is muted in a call, it's very hard to read the room.

We have the target that everyone for example, turns on their camera because it makes the connection and the dialogue much better than talking to a gray label at the end of the day. But I think that it's something where you need to also work, especially on the one-to-one relationships where you get a better understanding how people currently think about situations, how they see their work, how they see what they're excited about, what they would like to focus on. I think this is something that you simply need to work a little bit more intense in a remote environment because in a office environment you simply get them naturally. You see these kind of reactions, you know who is working with whom because they're standing next to each other at the same desk, they can share these plastic water cooler topics and stuff like that.

And I think this is something you need to recreate a little bit, so it's not just someone sitting meeting someone for 10 minutes a week and that's it so that they have this kind of connection to the rest of your vision, your target, what you want to reach with the team because this is something that of course creates teams, and teams work 10 times better than individuals. That's the missing part where a lot of people think, underestimate. They think, okay, I used to pass to my remote first. Of course, they are happy about it, because they have this kind of flexibility, but as everyone knows, if you have someone who is super motivated who really understands the mission, will be much, much, much better at their work, will be much more efficient and much more productive in my perspective.

Caleb Brown:

Something that I've found interesting in just chatting with you is a dedication to the product, which I love. And that reads to me a little bit from my experience of being in startups and smaller companies, you really had that, but it seems that you've been able to scale with that as you've grown into a larger company. But I wonder how you maintain that startup-like agility while implementing a structure that is needed for a much larger organization.

Tim Zallmann:

I think one of the aspects that I'm very focused on is to keep units small and agile at the end of the day to give them enough room to make their own decisions, and to steer through the day-to-day as much as they need completely on their own. And I think this is, or with counterparts or with other connected parts of the company, but trying to stay as dedicated as possible to a certain task I think always helps, that you have simply a group of people who can decide, who can move forward with things are not constructed, basically obstructed by the rest of other things and all the dependencies that you might have in a larger organization that leads to this super slow down.

I've seen this in multiple environments before in my other jobs is that as soon as you have this huge dependency tree, that's where it becomes complex because suddenly you need to talk not to two people, but you need to talk to 20 people, you need to convince 20 people that this is the way forward. You need to wait until someone over the air gives you the green light and then you need to talk also to someone over here. And this kind of dependencies has I think the highest effect of how fast people can move.

That's what I'm trying to recreate, that we have these units and we even have now, literally just weeks ago, we have even created a smaller subsection of that where we say, okay, we are building a team specific just for building a feature so that you bring in from the different areas from everyone who is needed to build a certain feature, you bring them together, they are from that day on, they started working on this feature, they are a subteam, they have a kick-off, they have a clear dedicated Slack channel. That's the people who will get this from start to finish. This is exactly something that as the whole organization in certain areas grew bigger is something that hopefully will help to deliver stuff even faster.

And on the other hand, a huge aspect is that everyone on the team has the same kind of understanding. This of course helps a lot with simply the product that we are building because we have people who have a clear understanding of what our intention is. It is not something very abstracted. Engineers are simply implementing, then they're shipping it, then they hear a couple of months later, no, they implement it, they try it out on themselves, they use it then on themselves on a day-to-day basis. This is definitely something super important because then people can make these kind of decisions on a day-to-day basis because they have a clear understanding. They need to take also these things into consideration. There's always a very complex things of course to get all the information into a team so that everyone is up-to-date with, okay, how do customers use the features? What are the sizes and scalings and different aspects. Customers use our stuff out there, but I think it's super important that people can do their best job at that.

Caleb Brown:

100%. That's fascinating. You mentioned something in that leads me to my next question, which is just how do you maintain alignment, I guess you would say across 25 teams or so working on different components of the platform? I'm just interested how that works at that kind of scale. And like I said, you touched on it, I wanted to dive into it a little bit more because it's fascinating.

Tim Zallmann:

To some extent, I think it's the target of my group managers and line managers. It's not just, okay, you need to do the deeper management. No, we have the dedication that all our engineering management is focused on engineering and management, which means that the people that I have in my management team know and understanding the engineering part but also understand of course what we are trying to achieve overall and building the product. That's where they come in and try to connect the dots. To some extent, one of the biggest task of my job is literally connecting the dots and trying to see what is the needs of my different teams. But at the end of the day it's literally, hey, yeah, this team is building this and by the way, these other teams also doing the same stuff. Hey, you should talk to each other, and then talk to this other third team because they just have done this three months ago.

That's something where we are trying to keep everyone up to date by simply bringing people together. And of course, strategically all these things change not on a day-to-day basis, but you have different challenges over time. But that's also where then my directors and senior engine managers come in, and they are trying to align between the different teams. We also have a key target that we understand what our needs are for certain teams, which means I'm a huge football fan and that's where I bring always football management, soccer for you in the US. But I tried to bring in also these connection points where it's like you need to understand what your team is missing in a certain situation, and what it is also missing, not just right now, but that the manager or larger group manager has a clear understanding what is the stuff that we want to build in six months, in 12 months and that they already read now in hiring to say, "Hey, yeah, we are missing this technology part," or, "We are missing this kind of skill set."

Okay, this means you have a radar chart of what are your needs of a certain team and you start hiring, or you change your organization, you adapt the organization, you move people between teams and do internal hiring to adapt exactly to the needs that come along. I think these are two biggest tools that we are using on a day-to-day basis is literally connect data dots and bringing people together internally and trying to align them on also large scale operations that we are doing. And on the other hand, do this kind of organization design around new hires, but also moving people around, giving them new challenges and bringing them into situations where they have also they can grow. They can grow literally by going to another team and building up their certain architecture or a certain skill set.

Caleb Brown:

100%, and that's also I think to some degree shows some level of trusting in them and wanting to see them grow. I think that's good, well said. And something again referencing something you mentioned earlier that I really wanted to make sure that we got back to because I thought it was very fascinating. You had mentioned that a proof of concept speaks a thousand words more than any slide deck, something along those lines, which I certainly agree with, but I'm curious how you implement that philosophy in your leadership approach.

Tim Zallmann:

Yes, so this is something I'm very passionate about because as mentioned before in the job before GitLab, this was my main role was bring something to life. And I think this is still the power of a POC. As I mentioned, the way you have the capabilities of not just doing, okay, this is one use case, here's another screen and here's another screen you can experience that you can bring and build. Also, the connection most of the time in POC is also with the rest of your existing products. For sometimes, it's one thing to transport and certain idea, but I think it's also super important that you're not transporting the idea at hand, but also then the long-term kind of impact that you might have across the time while you are building a certain product, while you are certain extending and building more on top of this.

I think that's also where POCs can come in. They can show already a vision, they can connect the dots, they can bring in these items. One of the things is we are building a lot of POCs both on a technical level but also on an exploration level. And especially right now with AI, I think it's super important where it's not just, yeah, let's build this feature. No, you have a certain technology, and you need to try to figure out first what is possible with this kind of technology that you can push exactly this technology to the limit and then can come back and say, "Okay, this is what we think we might be able to do. And by the way, this is also something we already tried out and look here, this is a use case and this is how it could work."

That has a huge power and a certain aspect of not only bringing the understanding for yourself, because I think this is also a very underestimated aspect of POCs is sometimes especially in building products and as an engineering world, you have an idea but you're not 100% confident. You need to figure out the bits and pieces that are still a certain gray area and this helps you to fill out a certain idea bubble. And I see this all with my engineers who are especially great at that.

They're like, "Oh, I had an idea and then I come back 48 hours. I had an idea, I built it out and by the way, I just figured out we can also do this and we can connect it to this."

And suddenly bam, bam, bam, it's like puzzle pieces, putting them together. And that has this kind of aspect where you can then bring also not yourself on board, but also can bring other people on board and can show them, "Look, if we invested with that."

And at the end of the day, the work that we do is always connected to investments in the sense of, hey, we have a certain feature or a certain part of the product and the product management needs to decide, okay, we want to invest into that area. We want to build out this certain feature and that helps us understand better, okay, this is worth doing that kind of investment and transporting the target of the application that we want to build or the target of the feature that we want to build.

Caleb Brown:

Yeah, love that. Curious to just learn your perspective on how you see AI transforming software development and really what you're most excited about with presuming that you're excited about it, what you're most excited about it in that space of software development.

Tim Zallmann:

Yeah, great question. As I'm also responsible for the AI development use that are building the GitLab AI features, I'm very deep into that topic. I think on one hand something super important to understand, and that's still the most surprising thing, is how fast the AI space has grown over the last month to some extent, or not even years, but seeing that you make a certain prediction and three months later we are already two times further ahead of it. That's still something that is very astonishing. The amount and the speed of innovation that fuels then again, more product development and more things and then another round and another round. And the more people of course with more investment and more focus on it is like it's high speed. That's the last time I have seen this was a little bit like when the internet came around and there was so much that suddenly were opened up and completely new areas and new spaces.

I think for software development, this is real industry change. How I see it is a little bit, I'm trying to, when I'm explaining this to people outside of the industry, I'm trying to explain this always with the connection to high-class chefs is like they need to do a lot of things during the day and one of the main things that they're focused is building new recipes and doing the final, putting the final thing together. But day in, day out, they do also, they cut tons of vegetables, they cut. They need to go to the market and buy stuff. They need to clean their kitchens, they need to clean tons of things and they need to do a lot of other things around their main focus of work. And I think this is how I see it at the moment is how the industry can be changed in the way that we take away exactly this kind of work that is not the main focus of people.

And that's a little bit how I see this for software look at. We are capable of solving certain things that a software engineer is doing on a day-to-day basis, we can take away from them and that they can focus on more, a little bit more orchestrating a little bit more on the higher and bigger speaking. And this can be, there's of course a huge focus on the coding style. And this is also a great aspect that we are looking into from the GitLab side, but especially with the agentic space, the capabilities that are constantly also again exploding to some extent. It's like I think there are so many aspects in the software development side. Good example is engineer gets the new ticket, a customer has seen the error, they get 500, blah, blah, blah, blah, that's the error message. And in that second, what happens is normally that triage starts. Engineer to look around, they need to look for issues and oh, log file, they need to log in there, and hey, maybe this person has seen this and so on.

And that's again, I think something and that we are also looking at GitLab where we can bring agents to help you on that and cut the time of that task. They're on to a minimum because these agents can run around, they can look a lot at log files, they can look around if there were recent code changes. They can tell you, "Hey, by the way, this error happens most of the time just on Firefox. This error is happening only at that time of the day, and it is only if these people have this kind of license and if they have activated these feature flags. And by the way, here was a change that was recently introduced in that as they called."

If you think about this, then you suddenly have literally cut down the time of the engineer to really look at information and do this kind of combination and thinking through these things and trying to find the root cause compared to just, "Oh, now I need to log into this system. And yeah, what was the query for the log file?"

This can be, you can go lost in a rabbit hole very quickly and it's very time-consuming. I think there are so, so many aspects of the software development side that we can re-innovate to some extent through AI, where we can support software engineers, where we can resolve things automatically. Huge aspect, dependency management, upgrading dependencies and fixing and adapting tests to this is a huge part, which is not only a huge part for a single engineer, but it's also a huge part for especially large enterprises because if you think that you need to upgrade your dependency not in one project, but you need to upgrade it in hundreds of projects. And then for me for example, it comes also to the point it's like, is this something we can invest? Do we have the time for it?

Or this takes a couple of months, we need someone else to investigate or let's push this out classic, basically push out. That's I think where we can also cut down this kind of work because it doesn't need to mean that AI solves 100% of the problem, it can literally just save 80% of the topic. And that's a huge value. That's a huge customer value. That's again, where we are also looking at from the GitLab side is what can we do both in the coding aspect but for the rest of the platform? And that's the really interesting part working in AI GitLab is we are not just looking at one aspect. It's not about creating code certainly in a certain file, but it's looking at the whole software development side. We're looking at all aspects and looking at it that we have the access to it through the target. We have one platform that has all this kind of information.

Caleb Brown:

Really interesting, well said. And I want to be respectful of your time, one more question that we'll end on. Folks that listen to this are often already engineering managers or we have a lot of engineers, individual contributors that are listening to think about if that's what they want their next move to be. I just wanted to see if we could end it on something that someone like that listening, one thing that you would want, if they forgot everything else in this podcast, one thing that you would want to have them take away from our conversation here, what would that be?

Tim Zallmann:

Good question. I think it's adapt. Adapt to certain situations, adapt to certain teams challenges, adapt how you personally interact with teams and with certain situations, but also try to get this into the rest of your organization. I've seen this especially around ICs moving into the engineer management. I always ask them, "What's your motivation to go into engineer management? Why do you want to now go from an IC role to the management?"

And I think this is something very important for them on one hand to really think through, is it just the title? Is it just I want because I've seen this is pretty cool, or is it really that they have also the certain aspects of it that they need to be interested in to go into management? Which is on one hand working with people and literally trying to build teams, trying to connect people, trying to set them up for success, giving them opportunities, understanding people, communicating a lot with people. I think this is very different to a classic IC role.

I've seen this multiple times from my career is the classic, "Oh, you are here the longest at the company, you are now the most senior, now you are our manager."

And I think that's the worst thing that can happen, and that should be that the last of the motivations for people to go into engineering machine. It needs to be this kind of combination of, "Hey, you are super interested into engineering, and you are super interested into people and trying to combine that on a day-to-day basis."

And as mentioned before, I'm a huge proponent that people in engineer management need to understand their engineering stuff. They need to understand what they're working on. They need to understand what their team is doing on a day-to-day basis because only then you have have a clear understanding, okay, this is the frustrating part, okay, let's fix this, let's help them to be more productive, let's help them to be more efficient.

One good topic there is target your managers also to do code changes. They know that they shouldn't be, not part of their roadmap, but they should have an understanding what is the daily structure example for an engineer, what do they need to go through to develop something, test it and deploy your code. What are things and that should bring out, and again, this engineering mindset is where do we have certain aspects that you can improve that your team, your organization can better? And if you have this kind of understanding, then I also do this internally a lot is talk to your manager, talk to your manager that you're interested in. And then because managers could create opportunities and if they create for you the opportunity to start experiencing it, that you get a better understanding is this really the stage for you?

Then you can do step by step. For example, we give them people who are interested into engine management, we give them a certain kind of target for the first task around managing certain aspects, managing also communication of a group so that they can figure out is for example, talking to a lot of people, something for them. Is it really something that they can stand in front of 10 people and say, "Look, let's have a conversation."

And not be like, "Hey, how are you?" And that's the end of the story.

I think this kind of experience and these first steps are so, so important that you are able to transform the people who are really the right talent and the right interest to get into engineering measures. That's in my opinion that the base part of having then managers who can apply this then to their teams and can grow in this role also beyond just managing one team and have them also understanding how you can manage managers, which is another level, but again, opportunities and start people growing into it. And I think that's the main topic that I would give if you're interested, bring it up, figure out if, what are your talents? On one hand, there are things that you can of course learn, but what are also your targets of getting into management? And then trying to get these opportunities to experience them, and then grow into them.

Caleb Brown:

Very well said. Tim, thank you so much. I really enjoyed this. Super interesting. And yes, thanks for taking an hour out of your day to chat.

Tim Zallmann:

Of course. Thanks so much for the invitation, and thanks for really great questions.

Caleb Brown:

Chatting with Tim offered a clear look at what it takes to lead engineering teams that are both distributed and deeply connected. One thing that stood out to me was his focus on clarity, making sure people have the information they need when they need it so they can move fast without second guessing. His approach to building trust by empowering teams with context and autonomy is a blueprint for leaders everywhere.

I also found his thoughts on balancing innovation with operational stability especially valuable. He's not just talking about keeping the lights on, he's talking about creating a culture where engineers can take risks, learn quickly, and still deliver with consistency. It's a thoughtful reminder that leadership in tech is as much about building the right environment as it is about hitting the right goals. Tim's perspective shows how being intentional and putting trust in your team can unlock both speed and quality at scale.

Join us next time for more insightful conversations with tech leaders who inspire us to grow, lead, and innovate. Find us on Apple Podcasts, Spotify, or YouTube Music, and don't forget to share this episode if it resonated with you. Until next time.