Electrical engineering with real-world impact

For both Sigurd and Eirik, electrical engineering is not just about calculations on a screen. It is about understanding what happens when something fails, what keeps a system stable, and what has to work when the stakes are high. 

Meet Sigurd and Eirik 

Sigurd Terland Danielsen came into Kongsberg Maritime through the industrial master’s route. After taking a bachelor’s in electrical engineering in Kongsberg with a cybernetics direction, he chose Systems Engineering because he wanted something broader – with more product development, project work and a different way of thinking about engineering. He also points to the atmosphere in the interview as an important reason why Kongsberg Maritime felt like the right place. 

Sigurd Terland Danielsen, Systems Engineer

Eirik André Borvik was Sigurd’s mentor when he started with us. Eirik, joined Kongsberg Maritime in 2018 after studying Advanced Electrical Power Engineering in Scotland. He started out working with electrical studies and analysis tools such as ETAP (Electrical Transient Analyzer Program). Over time, programming and tool development also became a bigger part of his working life. He also enjoys helping new colleagues in the role as a mentor, “I like the teaching people things, and help to get them up to the level where they feel a bit more comfortable with what they’re doing,”.   

Eirik André Borvik, Specialist Engineer

Sigurd still remembers his first impression of the work. He was placed next to two people working with the same kind of studies – one of them was Eirik – and his reaction was immediate: “I understood nothing.” In fact, he remembers thinking: “This is definitely not something I want to work with.” 

But he tried it anyway. And somewhere along the way, that confusion turned into enthusiasm. What had looked “completely terrible” at first became exactly the kind of work he wanted to keep doing. 

Complex questions, practical consequences 

At its core, electrical engineering is about understanding how systems behave and making sure designs meet technical requirements before something goes wrong in practice. 

One part of the work is protection and coordination studies. The technical language can be advanced, but the basic logic is straightforward: if something fails, the right protection needs to respond in the right place. Sigurd explains it with a comparison that is easy to picture. If something goes wrong in a socket at home, you want the fuse for that circuit to trip-not the main fuse for the whole house. On a vessel, the same principle applies, but the systems are far larger and more complex, and the consequences are more critical. That is why the details matter so much. 

Another part of the role involves studying what happens dynamically when the system is disturbed. That can include transient studies, short-circuit calculations, redundancy assessments and other analyses that test whether a vessel remains stable when faults occur. As Sigurd puts it, “this is particularly critical for vessels with Dynamic Positioning (DP) notations, where any loss of position-keeping can have serious safety and cost implications.” These are not abstract questions. They are exactly the kinds of scenarios the studies are meant to answer before a problem happens in practice.  

Much of that work ends up in reports and technical documentation. For them, though, documentation is not just paperwork. It is part of proving that a design meets requirements and making the technical reasoning visible to others. But the role also becomes broader over time. Sigurd describes how the job now includes not only studies and reports, but also technical input, troubleshooting, simulations of real events and discussions about possible solutions. 

For Eirik, the role has gradually also come to include programming and tool development. He talks about using code to solve problems, automating repetitive tasks and making tools that others in the team can use as well. 

One of the moments Eirik lights up when talking is when a simulation matched exactly what happens in the real system. In one project, he had modelled how a short circuit fault current would flow through solid state breakers. Later, when it was tested physically, the results matched almost one to one. That was a real high point - not only because it was exciting to see the simulation play out so accurately in practice, but because it verified the quality of the modelling he had done. “Then it no longer feels like something happening only on the PC – it proves that what you are working on reflects something real,” he says. The model has since become essential for simulating fault behaviour in other systems and is now a key part of design verification.

Eirik`s curiosity has also pulled further into programming. He talks almost with disbelief about discovering Julia, a language he describes as doing the same kind of maths as MATLAB, just much faster. He calls it “black magic” and says he thinks about it all the time – reads about it, trains on it and keeps testing how it can be used in his work. 

That is also part of what makes the work appealing. The deeper they get into it, the more there is to understand – whether that is how a system responds under disturbance, how different disciplines affect each other, or how a tool can make the work smarter. 

One of the clearest themes for both Eirik and Sigurd is that this is not a field where people are expected to understand everything from the start. Eirik says it very directly: in the beginning, you survive by asking questions. That openness seems to be an important part of how people learn the work. 

That shared curiosity comes up in both conversations. Eirik talks about how valuable it is to sit with others and discuss technical questions together. Sigurd points to the same thing in a different way: in a big environment like this, there is almost always someone who has seen something similar before – and you can call them. 

That also shows up in the way they talk about ownership. Standardisation comes up repeatedly-not as a buzzword, but as something practical. Together with colleagues, they are improving templates, methods and ways of working so the output becomes easier to trust, reuse and build on. 

They also return to the importance of freedom and trust. Sigurd highlights the trust he is given and the feeling that his role keeps growing if he is willing to take on more. Eirik, in his own way, describes something similar: the chance to follow technical curiosity, try ideas out and sometimes turn them into tools that others actually use. 

Maybe that is also what makes this kind of electrical engineering exciting: the work is demanding, but never static. There is always something new to understand, test, improve or question – and for the people who enjoy that, it is hard not to get hooked.