Startup vs corporate

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

By August 24, 2020 November 9th, 2020 One Comment

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.




Jakob Offersen

Jakob Offersen

Jakob is the main driver behind Conflux Insights. He interviews cool Conflux Mentors and distills their career stories and gold nuggets into online content for other students to learn from.

One Comment

Leave a Reply