The Onboardee’s Checklist

ou’re starting a new job at a new company. You don’t know their internal processes or culture yet, and your role may be different from what you’ve done before.

You do have some information from the interview, but the reality of a job often doesn’t match the job description. Even if the interviewer previously held your position, day-to-day tasks are often glossed over in favor of more memorable, less frequent events.

Build Your Own Checklist

When you feel like you know nothing, it’s hard to make a plan. Every company is different, right? True—but you do have past experience to draw on.

If you’ve ever joined a new team, learned a new skill, or started a new activity, you’ve seen patterns emerge. Those patterns can form the basis of your personal onboarding checklist.

Here’s my checklist to get you started:

• Know your go-to people – Who can help you when you’re stuck?
• Map your resources – What tools, documents, and systems do you have access to?
• Spot the risks early – What can go wrong? How will you know, and what’s your first response?
• Understand communication norms – Email, chat, meetings—what’s preferred?
• Notice process pain points – What’s broken, and what’s been patched over for too long?
• Identify neglected work – Is there an unowned responsibility quietly gathering dust?

Remember: your weakness is that you know nothing—and your strength is also that you know nothing. A fresh perspective can spot issues veterans overlook.

It is common to feel overwhelmed. If you’re unsure how to ask a question, jot down your confusion. Then, once someone’s explained, revisit that spot and ask for clarity.

Make the Most of Onboarding

Document your onboarding experience—especially what’s missing or wrong. It will help the next person in your role and may highlight gaps for your team.

When reviewing tutorials or documentation:

• Follow them step-by-step.

• Note unclear instructions, unnecessary detail, or missing steps.

• Suggest simplifying overly long guides by focusing on defaults for common cases.

Many tutorials suffer from the curse of knowledge—written from an expert’s view, crammed with every feature, and organized by internal logic rather than user needs.
Whenever possible, reframe them for the intended user: explain the intent, group by use case, and keep it simple.

Communicate Effectively 

Tame your inbox – Set up filters to keep critical messages visible amid the noise.

Be intentional with meetings – Know why you’re invited before accepting. Saying "No" is a skill. Long meetings with many people are costly; make them count.

Keep retrospectives actionable – The value is in the follow-up. Track action items and ensure they happen.

Adapt to the team’s style – Use their tools and tone, even if it’s different from what you’re used to.

Make Early, Smart Suggestions

It’s natural to wait before making suggestions, but don’t wait too long—momentum matters. The first 90 days set the tone for your role.

Look for:

• Obvious gaps – Missing processes, outdated tools, unassigned work.

• Avoided problems – Pain points that no one wants to own.

• Low-bar opportunities – When a solution is bad or nonexistent, you don’t need deep expertise to make an impact.

Some of my biggest wins came from tackling tasks outside my skill set—because no one else wanted to touch them. If you approach them with curiosity, persistence, and a willingness to learn, you can quickly add value.

Even small fixes to frustrating workflows can dramatically improve team morale and productivity.

Final Thought

Your first weeks aren’t just about learning the ropes—they’re a unique chance to see with fresh eyes. Notice what’s confusing, inefficient, or broken before you become used to it.

By combining curiosity with action, you can contribute meaningfully while still finding your feet.

Related Posts

• Imposter Syndrome (Part 1): Reasons and Causes
• Imposter Syndrome (Part 2): Pros and Cons
• Team Building Exercises
• Making Work Actually Flow

More Information

Books

The Checklist Manifesto: How to Get Things Right

by Atul Gawande

Shows how simple checklists can dramatically improve consistency, onboarding, and problem-solving.

Video Reviews  1 &  2

The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer

Excellent for decoding communication and decision-making styles, especially if you work in international or cross-functional teams.
 

Crucial Conversations: Tools for Talking When Stakes are High  by Kerry Patterson, Stephen R. Covey,  Joseph Grenny,  Ron McMillan,  Al Switzler

Practical techniques for staying calm, respectful, and effective during emotionally charged feedback moments.

Never Ask for Feedback You are Not Willing to Listen to

