Engineer Spotlight: Steph Lee on Startups, AI, and Growing as an Engineer

Steph Lee joined the Imprint Team as a Senior Software Engineer in July. Throughout her career as an engineer, Steph has intentionally gravitated toward smaller teams and growing organizations, where the work is hands-on and the impact is immediate.

You’ve worked at both early-stage and later-stage startups. What are the lessons you can learn only at an early-stage and only at a later-stage startup?

I think at an early-stage startup, you’re usually so small and so lean that there isn’t a lot of time to get into process or how you organize, so there are fewer people problems, and you’re purely solving technical and product problems—business problems—at a very high rate. Things you learn at an early-stage startup are just how to be very scrappy and very efficient with your time, since you really don’t have time to spend days prototyping things, since a lot of these experiments aren’t gonna pan out. It’s just not worth the very small headcount you have—not spending one whole person’s time building something out completely. So some of the experiments that do survive, you’re gonna have to live with for a long time, because you don’t have time to refactor them either. You have to learn to build quickly, but with a strong foundation that you can switch out easier. So I think you do learn to build little blocks of stuff at a time.

At a later-stage startup, I think you do start to get into a lot of people and organization problems. If you get to an org size of—engineering org size of maybe—you’d go from, let’s say, 5 to 10, or even 20 or 30, you have to start solving all of the ways that you’re now going to work together. With 5 people, you can kind of just ad hoc talk with the person next to you, or it doesn’t really matter how you work. But once you have many people needing to organize and coordinate, all of those problems crop up, so I think you’re a lot of times solving for that. So more like process building and process changes. And then you also start, if you’re lucky enough, to get into problems of scale and performance, which early on doesn’t matter since you have, you know, 10 people using your site or something.

Looking at your career, you haven’t worked at an Apple, Google, etc. What has kept you focused on smaller-scale companies?

Yeah, I think it’s just a personal choice. What I enjoy most about my work is building new things, moving forward quickly, and I love trying to find the balance between speed and practicality. My impression of what I’ve seen in some of the larger companies that I’ve worked at is, the bigger the company gets, the more you’re just trying to subdivide problems into smaller and smaller pieces and really trying to perfect those. I would say that’s not my strong suit. I kind of like to solve problems with the 80-20 rule. I like working on the bulk of the problem and not dealing with the long tail of all those details. And just trying to do that as quickly as I can is what I enjoy. Getting into some of the large company organization and bureaucracy issues, or sometimes political issues, just is not what I enjoy doing or what I’m good at. So I’ve just never been really drawn to those companies.

Could you give me insight into how you use AI during your day-to-day? Do you find it just as overhyped or actually useful? Some folks have said AI is more helpful earlier in their careers. Since you are an experienced engineer, do you find Claude Code and other AI tools helpful?

I didn’t actually use AI at all until I joined Imprint. I’m a slow adopter—kind of a Luddite, despite working in software. Previously, I worked on stacks and areas I was comfortable with, so I didn’t feel the need.

But coming to Imprint, there’s so much focus on AI, and so many people demonstrating what they can do with it. What Preeth showed with the Datadog integration was genius. Seeing that made me think, “Oh, I didn’t realize I could use it that way,” which helped me adopt it faster.

More than that, though, I jumped into Imprint not knowing anything about Go or the payments industry domain. Given the fast pace here, there was no way I could have started working immediately and gotten things done without using AI. It lets me skip the weeds and focus on high-level thinking while it handles the implementation. At this point, I still don’t really know how to program in Go.

I don’t think AI is overhyped. I do worry that if we overuse it, people will forget how to do basic things that are important core skills. But overall, I think it brings more good than harm.

I pretty much only use Claude Code and Cursor, and then I talk with it like a much smarter coworker who knows how to do things—I’m essentially managing it.

More recently, Datadog released its MCP integration, which has been incredibly powerful. Now when I’m on call and run into alerts, issues, or logs I don’t have background in, I ask it to look things up for me. It’s much better at Datadog than I am, so it’s been invaluable. I honestly don’t know how I’d do my job without it.

During your time at a startup, when do you keep building on your monolith before entirely switching over your codebase?

You’re always in this constant discussion of: do we get rid of the old one, or is it time to build a new one? That conversation’s always ongoing. In my experience, most engineers are so good at seeing the problems in the existing system, their inclination is to always think, “I could build a newer, better one now, using the knowledge I have now.” And so I think most people are always leaning towards, “This one’s unmanageable—let’s start a new one.” When I started early in my career, I was probably the same way, where you do just think, “Oh, I could definitely do this better at this point.” But when you’re starting a greenfield project, you’re spending 100% of your time building new stuff. At some point, people start using it, you need to start supporting it, so 10% of your time goes to fixing bugs or support issues. As time goes on, unless you’ve taken great care of your codebase, it’s gonna be 20%, 30%, 40%. And then you start to get a bunch of really unhappy engineers when you’re spending 50% of your time trying to dig and investigate issues, or fix things that keep cropping up—the same old tech debt problems—and they’re usually problems that are so big that no one has gone and done them yet, and so you’re just at this impasse of, “We don’t have time to fix it. But there are problems, but we don’t have time to fix it because there’s so many problems.” And I think at that point is when people start saying, “Let’s just start over.” But I think, after however many years it’s been working, I feel like it’s almost never the right solution to build a new thing, or switch over. I think it’s a good idea to start new areas in a new thing, and then slowly transition, but all of the big cut-over projects that I’ve seen—they never fully make it. And you find there’s so much time and energy baked into your old product. You forget about all these things that you need to move over. And all these things have been battle-tested. When you switch over, you’re like, “Cool, I built this new thing, it’s fixed some of the old problems,” but you forget about the things that were not problems. You have to fix those, too. And it’s just so much more of an investment. Everyone’s like, “It’ll take a year,” it’s gonna be 3 years, you know, and then in that time, we’ll have switched executive suites, and someone will decide, “We’re gonna stop doing this.” And I’ve just seen that happen too many times that I’m almost always pro, “Let’s just fix the existing thing.”

What have you found most effective growing the earlier-career engineers that you have worked with?

What I usually see in younger engineers is they’re incredibly smart, and now with AI, they have so much capability and knowledge at their fingertips—just by asking, it’s there. It’s less about needing to go study API specs or really needing to learn the very minutiae of Python or something. That is stuff that AI can actually help you with. I don’t think that’s as important. I think what I would recommend more is just focusing on the soft skills side of things.

The hard part now isn’t getting the implementation done—AI handles that. The challenge is how you get that working with a larger team. How do you use AI to solve bigger problems? Most of those won’t be one person in a silo doing something. It’s going to be you working with a team, or maybe even a cross-functional team, trying to solve a problem together.

So for that, it’s mostly soft skills. How do you communicate technical things to stakeholders who might not be as technical? If you’re in a situation where an incident happened and you have to explain impact in a way that matters to business people—that kind of perspective and understanding of how to navigate those situations is what’s going to boost your career.