The Onboardee’s Checklist

ou’re starting a new job and you know nothing. It is a new company, with their own internal processes and culture. Plus your role may be different, from what you were doing before.

You have the information you obtained in the interview, however the realities of a position do not often match the theory of a job description. Even if the interviewer filled your role in the past, the day to day activities tend to be glossed over in favour of less frequent but more memorable events.

Your own checklist

So the first thing you need is a plan. But how do you make a plan when you know nothing, every company is different. While that is true, it is not the whole truth. You have previous experience that can be used here. You would have noticed reoccurring patterns, especially if this is not your first job. 

If you lack knowledge the first step is identifying the needed knowledge and the initial steps in obtaining it. Remember you do not need to know everything all at once, you just need to know the next step.

Take your previous experiences as a new hire or learning a new activity or joining a new organisation and distill the commonalities down to a checklist. It is better to create your own, but on the off chance that it has something of value I will share my own.

My checklist

The following may seem obvious, but listing it out can help calm yourself and give you confidence. You have a way forward.

Remember your weakness is that you know nothing and your strength is that you know nothing. You can look at things with a fresh perspective.

Don’t be afraid to ask questions. If you have problems framing a question, note down an area where you are uncertain and after they have finished their explanation, ask for elaboration.

First steps

List the answers and / or the first steps in obtaining the answers to the below questions somewhere prominent.

• What do you need to know?
• Who can you go to for help?
• What are the resources you can call on?
• What can go wrong? What are the triggers for escalation and what are the first steps in response.
• What are the preferred communication channels?
• Is there any awkwardness or pain points in the processes? The existing team may be so used to working around problems that they put off changing the existing process.
• Is there a missing skill or responsibility that is not being covered by the existing team? Teams have a tendency to avoid essential tasks if there is a skills gap or a responsibility gap.

Onboarding and Tutorials

Document your onboarding experience, especially missing or incorrect information. Your successors will thank you.

• Evaluate step by step tutorials. Most people hate creating tutorials and are not trained in writing them so unless there is a dedicated team of technical writers they are often bad or completely missing. Even when a company employs technical writers, those writers need to communicate and coordinate with the relevant subject matter experts and this can be a failure point.
• There is almost always too many steps in these tutorials. This can be fixed by streamlining processes and creating defaults for the most common use cases. This is usually easy if your new role owns the process, a little harder but doable if no one owns it and if someone else owns it then some lobbying may be needed.
• A common failing in these tutorials is due to the curse of knowledge. Many tutorials explain from the point of view of the creator, emphasising implementation details and listing every possible function of the system. 
• It is better to explain things from the users point of view, emphasising the intent of the system and breaking things down by common use cases rather than by internal structure.

Communication 

• Create filters for your email that sort email into folders. In some companies, you will have 10s or 100s of emails a day, many of them automated notifications. It is easy to lose the signal for the noise.
• Don’t blindly accept meeting invitations. Know why you are in the meeting. Meetings are necessary for coordination, but they are costly. The more people in the meeting and the longer they run the more expensive they are.
• Frequent retrospectives are key to continuous improvement and the most important product of retros are the action items. Track the action items.
• Communicate using the teams preferred method.

First suggestions

You probably won’t volunteer suggestions until you have a feel for the lay of the land. However don’t wait too long as you can lose momentum.

Are their any gaps or pain points?

• Gaps
• Some of my greatest career successes have been from tackling problems that the other team members were avoiding, despite the fact that I had no previous experience with those problems. If the existing solution is either missing or extremely bad, then it matters less that you know nothing, the bar is low and it is amazing how far you can go with a little persistence, a fresh outlook and a willingness to learn. It is also easier to make changes if it is no ones responsibility as you are not stepping on anyones toes.
• Pain points
• If the existing process is painful then you will face less resistance to change and more impact on efficiency and effectiveness if you manage to streamline it.

Never Ask for Feedback You are Not Willing to Listen to

hen asking for feedback, make sure than the feedback giver feels listened too. Make sure that you make a good faith attempt to address their concerns. If you cannot then humbly and regretfully explain why you cannot comply.

Some people will be tempted to dismiss this as too touchy feely. Don't. If you get this wrong, things can get bad. Really bad.

One example of an attempt to gain feedback gone horribly wrong stands out in my memory.

A previous company I worked in had an open plan office, full of cubicles with my team and team Marmalade sharing the same area.  Marmalade was an endless source of vicarious learning. I have learned more from them than any other team. They may have appeared once or twice in other blog posts.

