← Back

Expertise as mistakes, bravery and perspective

No, wait; I'm not the expert

Transitioning into a new role, I’ve been reflecting on the balance between self-doubt and confidence, learning to redefine 'expertise' not as what I always thought meant 'infallibility' but as something more within my grasp...an ability to recognise patterns, draw from diverse experiences, and empower others in leading on creating an environment where they can be their best. For me, I'd like this to be increasingly not at all about me

I'd never embark on this role regarding myself an expert in this specific codebase or even sector; rather I'm laying my chips in my value in fostering team trust, and coaching in good communication patterns, engineering principles, and bringing a renewed perspective to a team to define their ways of working.

I will always work to carve out the space and mindset shift, in the most difficult circumstance, for developers to do their best work.

By being mindful and forgiving of myself, I hope to feel more capable and confident to contribute with a true-to-self authenticity - to get out of my own way and demonstrate to others how we can radically question, introspect and unlock each other in delivering the outcomes that matter to users.

The Foundation of Trust and Authenticity

There’s a profound sense of freedom we give ourselves in humbly yet confidently learning to trust ourseleves. For myself, this shows up as recognizing my own equality to others, worthy of the space and platform to contribute as others and no less capable.

This is the mindset I am working on; I feel it's imperitive if I'm to realise the contribution I want to make, asble to have impact for others without undermining myself with doubt. I receive repeated reassurance of my contributions and ability, but I'm working on convincing myself!

Navigating Expertise and Imposter Syndrome

Amid this, I'm still harboring a disquiet about being regarded as an Expert, even nominally in a specific context. Not only in a new role but in an entirely new codebase, sector, and delivering outcomes for users with very specialized needs. My habitualised response is to doubt; 'how can I possibly regard myself as an expert in this scenario?'. Experts are those I look up to, who can articulate complex ideas from their experience and have much better retention than me...right?

Given that skills in Software Engineering have a limited shelf life and are often highly contextual, it feels naïve to ever fully regard oneself as expert in that sense.

However, on reflection, a more realistic, humane and helpful way to find peace in my role, is to cast myself as simply someone who’s (had the fortune!) of screwing up in more new and interesting ways and learned from them than many!

So there it is: I’m an Expert because of myriad past screw-ups!

Software delivery is as much about interactions, communication and coaching others as it is about code. The machines are coming for that part.

Redefining Expertise and Its Application

I'm straw-manning this 'Expert' title admittedly; as in this case it's more a company-specific designation; but more importantly I am recognising that my relative expertise can fit in this context, without needing to be any more knowledgeable in the specific domain than my peers.

That is, not so much expertise in delivering medical software in one context, or even deep knowledge yet of the sector itself...

But rather skills in pattern recognition and trials from previous situations and teams.

After being part of a variety of product teams, I've encountered recurring dynamics, process bottlenecks, each with unique team cultures.

But I've also been exposed to what visionary, inspiring tech leadership looks like and can aspire to model it myself. That is, setting a clear vision for devs, modelling strong engineering behaviors, 'going-first', and repeatedly promoting a culture of safety to experiment, screw up, and change!

Empowering Teams Through Perspective and Guidance

While my colleagues undoubtedly have deeper expertise in the product and codebase, I'm happiest in being able to apply my broadly-applicable skills in coaching and having fioresight for patterns and solutions drawn from past experiences.

Across all software teams, one constant remains: they are composed of people, with shared fundamentals, while organizational process challenges are rarely unique.

Perhaps a crucial aspect of our roles as Leads is to give others permission to trust their own judgments and the courage and safety to find out. I can help build a high-performing teams by promoting respect, and space for learning, feedback, and honesty with each other.

However, while this is the goal and what I expect of myself as someone who cares about my work, I’m learning to put up boundaries around this...

Doing so for others; to signal safety to a team, doesn’t mean subjugating my own growth or safety.

But there is a middle ground; suggesting alternative approaches, more contribution from everyone, and help a new team find joy in their (our!) work.

The Opportunity of Joining a New Team

On joining a new team, I feel granted a special invincibility cloak for a time - and I'm liable to need this more than most!

It's that rarified window where colleagues are socially-bound to be patient, tolerant of my naïve, probing questions, and the risk of challenging current processes is reduced—sometimes even expected.

That's just as well! I know as well as anyone that I’m not the fastest or cleverest developer. But I can ask the right questions, challenge in constructive ways that (I hope) prompt reflection, and spot repeating patterns that slow teams down them in delivering great outcomes for users.

For me, as the new Senior in a team, I can still find identity and credibility in demonstrating a mindset of ownership and true product-thinking among developers...

Coaching colleagues toward becoming true Product-minded Engineers where we can experiment, try new things, and improve the our ways of working and developer-happiness.

It'll be a 2025 of growth for my new team, but for me personally in identifying and approaching the bigger challenges for our teams and users.