Leadership Stories

Solving Complex Problems & Growing People

Artsiom Mezin

1. Keep it Simple

Solving a complex problem with a simple solution

Context

I was leading the engineering team responsible for alert generation in an AI surveillance platform used by banks.

The platform:

• analyses employee communications such as emails, chats, and voice recordings
• uses AI models to flag suspicious sentences
• generates alerts for compliance officers to review

The goal was simple:

reduce the number of people needed to monitor thousands of employees

What changed

Customers started sending us Webex meeting recordings.

That created a new problem.

In large meetings like company town halls:

• hundreds of employees could join the same call
• Webex recordings were stored locally
• those recordings eventually landed in the company archive
• our platform ingested them as separate files

Why this was hard

The files looked similar, but not identical:

• different encoders
• slightly different audio quality
• different lengths because people joined and left at different times
• no reliable meeting ID to link recordings together

So the system treated each recording as a different conversation.

The user impact

Each version of the same meeting was:

• transcribed separately
• split into sentences
• analysed by AI models
• turned into alerts independently

That meant the same sentence spoken in the same meeting could generate multiple alerts.

For compliance officers, this created significant noise.

Instead of reducing workload, the system increased it.

The initial proposal

The issue was first assigned to the ingestion team.

Their proposal was technically sophisticated:

• analyse the audio directly
• generate acoustic fingerprints
• identify duplicate recordings, similar to how Shazam identifies songs

It was clever.

It was also estimated to take roughly three quarters of engineering work.

The reframing

My team approached it differently.

We were on support calls with the users who were actually feeling the pain.

And the real problem was not:

duplicate recordings

The real problem was:

duplicate alerts

That distinction changed everything.

The key insight

Alerts were generated after transcription, at the sentence level.

Each sentence already had useful metadata:

• speaker identity
• timestamp within the recording
• recording start time

That meant we could compute the absolute time when a sentence was spoken during the meeting.

The simple solution

We realized:

If the same speaker said the same sentence at nearly the same absolute time across different recordings, it was almost certainly the same moment in the same meeting.

So instead of deduplicating recordings, we decided to:

deduplicate alerts

What we built

My team created a small proof of concept in Groovy that grouped detections by:

• speaker
• sentence text
• time proximity

This happened before alerts were finalized.

We delivered the prototype in:

2 days

Result

What looked like a difficult signal-processing challenge turned into a much simpler product-focused solution.

Outcome

• duplicate alerts were eliminated
• compliance noise was significantly reduced
• we avoided a long, complex engineering project

Lesson

Sometimes the fastest way to solve a complex technical problem is to focus on the symptom that actually affects the user.

2. Get it done

Helping someone grow beyond what they could have done alone

Context

When I started leading a new product initiative at Behavox, I had two responsibilities at the same time:

• deliver a brand new product
• build the team that would create it

That meant hiring externally, but also developing people already inside the company.

The person

One engineer reassigned to my team was Peter, a senior engineer.

Before joining my team, he had briefly tried being an engineering manager on another project.

That initiative was later cancelled after the product failed commercially.

Peter returned to an individual contributor role and joined my team as a senior engineer.

The challenge

When he arrived, he was clearly demotivated.

He had already tasted management and wanted to continue down that path, but the failure of the previous product had pushed him backwards.

At the same time, I still needed the team to deliver critical features for a new product.

So my goal was twofold:

• help Peter keep progressing toward management
• keep him motivated and effective as a senior engineer

What I did — part 1

Structured mentoring

I scheduled regular 1:1s with Peter and introduced a framework I use to explain engineering management.

I described the role as three major areas:

• people management
• process management
• technical management

During those discussions, I:

• shared examples from my own experience
• explained how those responsibilities show up in real situations
• recommended books that had helped me earlier in my career

This gave him a much clearer picture of what the role actually required.

What I did — part 2

Real leadership opportunities

I also wanted Peter to practice leadership, not just discuss it.

So I created practical opportunities for him to lead while still performing strongly as an engineer.

I made it clear that:

• strong IC delivery still mattered for promotion
• leadership could be demonstrated before having the formal title

The stretch opportunity

As the team grew, we hired several contractors.

I asked Peter to:

• lead development of one of the major features
• coordinate the work of those contractors
• drive planning and execution

They did not formally report to him.

That was exactly the point.

He had to lead through:

• influence
• clarity
• planning
• delivery ownership

What changed

The approach worked very well.

Peter:

• stayed motivated
• delivered strong technical results
• gained confidence in leadership responsibilities

Later, when a new team was formed inside the company, he became a candidate for an engineering manager role and successfully transitioned into it.

Result

Today we work together as peers and still occasionally collaborate across teams.

The outcome was bigger than a promotion.

It strengthened:

• his confidence
• our professional relationship
• our ability to support each other as engineering leaders

Lesson

People often grow fastest when you combine mentorship with real responsibility.

Closing

What these two stories say about how I lead

• I focus on the real problem, not just the most technically interesting one
• I look for simple, high-leverage solutions
• I invest in people by giving them both guidance and ownership

Thank you

Hope to answer your questions on a follow-up call