Gregor

Honestly, I don’t know. I got business cards at some point, but I’ve never handed one out... My email signature says “Senior IT Consultant / Solution Architect.”

Good question, but hard to answer. We have a very flexible work culture, where you can end up doing quite different things that don’t always match your job title. But I’d describe it like this: As a software architect, you give the code that developers write a context. The job is about understanding the process one level of abstraction above the software. That way, you can often answer the “why are we doing this?” question for developers — and I’d say that’s my main role. It’s definitely not about standing on a theoretical pedestal and handing down unrealistic instructions to developers.

I’d agree. You inevitably learn a lot about the client’s business.

Yes, exactly. Truly understanding what the client wants to achieve — and helping them understand their own processes — is more satisfying than you might think. And it’s genuinely fun to bring together people from different departments who normally stay in their organizational silos. Plus, I really enjoy hearing myself talk — and I get plenty of chances to do that.

This might be a surprising answer, but I rarely feel challenged in the sense of “I don’t know what to do.” What I struggle with most is bridging downtime. The job doesn’t require constant typing or drawing — it requires being available to answer questions at any time. That can mean having nothing to do between meetings, but also not being able to start something new because you need to stay available. Coming from a developer background, it’s easy to feel guilty for not being constantly busy. Learning to see that correctly and deal with it was actually the biggest challenge for me.

1. You need to be at least as good at listening as you are at talking — and that’s not always easy.
2. You have to be able to talk to people with completely different professional backgrounds — and NEVER fall into the trap of thinking they’re stupid.
3. You need to be able to think in processes and translate those into IT.

Technical skills are important, but they’re secondary and depend on the project. It’s much more important to understand workflows and document them well. If we want to make that more concrete: I think it’s more valuable for an architect to be able to diagram processes correctly in BPMN (Business Process Modeling Notation) than to have a cloud architecture certificate or a course in AI.

I’m a very particular kind of person: highly introverted, affected by ADHD, and generally considered a bit quirky. In other companies, all of that would be career killers, and I’d spend 90% of my energy pretending to be someone else. That’s not necessary at blu — the leadership actually worked with me to figure out how to use all these traits and keep me whole as a person. Could I earn more money elsewhere? Possibly. But two years later, I’d probably be burned out. I’d rather stay with people who value me as a person just as much — maybe even more — than as a resource.

I don’t really “unwind” after work. My job and the flexibility blu gives me throughout the day allow me to reduce stress as I go. A walk between meetings, a 3D print running during a call, the cat on my lap during a video conference on the terrace… These are all things that help me avoid stress in the first place. OK, some days are awful — that’s life — but that’s what video games and Netflix are for.