The jump to the big corp

Learnings from a young designer


Young designers often start their career working as freelancers, some join a cool start-up, while others take a step into a different direction and join the consultancy and agency world. Working as the solo designer on small teams, or perhaps with a few others, teaches many valuable lessons, including the following:

  1. Focus on details
  2. Build close designer-dev relationships
  3. Learning to code will help you get ahead

The moment I joined a big corporation, I had to learn to work in a completely different way. So far my career has spanned a large consultancy to an even larger tech giant. I would like to share some of the learnings with you.

A few years ago I left Munich, where I worked at a large consultancy, and decided to join Skype and the Microsoft family in London. I arrived thinking “I will meet all these super interesting people that have years of experience, people that are at the top of their game. After all, Skype is the most popular communication platform on the planet, so I must be at the top of my game too since I am working with them.” And yet, there was so much about design process I could learn. I was eager to match my design skills against the other designers at MSFT.

My first project at Skype — design conversation bubbles and align to the Skype branding. “Piece of cake! I can get this done in, say 5 or 10 minutes? Right, let’s make it a couple hours since I’ll have to do some research and toss in a few variations I guess?” Almost a week later, I still hadn’t manage to get a sign off for my project. It’s not because it wasn’t beautifully executed, but because I had overseen one of the most crucial parts of working in big teams:

Get others involved in your project

You’re smart, we get it, that’s why you’re here. But in a company that’s divided by teams where each person works on a different component, making changes should be seamless, easy, and fast. Everybody in the design team should understand the need for that change, and the project should be a simple, collaborative effort. However, that’s not often the case. Some teams might want those changes but others, might not see them as a priority. More so, is this change truly helpful? How does it exactly adapt across different sizes and viewports? You’ve been working on this, it’s your project, so of course you know the nuances. But each designer, developer, PM, manager, all have their own agendas, and it isn’t always evident which problem you’re trying to solve.

Which leads me to another important lesson:

Always provide the context of what you’re explaining

You need to do this, even to your peers, including the ones that have been working on the same project before you. It’s impossible to always remember every single detail of the bigger picture. As designers, we often see many problems in our UI. Thus, we need to set the context, focus on the specific situation, so that we get the right feedback in return. Talking to other designers, asking for feedback (and actually incorporating the feedback), is what makes us practical and what makes our solution collaborative. Learning this provides you with a different sense of ownership.


Your work is like wheat. It will be consumed by other people. Other designers will make different types of bread out of it, and developers and PMs may modify it to fit the users’ needs, whether for cooking, baking, manufacturing, eating... And ultimately, consumers may make sandwiches, toasts, cakes, or even find new uses out of your product.


In a big structure of nested teams, you develop a new sense of ownership. You can no longer claim: “I designed this app,” or even “I designed the call experience” because there are many moving parts. Countless people contribute to various parts of the UI, which all influence each other. Your buttons are blue, round and 40px big because someone else previously defined those parameters. Perhaps you made the first draft of that icon, but it has been polished by someone else, whose work is to make the best, most consistent icons. Knowing that should provide comfort and clarity: you’ve put the pieces together to make it work.

We all move towards the same goal and even if your current design doesn’t ship, it will inform other designers in other teams in the future. To be honest, this is a part I’ve struggled with, but it helps to know that you are also picking up and improving others’ work. Focusing on the final product, what the users will see in the end, is critical, and makes you realize it’s less about you, and the work you’ve done, and more about the team, the organization, and the company.

Which, gets me to my next point around other people’s designs:

You have to know and respect your peers’ work

Now, this one sounds obvious, of course we all respect what people in the team do. But, secretly, you might think that you can improve something, or make it more efficient. Sometimes you pick up other people’s projects, and even in your own projects, you have to consider what’s been done before and why. This flow was designed a certain way for a reason, and now it’s your turn to check if those reasons are still applicable. Is there any part that I could improve? Is that change truly positive to users? Or is it just to be flashy and feed your own ego?

It might seem like your voice gets lost when you work for larger teams, but you have to trust in your capacity to inspire others, to lead when you should lead, and also to follow when others are leading the way. You’ll learn that you’re not cooler because you jumped on the long-shadow wagon earlier than anyone else, that the guy who writes copy will often have better insights than yourself, and that presentation skills and empathy are often more valuable than coding with the latest version of framer.

Suddenly, delivering something brilliant becomes less about the prettiness of your own designs, and more on how well you co-design, co-build, and collaborate with your team.