All Posts By

Jakob Offersen

Early Career Insights from an Ørsted Manager

Sune Grønskov has worked in every part of the value chain within power grids and offshore at Ørsted. He has been an Operations Specialist, Project Manager (PM), Team Leader, Senior Specialist, and is currently working as a Manager. Evolving from a new engineer to someone who employs and manages new engineers has given Sune insights into what works well when you start.

In this post, we’ll learn why Sune thinks you should become a specialist instead of a generalist. He will explain how you become a specialist early on in your career, and why saying ‘yes’ to everything is the right strategy in your first job.

From his story, we’ll see how specializing creates a great foundation for achieving a well-rounded career consisting of both specialist- and leader roles.

Career advice is always subjective and these choices are at their core personal preferences. However, there is still tremendous value to be found in mimicking and learning from interesting people with interesting careers – especially those whose story you can see yourself in.

Conflux Insights is a new series of articles where we learn key insights and findings from interesting Conflux mentors from the Danish STEM industries and share them with you.

Sune’s Career History

In 2006, Sune was about to graduate with a MSc degree in Electrical Engineering from DTU. He had a vague idea regarding where to work post-graduation, “but to be honest, I had no greater plan figured out. I just wanted to get a job and then the rest would be figured out from there.”

From a conversation he had with one of his professors, he ended up applying for a job at a Danish energy company, which later merged to become Ørsted.

As an Operations Specialist, Sune worked with the Danish power grid. The responsibilities were partly in maintenance but also in strategy. “I worked with strategic planning of the power grid so that it would be ready for what would come 10, 20, and 30 years down the line”. It turned out to be a great introduction job to the energy industry, as the maintenance tasks learned him about how the power-grid-world works in reality. And the strategic and analytical tasks leveraged the analytical and theoretical foundation he had built at DTU.

After 6 years as a specialist, Sune knew his domain in and out, and it was time for him to pursue new opportunities, which he found internally at Ørsted. “I had the impression that I had great growth-opportunities professionally in line-management, as I felt I could take full advantage of my skill set in that role. So I made a career plan: First, I had to become a PM, as that role would expose me to many leadership tasks. And then I would transition into line-management”.

Before officially transitioning into becoming a PM, Sune tried out the role, by saying ‘yes’ to several ‘PM-like’ tasks. He mimicked his future role. This is a great idea to dig deeper into; Yes, Sune had a plan to turn himself into a PM. But he probably didn’t know the daily challenges for that role. So by acting like he already had the role he wanted to pursue, he achieved two things:

  • First, he improved his role-specific skills and allowed himself a playground where it was more allowed to make the typical early missteps.
  • Second, he tested out, whether the job is the right fit for him personally. Transitioning into a new role is often a big decision, so it makes sense to perform smaller tests to figure out if this is the right transition to make – and to act like you have the role before you get the role is a great way of doing this!

As a PM, Sune’s main responsibility for the project was to define a common goal and set up and manage the process to achieve that goal. He had to lead the process for buying the right components and managing the contractors as well as his team.

Say ‘Yes’ to Everything Early On

During his career, Sune has employed and managed multiple new engineers, and he knows what works when it comes to starting your career in a great way:

You typically want to show your worth, when you start as a newly graduated engineer – both to your new employer but also to yourself. You say yes to every opportunity and every task you can get your hands on. And this is great! This is how you learn and grow, and its a natural part of starting. But this phase typically lasts about a year before you have too much on your plate. There are two important learnings to make from this: First, you need to reach out to your manager before you burn out. And second, you must align with your manager on how to prioritize your tasks so that you can also learn how to say “no”.”

Being eager and hungry early on is a great way to find your place and figure out what you think is interesting to work with. But it is important to not be too impatient when it comes to moving on to your next project. “You should be open to the tasks that come your way – even the not-so-fun tasks. When you build up your expertise in an area, people will start to come to you for your help, and this will greatly improve your reach and growth opportunities. And this is often an easier ladder to climb when you embrace what others don’t focus on.” Sune points out. And being the expert to go to for some expert knowledge is great – especially inside a large company like Ørsted. It will introduce you to other interesting people and projects, which very well will turn into interesting opportunities for you down the line. And it all starts with building the right specialist-foundation early on.

