Integration Love Story med Carl Lindberg

Thank you so much for joining Integration Love Story.

My pleasure. Thank you for having me.

For those who have been following us, you know that we recently introduced a new format where I introduce the guest and you can correct or add anything you’d like. So I did some research. You are working at CNIT as an Expert Engineer and you’re in your second year as an Azure MVP. You’re also creating content that others can learn from. Outside of tech, I found that you’re a fan of strength training – because as we all know in IT, we sit still a lot and physical health matters. I also have a question about your bench press record, but we can save that for later. Self-improvement is clearly important to you and I saw that you read a lot of books, so I have a question about the most eye-opening book you’ve read. And beyond tech and the gym, I found that you follow IFK Göteborg and Frölunda – so I’m guessing you’re a football and hockey fan as well?

Yes. Amazing. You know me better than I know myself. I don’t think I can add much.

Books and productivity

Which book are you currently reading?

I’m actually rereading two books right now. For productivity and organizing your work, I’m an avid fan of Getting Things Done by David Allen. The main thing I’ve taken from it is simply getting things out of your head and onto paper or a document. His quote is: “Your mind is for having ideas, not storing them.” I’ve found that to be pretty true no matter what area of life you’re in.

The second book is Making Work Visible. It’s about working with Kanban – what should go on there, what shouldn’t. Basically: how do we, as a team, visualize what we have to do? A common complaint is “I have too much to do,” and then you sit down and ask – what do you actually have to do? Write it down, get it out of your head, and make it visible.

Rereading is about putting things into perspective of what you know now. The first time I read Getting Things Done, I followed everything strictly by the book. Now when I reread it, I think “that was a good point, but it doesn’t fit how I work today – I can approach it differently.” That’s the benefit of reading: connecting the dots to other things you’re doing.

A normal working day

How does a normal day look in your life – both during and after work?

Everything sort of blends together. I’m working as a consultant with one long-term customer. The mission is to be part of what we call an enabling team or platform team – enabling the customer to take full advantage of Azure, GitHub, Power Platform, Atlassian, and so on. We make sure the plumbing works so others can focus on their core work. That can mean anything from troubleshooting an Azure firewall to doing code reviews. We’re pretty strict about code reviews – even if I’m very confident in a Terraform snippet, I’ve almost certainly missed something.

Days can look very different. Some days I’m in the trenches writing code. Other days are more about meetings and figuring out how we should work – improving processes, solving challenges.

I try to balance all of that with strength training. I’ve learned to recognize when my mental capacity is at its limit – when the RAM is full, if you will. That’s when I go lift heavy weights, run, or cycle. It humbles me, I recharge, and then I can come back and spend an hour or two in the evening writing scripts or editing YouTube content.

You had a question about the bench press record. I haven’t tested my one rep max in ages, but I’ve done 100 kilograms for three reps, three sets. It’s me versus me every time. Some days you’re not as strong, and some days you don’t know where all the energy is coming from – but that’s how it is for athletes as well.

What it means to be an expert

Do you feel like an expert during the day, or do you question that as well?

Both, depending on who I’m talking to. When I’m in a mentor role I feel very accomplished – excited about what we’re going to discuss and glad I’m helping someone. But then I can go into a meeting with my own mentor and suddenly feel like I know nothing. I think it’s important to have both. You need to feel like you’re making a difference, but you also need people who can still teach you things.

When did you know you were an expert?

I don’t know if I ever consciously thought of it that way. There have been different points in my career where I felt accomplished at what I was doing day-to-day. But I have to be careful – if I stop learning new things, I won’t be an expert for very long.

The titles Azure MVP and Expert Engineer are not titles I claimed. They were given to me by someone else. My main objective has always been to be a learner and a sharer of information. I have this tendency where, if I don’t understand something, I go almost manic trying to figure it out. And then I want to share it.

The reason I started my blog was partly the same thing Scott Hanselman described in his episode – you’re just so excited about these things that you want to talk about them. But also: if I try to explain a technology to someone, any gaps in my knowledge become very apparent very quickly. And when you’re publishing a blog post or a YouTube video, you don’t want those information gaps – people will point them out, which forces me to fill them. All of that leads to deeper understanding, and then people look at you and say you’re an expert or you should be an MVP. But I would do all of it even without the titles, because that’s just who I am.

How it started – from GTA to Azure

You mentioned you don’t have an engineering degree. How did you end up where you are?

I’ve always been interested in computers. When I was about 11 or 12, I was playing San Andreas Multiplayer – the multiplayer mod for GTA San Andreas. They had roleplaying servers with a help chat for new players. I started volunteering there, answering questions. No pay, nothing – just answering questions. Eventually I became a server administrator, then a forum administrator.

On the forum, users could buy custom titles for their accounts. My job was to open a web console and fill in what was essentially HTML snippets – changing colors, making text italic or bold. And I remember the moment I updated something in that console and the website actually reflected the change I made. I thought: I did this. I made this happen. That was the spark.

After a period of burnout from school, I went into construction for a while. I couldn’t find a job, which was humbling. But a friend recommended me for a company where we installed point-of-sale computers and printers at customer sites. From there the journey continued, and since around 2015 I’ve been in tech and I’m never leaving.

Survival kit

If you could only bring three things to survive your working week, what would they be?