hen you ask for feedback, you’re not just gathering opinions—you’re making a implicit promise to listen and think about the feedback . The person giving it needs to feel heard. That doesn’t mean you have to do exactly what they say, but you do have to respond with honesty, humility, and genuine respect. If you can’t act on it, explain why—openly and without defensiveness.

Some people dismiss this as “touchy-feely.” Don’t. If you get it wrong, the fallout can be ugly.

The Day Feedback Went Spectacularly Wrong

At a previous company, I sat in an open-plan office where my team shared space with another group I’ll call Team Marmalade, the where working on Project Indigo. They were a constant source of vicarious learning—and sometimes cautionary tales.

Most managers, when they need to discuss sensitive topics, book a private meeting room. It’s quieter, more focused, and free from an audience. For reasons only he knew, Team Marmalade’s manager decided to skip the boardroom and hold an important meeting right in the middle of the cubicles. I heard everything. So did the entire office. And by the end, I suspect he wished no one had.I suspect he wished no one had.

Most managers when talking to their team about important and Most managers, when discussing important or sensitive topics with their teams, book a boardroom. These rooms are quiet, private, and free of interruptions. For reasons only he knew, Team Marmalade’s manager decided to hold an important meeting right in the middle of the cubicles. I heard everything. The entire office heard everything. And unfortunately, so did his team. Normally, it’s a good thing when a team hears their manager. But by the end of this particular meeting, the manager likely wished everyone would just forget it had ever happened.

The meeting began reasonably enough. The manager explained that the team’s process wasn’t working, results were slipping, and change was needed. He then invited the team to share ideas.

They did—enthusiastically. They identified problems, proposed fixes, and mapped out ways to boost productivity. The suggestions were clear, practical, and—if implemented—would have solved much of what he’d raised.

But with each idea, the manager’s expression grew more and more alarmed. Eventually, he cut them off:

“I can’t tell upper management any of this. We’ll just have to stick with what we were doing.”

 

The Downward Spiral

Morale dropped like a stone. Productivity followed.

A few weeks later, the team leader (not the manager) managed to lift spirits through… let’s say creative morale-boosting tactics. They might have worked if results had soared. They didn’t. The team’s output improved slightly but never reached even the low levels from before the “feedback incident.”

Worse, the team’s attitude shifted. On the surface, they seemed fine. Underneath, they were frustrated, angry, and disengaged. Nothing had really been forgiven—or forgotten.

Then one day, while the manager was offsite and the team leader’s “creative” tactics were in full swing, upper management walked in. The scolding was loud, public, and humiliating.

And still—had all the managers forgotten meeting rooms existed?

Morale collapsed again. So did productivity. This time, recovery took months. 

And this time, it took a long time for Team Marmalade to recover.

This isn’t the only time I’ve seen a request for feedback go wrong—but it was definitely the worst.

If you don’t treat feedback with respect, those giving it can become cynical, resentful, and disengaged. By the time you’re ready to take action, your team or community may no longer care to listen.

The Lesson

I’ve seen feedback requests go wrong before, but this one was catastrophic.

If you ask for input but then ignore, dismiss, or shut it down, you teach people that speaking up is pointless. Cynicism sets in. Engagement erodes. And when you are finally ready to make changes, it may be too late—because the people you need have stopped caring.

Related Posts

• Have the Courage to Speak
• Lessons from Project Indigo: A Slow-Motion Train Wreck
• Giving Feedback (Part 1) - Why Getting Feedback Right Matters More Than You Think
• Giving Feedback (Part 2) - Feedback on People Skills
• Giving Feedback (Part 3) - Taking Your Time

Lessons from Project Indigo: A Slow-Motion Train Wreck

y boss called me into his office and asked if I thought Project Indigo could be completed on time.

Strange question. My opinion on Indigo’s feasibility was no secret — I’d told him more than once. Indigo was due to start the next business day. Was he having last-minute doubts? Or wondering if I’d make trouble with his superiors or the new hires?

It felt like being dropped into an Asch conformity experiment. I had estimated Indigo would take five years with a team of seven. The other senior developer and the project manager? Nine months with a team of five.

Even my five-year figure was generous, thanks to the anchoring effect. Every shred of my experience told me it was a multi-year slog, yet surrounded by confident people quoting nine months, I began to doubt myself.

