I Joined IBM With No Personal Operating System. So I Built One.
For students stepping into their first engineering role, this is the roadmap I wish I had on day one at IBM.
My first day at IBM was in 2005. I was a student intern, excited, prepared technically, and completely lost by the end of the day. Not lost in the code. Lost in everything around it. I joined full time shortly after graduating and the feeling did not go away. If anything it got sharper.
This is the post I wish had existed before I walked through those doors.
Where this came from
Before IBM I had done internships at smaller organizations in New Brunswick, a government office and a few small IT companies. Good experiences. But nothing that prepared me for what IBM actually was. A few friends had interned there before me but nobody told me what it was like on the inside. The only thing I thought I needed to prepare was my technical skills.
I was wrong.
Day one I was lost. Not after a few weeks of settling in. Day one. The scale of it, the complexity of it, the sheer number of things I did not understand hit me immediately. The people, the team dynamics, the processes, the unspoken expectations. Smart, experienced professionals all around me who seemed to know exactly how everything worked. I did not know how to navigate any of it. I did not know what was expected of me beyond the technical work. I did not know how to read the room, how to ask the right questions, or how to exist in that environment without feeling like I did not belong there.
The technology was never the problem. I could handle that.
What I couldn’t handle was everything else.
I struggled to communicate, really communicate. Listening in meetings without tuning out. Writing clearly under pressure. Speaking with any confidence in a room full of people who seemed to know exactly where they stood. Reading the room. Navigating across personalities. Knowing when to push and when to wait.
I didn’t know how to exist in that environment. I didn’t believe I belonged there.
I didn’t know the path forward. I just knew I was lost.
Three people changed that.
My supervisor Tahsin Rouf, my first IBM manager Kent Klaas, and my second manager Ed Van Gennip. Their support in my early years at IBM was not incidental. It was foundational. The trajectory I have been able to build over the past 20 years, everything I have learned, taught, and contributed, sits on the base they helped me build. Tahsin saw something in me at exactly the right moment and offered guidance when I had no idea how to ask for it. Kent supported me consistently and introduced me to mind mapping, a thinking tool I still use today for planning and problem solving. Ed believed in me deeply and gave me the kind of continuous feedback, support, and direction that most early-career people never get. I want to name them here because people like this rarely get named. They should.
And I joined Toastmasters.
That decision opened something I did not expect. Not just better communication. A deep curiosity about the foundational skills nobody had ever taught me. How to learn better. How to think more critically. How to listen deeply, and build the kind of discipline that actually compounds over a career. I started taking IBM’s internal courses. I started building personal frameworks. I started testing things on myself.
Then came the moment that pulled everything together.
About a year or two into my time at IBM, I volunteered to run Think Friday. A weekly internal knowledge-sharing session for our team. I wanted to do it well, not just show up and lead it. So before I ran my first session I read a book called “Not Another Meeting” by Frances A. Micale. That book gave me something specific: a method. How to prepare with a clear outcome in mind, how to structure the discussion, how to manage debate productively, how to take notes that were actually useful, and how to close with clear action items organized by topic and next step.
I ran Think Friday that way for two to three years.
Looking back, those sessions taught me more than I realized at the time. How to bring a group of people toward a common objective. How to hold a productive discussion without letting it drift. How to capture what actually matters and make it useful afterward. How to lead a room, not just occupy it.
That weekly meeting was a turning point. Not because it was high-stakes. Because it was consistent. I got the repetitions. And the confidence that came from those repetitions was real in a way that no single course or credential ever produced.
What was missing
Looking back, I was technically prepared and foundationally underprepared. Both things were true at the same time.
The technical skills got me hired. They kept me moving in the first few weeks. But the moment I needed to work across a team, recommend a clear solution, listen in a meeting without missing half of what was actually being said, or simply believe I had a right to be in the room, the technical skills went quiet. They had nothing to say.
Nobody had ever taught me those things. Not in school. Not in any course. Not in any internship prep session I had ever sat through.
I had to figure them out the hard way, mostly alone, mostly by making mistakes I did not understand until much later. The difference was that I eventually found people who believed in me, and I found a way to practice. Most students never find either.
The framework, step by step
After two decades of learning this myself and then teaching it to students, I have found the foundational skills fall into a small number of areas that show up again and again. These are not soft skills in the vague, resume-filler sense. They are specific and learnable.
Communication that actually works in a corporate environment. Not presentation polish. The ability to write a clear email, summarize a meeting, give feedback without creating defensiveness, and ask a question without sounding lost. This also includes thinking tools. Kent Klaas showed me mind mapping early in my career as a way to organize thinking before writing or speaking. It changed how I approach any problem that feels too big to tackle in a straight line. These skills are different from anything you practiced in school and they matter from day one.
Learning how to learn on the job. School gives you structured problems with known answers. Work gives you ambiguous problems with moving targets. Building a personal system for learning new things fast, the way I built one by reading a single practical book before running my first meeting, is a skill in itself.
Navigating the environment, not just the work. Understanding how decisions get made. Reading team dynamics. Knowing when to speak up and when to listen. This is not political in the negative sense. It is situational awareness, and it determines whether your technical work ever lands.
Believing you belong there. This one sounds soft. It is not. Self-doubt is not a feeling to push through. It is a pattern that shapes every decision you make, who you ask for help, whether you volunteer for harder problems, how you handle feedback. The students who address it directly move faster than the ones who try to outwork it.
Building discipline that compounds. The habits you build in your first year set the baseline for everything that follows. Not productivity hacks. The small consistent things: how you prepare for meetings, how you follow up, how you manage your own energy, how you stay curious when the work gets repetitive. Running Think Friday every week for two to three years was not glamorous. It was the repetition that built the skill.
The two assets most students skip
Following this kind of framework produces two things that matter more than any project portfolio.
The first is self-awareness about where you actually are. Not where you think you are, not where you hope you are. A clear read on what is working and what is not, grounded in real situations from your actual job.
The second is a personal operating system. A small set of principles and habits you have tested on yourself and trust. Not borrowed from a book. Yours. Mine started with a practical meeting guide and a weekly Friday session. It grew from there.
Why this works
Corporate environments, and AI teams in particular, move fast and reward people who can operate with ambiguity, communicate clearly under pressure, and keep building without waiting to be told what to do next.
The students I have seen thrive earliest are not always the most technically brilliant. They are the ones who understood early that the job was bigger than the code. They put time into the foundational skills deliberately, not because someone told them to, but because they could see the gap and decided to close it.
That gap is real. It is common. And unlike a lot of things in your career, it is entirely within your control to work on.
After 20 years at IBM, mentoring and helping more than 100 students across undergrad, masters, and PhD programs, I still see the same gap show up in the same way. Not because students are underprepared. Because nobody told them it existed.
That is exactly why I am sharing this with you now.