Thursday, July 27

The Onboardee’s Checklist

Y

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.


Your own checklist

The first thing you need is a plan. But how do you make a plan when you feel like you know nothing, and every company is different?

While that’s true, it’s not the whole story. You do have past experience to draw from. If this isn’t your first job, you’ve likely seen some recurring patterns. Use them.

If you're lacking knowledge, your first step is to identify what you need to learn and figure out how to begin. You don’t need to know everything at once—just the next step.

Think back to your previous experiences joining a new company, learning a new skill, or starting a new activity. Identify the common patterns and turn them into a personal checklist. Everyone’s list will look a bit different, but in case it helps, here’s mine:

My checklist

Some of these may seem obvious, but writing them down can calm your nerves and give you direction. It’s a way forward.

Remember: your weakness is that you know nothing, and your strength is also that you know nothing. You bring a fresh perspective.

Don’t be afraid to ask questions. If you struggle to phrase a question, note down what you’re unsure about. Then, once someone finishes explaining, ask for clarification on that area.


First steps

List the answers—or how you’ll get the answers—to the following questions somewhere handy.
  • Who can you go to for help?

  • What resources are available to you?

  • What can go wrong? What are the signs you need to escalate, and what are the first steps in responding?

  • What are the preferred communication channels?

  • Are there any pain points in existing processes? Sometimes teams are so used to workarounds that they avoid fixing broken systems.

  • Is there a skill or responsibility that’s being neglected? Teams often skip essential tasks when there’s a gap in ownership or expertise.


Onboarding and Tutorials

Document your onboarding experience—especially anything that’s missing or incorrect. The next person in your role will appreciate it.

Review existing tutorials step-by-step. Most people dislike writing tutorials, and few are trained to do it well. Unless there’s a dedicated team of technical writers, documentation may be poor or nonexistent. Even with technical writers, problems can arise if they aren’t closely working with subject matter experts.

These tutorials often include too many steps. That can be improved by streamlining the process and defining defaults for the most common cases. This is easier if you own the process, doable if no one owns it, and possible (with some lobbying) even if someone else owns it.

A common flaw is the curse of knowledge: tutorials are written from the expert’s point of view, focusing on implementation details or listing every feature, regardless of frequency of use. It’s better to write from the user’s perspective, focusing on the intent and organizing information by use case, not internal structure.


Communication 

Set up email filters. In some companies, you might receive dozens—or even hundreds—of emails a day, many of them automated. It’s easy to miss important messages in the noise.

Don’t accept meeting invitations blindly. Understand why you're in the meeting. Meetings are useful for coordination, but they’re also expensive. The more people and the longer the meeting, the greater the cost.

Frequent retrospectives are key to continuous improvement. The most valuable outcome of a retro is the action items. Track them.

Use the team’s preferred communication style and tools.


First suggestions

You might wait to make suggestions until you understand how things work. That’s normal. But don’t wait too long—you may lose momentum. The first 90 days often set the tone for your future at the company.

Ask yourself: Are there any obvious gaps or pain points?

Some of my biggest career wins came from tackling problems others were avoiding—areas where I had no experience. If the existing solution is missing or poor, your lack of expertise doesn’t matter much. The bar is low, and you’d be surprised how far you can get with a fresh perspective, persistence, and a willingness to learn.

It’s also easier to make changes when a task has no clear owner—you’re less likely to step on toes.

If a process is painful, people are usually open to change. Fixing it can greatly improve efficiency and effectiveness. Even small improvements in frustrating workflows can have a big impact.

Tuesday, January 24

Never Ask for Feedback You are Not Willing to Listen to

W

hen asking for feedback, make sure the person giving it feels heard. Show that you're making a genuine effort to address their concerns. If you can’t, then explain why honestly, humbly, and with regret.

Some people might dismiss this as being too “touchy-feely.” Don’t. If you get this wrong, things can go badly. Very badly.

One example of a feedback session gone horribly wrong still stands out in my memory.

At a previous company I worked for, we had an open-plan office with cubicles. My team and Team Marmalade shared the same space. Team Marmalade was a constant source of vicarious learning—I learned more from them than from any other team. (They may have appeared once or twice in other blog posts.)

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 could just forget it ever happened.

He began by saying the team’s process wasn’t working and they were falling short of their goals. He acknowledged that something had to change and asked the team for ideas on how to improve. So the team responded. They told him exactly what was wrong, how things could be fixed, and how they could dramatically boost productivity. They spoke at length and in great detail. But as each team member shared their thoughts, the manager became visibly more uncomfortable. Eventually, he interrupted:
“I can’t tell upper management any of this,” he said. “We’re just going to have to stick with what we were doing.”

Morale plummeted. Productivity plummeted.

A few weeks later, morale began to recover—thanks to the team leader, and not the manager. But some of the team leader’s methods for boosting morale were a bit questionable. He might have gotten away with it if productivity had improved significantly. Unfortunately, while things did get better, they never returned to even the low levels from before the “feedback incident.” And those low levels were exactly why the manager wanted change in the first place.

I felt conflicted. On one hand, I was impressed by how the team leader managed to lift spirits. On the other, it felt like Team Marmalade had given up on their project. They seemed less committed. Beneath the surface, there was a strong undercurrent of anger, frustration, and resentment. Nothing had been forgiven—or forgotten.

Then one day, while the manager was offsite and the team leader got especially creative with his morale-boosting activities, upper management stepped in. They loudly and publicly scolded Team Marmalade for being unprofessional.


Had all the managers forgotten we had meeting rooms?

Morale plummeted again. Productivity plummeted again.

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.

