Pros and Cons of Imposter Syndrome (Part 2)

able of Contents

• Reasons (part 1)
• Pros and Cons (this part)

Pros

You are constantly striving for self improvement
You are motivated to overcome or mitigate your weaknesses

Cons

Internal Focus  - Its not always about you

You should start with you and what actions you can take. However that is not where you should end.

After you have watched, listened and adapted by adopting short term work arounds, you should seek more long term solutions (which usually involve changing the environment)

Seeking External Solutions and Validation - Other people don’t always have the answers

You should always ask for help. However you should also always evaluate the help and suggestions you receive using an evidence-based approach.

There is a lot of bad advice out there - Is it working for them? and will it work for you? ( people have different strengths and weaknesses YMMV)

Sometimes watching what people are actually doing can be more informative than listening to their explanations. You should do both.

You know your problems best; you are usually the best person to come up with a solution. That does not mean you need to do everything yourself. However taking some ownership of the process, is the best way of increasing the chances that the final solution will work for you and take account of your needs.

Over complicating things - There is no secret sauce

There are tricks of the trade, but they are not secret. Watch, listen, put in the work and be patient and you will learn them.

Sometime the skills you need are  ones you already know e.g. ones learned in kindergarten. Sometimes simple solutions work, after all the classics are classics for a reason.

For example it turned out that the best way to improve my social skills was doing activities I enjoyed with people I liked (Who knew? My mother that’s who.,)

Impatience - Fools rush in

Everything doesn’t have to be fixed right this minute. As long as you are improving, and as long as you have a plan or a strategy for moving forward, that is enough.

Focusing on one area of improvement at a time is usually best.

Watch, listen, plan, then leap.

Boom and Bust - Slow and steady wins the race

Using a tight deadline to motivate yourself to complete a task that you lack confidence in, (or your instincts are warning you against) can sometimes help. However it can also lead to

• Increased risk of failure,
• More errors, 
• Burnout, 
• Lost opportunities.

Just powering though is not always the answer. If there is something blocking or interfering with your success, you should do something about it.

If your instincts are warning you against doing something, listen to your instincts. What your being asked to do may be 

• Counter productive
• Could be achieved in a simpler way           
• Could be achieved in a way that is a more natural fit to your talents.

Working longer hours in order to offset some perceived disadvantage can lead to burnout, and is not addressing the underlying problem.

Monitor and manage your stress levels and your general health.

Undermining your long term ability to complete tasks in order to achieve short term goals is not usually a winning strategy.

Analysis Paralysis 

Perfect is the enemy of the good. Even if you come up with the wrong answer it gives you a starting point to find the right answer.

Learn to recognise when you are spinning your wheels and ask for help.

Not Speaking up

If problems are not discussed, they are unlikely to be resolved.

Avoiding Challenging Situations

You may avoid tasks where you might shine due to lack of confidence. This can be damaging to both you and your team as your potential contribution is lost.

Catastrophising - the sky is falling

DON’T PANIC 

Take a deep breath

• What is the best thing that can happen?
• What is the worst thing that can happen?
• What is the most likely thing will happen?

Talk to your co-workers about your concerns. Ask for help.

Mitigate risks where the benefits out weight the costs. 

Are their opportunities that go with the threats?

Focusing on shoring up Weaknesses instead of playing to strengths

People work in team for a reason. In effective teams, team members will cover each other’s weaknesses and utilise each others strengths.

Conclusion

The cons generally out way the pros.

Resources

• Books

• All I Really Need to Know I Learned in Kindergarten
• Videos

• Learned helpless               
• Ban average

Related Posts

• Deliberate Practice
• Reasons (Part 1 of The Imposter Syndrome Series)

Reasons for imposter Syndrome (Part 1)

able of Contents

• Reasons (part 1)
• Pros and Cons (part2)

Triggers

• Outside their comfort zone; trying something new.
• Not psychologically safe and are reluctant the expose vulnerability.
• Plagued by trauma and have learned the wrong lessons from the past.

New Role

If you’re nervous about driving into something new check out my onboardee’s checklist.

Constant Change

