An article in Harvard Business Review titled “Mentoring Someone with Imposter Syndrome” resonated with me. The article covers the topic well and offers the following main points for guidance in mentoring:

• Empirically challenge negative self-talk
• Affirm, affirm, and affirm some more
• Deliberately counteract stereotype threat
• Share your own imposter stories
• Do not allow your mentee to give you all the credit

Reflecting on my career, I remember too well the feelings of being an imposter when I started in the industry! I came out of the US Marines, and bounced around a few jobs before landing at a steel mill as an automation electrician and team lead. While there, I felt out of my depth a number of times as I learned on the job, but at that time, I did not have the advantage of the internet and the world at my fingertips that I do now. I started my own business while in that role, teaching myself development focused on the emerging world of websites and web applications. Again, switching my frame of reference, I had to present myself with confidence, and at the same time, learning a whole new lexicon and way of thinking. From there, I joined a consulting firm in the marketing department, again learning a new vocabulary and thinking pattern before jumping again into a global consulting practice and eventually leading the internet practice. I learned to keep my mouth shut unless I had something valuable to say, and to work my tail off in the evenings to answer all the questions I accumulated during the day! I ran 17+ servers in my home and taught myself multiple programming languages while others just assumed I knew the space and had worked it for years as they had.

I lived with the regular feeling of potentially being “discovered” to be inadequate. I channeled those feelings into work and self improvement, leading to constant growth. Over the years since then, I have continued to change my path many times and coming to the point where it felt unnatural to not be outside my comfort zone to some degree.

As I grew more comfortable with the feeling of “being inadequate”, and learned to embrace the feeling of being outside my comfort zone, I transitioned to a place where I started to seek out those experiences for high growth opportunities. I am now in a mentoring role for a number of people in my industry and outside it as well. I find that the points outlined in this article are solid advice and I encourage a read through if you are feeling like an imposter, or if you are seeking to mentor someone.

The negative talk and feelings of doubt are one of the first things I try to tackle in a mentor relationship. I build on that with sharing much of the story in this article, with specifics about my journey. I try to make it clear that we all have times of doubt, and if we never do, we are likely not stretching ourselves nearly enough.

Mentoring is tremendously rewarding, and any mentor will be even more effective directly addressing the self doubt paradigm.

As we have been taking our organization through an Agile Transformation as a part of an overall Digital Transformation, we have been leading extensive training across our business lines and technology teams. One of the most common questions as we discuss Scrum, is around job titles and role. In scrum, there are only a few key roles, and job titles do not apply! There is a good article on the Atlassian site, linked here, that I encourage you to read through. Ihit the highlights here, but they offer a deeper read.

“the essence of Scrum is empiricism, self-organization, and continuous improvement, the three roles give a minimum definition of responsibilities and accountability to allow teams to effectively deliver work.”

The idea of scrum is to keep things simple, contained to a self organized team, and optimized for continuous delivery. To accomplish this, there are 3 defined roles and it is from the intersection of these roles and classic titles or thinking that I see many questions.

Development team

The development team does not have to consist of software developers. According to the Scrum Guide, the development team can be comprised of all kinds of people including designers, writers, programmers, etc.  Titles here have been a source of confusion as involved leaders ask why a business analyst or business user is called a developer – I hear arguments that “I’m not an IT person” or “I don’t write code, why am I a developer?”. The key point for the developers role is that the person is a team member, focused on delivery of value in one or more capacities.

Ideally in a long running scrum team, the members will cross train sufficiently to blur the lines in roles, even in the development team! Unfortunately, in my industry and area, most teams come together for a project, and then disband leading to a higher than ideal rate of churn on this topic.

CSM / Scrum Master:

The scrum master is the “glue of the team” and the challenges in role vs title I see most often are those that come from the traditional PM thinking. I get the question – so who is the PM on this agile project? Or I get the CSM trying to hand out tasks against a project schedule instead of the collaborative scrum approach. This curve is an interesting one to watch, especially in the long time PMI / PMP trained professionals!

Product Owner

“The product owner should not only understand the customer, but also have a vision for the value the scrum team is delivering to the customer. The product owner also balances the needs of other stakeholders in the organization.”

I see business owners who initially struggle with the idea of the product owner role. They are used to the paradigm of meeting with a business analyst, providing requirements and waiting for something do be delivered that they then need to spend more money on since it does not match what was in their head or did not keep pace with the changing business needs.

The product owner role is a far more hands on role, and has expanded responsibility. The key step to success in communication and managing this role is establishing real clarity on the value of the high engagement. The regular feedback cycles, direct ownership and participation in sprint reviews means change is always an option, and surprises are minimal. This means less re-work but to get there, a product owner must understand that they are not the “hands off sponsor” or business lead that gets a “white glove” engagement. The product owner role is a bit of a dirty, hands on, learning in role to get the most value. This is a real paradigm shift for many, but pays off in amazing ways.

I was recently reminded of an old ritual we used to engage in from my consulting days – prior to entering a client site, we would prep and then “armor up” by putting on our suit jackets / sport coats. This was a symbolic process to ready us for the engagement and a reminder to not take anything too personal. I had a different perspective on it as I had come from the US Marines, and “Armor up” had a bit of a different connotation to me initially. The idea stays consistent though, in that the phrase is an indicator that it is time to shift your mindset, and ready for engagement, whatever that may be. We need to be conscious when presenting ourselves in our working environments, to think both tactically and strategically.

What are the outcomes we are after? What is our conversation partner looking for and what barriers might we need to address. What can we give and what MUST we get in this tactical engagement, to further our strategic goals?