Starting out in engineering can be both thrilling and a bit daunting. How to distinguish one tech hype from the next? What to do with those tricky career decisions that will inevitably come your way? Fear not, we’re here to help! We sat down with Andreas Stryz, Chief Technology Officer (CTO) and co-founder of FINN, who has extensive experience as an engineer and in technical leadership. He shares his thoughts on the power of giving autonomy, the impact of no-code tools, and focusing on the tech you love. So grab a cuppa and let's dive into some key insights from a seasoned tech leader.

Hi Andi 👋 and thank you for talking with me today. To start things off, could you say something about what your current role as Chief Technology Officer (CTO) at FINN involves?

Sure! I don't have a typical day. Very often I will be working on a range of completely different topics. About 60% of my job is one-on-one meetings. This includes talking with people, listening to their challenges and successes, and occasionally giving guidance on the decisions they face. Next, 10-20% of the job involves participating in meetings, such as our Senior Leadership meetings, where we talk about big, strategic decisions regarding the future of the company. And the rest is basically random stuff. It can be recording a podcast, giving a conference talk, things like that.

What is the same, though, is that each of my days has to be highly structured. Because I can be chaos in my private life. Totally unstructured. At the same time I can have a very high discipline, for example in sports. So to bring that structure, I now use my calendar for everything. Not just for meetings, but also to place blockers to work on specific topics. My calendar is my boss -- if it's in my calendar, I will do it.

Are you mainly involved in tech strategy, or also in some nitty-gritty engineering decisions?

Today I am purely involved in tech strategy. I actively try to avoid getting into any nitty-gritty technical decisions. Because I’ve been an engineer for a long time, and with the high level that I'm operating on right now, there's a good risk that any of my statements on detailed engineering decisions would do more damage than good. People might cling to something I mentioned and say: ‘Hey, but Andi told us to …’ Even though I never, ever told anyone to do anything. That's why it's really important for me in my current role not to get involved in detailed technical decisions within the company.

In the early phases of FINN, the situation was completely different of course. Then I was the entire engineering team. But at the current size of FINN, with over 400 employees, it is important to me to avoid getting involved in any technical decision. Which is hard, because I am (was) a really good tech guy 😀

For me, a CTO is someone who makes the life of the whole company better, easier, simpler, faster, by technology.

I do not miss being involved in these detailed technical decisions at all though. I have worked as an engineer myself for a long time. That extensive experience is a great foundation for technical leadership, because it means that I can easily identify bullshit. If someone is bullshiting me on a technical level, I can spot that very, very fast.

What do you like best about your current position?

What I like best is actually not based on my position itself. It's because of the company. I love to work with young, fresh-minded, and fast-thinking people. I need this environment to feel alive, like a flower. Without such a stimulating environment, I would just feel sad and perish and die and that's it. So for me it’s really the high-energy company environment that powers me up.

Was there a key moment that helped you get where you are now?

There were two moments from which I learned the most in my previous job. One was when, on a Friday morning, I was told I had to fire multiple people on the same day because of a financial situation. At that time, I was not on the level where I knew about any of this in advance. I just had to execute. Moreover, it wasn't even my decision whom to fire. It was simply everyone who was still in their probation period. It had nothing to do with skill -- it was just bad timing. That hurt me a lot.

Number two was when my team got almost doubled within a single week. Initially, I was working with around 40 engineers. A few days before, there was the announcement that I would now also get to lead additional teams. There had been two separate development teams, which then got consolidated into one. Which meant that all of a sudden I was the manager not for 40, but almost 80 people -- 40 additional people, some of them I had never met before in my life, or even heard their names. That took me a good one and a half years, really to get the full buy-in to the way I manage people. Those two experiences were very important for my career, because I learned a lot.

What would you say has been the biggest change within the field of engineering since you started out?

From a technical perspective it’s always the same thing. Always, always the same, I can guarantee you. I started coding in 1996. This was QuickBASIC. Since then, it’s always been the same principles. What you do is you apply those well-known principles to different entities -- different code, different data. Of course there are a lot of great technologies over the years that I have worked with that are new. But take for example Kubernetes: it's not a milestone. It's orchestration. You can orchestrate code, you can orchestrate environments, you can orchestrate everything. So from a broad technical perspective it’s always the same.

