9 Things I am Thinking About
Mentorship, Single-Thread Leadership, Influence, and Legos
A lot of the time when I write, I write to myself— as something I can look back on to mark the progression of my thinking. This is one of those times.
My experience in the professional world is short. So too is my experience with life generally. As I approach thirty, I am grateful for the experiences I have been afforded and for the mentors I have had the benefit of learning from. Sometimes lessons come the old-fashioned way too, from books.
I have curated a few things I have been thinking about this year— some of which are broadly applicable and others specific to a product role that may not interest you. This isn’t career advice, nor will it apply to everyone. The common cliché of this type of material is that you write to your ‘younger’ self. In contrast, I view this as writing to my ‘older’ self. With any luck, I can look back on what I write today and cringe at how naive it was.
1. Mentorship
When I was younger, I often read that it was important to find a mentor—someone who could guide and advise you in all matters related to life and career. “Find a mentor”, people would say. “I am meeting with my mentor”, declared others. Due to my inexperience and the fact this concept was foreign to me at the time, I had preconceived notions of what this relationship should entail.
I imagined some kind of ‘search’ would take place— where you actively seek out your mentor and shape a formal relationship.
“Hello sir would you like to be my mentor?”.
“Of course, let me now mentor you, mentee”.
“Excellent”.
In retrospect, my view of mentorship was almost ceremonial— an affinity with a more experienced person that came with labels, scheduled meetings, and in a way a somewhat one-sided and transactional relationship. As I eventually encountered mentors, I discovered that none of this has to be true (at least, in my experience).
In reality, mentorship transpires organically and the symbiotic relationship between mentor and mentee often exists without vocal acknowledgement. Sometimes, you will stumble into mentorship as a result of proximity. Other times, you are a mentee from afar, learning from someone you admire without direct interaction— whether through their writing, talks or watching how they handle challenges, you can learn by observing and applying the lessons to your situation. If you are willing and eager to learn, a mentor will find you.
I once thought that a mentor was simply someone who demonstrated how to do things, gave you advice, and showed you ‘the ropes’— shaping you in their vision. What I found is a mentor is someone who identifies talents and capabilities within you that you may not have realised— giving you the freedom and trust to develop those abilities. Someone who identifies your potential and nurtures it.
I no longer believe the relationship to be one-sided. Benefits to the mentee centre around personal growth and skill development. Depending on the context, mentors can benefit by improving their leadership skills and improving the aptitudes of their employees. There is an element of reciprocal learning that occurs too— engaging with a mentee can fructify fresh thinking, novel ideas, and new perspectives.
As I progress in my career I consider myself fortunate to have had a couple of great mentors, both of whom took a chance on me and offered me opportunities to develop my skills in ways that would have been difficult in a more traditional career path. Mentors are all around us. You can learn from anyone, in any discipline.
2. The Single-Thread Leader
The single-thread leader is an organisation-design concept popularized by Amazon. While commonly applied to teams and groups, it’s a useful tool for the individual. This concept was taught to me in a previous role by a Product Manager I worked under. At the time, some responsibilities that had previously been handled by two people were being consolidated into a single owner— me. I was educated on the concept of single-thread leadership— used as a rationale for why this decision would result in higher agency and greater quality output.
There are many definitions, but I like this one1 from Pedro Del Gallego:
“A single-threaded leader is an individual wholly dedicated to solving one business problem, someone who wakes up in the morning and worries just about that one thing, ensuring the initiative’s vision and goals are always at the forefront and is ready to escalate risks early. Single-threaded leaders may be individual contributors, manage a single-threaded team, or a large organization whose attention is similarly focused on that one initiative. The defining characteristic is not the scope of the initiative but the single-threaded nature of the work”.
- Pedro Del Gallego
When a single person is fully accountable for an initiative or project, they have a stronger sense of ownership. They become more invested, make decisions that are more closely aligned with the success of the initiative and tend to drive more potent output because they are personally responsible for its success or failure. Accountability results in stronger engagement, higher quality work, and faster execution. The key point here is not that single-threaded leadership is about delegation— rather, it’s about licensing someone with responsibility, ownership mentality, and autonomy. When people feel a sense of ownership or responsibility, they care more.
“The best way to fail at inventing something is by making it somebody’s part-time job”.
- David Limp, Former SVP of Devices and Service at Amazon
I am sure many reading this can relate. We have all likely experienced a job where we feel like a replaceable cog in a giant machine. If one cog stops working (that’s you), another one can be put in its place at relatively short notice. Instilling a sense of autonomy into an employee is a smart decision for many reasons, especially because it makes them feel like an engine instead of a cog.
Cogs are replaceable, but engines propel the system. Cogs are mobilized from up above, engines mobilize the cogs. While this may not strictly be true in reality (even senior executives or CEOs are replaceable) it’s about how these individuals feel and engage with their responsibilities. It’s less fun to be told exactly what to do— it’s more fun to be told to go make something happen.
This concept relates to the next point— making yourself indispensable.
3. Make Yourself Indispensable
At face value, the term “make yourself indispensable” can conjure up a lot of different meanings. A simple way of putting it is that your absence will be felt if you suddenly disappear. This doesn’t have to mean becoming the master of the mundane. If a member of a packing facility steps off the line and goes home for the day, their absence will be felt— but the line member can be easily replaced.
So making yourself indispensable must be about making yourself irreplaceable? This is not necessarily true either— within reason almost anyone is replaceable given enough time. Becoming indispensable moreso aligns with the following non-exhaustive list;
Developing a skill that few others in the organisation have
Owning a function that nobody else does
Being reliable and consistently delivering high-quality
Taking the initiative to solve problems proactively
Being responsive to solve retroactive problems
Being a strong communicator
The ability to learn and adapt quickly
Willingness to take on more responsibility and ownership
Sometimes this means doing things you don’t necessarily want to, or that others don’t want to— or both (more on that later). The point is not to be thought of as irreplaceable (although, that is nice), but rather to create the impression that it would be a challenge to find someone to replace you— with the caveat that simultaneously nobody wants to replace you.
Ami Vora2 wrote a concise article about what makes an indispensable employee— one worthy of promotion. Get better at complexity, autonomy, and throughput:
Complexity: How difficult a problem can you solve? Sometimes this masquerades as “scope” or “breadth” or “depth” — all different ways to describe why a problem is hard.
Autonomy: Can you handle the problem with minimal guidance? This doesn’t mean “solve it yourself at all costs” — but instead, can you take the lead and pull in your manager and others appropriately to keep them informed or get their support when needed?
Throughput: How many hard problems can you solve at the same time?
- Ami Vora
4. Be Open to Doing Everything
Maybe this is a trope of being earlier in my career that I will someday realise outlives its usefulness, but I have always tried to be open to doing everything. Naturally, there are times when you should learn to say “No” or avoid doing work that is not an efficient use of your capacity— I imagine this is a more important consideration as seniority grows. But at my level, curiosity has allowed me to experience customer support, partnerships, social media work, and product-led work in addition to gaining insight into functions I don’t actively contribute to but that impact my role and organisation such as sales, engineering, marketing, and hiring.
There is an expression that the ‘jack of all trades is the master of none’ but I believe that understanding the various factions within an organisation will help in a stronger holistic sense of the organisation as a whole. This also feeds into the topic of perception vs. perspective, which I cover next. If you can’t “do” a function, take time to understand the position and what it entails from others in that role.
The concept of “trying everything” vs. “being a single thread leader” naturally collide. The conclusion is that “it depends”. Framed around context, career stage, and impact, each will be useful to an individual at varying moments in their life. Earlier stages in one’s career or tenure at a company are a good time to explore everything— later stages are conducive to specialization or deeper ownership. There are times when you must be a generalist and times when you should focus deeply on a limited number of objectives. The key is understanding when to say yes to learning vs. saying no to distractions.
5. Perception vs. Perspective
I have found the distinction between perception and perspective useful across a variety of workflows— whether in investment analysis, product-led work, or general communication.
Perception is the way that we each observe the world— “If there are 7 billion inhabitants of the earth, then there are 7 billion pairs of spectacles through which the world is viewed”3. Perspective is understanding how other people are observing the world.
In conversation, it’s often a battle of perception vs. perception. The sharing of perception unlocks perspective but this is seldom acted upon by those privy to the conversation. Perception tends to trap its owner in a narrow-minded frame of thought. The subtle shift in focus from perception to perspective when engaging in discussions can be powerful and arm you with an informational advantage.
In communication, it can lead to stronger arguments and persuasion if you understand what will resonate most. In decision-making and planning, it can help you pre-empt the pushback you may receive on a proposal and proactively augment the pitch or come up with rebuttals.
This is particularly true if your work involves communicating with technical members of a company— a point I address later. As a Product Manager, I don’t write code, I don’t know the language, and I don’t think I ever will. Yet, through conversing so often with engineers, who help me understand (amongst many things) our system infrastructure, I now often have a better sense of what the pushback or technical limitations of a proposed product requirement will be. This helps narrow the focus on the things we can deliver and avoids squandering precious product and design resources on functionality that extends beyond the realistic scope of the project.
In short, if you are a Product Manager, you shouldn’t always be thinking like a Product Manager. You should be viewing the situation from the perspective of the user, design, engineering, and various other stakeholders. The same idea can be applied to all disciplines. If, for example, you are a defence attorney, it helps to understand the perception of the prosecution.
6. Understand Your Influence Can Change
I’ve worked at companies with employee counts ranging from 30 to 2,000, to 100,000 with varying levels of influence. I discovered the potential and velocity to learn, gain responsibility, and evolve is levels of magnitude greater in a smaller company. I will add the caveat here that this is personal to my journey and the stage of my career. There are opportunities to excel at companies large and small.
In smaller companies, I have been fortunate to have some great mentors who supported my growth and for the first time gave me a sense of influence— responsibility to make decisions that affect the organisation. I will admit that I still find it somewhat weird when someone comes to me for a decision. I will add another caveat here that I am not overestimating the influence, as these decisions are largely product-related which, while important, can be rectified or changed.
To remain grounded, I remind myself that influence is subject to change. In Elad Gil’s book, the High Growth Handbook, he makes several great points about employees who scale and those who don’t. When a company grows from 100 to 1,000 employees the culture changes, and the CEO/founder should be the one communicating that culture transformation is okay and expected. What often happens is resistance to change.
I recall my first ‘real’ job out of university, working as a data jockey for an investment accounting software provider. The company at the time had ~1,500 employees and was a couple of years away from an IPO. Although I didn’t quite connect the dots as much as I can today, I recall there being a visceral divide between the ‘original’ employees and the swaths of new young graduates that flowed in as the company entered its scaling stage. The former clung to the culture that existed when the firm was considerably smaller. The latter embraced the new corporate identity of a company that was no longer founder-led.
Gil calls this the ‘Old-Timer’ syndrome of early employees4. The early employees who fail to understand that their influence will diminish as the company grows can become resentful, resistant to change, and will be outgrown by the company— constantly longing for the old days.
“Some of the most valuable long-term employees of a high-growth company join early on. These employees often have earned the trust and admiration of the founders and CEO, and they have the cultural context and long-term mission of the company in mind, which enables them to achieve outsized things in a high-growth startup.
Their "old timer" status allows them to challenge convention (or provide context on it) in ways that enable them to reshape or remove rules or old processes”.
- Elad Gil, High Growth Handbook
The employees that will thrive are those who accept their influence will diminish over the short to medium term.
“Early employees who are humble enough to realize they can learn from fresh blood can grow with the company and use it as a personal platform for their own learning and impact. Some early employees will stick with a breakout company for decades and their personal story arc mirrors that of the company. These employees tend to be hungry to learn from others, understand that the company, their role, and its culture will inevitably evolve, and are open to change.
A common sign that an old-timer will work out is their eventual acceptance that their role and influence at the company will shrink in the short- to medium-term as the team scales, but that it will expand with time as they continue to learn and the company continues to scale”.
- Elad Gil, High Growth Handbook
This is a facet I have not learned through experience yet, but one I am cognizant of so I can avoid slipping into the old-timer syndrome if the opportunity presents itself (see footnotes for warning signs).
7. Let Go of Things You Love Doing to Grow
Like the last point, this is another one I am expecting to learn through experience and am preparing for when the time comes. The idea of ‘Giving Away Your Legos’ was coined by Molly Graham5 in an article that shares the same name.
Graham witnessed the growth at Meta as it expanded from 500 to 5,500 employees in the early days. She describes the concept as follows:
“The best metaphor I have for scaling is building one of those huge, complex towers out of Legos. At first, everyone’s excited. Scaling a team is a privilege. Being inside a company that’s a rocket ship is really cool. There are so many Legos! You could build anything. At the beginning, as you start to scale, everyone has so many Legos to choose from — they’re doing 10 jobs — and they’re all part of building something important.
You have so many choices and things to build during this early phase that it’s easy to get overwhelmed. There’s too much work — too many Legos. You’re not sure you can do it all yourself. Soon, you decide you need help. So you start to add people. That’s when something funny happens on a personal level and to teams: People get nervous.
As you add people, you go through this roller coaster of, ‘Wait, is that new person taking my job? What if they don’t do it the right way? What if they’re better than me at it? What do I do now? These are some strong emotions, and even if they're predictable, they can be unnerving. In order to get to a really high-functioning, larger team, you have to help everyone get through this roller coaster. If you don’t, you can end up with a real mess”.
- Molly Graham, Give Away Your Legos
Until now, i’ve been focused on acquiring new skills and taking ownership of new responsibilities. I juggle several different functions, most of which I love, and I hope that someday I am forced to give away some of these functions— implying that the company and I are growing. There is a natural desire to want to cradle functions which were once your “baby” or to remain “in the details” as Airbnb’s Brian Chesky would say. But as Graham remarks, “Almost everything about scaling is counterintuitive”.
“One of the foremost examples is that reacting to the emotions you’re having as your team adds more people is usually a bad idea. Everyone’s first instinct is to grab back the Legos that the new kid took — to fight them for that part of the tower or to micromanage the way they’re building the tower. But the best way to manage scaling (and one of the secrets to succeeding in a rapidly growing company) is to ignore those instincts, and go find a bigger and better Lego tower to build. Chances are if you pick your head up and look around, there’s a brand new exciting pile of Legos sitting right next to you.”
- Molly Graham, Give Away Your Legos
8. Speak to Technical People
If you are not a technical person and you work with a technical product, speak to technical people. This is a mutually beneficial relationship. Engineers are the architects of your product but are not usually the target users. Conversely, a product person is closer to the target user and (should) have a desire to understand the infrastructure of the product they help cultivate.
Product people want big and powerful features. Design wants intuitive flows, continuity, visual feedback, and signifiers that make sense to the user. Engineering wants to maintain a strong cadence of delivering new features and improvements to production, efficiency, an absence of bugs, and happy users.
Earlier in my career I asked why don’t companies just hire product people who can code, or engineers who are gifted with great product sense? In reality, while it’s certainly possible to find some instances of this, it’s not the norm. They are different mental mappings. As a product person, communicate with engineers as much as possible. Don’t accept an explanation, seek to understand it.
This takes time, numerous conversations, and repeated exposure, but if you absorb as much as you can, you will further your understanding of how the product works and might develop a sense of foresight when it comes to pre-empting constraints or issues that may be raised when handing over a project to engineering.
9. Speak to Users
The saying goes that if Henry Ford had asked consumers what they wanted Ford to build, they would have said “Faster Horses”. There are varying viewpoints on when and when not to listen to consumers. The ‘True’ luxury companies, for example, are thought to be the arbiters of taste. They don’t create for the consumer, they simply create— and the consumer follows. Brands in the ‘Premium’ category are the ones who create for the consumer. Unlike luxury products, which are non-comparables, premium products are often compared against peers along the value-to-utility scale— “Am I getting my money’s worth?”.
I don’t have experience with the luxury space personally, but if your product is being built for a consumer (whether B2C or B2B) it’s useful to keep a finger on the pulse of what your users want— whether that’s functionality you are missing or pain points with existing features. Engage with their online communities, set up calls, and create networks of highly engaged users to tap for feedback.
If you are involved with a product, you must speak with users.
It’s not always the case that product teams have the most direct contact with users. In some cases, the sales team have the closest proximity to enterprise customers. Something I have found to be invaluable is an open communication line with sales. The customers they communicate with frequently share valuable feedback on features that will get them over the line for signing a deal. If this information is lost in the siloed environment of the sales team, there will be no sense of urgency or understanding from a product perspective. The feedback should find its way back to the product teams.
Thanks for reading,
Conor
7 Billion Sets of Spectacles: Curiosity, Biases, and The Way Through Which Investors See the World (2022) - Conor Mac (that’s me).
A list of bad behaviours that may be signs of old-timer syndrome, from Elad Gil’s High Growth Handbook.
Great experience and reflection, will serve well for the next decades for sure! Cheers!