Engineering Spotlight: Nick Dupoux
Meet Nick: From Startup Engineer to Data-Heavy Craftsman at Numeric
Nick joined Numeric with nearly nine years of startup experience behind him. He started his career at Addepar as a full-stack engineer building financial software for asset management, gravitated over time toward backend development and architecture, did a brief and decisive stint in grad school (”left very quickly, was not for me”), and spent time at Attentive on their data platform team before landing at Numeric. Data-heavy work has been the running theme ever since, and it’s where he is most at home.
In this interview, Nick talks about what it means to engineer for sophisticated users, why he stopped worrying about not having a roadmap, and what on-sites taught him about who the real systems thinkers are.
1. What drew you to Numeric, and how has working here shaped your approach to engineering?
I think my answer is very focused on engineering culture and mindset. I really describe myself as a craftsman. I care about software as a craft and the output of software itself being high quality. I’ve always felt that the production of high quality software is an end in itself. Even if the goal is pushing out impact and value into users’ hands, the best way to go about it is to also care about the details of the software.
I very much felt that sense, that intuitive feeling, from everyone I interviewed with at Numeric. Everyone seemed like they had a similar care of craft. Very crucially, though, it was balanced by a strong motivation to deliver good product at high velocity. It’s really easy to end up working on a team that cares about software but doesn’t invest enough into pushing out the right product decisions. Numeric balances that very well. It hit that hard-to-balance niche: a place where people care about the software they write, but are also pushing out product that’s actually very impactful.
2. What was the biggest mindset shift when building software for accounting teams?
Accountants are very sophisticated users, and very opinionated in the best ways possible. I took for granted just how much sophistication I can expect from them, in terms of how they do their workflows today and their sense of what good solutions look like. I have been continuously impressed with the way that accountants have solved their own problems peppered over suboptimal tooling.
As a consequence, I don’t feel afraid, and I don’t feel like I need to handhold in pushing out a solution I think is complex. In fact, sometimes what I’ve found is that my natural instinct, the voice that says “users are going to get confused about this,” is actually detrimental. It’s often better to push something in front of users that I feel is too complicated, because they’ll surprise me and grok it immediately. The more constrained solution actually limits them and pisses them off. Like: why won’t you let me do X?
3. Can you share an example of how real accounting workflows changed your technical approach?
Going on-site and watching clients close their books was a big one. I saw someone show off a Python script they’d written to automate data aggregation for a monthly email they send to their CFO. Something very specific that they solved in a very technical way. And I found that kind of finely grained, pinpointed solution is quite common. Teams have bespoke processes because of the nature of their business. They come up with unique solutions to unique problems.
That directly informs how I think now. I’m not shying away from saying we’re going to have a big configuration page where users are technically configuring conditional logic that could be quite complex. With the right UI, just handing them a big box to play with, I trust that our users can handle it. That’s directly informed by what I’ve observed from them.
4. Since joining Numeric, has your perspective on good engineering changed?
One thing I’ve very much over-indexed on in the past is having a roadmap, or at least a clear-cut North Star to inform my immediate decisions. I’ve leaned very platform-heavy, backend-heavy, critical-systems-heavy, and I used to have a lot of anxiety about the unknowns. If I didn’t have a clear sense of where something was going to grow, what the difficulties were going to be, I felt anxious.
At Numeric, it’s been nice to just let that go and become better calibrated at considering what matters in the moment. Most problems we’re trying to tackle, we won’t find the right solutions until we’re facing them. So it actually behooves us to build out software, push it out there, see what falls over, and then respond to it as it does. We’re not manning the space shuttle. If my code goes down, I don’t have to worry about the accounting team blowing up in a fiery explosion.
5. How have interactions with customers at on-sites changed your thinking as an engineer?
I think I had an unstated bias that systems thinkers are primarily found in engineering. I thought of it as: we are the computing experts coming in, you are the expert in your domain, let’s see how my expertise can help empower yours. I took for granted how much that concept of a systems thinker applies across all kinds of domains.
I no longer think engineering is where you find the systems thinkers. Accountants are systems thinkers. They work with sophisticated systems all the time. Some of our solutions team members who are former accountants are among the best systems thinkers I’ve encountered in my career. That’s a phrase I never would have said before about someone outside of engineering.
On-site, I’ve seen that play out. Someone automating a monthly email had to interact with six or seven different data systems to pull everything the CFO needs for a four-sentence email every month. That requires juggling a lot in your head. Beyond just the accounting, there’s a random constraint from an Excel spreadsheet over here, and all of that has to fit together. It was genuinely eye-opening.
6. What advice would you give engineers new to Numeric or to building products for financial systems?
Go on-site. I would be making worse software right now if I hadn’t gone on-site early on to really burst my bubble and learn more about how accountants think, and to challenge those implicit biases about what it means to deliver good software and what it even means for my users to need my help.
And then lean in heavily to your area of expertise, knowing that no matter where you choose, you’ll have interesting problems to solve. I don’t think there’s a single boilerplate, cookie-cutter area of the stack here. In extracting data, we’ve applied interesting algorithms to deal with the constraints of accounting data. In designing user workflows, there are interesting constraints around how accountants think about things and how reports have to be formatted. At Attentive, I never really had to think about the fact that I was working with marketing data. It was just blobs of data going from here to there. I don’t think that’s the case with our work. Accounting knowledge bleeds its way in everywhere.