“The Generalist-term Doesn’t Sit Right With Me”

From the outside, it looks like Sune has transitioned from being a specialist engineer to more generalist roles where he had to manage projects and people. But we don’t think this is the right way of looking at it: “I don’t really believe in the generalist-engineering role, to be honest. It doesn’t sit right with me, because there will always be something that you are specialized in. To me, a generalist is a person who knows and insights into a broad range of domains. But their specialty is typically to quickly and reliably analyze a complex cross-domain-problem and assess the right decision for a project.”

This view on the specialist/generalist spectrum is typically referred to as T-shaped skills. Here the idea is to know a little in a lot of areas – enough to navigate them and know what you don’t know, while also having a single expertise domain where you go deep and specialize.

So where should you start building your own “T-shape”? Is it best to focus on the depth or the width of the ‘T’ first?

According to Sune, you should always seek to specialize in the domain you are currently in and then grow from there. Focus on depth-first and leverage your expertise to grow wider with time.

Embracing the technical challenges ahead of you is typically a strategy that engineers find pleasing, as it aligns well with our desire to understand and solve problems. But Sune has seen countless times, engineers typically end up exhausting the domain and turn towards other challenges: “I think the wish to go wider comes naturally for many engineers. When you have specialized in a niche domain for some years, you may feel like your opportunities have been exhausted. So to meet challenges again, you will turn towards other domains and expand your horizon. And remember, this will be possible to do from the specialist-foundation you have built”. This view aligns well with Daniel Eggert’s experience working as a specialist Software Engineer at Apple. Both Sune and Daniel recommend to use your technical background to specialize early on, and then leverage that specialist role to grow into other roles. And they both experience, that your specialist skills will benefit you in your new roles, whether it be in management or specialist role.

Becoming a Specialist

Next; how do you follow Sune’s advice to become a specialist? Of course, a lot of the specifics are domain-dependent; to become a great medical engineer you need to do the work in that domain. But you don’t need to figure e everything out on your own. Seek out mentors from within the company, preferably someone who is just 2-3 steps ahead of you. They clearly remember the struggles you are currently facing, but also how to overcome them.

However, some advice is applicable regardless of the direction you are heading. Two examples:

  • It is always a great idea to understand the fundamentals and first principles of your domain. Understanding the technical foundation will greatly improve your rate of learning new and complex topics.
  • It takes deliberate practice and deep work to become a specialist. Personally, learning about these topics has greatly improved my way of working. To get a taste of it, I recommend you go start here and here.

Wrapping Up

On a final note, Sune wants to share a few insights for you to consider in your first engineering role.

  • Don’t focus on the work conditions (benefits, salary, the quality of the canteen, etc.) as these things are quite equal and great across companies – especially the large ones.
  • Instead, choose your first role based on what field and domain you find interesting. And this is something you should try to figure out during your studies. The important thing is to learn how to learn and to find out what fields appeal to you and try to specialize in that. Choose your courses so that you try out many areas of your degree.
  • Say ‘yes’ to every chance heading your way early on. Specialize in your current domain, and use your expertise to expand into other roles if you wish to.
  • Don’t plan your career too much. As an engineer, you most likely enjoy working towards and achieving a goal. But in Sune’s experience, it makes you blind to enjoying the actual journey – and it may also make you blind to great opportunities that suddenly appear. So don’t follow a career plan just for the sake of achieving it.

This is the second of several articles from Conflux Insights. Our goal is to learn from real career histories, extract key findings from them, and share them with you. We would love to hear your thoughts on the article, as we are still trying to find the right fit for us.

If you have any comments or questions about the article or Conflux Insights in general, please reach out at

Thanks to Sune Grønskov for sharing his experiences and career history with us.

This interview was performed and written by Jakob from Conflux.

Apple Software Architect: Specialize at Large Companies Before Building a Start Up