Most managers when talking to their team about important and sensitive information, book one of the boardrooms to hold a meeting. They are quiet, private and usually free of interruptions. Team Marmalade's manager for reasons known only to him decided to hold an important meeting in the work area in the middle of the cubicles. I heard everything. The entire office heard everything and most unfortunately his team heard everything. The team hearing their manager is usually desired, however by the end of this particular meeting, the manager would end up wishing that everyone would forget that the meeting ever happened.

The manager started off by explaining that the teams process was not working. They were not achieving their goals. He said he understood that they had to change. He asked them for ideas on how the team could improve. So his team told him. They told him exactly what was wrong with how they did things. How they could fix things and how they could dramatically increase their productivity. They talked at length and in great detail and as each team member talked the manager became more and more uncomfortable. Finally he interrupted them. "I can't tell upper management any of this!" he said, "We are just going to have to stick with what we were doing."

Morale plummeted. Productivity plummeted. 

Then a few weeks later morale bounced back, thanks to the efforts of the team leader and no thanks to the manager. However some of the methods Marmalade's team leader used to restore morale were a little bit dubious. He might have gotten away with that if the team had been more productive. However while productivity had increased it was not back to pre-"feedback incident" levels and pre-"feedback incident" productivity levels were low to begin with. That was why the manager was talking about change in the first place. 

I felt conflicted. On one hand I was really impressed with how the Team Lead had turned around the team, on the other hand team Marmalade seamed to have reduced their commitment to their project. They seamed to have given up and there was an undercurrent of anger, frustration, and resentment simmering under the surface. Nothing had been forgiven or forgotten.

One day while the manager was offsite and the team leader got particularly inventive with his morale building activities, upper management stepped in to stop the fun. They loudly and very publicly told off team Marmalade for being unprofessional. Had all the managers in this company forgotten that we had meeting rooms?

Morale plummeted again. Productivity plummeted again.

This time it took a long time for team Marmalade to recover.

This is not the only time I have seen soliciting feedback backfire but it was definitely the worst.

If you are not respectful of the feedback you are given, the feedback givers can become cynical, resentful and apathetic. By the time you get serious about making changes your community may no longer be interested in listening to what you have to say. 

More Evidence Does Not Always Help, but Always Schedule Followup

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, 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.

How the meeting with my boss played out, 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. 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.

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

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

I changed jobs in the second half of 2021. My Javascript skills were less of a priority as my new role was focused on Swift. I felt as though I had mastered Learning to Learn, therefor I swapped it out for leadership and communication.

My wellness routines where an ongoing concern, so I kept that focus. I hadn't made much progress in category theory in 2021, so I rolled it over to 2022.

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 contrast to the previous year, I ended up over-investing in category theory in 2022. I was constantly running into a web of mathematical concepts that I was less than familiar with. I did manage to uplift my understanding from a vague shaky beginner level to a more solid intermediate grasp of the material. There were lots of diversions along the way. The consensus was that category theory was easier if you knew abstract algebra so I added it to the list.  Most of the programming examples that were used to illustrate category theory were in Haskell so that went on the list too.

I had a bit of trouble translating the theory into practise. I am mostly using Swift at the moment and while Swift uses lots of category theory's concepts, they tend to be obscured .e.g. although, concurrent contexts, throwing contexts, sequences and, optionals are all monads, in Swift they are each treated as their own separate thing, and you would only notice the similarities, if you already knew the theory. If a programmer wanted to tie those concepts together, e.g. using a Monad class they couldn't, because Swift does not support higher kinded types. 

There are libraries that help Swift be more category theory friendly, and one, Bow even simulates higher kinded types. Maybe I will experiment with those libraries in 2023.

Leadership

I managed to make some progress on this, even though it felt, as if category theory was stealing my focus. I even managed to translate my learning into activities at work. Although, most of these leadership activities, were extensions of things I have been doing for a long time, or started as a part of my Learning to Learn focus in 2021. 

Wellbeing 

I,  for the most part, continued with the wellbeing strategies I developed in 2021. However insomnia and stress started to creep back. This was probably due to my letting music practice lapse. Exercise and mindfulness meditation were not enough. Playing a instrument seems to be the most effective de-stressor for me.

Swift

There is always a lot to learn in Swift. Every year apple releases new versions of Swift, XCode, iOS, macOS, watchOS and tvOS. There is also the new Swift libraries and APIs. While I learnt a lot this year I feel I am barely scratching the surface. I am still working my way through last years WWDC videos.

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