Leading Engineers at a Remote-First Scaling Startup

A conversation with Kainar Kamalov, Director of Engineering, Pipe

This week I spoke with Kainar Kamalov, Director of Engineering at Pipe. We talked about how to be intentional with your culture, picking up on and handling emotions in a remote-first culture, and how to make sure the team stays aligned. 

I'm excited to have you today, Kainar. Can you introduce yourself and what you do?

I'm Director of Engineering at Pipe. We are the world's first trading platform for recurring revenues.

What is a trading platform for recurring revenues?

English is not my first language, so I had to think really hard and break down Pipe into words before I fully got it. But then it's very simple. If there is a company where you earn recurring revenue—it can be subscription revenue or it could be any D2C product that you purchase or subscribe to every month, and so on—you can trade a portion of that recurring revenue as an asset on our platform. This is Pipe’s sell-side. We also have a buy-side: institutional investors that bid on those assets and purchase them.

For the sell-side companies that use Pipe, it's easy access to the capital they need by Piping their future revenue. If you are a healthy business, you can get that money upfront. Every month as you get payments from the goods, those are delivered to the financial institutions.

Oh, fantastic. When was Pipe founded?

Pipe was founded at the end of 2019. So we are two and a half years old. I think the founders were the first to come up with the idea of being able to sell this new asset class.

So you all started and then the pandemic happened shortly after.

Exactly. That was something that no one could anticipate, but I think that probably sped up, in my opinion, the acquisition of [the product] and the ease of access to capital. It also helped us to be able to be this remote-first team. Originally the founders were all located in LA, but then as COVID hit, they just went into different corners of the United States. And then we've hired people all across the globe. Today we are fully remote and globally distributed.

So you’re fully remote. And what do you mean by across the globe? What's the spread there? Timezone or geography-wise.

We have team members all over the world. For example, in Australia, I'm located in Kyrgyzstan, and we have a lot of the team in the European time zones and the United States.

Oh, that’s a widespread of timezones.

Yeah. Those are the challenges that we have to navigate as we work and as we build the product.

So what time is it for you right now?

It's 8 PM here in Bishkek and this is one of my earliest meetings today. My meetings tend to go up until two in the morning.

When is your first meeting typically?

Usually, I have my focus time during the day time when I get to do coding and review a bunch of emails and documentation. Then I have a couple of calls with European folks, like closer to my evening around 4:00, 5:00 PM. And then as the US wakes up, we have a big chunk of time when it's early in the morning on the West Coast, but it's late at night here. So we have like three or four hours where the whole team has online time. We are distributed and  we've learned that to be highly functional, it's important to have these chunks of time that you reserve for meetings to make sure that everyone is on the same page.

That's a real challenge. So do you have some set hours where everyone tries to be on at the same time every day?

More or less. We have like four teams within the larger product team and each operates differently. Certain teams have more folks in, for example, Europe, so their working hours are a bit different, and then the other teams have more people in the United States. People in the Eastern hemisphere have to adjust a bit to the American time zones. Every week we have an all-engineering meeting, and every other week, a company-wide meeting where we all meet.

Do you have any teams that have a really wide spread around time zones? Like from Australia to the Pacific coast of the United States?

I think the biggest spread we have is a team that has engineers in Finland and then product people in New York and then a couple more engineers on the West Coast.

Got it. Back to Pipe. How many folks do you all have?

We’re around 110 people—or plumbers, as we call ourselves. We've grown sizeably over the past year. When I joined, we were at around 30.

That's a good pace. Are you expecting to continue growing?

Yes, but we aim to keep hiring at a moderate but effective pace. We don't have a certain number of hires that we want to hit as a company. We have certain gaps, at least on the product side of things, where we want to make sure that we are well-staffed in order to solve the problems that we are seeing day to day.

So you’re looking to add folks only to achieve specific business goals.

Exactly.

