In our First Line of Code series, Commit co-founder Beier Cai talks to prominent tech founders and tech leads building the next generation of companies, to hear experiences and lessons learned from their early days.
Dessy Daskalov is the co-founder and CTO of Nudge, a Toronto-based startup building a digital communications platform for deskless and frontline employees. Nudge provides employees with the information and tools they need to stay connected at work and reach organizational goals.
Commit co-founder Beier Cai sat down with Dessy to talk about the early days of Nudge and what it was like writing the first lines of code.
Beier: Let’s start at the beginning. How did you get into coding? And what led you to start Nudge?
Dessy: I was born in Bulgaria and immigrated to Canada when I was seven. My dad had a positive attitude: you’re in this country, you have no money and no connections, but you have an infinite opportunity to do anything you want. He was always telling us about the Googles of the world—these two guys who were like you or me, who used their brains and created a massive, scalable thing. So I grew up wanting to run a business. My brother and I are now both startup founders, so I guess it worked out.
I was always into math and science in school and ended up going into engineering for my undergrad. I started to focus on software during that time, because software scales. You need the least amount of capital and it’ll scale the furthest.
During my time at school, when everybody was getting summer jobs, my dad, again, said, “You have no connections, but pick up the phone and make more phone calls than anyone else and you’ll get an internship.” So, I picked up the phone and ended up getting an internship at a company called Eloqua. It was around 400 people, and I was inspired to see how just a few people could start something that grows to be massive.
I had one other job after that, at an agency called The Working Group. I did that for a year and they actually introduced me to my cofounder. She had the original idea for Nudge and a few early customers, and was looking for a technical co-founder. We partnered up and started building.
Beier: Let’s get into the technical side of things. When you started Nudge in 2012, how did you choose between new technologies and tried-and-tested technologies?
Dessy: In those days my main concern was not so much the trade-off between old and new technology, but how do we get our product into the hands of customers as quickly as possible?
At the time I was working in Rails a lot, and I chose Rails. You have to do a few gut checks, such as, is this going to scale eventually? Will I be able to hire and grow a team with this technology? But it was mostly about what technology I was comfortable building quickly with. I would try new things, because it’s fun and important for learning, but that was 10 percent of the time, not 90 percent.
Beier: How do you approach new technology adoption? Is it introduced by you or the leadership team or are there other team members who suggest things?
Dessy: At this stage we’re much larger. I have a really incredible team, so often my team will be the ones to introduce it. You have to work with people you really trust, and I really trust them. They make these trade-offs all the time, and I get involved if it’s a foundational decision.
Beier: One thing technical leaders struggle with is a strategy to manage technical debt. What is your approach?
Dessy: Early on we were strict with having solid test coverage for everything. Rails encourages that, which is fantastic. But we were quite diligent, which helped us when we were building quickly, because we were less worried that we would write something that breaks something else.
In the early days, whenever we introduced code that didn’t get used, we eventually tried to rip it out. Now, we keep a backlog of technical debt, and we treat larger technical debt items as proper features.
It’s not easy to do, to be honest. You want to always be creating value for customers, and the value of reducing technical debt is less immediately obvious, even though long term it’s extremely important.
Beier: Do you have a framework to prioritize technical debt?
Dessy: We have it listed as high, medium or low priority, and we roughly estimate the time. So we can see high priority items that don’t take a lot of time, and those are the ones we should do pretty quickly.
We also have something called firefighting weeks. When a dev is in a firefighting week, they don’t touch feature work at all. They’re working on bugs, but that’s not going to fill up the whole week. They’re also taking items off the technical debt list. That’s been really helpful to knock things off.
For bigger items, you have to schedule them in. If something is producing bugs, or it’s hard for anyone else to understand, it’s time to refactor it.
Beier: What was your strategy for early-stage hiring? What kind of qualities were you looking for in engineers?
Dessy: The number one quality is reliability. Every early employee has to take on so much, because there are so few people. When the business is just a handful of people, if one person is not reliable and balls are constantly getting dropped, it’s really difficult.
We were extremely lucky. Our first hire was a developer that stayed with us for five years. He and I developed a really close friendship. We worked together for a long time and he was extremely reliable and adaptable. He understood when something needed to be shipped.
Beier: For early-stage teams, are you looking for senior engineers with lots of experience, or does that matter?
Dessy: I think you definitely need senior people early on. When you’re hiring junior people, you want to do the right thing for them. To give them coaching and bring them up to speed and work with them, and sometimes you don’t have the time. In the early days, having people who are senior is important. But as you grow, I think it’s important to bring on other talent as well.
Beier: A lot of technical founders wrote their initial software. Because they know everything about it, when a new team member comes in the technical founder is often very involved in decision making. But as you scale a team to 5 or 20 engineers, it gets a lot harder. How did you transition from owning everything to letting other people make decisions?
Dessy: It was definitely a struggle. It was getting to the point where if I owned a piece of code, it couldn’t be high priority in terms of timelines, because I was going to be a bottleneck. When it got to the point where that was happening too frequently, and I could only take on really small features, then how do I justify doing small features that aren’t highly important or valuable or urgent?
It’s so hard to let go, because it’s also such a joy. There’s nothing I love more than a day of being fully in the zone. It’s also your baby. You’ve been building it for a long time and it’s yours and you’re protective of it. That said, I was able to let go because we have an incredible team of talented developers who I trust immensely.
Beier: How do you motivate your team to have a sense of urgency? You have customers, constant demand, technical debt to fight—how do you nurture the motivation in early-stage teams?
Dessy: Some people are more suited to a startup lifestyle than others. Some developers are naturally more adaptable, and understand that priorities shift more frequently in the earlier stages of a business.
So some of it is just getting the right type of person, who’s flexible and adaptable. You do have to protect your team though. You have to make sure you’re not changing things too quickly. If your team trusts you to make that tradeoff, it’s much easier to have a sense of urgency, because they know that when you say it’s urgent, it really is.
Beier: Is there anything you intentionally did to nurture your early-stage culture?
Dessy: Early on we had this idea of dev hours, a few hours a week that we could explore whatever we wanted to. We found that those dev hours paid dividends, because we would learn and explore, and apply those new learnings back into the codebase.
We also do dev budgets—a budget per person to go to conferences or to encourage people to learn from books or courses. When we could all be in person, we’d do quarterly dev hangouts, to stay social. Earlier on, that happened much more organically, but we formalized it later. We try to do lunch and learns—again, to encourage learning and build culture.
Beier: In the early days, what technical decisions did you make that turned out to be troublesome for later engineers?
Dessy: Right before I started writing code for Nudge, I was playing around with Backbone on the frontend. I thought, this is fun, I’ll use Backbone again on Nudge. But Backbone wasn’t a frontend framework that took off—React is what we’re using now. It took some time to unwind that decision. Would I have changed it? I don’t think I could have made a different decision at the time with the information I had. I wouldn’t say I regret it.
Beier: After one of our engineers joined a startup, as CTO, he had to attend board meetings, and he asked me what his responsibilities were. As a co-founder and CTO, in the early days you wrote code, but you need to wear multiple hats. What are some of your memorable non-technical moments?
Dessy: There were lots of memorable moments in the beginning: pitching in front of investors for the first time, fundraising in the early stages, launching our first customers. We also went through an accelerator called Jolt out of MaRS in Toronto. We were there with several other startups pitching, selling, building product and getting a condensed education in a few months. We have lots of good memories from those days.
Beier: I’m curious about your personal career transition. A lot of technical founders decide to remain individual contributors, others decide to be more holistic. It seems like you went down the latter route, where you manage the whole engineering team. When did you decide to make that career transition? And how did you decide?
Dessy: I think so much of it is based on your tendencies. When you’re small, you hire to fill in gaps. I don’t think I ever thought, this is the point where I’m going to make the transition. Less time to code? Hire more developers. But I’m definitely the latter—I’m absolutely not an individual contributor involved in one specific aspect of the business.
Beier: What are your tactics for dealing with the stress associated with startups?
Dessy: When I’m worried about something, I try to think, can I do something about it? If I can, great. If I can’t, then I shouldn’t worry. When there are big things I’m concerned about, I make sure there’s a really good plan in place—that we’re doing what we can about it.
I never want us to drop the ball for lack of effort. You’re going to drop the ball sometimes, of course, but I never want it to be for lack of effort. I try to make sure I’ve done everything I can, and if I know that I’ve done everything I can, then I consciously make myself not stress about it.
Beier: You’ve been a mentor in the Ladies Learning Code program. We all know that the industry has a severe shortage of non-male engineers, and there are even fewer non-male founders and technical founders. I’m curious about your perspective on this, and any advice you have to encourage women to get on the entrepreneurial side of the career journey?
Dessy: I think the only reason I got into it was because nobody told me early on that I couldn’t. My parents always told me that I could.
I’ve always liked the phrase: It’s hard to be something you can’t see. I think the best thing women can do is tell their stories and show other women that they too can do it.
I don’t want to broadly give advice, because it’s not going to apply to every situation, but the best thing for me on my entrepreneurial journey was to do it way before I felt ready. Just dive right in, be unwilling to give up, and you’ll prove to yourself that you’re ready.