One of the challenges of working in the software industry is the need for constant learning. There is always new languages, new platforms, new frameworks and new subject matter domains with new jargon. Even if you stick with the same technologies and the same industry, the technologies release new versions and the industry evolves as the environment changes. You are always doing things you have never done before. You are continually pushed outside of your comfort zone.

Fake It Til You Make It.

We are told it is better to remain silent and be thought a fool than to speak and remove all doubt. This is baked straight into our school system. If we struggle then we are suppose to just work harder and bulldoze are way through.

However keeping quiet, means the you do not ask for help that you need or warn of problems that you see. You may be setting yourself up for failure as the underlying issue is not identified and fixed, therefore is likely to worsen, leading to an eventual reckoning.

Sometimes You Aren't Safe.

Unfortunately sometimes you are not imagining it. You feel unsafe because your work environment is in fact not safe.

In which case you need to change your workplace or change your workplace. Don’t let it slide, your workplace culture is unlikely to improve by itself. A bad culture is stressful and counterproductive. Your team, your project and the company itself is more likely to fail, as problems do not get addressed, as it is unsafe to even admit that they even exist.

The unfortunate habit that some people have of asking questions that they make clear only have one acceptable answer or showing no curiosity in the answer, can lead to the death of honest communication and the fostering of an unsafe environment.

Past Trauma

I was mentoring a co-worker on how to present technical changes in terms of business value. I ran into the problem that they were reluctant to raise certain matters. They had received very negative feedback on the topic in the past. I pointed out that that was a different company, different workplace culture, different manager and they had not used a strategy of emphasising business benefits. Sometimes the wrong lessons are learned.

 

The Effects of Imposter Syndrome

This is increased stress and erosion of confidence.

Productivity and learning are effected by stress in a U shaped pattern. Too little stress leads to complacency and too much leads to panic, paralysis and counterproductive behaviour.

The people who see a silver lining or benefits to impostor syndrome are talking about moving from complacency to motivating eustress. Stepping out of your comfort zone is an opportunity for growth, and can motivate change. Those who see the harmful effects of impostor syndrome are talking about moving from motivating eustress to debilitating distress.

Conclusion

When lack of confidence is warranted it can lead to avoidance of risky or dangerous behaviour. And can motivate people to ask for help.

When lack of confidence is not warranted it lead to avoidance of opportunities and the very experiences that will lead to improved abilities. It can motivate people to hide the fact that they need help.

Resources

• Videos

• Learned helpless               
• Ban average

Related Posts

• The Onboardees Checklist
• Pros and Cons (part 2 of The imposter Syndrome Series)

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

Evaluate Learning Outcomes

t the half way point in my professional development plan for 2021 it is now a good time to review my progress . 

So far I have found the plan to be very helpful. Over the last six months I have studied a broad range of topics, some of those topics where within the plan and some where done in an ad hoc manner. Comparing topics studied within the plan to those studied without, the planned topics were studied in a more comprehensive and systematic way with more deliberate practice and social learning. This resulted in better learning outcomes with a more solid grasp of the subject.

Skills Learned

Learning to Learn

I completed my initial goals, finishing the practical, social and formal components with only bonus items outstanding on the progress tracker.

I finished a second course in addition to the one I initially identified and I was happy with the way I was able to put my learning into practice.

JavaScript

I completed my initial practical and social goals with the formal component still unfinished. A bonus practical activity as two video courses are still outstanding on the progress tracker.

I am happy with the improvement in my JavaScript skills and have been able to put my new knowledge into practice. The modularity and reusability of my JavaScript has improved. I am looking forward to finishing the final modules in my courses.

Reduce Stress 

The activities that I chose to combat stress were very effective and the WOOP Matrix was helpful in keeping me on track.  However while it was easy to keep the schedule when I was stressed it became harder when I was merely preventing possible stress in the future. I fell off the wagon in March but rededicated my efforts in April.

Functional Programming

I still haven't yet identified practical and social activities for category theory and lambda calculus. I am hoping they will help me improve my functional programming which is a style I have been utilizing with increasing frequency over the last decade.

 

.