We are very intentional. We try to keep our product teams on the smaller side because the faster you grow, with every new hire you bring to the team, someone has to onboard the new hire, and it slows down with both people. Those two people can’t be at one hundred percent capacity. So if you’re constantly hiring, someone is constantly not doing the building part of things. We try to stay more nimble on the smaller side of things.

Also, conversations and the information flow is so much easier when you are on a smaller side of things. 

It's such a good point, especially in scaling companies, which is my bread and butter. I like that phase. It's a little chaotic sometimes, but I like it. When we think about scaling, we forget that every new person has to be onboarded. And then that reduces people's productivity for a while.

In my career, I've been part of smaller teams and for me, it's natural to keep small because, just like with culture, it’s very different on a smaller team. You are not corporate, it feels a lot more like friends doing exciting work together. Obviously, you're solving big problems and you're building a great product, but you also have fun while doing it.

Yeah, I get that. How big are these product teams? Do you have a limit for how many you want on each team?

Right now we don't have a limit, it's more like we have certain areas that we want to cover—for instance, customer onboarding is one team. How do we make sure that when a customer comes to the website—and all the way up until they start trading on the Pipe platform—they have the best experience? We staff the team accordingly and usually, the teams tend to be seven or eight people tops. And then within teams, they're working on multiple projects.

It feels very intentional. Focused on where you want to go, no hard and fast rules. Being intentional about creating the right experience. Not only for your customers but for the team.

Yeah, exactly. We had to be intentional about it because when I was joining the team we were still small, though we’ve since been scaling. When I started, we were still operating very much in early startup mode where there are a bunch of problems that need to be solved. Like we have this great idea, we found early customers, let's make sure that the technologies that we are building actually work. Teams were jumping from one project to another and whatnot. When you jump from project to project, certain things can start slipping through the cracks. That's why we had to be more intentional about this team structure so that there is accountability, and so that people tend to stay within their certain domains longer and build deep knowledge they can use to solve the problems.

Have you been at a scaling startup before?

This is the second company that I've been part of that was scaling. The pace of scaling is different and the nature of the business is different. But there are some things that are similar. At B12, my previous company, I was the founding engineer and saw it grow from a three-person team to a 40- or 50-people team. So we had to go through a similar transformation as well.

How is the pace of scaling different at this company?

I think it's just because the domain is different. We are in FinTech, and we found product/market fit very early on at Pipe, so we were able to then just go and start building, supporting functionality for the product. At B12, it took us much longer to find our fit.

What do you find is different between companies that have found their product-market fit early vs those that didn't?

I've been part of teams that never found the product-market fit. You build technology, you work really, really hard. You have a functioning website, everything makes sense, the product makes sense. And then you launch it and no one uses it, no one needs it, and you're like, what? Doubt creeps in. You don't find worth in what you're doing.

Once you find those excited paying customers that opens up possibilities. And then you work with them, and through them, you understand how the technology can enable other similar customers to do something, and then you just take that and replicate it and scale it.

I think it has an impact on the team too. If we think about autonomy, mastery, and purpose...when you have product-market fit, you have a purpose, right? When we serve these customers, we can see the impact in the world.

Exactly. Yeah. And I think that that works out perfectly with the whole idea of Pipe, which is that Pipe helps companies that have found product-market fit. The companies using Pipe have a base of customers already that are paying them every month, every quarter—they have recurring revenue. And then through Pipe, these companies can trade some of their future revenue to get up-front capital to scale their businesses. For example, they can invest in their marketing, or hire another great engineer. And that's what Pipe is about, making sure that founders and companies grow on their own terms.

It must be great when you can see the impact. 

100 hundred percent. I think that's been my driving principle in choosing the companies that I work for. We are opening up a whole new platform for people. If a business can trade their future recurring revenue—just because it's a good business—and scale to, for example, cover the whole of Europe and Asia, that means we did a great job as a company.

I'd never been outside of Kyrgyzstan until the age of 16 or something. Technology, the internet, helped me go outside, helped me go to the United States to do my undergraduate degree, and then computer science and engineering helped me get into this world of startups. That's how I found that spark: "Hey, we can build these great, amazing things."