the impact of no-code breaks through this little engineering bubble. With no-code tools, it's now convenient enough to equip non-tech people and give them another tool to be more productive.

The one really major change that for me had this wow!-impact is the whole no-code movement. This is because the impact of no-code breaks through this little engineering bubble. With no-code tools, it's now convenient enough to equip non-tech people and give them another tool to be more productive. To me, no-code is similar to when Excel was introduced to the whole business environment, and the impact that had.

Because with no-code, it’s not about the tech people. At FINN, approximately 20% of the workforce are engineers, while 80% are non-engineers. If, as a CTO, you would just focus on the engineering part, you're only focusing on the 20%. Why not on the 80%? Everyone is talking about the 80:20 rule, and so everyone just ignores the 80%. Wtf? For me, a CTO is not someone who's focusing on engineering exclusively. A CTO is someone who makes the life of the whole company better, easier, simpler, faster, by technology.

Why is it important to you that people feel more productive?

The problem is always: How do you measure productivity? For instance, some people would say that mobile phones changed our world. Yes, but they haven't increased productivity -- that rather decreased, I would say. Of course I do think that with today’s tools, people are also very much more productive. There's definitely an impact on that. But ultimately, the question is: when you leave your workspace or finish your work for the day, do you feel like you did something essential? That's what it’s all about for me.

What is your approach for keeping up to date with new technologies or developments in the field?

I recently discovered a podcast, called Doppelgänger (it’s in German), which is among my favourite podcasts. It's nice, digestible, and you can listen to it while running. But overall my best way to stay up to date with what is happening right now is doing interviews. Reading CVs, and interviewing people. As simple as that. All the core technologies that we use here at FINN -- Node.js or Typescript, Python, Go, or also Serverless -- I have never used in my professional career so far. Of course, I have some basic experience with Python, but I have never worked with it professionally. Yet from reading people’s CVs, and then talking about it in interviews, I get to understand what is currently the hottest shit out there.

How do you cut through the hype?

To be clear: I'm not trying to stop or avoid any hype. I try to understand if it's legit or not. Whether it is something worth investing energy into. And the way I do that is also through interviews. In an interview I might ask: Why are we doing that? For instance: Why should we use React? Then you go into discussion, and if the discussion makes sense and the arguments are strong, then: Hey, do it. So this process allows me to see: Is it just a hype or not? But overall, for the wider company, I want to give autonomy to the teams so that they can try things out.

But let's also step back and think about: Why is this whole engineering sphere so sensitive to hypes? Why?? They’re more sensitive to hypes than TikTok. (I know that’s a populist statement 😂) As I see it, in the last decades, engineers got loaded with simple, annoying requests. Always the same bloody tasks. So, what do you do, as a human? As a creative, purpose-driven person? You execute, but at least you try to use different tools to solve the same problem, just to have something new and interesting to add. That's why engineers are so easily affected by these technical hypes.

Ultimately, the question is: when you leave your workspace or finish your work for the day, do you feel like you did something essential? That's what it’s all about for me.

For me this also comes back to the no-code movement we talked about earlier. If you equip business people with the tools to implement automations in a simple way, then you can reduce the number of annoying ticket requests for the engineering teams. That will ensure that engineers can generate more value with the well-known tools they already have, without having to jump on the next hype train to keep things interesting. Because just the problems -- the new, attractive, complicated problems -- will give enough brain food not to have to dive into the next hype.

What advice would you have for someone who's starting out in engineering right now?

Just the sheer number of different technologies out there … If I had to start out afresh today, I would be overwhelmed. So, to someone starting out in engineering today I would say: Pick the technologies and tools that make things most fun for you. Try to find what that is for you, and then focus on that. When I started, it was PHP, Python, or C. Or maybe some other niche programming language. It was simpler back then. So I'm not jealous of the young people starting out right now.

My advice in terms of career development would be: only go into the people management part of things if you're actually curious about people. Don’t do it if you think people management is something you somehow need to do to get more money -- which, by the way, is not true. Because to go into tech leadership, you should be curious about people. If you have that, then you can take the people management path. But if that’s not you, then really try to become an expert in your chosen area and to hyper-focus on that.