Reflecting on my first work day at a new employer

This is a follow-up article to https://passt.blog/2025/04/01/first-work-day/

What went well, what could be optimized?

+ Hardware and periphery ready within the first work day
+ Onboarding meeting(s)
+ Hopefully my note-taking to remember the people and their responsibilities in their team that I met today
+ Read-permissions to access documentation
+ Solid documentation for onboarding

ToDos:
– some permissions still pending (accessing Scrum Board, some applications, …)
– a few follow-up tickets to set up VDI, admin permissions and more needed


Summary of my first workday:

Overall, it went well. Thankfully, I have experienced colleagues in my team who made most of the onboarding process pretty smooth.

From my experience with all the employers I’ve worked with so far, I’ve noticed that there’s no such thing as a perfectly smooth onboarding experience—and I don’t think it’s easy to achieve one. Many teams would need to collaborate on a single process: the new employee’s team, an identity team, workplace support, HR, facility management (and probably several more).

Roles and permissions differ for every team and sometimes for individual employees, after all.

First Work Day

“What would be a good first work day experience at a new employer?”

Starting to work for a new employer is always exciting. After onboarding several people in the past and having that experience by myself I began to think about:
“What would be a good first work day experience?”

The most self explanatory point would be: Getting to know your colleagues.
Building your network is crucial. At first it will probably be mostly your team but getting to know your colleagues and stakeholder you will work most often with is helpful, if you want to get small stuff (daily business tasks, small favors) done quick.
Every engineer/admin working in a big company probably knows the pain of lenghty processes like ticket creation or having to speak to head ofs for a task that gets done in 5 minutes by working together.
I have never worked in a startup before. Maybe it’s different there?

Another important thing for me would be to get an overview of the software we manage and use as a team and especially get read-only permissions. The IT solution architect in me wants to understand why certain decisions for software were made and how they are connected. It will also help reduce your downtime that will happen in the beginning.

On a related note: a functioning identity with all necessary permissions is a must. I’ve seen colleagues unable to use internal purchasing systems or access platforms like the Microsoft Admin Center because they lacked admin accounts with sufficient permissions—even months after starting. This can be a massive time sink and a frustrating experience, not just for the new employee but for others in the company as well.

That being said I am excited to meet my new colleagues and dive into more tech and challenges 😊