My computer, obviously. Coffee – I consume way too much caffeine and I can’t get through a day without it. And dumbbells, so I can do my mental reset and then get back to work with fresh energy. Computer, coffee, and dumbbells – and then you will be doing magic.

VS Code extensions

What’s your favorite VS Code extension?

Since you already know the favorite one – Claude – I’ll talk about the second favorite, which is the Microsoft Terraform extension. You have to have it if you’re working with Terraform. And GitHub Copilot – before it was an extension, now it’s just an essential.

One that is underrated: I have an extension called Presentation Mode that blacks out everything except the code you’re looking at. I find it helpful when doing screen recordings, or if I’m sitting with someone and I need their full attention on the code. We enable presentation mode and we’re not leaving until you understand it.

Platform thinking and infrastructure

You’re intentional about working environments and rules. If you were starting with a new client tomorrow, what’s your first approach when analyzing their infrastructure?

First, I’d set expectations on what they’re trying to accomplish. Some clients have everything on fire and just want you to fix it. But you can also introduce the question: how would you want to do things when we’re not on fire?

That leads to a major mindset shift I’ve made over the years. Previously, the idea was “Carl is the Azure guy – if it’s Azure, talk to him.” I’ve moved away from that. Now the mindset is: I’m not the Azure guy, I’m the platform guy. I’m not going to write your application for you. But you’re a developer and you need a platform – so I’m going to help you get a landing zone, make sure you can do what you need to do within it, and provide guardrails while still giving you autonomy. It’s always a tug of war between guardrails and freedom.

The most important thing is that developers can take responsibility for their own environment. If I go in and do everything for them, they won’t take ownership and they won’t learn what they need to maintain their own application. Enabling people through a well-built platform – that’s where I’m at my best.

People and process over technology

You talked about fires. Have you ever been in a “this is fine” situation?

Yes – and interestingly it’s usually not the technical things that are truly on fire. The real problem is often people and process. I’ve been in environments where someone is frustrated because nothing works, and two people refuse to talk to each other because they think the other is an idiot. In that situation you’re sitting there thinking “this is fine,” because it doesn’t matter what technical solution you implement if you haven’t solved the underlying issue – the need for alignment on where you’re going and how you’re going to get there.

The conversation also looks very different depending on whether you’re talking to a CTO whose main concern is budget, or a developer whose main concern is clean code.

AI, context, and the future of infrastructure

It’s January 2026 – from an infrastructure perspective, what do you think people need to pay attention to right now?

The slightly boring but genuinely exciting answer is: AI. But not AI for its own sake – AI with the right mindset and understanding.

The major insight for me is the same as with the Bicep-vs-Terraform debate: it’s less about which tool you use and more about your process and principles for using it.

With AI, context is king. Imagine talking to someone who has never met you, never seen your work. If I just say “write me a YouTube script” without giving any context, you’ll do your best – but it’s unlikely to match what I actually want.

In my own workflow, I use Codex and Gemini in my CLI, pointed at a repository of markdown files containing instructions – my personal notes on how to write YouTube titles, how to structure intros, what I’ve rejected before. All of that is context. When the AI gives me something I don’t want, it’s on me to go back and update the instructions. I’ve even set it up so that rejected YouTube title ideas get saved to a discarded.md file, and the AI checks that file before suggesting new ones.

The same principle applies to troubleshooting. If I give GitHub Copilot just an error message, I get generic possibilities. But if I also share the reusable workflow file, the calling workflow, the repository structure, and the managed identity setup – then I’m getting much closer to finding the actual issue.

Everyone is going to say AI, but maybe people don’t say AI for the right reasons. I want to say AI because if you use it with the right mindset and if you understand a little bit about it, you’re going to have better results. And it is further enhanced for me in a way that I feel like yeah, I’m not being replaced at all by this thing. I’m being enhanced by this thing because it’s still me who is in charge. I am still telling it what to do and what to look at. And I’m still saying – write the Terraform block this way. Don’t use that provider.

AI is a prediction engine, not a fact machine. Give it the right context, use it with the right mindset, and you won’t feel replaced – you’ll feel enhanced.

A practical tip: with Docker Hub and Docker Desktop, you can spin up an MCP server through a container and hook it up to Claude Desktop and tools like Obsidian. That’s where it really clicks – when you see what AI can do with the right context and the right connections.

Do you need to know how to code?

Do you think you need to learn to code to stay relevant, or are we entering a new phase?

There’s nothing negative about learning to code at any point. It’s not necessarily a requirement, but it’s always going to be a benefit. You don’t have to be a prolific developer, but if you can sit down, read code, and methodically work through it – that alone has brought me an enormous number of opportunities and ideas. My general recommendation for a life in tech: just keep learning.

Closing

We could keep talking for hours. You’re based in Gothenburg too, so maybe next time we do this in person.

I’d love that.

We’re also thinking about starting a think tank in Gothenburg – gathering people within infrastructure, integration, and tech to learn from each other.

Agreed. The more we learn from each other, the better.

We’ll have you back for an episode two – and hopefully bring your mentor Simon along as well.

Simon would be a great guest. I’m in awe of what that man knows.

And the question we’ll send out publicly with this episode – what’s your question for the audience?

My question is: what aspect of your life do you plan to improve with AI – or what project do you intend to build, from A to Z, using AI?

Thank you so much for joining us. It was a genuine pleasure.

Thank you for having me. Super fun. Looking forward to the in-person episode two.