Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×

Meet the…software architect

Vizrt's Marcus Bergner explains how a computer programming hobby led him into the broadcast industry, and why a software architect needs to be ready to answer any question

Marcus Bergner, M.Sc CSE, software architect, Vizrt
Talk us through an average day in your role

As a software architect my workdays can vary quite a lot because I engage with lots of different people and as such, I find myself in many different situations. Primarily I have a supporting role in our R&D organisation where I work with several R&D teams, some on a more day-to-day basis and some on a more weekly/bi-weekly basis. I support these teams with technical expertise, business knowledge, help guide the overall design of the product but also assist with smaller things. 

Smaller things could be to help diagnose a difficult problem, bridge occasional knowledge gaps between different teams to streamline our work, but also review and write code or documentation. I still write a fair bit of code, I enjoy doing that, but I tend to have to do it in shorter bursts nowadays since I have a lot of other things requiring my attention.

I also work closely with the product owner and product manager, but also with other external stakeholders as needed. I bring an extensive combination of technical and business knowledge into many discussions, which could be roadmap planning, overall prioritisation decision-making, or other matters. I occasionally also do more research-oriented or exploratory work, which can mean evaluating or exploring a piece of technology or a potential path to take as part of a larger piece of work.

The technical knowledge I have means, on almost a daily basis, that I also answer questions or help people elsewhere in our organisation. This could be people working on projects with customers or people from our support organisation. In most cases this involves helping them help themselves by giving guidance on how they can or should proceed, what to specifically look for or test to be able to move forward. In some rare cases I might get more deeply involved in such cases.

How did you get started in the media industry?

It was more a coincidence than anything else. I graduated from university and started looking for work at some companies I thought seemed interesting. One of them happened to be a company building products for the media industry and I ended up joining them. Initially, I worked on specific projects, and I was travelling to customers frequently. I think those early years and seeing media companies/broadcasters from the inside and working with them, mixed with my already quite extensive software development, set me up quite well for succeeding in this industry.

What training did you have before entering the industry?

I had a master’s degree in computer science and engineering and had been programming for five years or so as a hobby before entering university. So, in that area I was pretty good even as a fresh university graduate. I didn’t really know anything specific about the media industry, but thankfully a lot of technical knowledge transfers quite well between different industries.

Why do you enjoy working in the industry?

I can’t say I expected to work this long in this industry, 19 years and counting, but I think what has kept me interested is that things have continued to evolve and there have always been new challenges on the horizon that felt relevant.

What piece of advice would you offer someone looking to explore a role similar to yours?

Besides having a strong technical knowledge foundation, I think an aspiring software architect should want to work closely with teams and help them succeed. Their success is your success, their failure is at least in part your failure. Build trust and be a good technical leader, but also listen to people around you, whether that is engineers, managers, or customers. 

I think how you succeed in such a role can vary and will depend a bit on the circumstances of your organisation. In some cases, you might need to write and document more, in some cases your presence in discussions is more important. Find what works for you and the teams you work with. Try to strengthen the knowledge in the teams so that teams can be more autonomous and so that you and your teams can succeed with only higher-level guidance, and this is also how you can scale better to support several teams.