Daniel Eggert has become an expert within software development since he graduated from Technical University of Denmark (DTU) in 2003. His expertise led him to Apple in California early on before he moved to Berlin to work at various startups. He is now back at Apple where he works on Apple Maps, Apple Health, and Apple Mail.

In this post, we’ll learn why Daniel believes you should become a specialist instead of a generalist. He will explain why working at several large companies is a great starting point for later starting your own company or joining a start-up and what he thinks is the most important thing when choosing your first real job after university.

There’s a lot to be learned here – especially if you are a student heading towards the software development world!

Career advice is always subjective and these choices are at their core personal preferences. However, there is still tremendous value to be found in mimicking and learning from interesting people with interesting careers – especially those whose story you can see yourself in.

Conflux Insights is a new series of articles where we learn key insights and findings from interesting Conflux mentors from the Danish STEM industries and share them with you.

Daniels Career History

Daniel graduated from DTU in 2003 with a degree in electrical engineering. However, back then the job opportunities in his field were quite sparse, so Daniel chose to instead find a job based on his side-hobby; Mac-development. Back then Mac-development was a new and niche thing and there were only a few jobs to be found in Denmark in this domain. On the contrary, only a few people were working on the Mac platform, meaning the competition for these jobs was lower. He found a job at Phase One, where he worked on image processing on the Mac platform. “By combing Mac development with image processing, I became one of probably only 10 people in the world with this domain knowledge.” he says. This later put him on the radar at Apple who needed his expertise for the development of their upcoming products; the iPhone and the Macs.

At the time, Daniel didn’t per se have a deliberate desire to work abroad, but it was a great opportunity to come and work with some of the best engineers in the world. And when an opportunity like this comes to you, you take it.

Working at Apple was a huge shift for what Daniel had previously tried at other large companies. “I worked in a 2-person team to build various graphical libraries for the Mac platform and later iOS. My teammate and I had a lot of control over our work, and we probably used 90-100% of our time to develop our solutions. No long meetings or general bureaucracy.”

In 2011, after 5 years at Apple, Daniel moved to Berlin to join the rising start-up scene. During a handful of years, he worked at several different startups before re-joining Apple again in 2016 where he is still working to this day.

Become a specialist, not a generalist

Many software students struggle with the question of whether to become a specialist or a generalist. But we have to remember that this is not a binary choice, but a spectrum. However, it does still make sense to actively choose in which direction of the spectrum you want to go. From Daniel’s story, we see that he (more or less deliberately) chose early on to become a specialist in a niche domain. And this choice has benefitted him a lot since then.

When asked, if he ever was concerned that macOS development could turn into a dead-end, he answered: “No, I didn’t think about it like that at the time. A lot of what I learned as part of my specialization in software could also be re-used in other software fields. Of course, I would have to learn something new if I were to focus on another technology but I would still expect the overlap to be quite large. I don’t think you should be afraid to work in a very specialized field, as long as you are prepared to keep on learning. If your expertise domain ceases to be relevant, several companies will still find you interesting because you have proved that you can become an expert in a field.”

To me, this is a very interesting take on the topic. As Daniel points out, many software specializations often consist of skills that you can take with you in your next phase. In Daniels’s experience, a lot of what seems to be a niche in a closed domain might overlap a lot with future working areas.

Specializing is also about standing out of the crowd. “As a generalist in software development you quickly end up competing against a quite large market of developers as you then compete both against other engineers and those who are self-taught” he says.

Not only does Daniel believe focusing on a specific niche is a good choice, he also warns about being too much of a generalist: “I believe it could be dangerous for a newly graduated software engineer to not try to specialize in anything as they would never get to the bottom of any technical problem. Of course, at the end of the day, it is a personal choice. But to me, it means a lot to really understand a domain and a problem to its core – and it’s also satisfying to work with specialized colleagues who are the best of the best at their craft – for example to work with a database engineer who’s been working in their field for over 30 years.”

I think the last point Daniel makes here is especially interesting. Solving technical problems is to many a craft, meaning that you are an engineering-craftsman. Not only is it satisfying to solve technical problems for the sake of solving them, it is also rewarding to do so together with really competent people. Of course, this argument relies heavily on personal preference. But if you, like Daniel, find value in the process of solving a technical problem, then heading towards the specialization-part of the spectrum may be the right idea.

