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

FocusPeopleTasks
AbstractCommunication,
Coaching &            
Leadership
Category Theory,
Abstract Algebra & 
Lambda Calculus
ConcreteReducing 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

Thursday, January 19

Learning Outcomes for 2022

F

ocus Topics for 2021

Focus People Tasks
Abstract Learn to Learn Category Theory & Lambda Calculus
ConcreteReducing Stress & Refocusing the MindJavaScript & 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.