Mistake #1 – The Compromise Trap

Under my boss’s gaze, I suggested a “compromise”: the PM’s detailed schedule said the first module would be done in a month. If we measured progress after that month, we’d know how long the whole thing would take.

That was my first mistake. The problem wasn’t a lack of evidence — Indigo was a reboot of a project that had already failed once. We knew exactly how long it would take.

If my boss was looking for a reason to kill the project, I’d just blown my best chance. Or maybe he only wanted to know if I’d be a “team player.” In a company as internally competitive as ours, that wasn’t paranoia — just experience talking.

Mistake #2 – Not Locking in a Review

I also failed to set a firm, calendar-booked review meeting with clear evaluation criteria. If it’s not scheduled then and there, it won’t happen.

Later, I learned to make post-spike reviews non-negotiable. They led to pivots in some projects and smaller, life-saving adjustments in others.

Still, my partial resistance paid off: the PM and other senior dev ran Indigo, while I stayed on Project Teal — the project Indigo was supposed to replace. Perfect spot: close enough to watch the train wreck, far enough to avoid the flames. 

Month One – Nothing Done

After a month, I checked the tracker: zero completed stories. The PM insisted they were on track because they’d “partially completed many stories.”

I pointed out that partially completed work is impossible to measure reliably. He said his “years of experience” told him they’d make the deadline.

I told my boss it wasn’t going well. He said it was “early days” and he trusted the PM. 

Year One – Still Nothing Through QA

A year in, not a single story had passed QA. Some tasks had passed QA, but tasks aren’t supposed to be tested alone — they’re part of stories. 

Indigo’s stories were massive. In fact, stories were functioning like epics, and tasks were functioning like stories. The estimates? Pre-determined before anyone started.

Using completed tasks (gappy though they were), I built a chart showing Indigo would take eight years. My boss dismissed it: “We’ve learned a lot, we’ll do better this year.” When I asked how long he thought it would take, he didn’t answer.

By this point, canceling the project would have been too embarrassing. I don’t think anyone expected to meet the deadline. They wanted the project approved and assumed “few months” of overrun would be fine. It turned into years.

Year Two – Scope Games

Real scope dropped (low-priority features cut), but on paper scope increased as hidden work surfaced. New stories were added.

Management panicked: No more new stories. No more splitting stories.
This, of course, made stories even bigger and harder to push through QA.

Year Three – Reality Check (Sort of)

Management reversed course: Split stories, re-estimate to real values. The backlog improved, but stories were still too big. QA remained a bottleneck, and the backlog kept growing.

The PM was now flying in from interstate every two weeks, reputation on the line, venting to anyone who’d listen. The original team, except him, was gone.

The Endgame

I left for greener pastures.

Years later, over coffee, the final Indigo team lead told me the ending:

• Year 5: A prototype was shown to beta customers. They hated it.

• Year 6: Project Indigo was canceled. The dev team was laid off.

My former boss had been right — there was a lot to learn from Indigo. Unfortunately, the lessons didn’t stop after Year One.

Final Thoughts

Most of Indigo's problems I have seen to a lesser extent in other projects. However the words "lesser extent" are doing a whole lot of work in the previous sentence. 

There was one difference that was a difference of kind rather than a difference of scale, one mistake that doomed Indigo from the very start. A mistake that caused many of the other problems.

Mistake #0 – Letting Politics Determine Estimates

There were other projects were I was pressured to reduce my estimates, as if re-estimating would change the real completion time. There was only one project that I have ever been on where I was given the estimate I was supposed to come up with before hand.   

Related Posts

• Have the Courage to Speak
• Never Ask for Feedback You are Not Willing to Listen To
• Making Work Actually... Flow

More Information

Article

• The Anchoring Effect
• Story Splitting Guide

Videos

• Asch Conformity experiment

Learning Plans for 2023

urrent Focus Topics

Focus	People	Tasks
Abstract	Communication, Coaching &             Leadership	Category Theory, Abstract Algebra &  Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	Swift

Changes for 2023

I am currently spreading myself to thin between to many study topics. For the upcoming year I intend to slowly finish up many of the topics and narrow my focus.

Category Theory