Work at Multiple Large Companies Before Building Your Own.

To many, it is important to figure out, whether their early career should take place at a large enterprise or a smaller one. It is interesting to hear Daniels take on this, as he has been through the entire spectrum – from working at the world’s most valuable company to several small start-ups. In his experience, it is quite difficult to know beforehand what is best suited for you. And work-life at large companies also vary a lot. For example, even when working together with thousands of engineers on the Mac platform, the decision-making process was still very agile and decentralized. What he had experienced at other large companies had been way more bureaucratic. This makes it important to be prepared and urge job-hopping – especially early on. “At my first job, I simply accepted every process ‘as-is’. I had nothing to compare my experiences to and thus thought that the company’s approaches were the best ones. When I came to Apple, I found out that this was not the case.” he says.

However, because of their size, large companies face fundamentally different problems than startups. “If you and I were to make a start-up, bug reporting could simply be done as a simple list. But when you are thousands of engineers who have to collaborate, a process needs to be in place for everything”. To see how these problems are solved on a large scale is immensely valuable if you are to later join a startup. Especially as the startup grows and you have to face the same scaling-challenges as the larger companies. This is why Daniel believes it is better to have tried to work at multiple large companies before starting your own. It will put you in a position where you can recognize when a process needs to be put in place – and which process is preferable.

Daniels also points out that working at a large company is often more suited for the specialist role. Bigger companies have the capabilities to allow you to dive deep into a narrower topic, and large tech-companies often face more state-of-the-art technical problems. Contrary, at a start-up, you have to wear multiple hats and iterate faster. And many startups don’t fail because of technical reasons but instead because of a poor market-fit.

In both cases, however, it is extremely important for you as a software engineering to focus on team collaboration and the softer parts of the development. “At DTU you learn how to take the right technical decision, but you don’t learn how to take other factors into account. For example, if you need to solve a threading-problem, you have learned how to analyze the problem and find the right technical solution. But you have not learned how to take the team aspects into account. Often it is better for the product to pick a worse technical solution, that more people understand and maintain than to pick the best technical solution, that only a single person knows how to work with. These aspects are really difficult to learn from a course. In my experience, you only learn them in the workplace – and only from people at a workplace who also understand these trade-offs”.

Wrapping Up & Actionable Tips

We’ve now heard Daniels’s story working as a specialist software developer at Apple and various startups. If his story resonates with you, here are some tips from Daniel for you to consider during your studies as well as in your early career:

  • At DTU you are used to dealing with heavy and theoretical computer science problems. This gives you a great foundation to work with – but be aware that you may tend to over-complicate stuff in the real world. It’s just as important to know how to solve the smaller ‘every-day-problems’ in a great way.
  • Learn things at DTU that you cannot learn as easily by yourself. It is important to look into these heavier domains at university and get a broad understanding of the many aspects of software, even though you probably won’t end up using much of it in your every-day career. If you don’t learn it now, you probably never will. For example, iOS development is very tangible to learn by yourself, whereas threading is much more difficult.
  • Be prepared to work at multiple companies early on to find out which company culture works best for you. This will increase your chances of finding “your spot” and it will also give you a broader understanding of how (human as well as technical) problems are solved.
  • Don’t be afraid to specialize early on if you want to specialize. You will find enjoyment from understanding a domain deeply and you will stand out from the crowd – and much of what you learn will be transferable to other domains later on.
  • When choosing your first job, the most important thing to look at is the team you will be joining. Look for a team that you will enjoy working with. A diverse team is even better because it will allow you to learn more about what you still need to learn, and how to collaborate with people that are different than yourself.

This is the first of several articles from Conflux Insights. Our goal is to learn from real career histories, extract key findings from them, and share them with you. We would love to hear your thoughts on the article, as we are still trying to find the right fit for us.

If you have any comments or questions about the article or Conflux Insights in general, please reach out at

Thanks to Daniel Eggert for sharing his experiences and career history with us.

This interview was performed and written by Jakob from Conflux.