Artsiom Mezin
I was leading the engineering team responsible for alert generation in an AI surveillance platform used by banks.
The platform:
The goal was simple:
reduce the number of people needed to monitor thousands of employees
Customers started sending us Webex meeting recordings.
That created a new problem.
In large meetings like company town halls:
The files looked similar, but not identical:
So the system treated each recording as a different conversation.
Each version of the same meeting was:
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 issue was first assigned to the ingestion team.
Their proposal was technically sophisticated:
It was clever.
It was also estimated to take roughly three quarters of engineering work.
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.
Alerts were generated after transcription, at the sentence level.
Each sentence already had useful metadata:
That meant we could compute the absolute time when a sentence was spoken during the meeting.
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:
My team created a small proof of concept in Groovy that grouped detections by:
This happened before alerts were finalized.
We delivered the prototype in:
What looked like a difficult signal-processing challenge turned into a much simpler product-focused solution.
Sometimes the fastest way to solve a complex technical problem is to focus on the symptom that actually affects the user.
When I started leading a new product initiative at Behavox, I had two responsibilities at the same time:
That meant hiring externally, but also developing people already inside the company.
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.
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:
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:
During those discussions, I:
This gave him a much clearer picture of what the role actually required.
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:
As the team grew, we hired several contractors.
I asked Peter to:
They did not formally report to him.
That was exactly the point.
He had to lead through:
The approach worked very well.
Peter:
Later, when a new team was formed inside the company, he became a candidate for an engineering manager role and successfully transitioned into it.
Today we work together as peers and still occasionally collaborate across teams.
The outcome was bigger than a promotion.
It strengthened:
People often grow fastest when you combine mentorship with real responsibility.