As a Director of Engineering, who do you report to?

I report to the CTO. I think the way the founders think about the product team is to keep it as flat as possible, where there's no reporting, there are no titles, everyone is just a builder, and that worked out great so far. It means everyone has an equal say—if you see something say something about it, and if you think there is a problem, then propose a solution and bring it up to everyone.

What I love about tech is we’re exploring new models of organizations. It's interesting to hear that you all are trying to have as flat of a structure as possible.

I think we can have this flatness because we are still small. And because we try to focus on having clear communication so that everyone is on the same page. This means we are very transparent with each other. We give direct feedback. We come from a place of vulnerability. It’s ok to ask tough and sometimes ‘stupid’ questions. That's culturally normal for us to be like that.

I think because of that, we are able to have this flat structure, but as we scale, we will need to introduce managers. We will need to introduce more accountability, but so far it's been quite good the way we've been operating.

How big is the engineering department right now?

We have about 25 engineers. The product team in total is 40-45.

Are there other managers or directors in engineering?

We have a VP of Engineering, two Directors of Engineering, and a CTO.

Got it. I'm interested in structures because I have a background in organizational design. I think we think a lot about our function and the business but we can forget the organizational design part. We have to think about how to design it.

I am on the same page as you. I like to take a step back and understand how the team is working not only on the product side but how are we working with the go-to-market team, the legal team? We want to make sure that their opinions are also taken into account. I think that's where my job is. It's mostly making sure that all the stakeholders are involved and there is good communication between teams and we are prioritizing the right problems so that everyone agrees: "Hey, okay. That makes sense." And building this narrative of what needs to be solved and why it needs to be solved.

As we move further into leadership, we need to work across the organization. We have to make sure we're all communicating, that we all have the same priorities and that we all have the same understanding and expectations. Sounds like you spend a good amount of your time there.

Exactly. I want to make sure that we understand the problems from different angles. Sometimes we create working groups with people from different parts of the organization to solve a problem. We come to a common ground and then go to the separate teams and make sure that everyone in the team is aligned on why we are solving a certain problem.

Alignment is so important. Do we all understand each other? How are we working with each other?

Yeah and it’s twice as hard, I would say, to do it in a remote-first team or remote-only team, right? Because you just get to talk to people for a couple of hours a day. The other thing is you have to take into account the cultures and the backgrounds of people. We have meetings where every quarter the engineering team meets or the product team meets up, and the company meets up twice a year. We spend like three or four days, and we're making sure that we're not only on the same page, but that we develop a trust between each other. Because at the end of the day, if I'm not comfortable sharing why something is great or something sucks, then it adds politicking to the company, which we're trying to stay away from.

If not everyone is on the same page, people tend to create these clusters that are trying to solve certain things, and then others are not involved. And then it creates weird dynamics.

Like little cliques or fiefdoms. Then we're fighting against each other rather than realizing we're all on the same team.

Exactly. It creates these competitive dynamics within the team. I think that we are very intentional about not being on that road.

Is this your first time at a remote-first company or have you been remote-first before?

Luckily I've been in remote-first for the past seven years.

So it's easier for you. Is this your first leadership role or have you been in leadership roles before?

I've been in leadership roles before. When I moved back to Kyrgyzstan in 2015, I wanted to contribute to the local community. The way I thought that made the most sense was to create a local hub of engineers. Just like hiring people from Kyrgyzstan to work for B12, and I was managing the team here. It was 13 people and then I was also a product lead afterward. So I put on many hats over the six years I was at B12.

Being remote-first, what’s been hardest for you?

I think for me the hardest is to understand people's emotions.

Tell me more.

In a way, it's like through chat, unless it's all caps lock, it's really hard to know the feelings behind the sort of message.

Oh yeah, we know what caps lock means. 

