—
There is a particular kind of professional satisfaction that never makes it into a highlight reel. It does not look like a product launch or a keynote speech. It looks like a report that used to take eighteen hours now taking four minutes. It looks like twenty-three overlapping benefit programs quietly becoming four, without anyone losing a benefit they were entitled to. It looks like a system nobody notices, because it simply works.
Ujwal Dyasani has built a sixteen-year career almost entirely inside that unglamorous space, and talking to people who have watched that career unfold, a pattern emerges that has less to do with technical talent, though there is plenty of that, and more to do with a particular kind of temperament. Call it patience with a purpose.
Patience as a Discipline, Not a Personality Trait
It is tempting to think of patience as something people either have or do not have, a fixed personality trait like height or handedness. Dyasani’s career suggests something different: patience, at least the useful kind, is closer to a discipline you practice deliberately, especially when the alternative, moving fast and leaving a mess, is so much easier in the short term.
Consider his earliest years, beginning in 2006, inside PeopleSoft’s Student Financials module. Every academic term brought new business requirements, and every new requirement meant reconfiguring a system that tens of thousands of students depended on to get their tuition and financial aid right. There was no version of that job that rewarded impatience. You could not rush a legacy-to-PeopleSoft data migration and hope for the best; a single mistake meant real students with real financial aid checks that did not arrive on time. Dyasani spent years in that environment, building AE-CI programs, leading migrations, and, eventually, taking a report that ran for eighteen hours and rebuilding it so it ran in four minutes.
The eighteen-hour report did not become a four-minute report because someone was in a hurry. It became a four-minute report because someone was patient enough to understand, completely, why it was slow in the first place.
That distinction matters more than it might seem. Rushed fixes tend to create new problems dressed up as solutions. The kind of improvement Dyasani has built his reputation on, again and again, across PeopleSoft security architecture, Workday data conversion, and eventually complex Workday Studio integrations, comes from a willingness to sit with a problem long enough to actually understand its root cause, rather than patching its symptoms.
The Courage to Simplify
There is a moment in Dyasani’s career, between 2011 and 2015, that deserves more attention than it usually gets. Tasked with a benefits eligibility redesign, he did not just improve the twenty-three separate benefit programs an organization was juggling. He consolidated them into four, by designing more sophisticated eligibility and event rules that let a smaller, smarter structure do the same job the sprawling old one used to require.
Simplification, real simplification, is an act of courage disguised as an act of tidiness. It is far easier, professionally, to leave a complicated system complicated. Nobody gets blamed for that. But collapsing twenty-three programs into four means taking responsibility for a new structure, betting your own judgment that the simpler version will hold up under real-world pressure. It takes a specific kind of confidence, earned rather than assumed, to make that bet and be right.
That same instinct shows up again in 2015 and 2016, in a project nobody assigned him. Between formal engagements, Dyasani independently designed and built a course-registration bolt-on system to solve a scalability problem in an existing university platform. He was not being paid, in any formal sense, to fix that particular problem. He fixed it anyway, applying hard-won production experience to something that was simply broken and bothering people. That is not the behavior of someone optimizing for credit. It is the behavior of someone who genuinely dislikes watching a fixable problem go unfixed.
Teaching Through Documentation
Perhaps the most quietly revealing part of Dyasani’s recent work, since 2016, is not the forty-five-plus Workday integrations he has designed and implemented, remarkable as that number is, or even the single integration where advanced XSL rework cut a three-hour runtime down to four point six minutes. It is his documentation methodology, which combines Visio diagrams, plain-language explanations, and instructional videos into something that reads less like compliance paperwork and more like an act of teaching.
Most engineers treat documentation as an afterthought, something to be produced reluctantly and read even more reluctantly. Dyasani appears to treat it as a form of care for the people who will inherit his work after he has moved on to the next problem. That is not a small distinction. It reflects an understanding that good engineering does not end when the system works. It ends when the next person, who was not in the room when the decisions were made, can actually understand why the system works the way it does.
A Research Record Taking Shape
In the last three years, Dyasani has begun formalizing this experience into published research, seven papers as of this writing, each one clearly grown out of something he actually built rather than a purely theoretical exercise. His earliest work examined XSLT transformation pipelines and secure file transfer architecture; his most recent, published in July 2022, is titled ‘Schema Design for PRISM Tables and Views: Optimizing SQL-Based Data Marts to Feed Downstream BIRT Layout Engines,’ a paper that, true to form, tackles a problem most people would find unbearably dry and finds something worth saying about it anyway. In between came work on data conversion frameworks, security group modeling, cross-functional analytics reporting, and, in March 2022, a quantitative study of the FTE reductions achievable through workflow automation using EIB and PowerQuery integration.
None of these titles will win any awards for excitement. All of them represent a person choosing to write down, carefully and rigorously, lessons that would otherwise live only in his own head, or worse, disappear entirely when he eventually moves on. That, too, is a form of patience: the patience to document not just how a system works, but why the underlying approach is sound, for the benefit of people he will likely never meet.
What Good Work Actually Looks Like
We spend a lot of time, culturally, celebrating disruption, speed, and reinvention. Dyasani’s career is a useful corrective to that instinct. It suggests that some of the most valuable work a person can do is not loud, is not fast, and does not photograph well. It is a report that runs faster. A security model that protects the right people. A benefits structure that is simpler without being worse. A piece of documentation that saves someone else a bad night. Sixteen years in, that is Ujwal Dyasani’s case for what good, patient, unglamorous engineering can add up to.
—
