A solid, seasoned engineer always takes passion in their past work and in their past deliverables.
– Said By Yours Truly đ
What Makes Someone Proud of their Projects?
Or associated synonyms – proud, satisfied, fulfillment, happiness, contentment.
Good question. I’d imagine couple of factors :
- Appropriately Challenged – they took on challenges at the right rigor level – not to easy BUT not to difficult. In the goldilocks zone.
- End Customer / User Satisfaction – their customers tell them that their products helped them out – in tangible ways or in intangible ways.
- External Praise Recognition – others tell them that they delivered a meaningful feature.
- Good Collaborators – the best work usually happens in groups, and folks will often talk about how they liked working with their collaborators. They may discuss what they learned working with someone else or “jiving” with their working style.
- Growth and Learning – the feelings that they learned a lot ; they explored domains previously unexplored and they picked up new skills.
- Internal Sense of Accomplishment – they delivered all ( or at least the majority ) of their work. They can reflect back and say to someone “I made X happen” or “I delivered X”.
The Situation
Alright, where do I even start the story? hmmmm what’s the situation …1
It’s my first three months in Geico – Q1 2024 – and there’s a major deliverable under way : the Automation Feedback Loop project. It’s a complex, quarter-long scope task – on every scan of a data source, we need to capture and and classify sensitive data element records with respect to two crucial fields of interest – business attributes ( which I’ll call BA ) and tags. Afterwards, we need to expose those results to an internal data catalog.
But sometimes, there’s a discrepancy – a mismatch between the scanner suggested BA and tag values with those currently in catalog. In this business scenario, we need a way to analyze those discrepancies and make a crucial determination – can we overwrite the catalog with the latest scanner-suggested values, or, do we store the discrepancies locally and then notify our stake holders – the data stewards and the data owners – to perform a human audit?
The Tasks
To deliver my goals, I had to identify and work on a few tasks. I needed to get my hands dirty in a new system. I have to ship out two major pieces of code – scaleable, performant code that can scan our sources and read the BAs and the Tags, and a rules engine module that can identify mismatches and the specific scenarios to inform our end customers.
The actions
So I got to work on a set of actions. I set up multiple meetings with involved parties in my engineering org , such as leadership or senior staff talent, to clarify business requirements and to simplify our rules engine so that we knew exactly which cases needed human audit. I also set up meetings to ask clarifying questions about the technical capabilities or technical challenges of our team. Questions like “Do we have a local or production database we could work with to store records?” or “Do we have to to build out a separate UI to action on misclassifications, or could we leverage pre-existing UIs?” These questions mattered. They mattered because they helped the team avoid scope creep – we could down scope on a MVP whilst enabling other teams or future quarters to focus on other functionalities.
The Results
In the end, I delivered many results and products. I shipped a complete and working feature by the end of Q1 – the data stewards and the data owners could successfully action on their misclassifications. I also drew up the system diagrams, authored a design document, and wrote a simplified rules engine module. I really admire these results, because the work delivered persists, and I’m still building off of them, even a couple of months following the deliverable.
My Learnings and My Takeaways
All-in-all, the feedback loop is a greenfield project – I navigated ambiguous requirements and I worked on a system from the bottom up. I feel super proud of my ability to navigate it’s complexity. And there’s so many good takeaways from the project.
The work was very challenging. Firstly, I had to incorporate extensive peer feedback and iteratively refined the design document and the diagrams . I must have created at least five versions of our system diagrams in Visio.io and multiple rough drafts of the design documents. But the sense of ownership and the ability to meet customer expectations by end of Q1 further solidified my belief in my engineering capabilities. More ever, I really admire my collaborators : engineers, leadership, and product owners. I learned new thinking patterns and new ways of tackling problems that I never would have considered before.
- Inspired by a behavioral interveiw prep card AND that it’s a commonly-asked question in behavioral interviews đ âŠī¸

Leave a comment