It's like, okay, I got to pay extra attention there. But otherwise, it's really hard, especially when the communication gets tough. When people have different opinions, or whenever teams, people are debating for really long. If there is a debate, emotion gets involved a lot of the time and it's really hard to understand whether someone got pissed off or not. So I think that was tough early on.

I think many people find emotions hard, especially when remote. How did you get around it? What tips might you have?

For me personally, I try to just have like five, 10-minute calls. If I know that the communication is going to be like 10 minutes of writing text, I'd rather have 10 minutes to be on the same page with that person and then just message out to the whole team what the conclusion was, or what we came up with, or what the solution was for a certain problem. I think it's important to have weekly 1:1s with people that you work closely with, just to make sure that you build this relationship where someone trusts you and where both of you can give feedback. If a person is going through some tough, challenging moments in life, then you are the person who can shield them from within the team. Make sure, "Hey, let's give this person more time." 

Or sometimes you can be a person that pushes. It's like, "Let's make sure that we help you to step up over the course of the next couple of months." I think you have to just be intentional about it. This word, "intentional," came up a lot today, and it comes from caring about the team first and foremost.

I also think being vulnerable helps a lot, just like reflecting on emotions. If I see frustration, just saying, "Hey, I see that you are frustrated."

Being a good listener is so important. For me it’s about asking a lot of questions, listening, and repeating back what I’ve heard. A lot of the time I don't have to do anything, people just go and solve the problems. They just needed someone to vent to and then the solutions come naturally from that.

What you just said is so fantastic. Be vulnerable, listen, and then a follow up with some questions, repeat back what you're hearing because I do think that a lot of times people just want to feel seen or heard and if they're not that frustration or that feeling might build and it gets in the way of work.

Yeah, a lot of the times burnout comes from not only overworking, but it's also not feeling that you matter. My job is to make sure that you are just happy and 10% more productive, because everyone on the team is a much better engineer than I am. So my job is to make sure that everyone is happy.

Any other thoughts about how to be remote-first at a scaling company? How do you keep everybody on board?

I think that's hard, especially as the team grows. It's like when the team is small, you have this relationship with everyone, you can toss the ball around and make sure that everyone catches it and is on the same page. Right? As the team scales, it's harder and harder to do. And that's when I think, for instance, we have processes around it. The way we solve it at Pipe on the engineering team, for example, is if we have a meeting where we're more than three or four people, we have a notetaker and we have a leader in a meeting. And those we have in a round-robin, so every meeting someone new is doing the job, and we make sure that everyone who is in the meeting, involved in their conversation, knows how to lead the meeting, and learns how to engage everyone in the conversation.

Someone is always taking notes and that's not always the same person. Certain people just tend to be the people that want to serve and want to help out. We want to make sure that everyone gets out of their comfort zone and takes on that role sometimes, and that way the information is also gathered and everything is noted. We make sure that the information is then spread to the whole team as well. Those are some of the simple tricks that we do.

And if you're taking notes or else sounds like people who missed it or people from different time zones can then go back. There's this written record, these artifacts that folks can look at.

Right. The thing is, we have an agenda before the meeting. "Why is this meeting happening? What is going to be happening in the meeting?" During the meeting, we take notes, and then we have action items after the meeting that we want to make sure come out of it. Then we have a follow-up message after the call with a summary of what the meeting was about. For the company all-hands meeting, we do a similar process, and we also send out bi-weekly product updates that detail what the product team has been working on and present the list of projects. It's very simple, it's one-liners usually just like, "Hey, these are all the things that we are working on. These are the people that are working on them." Anyone can ask questions: they can go to certain Slack channels, or they can even just DM people who they now know are working on whatever line item, and they can get more context around it.

Something that’s come up a lot is being intentional. It seems like your company is thinking a lot about being remote-first and scaling. It's a lot about, are we being intentional about the way we're working with each other, the way we're treating each other? 

Intentional is a good word. We try to stay nice to each other and be good people.

If this piece resonated with you, please let me know and give the heart button below a tap.