Structuring my work day using notes

Meeting notes in Loop, meeting transcriptions (and summaries), physical notes, digital notebooks—the list goes on. These are all tools that provide a more or less personal knowledge base.

When I first started working in a professional environment, I was pretty unstructured. There are some nice German IT phrases like “Turnschuh-IT (Running-shoe IT)” or “Helfersyndrom (helper syndrome)” that perfectly describe how I lived from ticket to ticket, tackled the occasional top-down task that needed to be solved immediately, and tried to please and help everyone as quickly as possible.

This often left me wondering at the end of the workweek: What did I actually accomplish this week? Did I make any progress on projects or bigger-picture tasks?

Nowadays, even with much less everyday business to handle, I force myself to take lots of notes. As a big fan of Copilot and Loop (or similar interconnected GenAI/notebook tools), I hope to eventually have a personalized AI assistant that:

  • Knows my working habits.
  • Has enough information to avoid hallucinating too much.
  • Provides feedback.
  • Offers ideas on how to structure my day.
  • Gives recaps of my workweek.

I currently have categories in my notebook like:

  • Tech
  • Team stuff
  • Everyday business
  • Architecture

I try to keep the important topics up to date. Oftentimes, this means copying 80% of an AI meeting recap into my notebook to make the information permanent (Retention Policies ❤️).

One issue I face with my hybrid approach (personal notes + AI assistants) is the limitation of available connectors to AI solutions. Documentation, collaboration boards, and meetings are rarely on the same platform, after all.

So, does my investment in note-taking and organization actually help?

On a personal level: YES. It feels great to have a good recap.
On a professional level: Also YES. My colleagues often ask how I manage to keep up with so much information being provided every day (at the architecture and on a technical depth level).

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.

Erster Arbeitsag

„Was macht einen erfolgreichen ersten Arbeitstag bei einem neuen Arbeitgeber aus?“

Seinen ersten Arbeitstag bei einem neuen Arbeitgeber zu haben, ist immer spannend. Nachdem ich in der Vergangenheit mehrere Personen eingearbeitet habe und diese Erfahrung natürlich auch selbst schon gemacht habe, habe ich mich gefragt: „Was macht einen erfolgreichen ersten Arbeitstag bei einem neuen Arbeitgeber aus?“

Der offensichtlichste Punkt wäre: die Kollegen kennenlernen. Zügig ein Netzwerk aufzubauen, ist wichtig. Zum Start wird es wahrscheinlich hauptsächlich das eigene Team sein, aber es ist hilfreich, die Kollegen und Stakeholder kennenzulernen, mit denen man am häufigsten zusammenarbeiten wird. Dies hilft, kleine Aufgaben (das Tagesgeschäft, kleine Gefälligkeiten) schneller zu erledigen. Jeder Engineer oder Admin, der in einem großen Unternehmen arbeitet, kennt wahrscheinlich den Schmerz langer Prozesse wie Ticket-Erstellung oder die Notwendigkeit, mit Product Ownern/Head Ofs zu sprechen, um Aufgaben zu erledigen, die in fünf Minuten hätten gelöst werden können.
Ich habe noch nie in einem Start-up gearbeitet. Vielleicht ist es dort anders?

Ein weiterer wichtiger Punkt für mich wäre, einen Überblick über die eingesetzte Software zu bekommen, die wir als Team verwalten und nutzen, insbesondere mit Lesezugriff. Der IT-Solution-Architect in mir möchte verstehen, warum bestimmte Entscheidungen für die Software getroffen wurden und wie sie von einander abhängt. Das hilft auch mögliche Downtime zu Beginn zu reduzieren.

Eng verknüpft mit dem vorherigen Punkt ist für mich auch eine funktionierende Identität mit den notwendigen Berechtigungen wichtig. Ich habe erlebt, wie Kollegen das interne Beschaffungssystem oder den Zugriff auf das Microsoft Admin Center nicht nutzen konnten, weil sie kein Admin-Konto mit ausreichenden Berechtigungen hatten – selbst Monate nach ihrem Start. Das ist nicht nur eine frustrierende Erfahrung sondern auch eine enorme Zeitverschwendung, nicht nur für den neuen Mitarbeiter, sondern auch für mehrere Personen im Unternehmen.

Das gesagt: Ich freue mich darauf, meine neuen Kollegen kennenzulernen und freue mich in mehr Technologie einzutauchen und Herausforderungen zu lösen!

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 😊