Monday, January 23

More Evidence Does Not Always Help, but Always Schedule Followup

M

y boss called me into his office. He asked me if I thought project Indigo could be completed on time. This was a strange thing to ask. My position on the feasibility of Indigo was well known, I'd had stated it clearly to my boss on more than one occasion. Indigo was due to start next business day. Was he having last minute doubts? or was he afraid I would make trouble either with his superiors or the new hires?

I had found myself in an Asch conformity experiment. I had estimated Indigo as taking 5 years for a team of 7 and both the other senior developer and the project manager estimated that it would take 9 months for a team of 5. Even the 5 year estimate was a product of the Anchoring effect, Yet, despite every skerrick of experience and expertise telling me that this was a multi-year long project, I was starting to doubt myself. Everyone else was supremely confident that it would only take 9 months.

Under the intense gaze of my boss I did something that I later regretted. I suggested a compromise. The project manager had a meticulous and detailed schedule laid out which stated the first module would be completed in a month. If we measured how much work was done during the first month we would have a good idea how long the whole project would take.

My first mistake was suggesting a compromise in the first place. The problem wasn't with there being enough evidence that I was right, after all this was a reboot of Indigo, it had already failed once. So there was plenty of evidence from the original project for how long it would take. The failure of the original project was why we had a project manager in the first place. He was there to rescue the project. 

One of the problems with Indigo was that the team was so focused on convincing higher management to green-light the project that they never stopped to consider whether they should do the project at all. Except maybe my boss was asking himself that question now. If so, I blew my best chance at killing the project. I guess I will never know whether being more assertive would have shifted my boss's position on Indigo. On the other hand, maybe he just wanted to know whether he could count on me to be a 'team player'. Sounds a bit paranoid, however the company was very internally competitive.  

My second mistake was not locking in a review meeting right there and then, with evaluation criteria. I probably didn't have the role authority or influence to swing something like that for project Indigo, but I could, and did, do something similar for later projects. It was an important lesson to learn. If you don't schedule it there and then, with  a firm date and time, and added to all the attendees' calendars it is not going to happen. Later I came across many projects that needed either an architectural spike or a technological spike, and post spike reviews are useful. In one case the review resulted in a major pivot and other cases ended up triggering minor adjustments.

With how the meeting with my boss played out, it was possibly not the best outcome, however because I hadn't completely caved, the other senior developer as well as the project manager were put in charge of Indigo while I was left in charge of project Teal, the project that Indigo was supposed to replace. Therefore it was also not the worst outcome; I could have been put in charge of Indigo. Teal was the ideal position. Close enough to the disaster to learn from it, but far enough away to escape the flames.

After a month I checked the work tracking application; the Indigo team had not completed any stories. I asked the project manager whether Indigo was still on track to be finished by the deadline. He said it was on track. I pointed out that the team hadn't finished anything. He told me they had partially completed many of the stories. I asked how he could say they were on target to meet the deadline when assessing progress on partially completed work was notoriously hard. He said that his years of experience and expertise as a project manager allowed him to know that they would make the deadline. I talked to my boss and brought up our previous discussion and pointed out that the project was not going well. He said is was early days and he had confidence in the project manager. 

After a year the Indigo still had not gotten QA to approve a single story. There were tasks the that had passed QA, but that was a whole other problem. Tasks are not suppose to be tested by themselves, they are suppose to be tested as part of the story they are a part of.

Indigo was experiencing the classic signs of having stories that were too big. 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, and that mistake was in how the estimation was done. 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.   

As a consequence the stories were like epics and the tasks where like stories. So I used the completed tasks to estimate progress. This was less than ideal, as the tasks were not comprehensive. There were lots of gaps. I came up with a pretty graph that showed that Indigo would be finished in eight years. Again I was making the mistake of thinking that I needed more evidence. More evidence wasn't going to help. 

I showed the graph to my boss. He said that they had learnt a lot from the first year, and they would do better this year. Also he did not think that it would take eight years. I asked how long he thought it would take. He didn't answer.

At this stage cancelling the project would cause too much embarrassment. I do not think that anyone involved actually ever intended to meet the deadline. They thought that it would slip its deadline by a few months and upper management wouldn't be too upset by a small delay. It ended up overrunning its deadline by more than a few months.

The second year the real scope was reduced as low priority functionality was jettisoned, while on paper the estimated scope expanded, as hidden functionality was discovered, new stories were added. Stories were split into small stories and management became alarmed by the aggressive scope creep. 

No more new stories, and no more story splitting, management ruled. This did not help. The stories became bigger and bigger with more and more tasks, their estimated size kept increasing. The scope creep continued.

The third year management decided that the team should split the stories into smaller chunks and re-estimate to the "real" values. The backlog was greatly improved, however the stories were still too big, they still had trouble getting stories through QA and the number of stories kept increasing.

The project manager was starting to panic, he was flying in from interstate every two weeks and the project seemed like it was never going to end. His reputation for bringing in projects on time was starting to suffer. He was complaining to anyone that would listen. Most of the initial team except for him were long gone.

I left for greener pastures. A few years later I met the final team leader of Indigo for coffee and he gave me the low down on what happened next.

After five years, a prototype was given to beta customers. The customers hated it and gave the team a long list of things that needed to be fixed.

After six years the project was cancelled and the developers where laid off.

I agree with my former boss. There was a lot to be learned from the trials and tribulations of project Indigo and the learning did not stop with the first year.


Saturday, January 21

Learning Plans for 2023

C

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 TheoryAbstract 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

Related Artefacts

Thursday, January 19

Learning Outcomes for 2022

F

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.