I feel that am pretty much done with Category Theory, Abstract Algebra  &  Lambda Calculus. I will experiment  more with practical applications of the theory, and some of the functional swift libraries then close the topic off in March with some final revision. I have been building up an Anki flash card deck which I will share. I won't replace this topic with another. I will leave that quadrant blank for now.

Leadership

I worked my way though a large chunk the courses and books I had earmarked for these topics and I am also applying that knowledge. I am going to finish Communication & Leadership in June and Coaching in October.  I intend to study creative writing in 2024. 

Wellbeing 

I am going continue on with this. The only changes I am making from last year is to alternate my exercise routines and restart my music practise.

Swift

There is still a lot I want to do in this area, so this one will be keeping me busy.

Related Posts

• Learning Outcomes for 2022
  
• Learning Outcomes for 2021
  
• Learning Plans for 2021
• Goal Setting
  
• Learning by Doing
  
• Select the Right Skills to Improve

Related Artefacts

• Learning Area Matrix 
• Learning Action Matrix
• Category Theory Tracking Board
• Lambda Calculus Tracking Board
• WOOP Matrix 

Learning Outcomes for 2022

ocus Topics for 2021

Focus	People	Tasks
Abstract	Learn to Learn	Category Theory & Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	JavaScript & Knockout

Changes for 2022

In the second half of 2021, I changed jobs. As a result, JavaScript became less relevant, and Swift took its place as the main language in my new role. I also felt that I had internalized the principles of "Learning to Learn" well enough to move on. I replaced it with a new focus on leadership and communication.

Wellbeing remained a priority—I carried it forward into 2022. My progress in category theory during 2021 was limited, so I decided to continue that journey.

New Focus Topics for 2022

Focus	People	Tasks
Abstract	Communication, Coaching &             Leadership	Category Theory, Abstract Algebra &  Lambda Calculus
Concrete	Reducing Stress & Refocusing the Mind	Swift

Category Theory

In 2022, I leaned heavily into category theory—perhaps too heavily. I often found myself caught in a web of unfamiliar mathematical concepts. Still, I managed to lift my understanding from a shaky beginner level to a more solid intermediate grasp.

Along the way, I was repeatedly told that category theory becomes easier with a foundation in abstract algebra, so I added that to my learning path. Most of the examples I encountered were written in Haskell, so I started exploring that as well.

Translating theory into practice proved difficult. Swift incorporates many category-theoretic ideas—optionals, sequences, throwing contexts, and concurrent contexts are all monads in disguise—but it doesn’t present them in a unified way. Without the theoretical background, the common structure is easy to miss.

Moreover, Swift lacks support for higher-kinded types, which makes it hard to generalize over these abstractions. While libraries like Bow attempt to bridge this gap and simulate higher-kinded types, I didn’t explore them deeply. That may be something for 2023. 

Leadership

Despite category theory dominating my attention, I did make progress here too. I even found opportunities to apply what I learned at work.

In truth, many of these leadership activities were natural extensions of things I’d already been doing—or things I had started back in 2021 under my “Learning to Learn” focus. Still, I felt a shift in intent: I was deliberately developing leadership skills, rather than just picking them up incidentally.

Wellbeing 

For the most part, I maintained the wellbeing routines I had developed in 2021. However, stress and insomnia began creeping back in. I suspect this was due to letting my music practice lapse.

While exercise and mindfulness helped, they weren’t quite enough. Playing an instrument has always been my most effective way to decompress, and reset. Without it, my stress levels noticeably increased.

Swift

Swift remains a fast-moving target. Each year, Apple updates Swift itself along with Xcode, iOS, macOS, watchOS, and tvOS—not to mention a growing ecosystem of libraries and APIs.

While I learned a lot in 2022, I still feel like I’m only scratching the surface. I’m even still working through videos from the previous WWDC. It’s a marathon, not a sprint.

Conclusion

All up I was less effective in converting my learning into day to day behaviour change in 2022 than I was in 2021. But I still made some good progress.

Related Posts

• Learning Outcomes for 2021
  
• Learning Plans for 2021
• Goal Setting
  
• Learning by Doing
  
• Select the Right Skills to Improve