Wahid Choudhury is the founder and CEO of Kaz Software, a Dhaka-based software outsourcing company serving clients across the world. Founded in 2004, Kaz has become one of the most fascinating companies in its vertical, that often gets credited for consistently producing leaders for Bangladesh's tech industry.
In this second part of our conversation (read part one here), we go deeper into the history, operational dynamics and the making of Kaz. Most of all, we try to understand how Kaz has become the company it is today, what makes it tick, and what we can learn from its journey.
We discuss what it takes to grow a company from its early, fledgling days to relative growth and stability, and then how to navigate the challenges of transformation as the company grows. As a company graduates from its early days, its leadership demands change dramatically. First-time founders often struggle to grow to the occasion and meet the demands that a growing business makes upon them. How do you tackle this challenge as a founder and operate? Delegate, fire yourself, create a second layer of leadership, and read and seek advice, suggests Mr. Wahid.
As I wrote in the introduction of part one, Mr. Wahid's approach to company building has a meditative tinge to it. It reminds me of the Chinese concept of "wu wei," which commonly translates as "try not trying" or "effortless action". Flow with the flow of life, as Wahid puts it.
But as you will see in this part of the interview, he has also been obsessed with building Kaz in a particular way throughout its journey, a necessary ingredient if you want to achieve any meaningful result in any field. We may call his approach a kind of detached obsession but obsession nonetheless.
There's a growing interest in entrepreneurship in Bangladesh, but most of these discussions miss the point that building consequential enterprises has a cultural component to it.
On the one hand, this culture is about the kind of founders a society produces, which depends on the family and the education system we have.
On the other hand, it is about a deep and intuitive understanding of the physics and sociology of building successful organizations.
In this second part of our conversation with Mr. Wahid, we focus on what produces consequential organizations through the fascinating story of Kaz Software.
Ruhul Kader: Thank you so much for taking the time to speak with me again. I'll start by briefly recapping our last discussion. You were working at BDCOM and, in between, doing some consulting gigs. One of these consulting projects was with a Silicon Valley-based startup that offered you to relocate to the US and work full-time. This was not something you could do because you moved back to Dhaka to stay with your parents. You told them so and proposed an alternative where you build a small team for them and do their work from Dhaka. They agreed. It was a six-month project. You thought that if it didn't work out after six months, you could go back to BDCOM or do something else. That's how Kaz started. That's where we were. Now, tell us more about doing that project, putting together Kaz Software as a company, and your thoughts during this period. Tell us more about those days.
Wahid Choudhury: As you said, the option was to get an H1 visa and move to the valley and work from there, which was not an option for me. Because I came back to the country from London to be with my parents, I told them that I wanted to stay in the country and do the project from Bangladesh if possible. That's how the idea of outsourcing and doing the project from Bangladesh came about.
The company needed new people. Their existing team was not working well. Had I continued with them and moved to the US, one of my primary tasks would have been to build a new team. I suggested that I could build a team in Dhaka and get the project done.
This was back in 2004. Freelancing was not yet commonplace. Upwork didn't exist. These were not the days when you could easily find freelancers online. There were freelancers, but in a consultant capacity. I think there was a platform called Rent a Coder. You could find developers there, but it wasn't as easy. Given that context, my proposal was quite an interesting approach.
Moreover, by this time, I had worked on that project for about four months as a consultant. I took on a leadership role in technology architecture. Their existing team was quite dysfunctional—each team member was thinking in different directions. They tried working with a consultant, but it wasn't working.
So when I proposed the idea, it was an easy decision for the founders. I was already making things happen for them. Cost was an additional significant advantage for them—doing it in Bangladesh was very cost-efficient. It was part of my pitch as well. They were running out of money, which meant saving money was important for them. It was a win-win deal—good for them and good for me.
At BDCOM, I told Sumon bhai that I had this opportunity and I had to leave. Two more colleagues from BDCOM joined me. It wasn't fair to BDCOM, but it wasn't really my choice. I mean, they said they wanted to work with me and build this thing together.
It was a huge risk for all of us. None of us knew what would happen after six months. However, we had the confidence that if this didn't work out, we would find something else somewhere, whether it was a job or consulting. Getting a job in the software industry was not difficult in those days.
That's how we got started.
Many entrepreneurs and startup founders usually have interesting stories about how they started. They take major risks to start a business—leaving a job, starting with almost no money, and facing significant uncertainties.
I actually didn't have such a big risk if you think about it. We already had a project that provided a runway for at least six months. Transitioning from a full-time job to something that was not full-time was perhaps challenging for my family. But it wasn't anything new to them either, because I already had a reputation for doing things like that.
My wife knew that I would make these unconventional moves at regular intervals. It wasn't that difficult. In many ways, my journey was quite straightforward. It was more like, let's try this—if it doesn't work, I'll try something else.
In fact, I had been thinking about a product idea for a long time. I was thinking that if things didn't work out after six months, I would try that idea out. I had saved some money from my previous consulting gigs. I thought I would spend two to three months building that product.
The idea was a short-term rental platform before Airbnb existed. I wasn't thinking of crowd-sourcing, but rather a platform where flat owners could rent their apartments for shorter periods. I have my doubts that had I tried it, it would never have become Airbnb. After some time, it would have died out. What I mean is that I had a plan B as well.
Those who joined me had a similar mindset. They wanted a change. While we were paid well at BDCOM, we craved more satisfaction from our work. We wanted an opportunity to work on software projects to their fullest potential. I worked on devices until the end, so it was enjoyable for me. We also worked extensively in Bengali and did many interesting things. But not everyone felt the same way. So that was the situation.
Anyway, luckily, we met that six-month deadline and things just got better. The startup we were working for made its first sales, secured some additional funding and that gave us a bit more runway. Our work also convinced them that this team from Bangladesh could get the job done.
Initially, they had their doubts about how to coordinate work between Dhaka and Silicon Valley. It was an untested concept for them. When they saw the initial results, they said they would extend the work and expand the team as well.
We were still working out of my bedroom. When we started the business, I moved my bedroom to our guest room and converted it into our temporary office. My wife was a little annoyed, but such is life. In the new office, we bought a few tables and a few computers, and that's how we started.
After working for six months out of that room, we realized that it wouldn't be sufficient. We needed to bring some structure to hire new people. Until that point, we hired mostly through referrals, or my similarly crazy past coworkers joined us. But not everyone is that unconventional. Plus, they didn't know us, so why would somebody take that leap?
Around this time—the timeline might be a little here and there—we thought we needed to give it structure. That's when we formed the company Kaz Software and thus found out that becoming a company means you just added a long list of additional tasks to your to-do list.
As we grew and became a company, things became more difficult. Until then, it had been simple. We were a small group of people. We could manage relatively easily.
We were still working out of my bedroom. When we started the business, I moved my bedroom to our guest room and converted it into our temporary office. My wife was a little annoyed, but such is life.
I was a developer, but I also had to play the role of office admin, accountant, and everything in between. If the A/C didn't work, I had to take care of it. I handled office amenities and environment, and ensured people got paid on time. It wasn't efficient for me to do so many things.
While everyone helped as much as they could, the primary responsibility rested with me. So I was already doing many things. It became even more work after we formed the company.
Around this time, we started expanding our team. We hired an admin person, but we didn't hire an accountant. I was looking after the accounts.
So we started in 2004. Our six-month period passed, and we delivered the project. We ended 2004 in a good place and started 2005 on a high note.
At the beginning of 2005, Kaz became a limited company. It was more of an organic outcome, which has been the case with many aspects of Kaz. Whenever something was needed, we did it.
For example, when we thought we needed to form a company, I had no idea how to do it. So I went to the RJSC office in Motijheel at that time. I met a broker downstairs. I told him I wanted to form a company. Someone had already told me earlier that you need a broker. When I told him, he said the first thing was a name search. He asked whether I had a name in mind, and I had a name in mind—I wanted to name it Kaz. The full name I thought of was Kaz IT Resources. That's what I put in the form. I did the name search, and it was available. I applied to register that name, and the broker submitted it. He said he would call in two to three weeks.
However, we had an intense workload for the following two to three weeks. These were the days when I wouldn't leave home for weeks.
On the other side of my bedroom was the office. I would walk over in the morning, work all day, and then go back to sleep. We had many deliverables and deadlines. We were trying to convince our foreign clients as well as ourselves that we could deliver world-class software, from design to delivery to deployment to customer support. I was also handling customer support at that time.
In the midst of all this, we forgot about the company formation. When things eased up, we found out that we needed to form the company. You need an entity for many different reasons. So I went back to RJSC, this time through another broker recommended by a friend. The first thing was to do a name search again. We went to apply for Kaz IT Resources, but the name was no longer available because it had been taken by me previously. The government system doesn't update properly, and I didn't have any papers proving that it was me who owned the name. So I lost the name to myself. It was so strange and quite frustrating.
Thankfully, Kaz Software is a much better name than Kaz IT Resources. The broker said, "Give me another name." I said I wouldn't move away from Kaz. I like the name. It's short. It embodies why we exist—we are here to work. It has a philosophical dimension to it. Moreover, I wanted a Bengali name. In addition to that, a little before we started Kaz, there was a P2P network that became very famous, called Kazaa. Everyone was talking about that name. That perhaps also influenced me a bit: Kaz to Kazaa.
Anyway, it was a quick decision. So I submitted Kaz Software, and it was available. That's how we became Kaz Software. But the legacy of Kaz IT Resources lingered for a while. For instance, we used to post all our job ads on BDJobs in the early days, and our email address on BDJobs was KITResources@gmail.com, from Kaz IT Resources. We used that email for a long time.
I don't remember the exact timing, but probably at the beginning of 2005, we thought we needed a website—at least a one-page website. We thought a .bd domain would be good. At that time, the .bd TLD was available, but the registration process was terrible. You had to go to the T&T office and fill out a form to get the domain. I struggled a bit, but kaz.com.bd became available after some effort.
From 2005, I think we have had kaz.com.bd, which is a good three-letter domain at the country level. We were very happy about that. This is the story.
Like I said, many startup founders have compelling stories—lots of challenges and ups and downs. I don't think there was much drama in my case.
Some challenges were there, which is only natural when you're building an organization, especially without any prior experience. You learn in the process. I never felt that it was particularly difficult. It wasn't, and I enjoyed the process.
We were fortunate that we could bring the right people together at the beginning. We wanted to prove that we were world-class. In that sense, the connotation in the name is accurate.
Ruhul: I think much of it is about perspective—how you look at things. If you perceive things as hard and unbearable, then they are hard and unbearable. The same is true if you think the opposite. If you think it's a hard problem, and you enjoy solving hard problems, then it becomes enjoyable. Anyway, I wanted to come back to your company name. It has a craftsmanship connotation, a sense of care, dedication, and soulfulness to it.
Wahid: That's what I've been trying to convey. You have to think in terms of 2004/05. It was a different Bangladesh in the IT and software space. There were few software professionals. The number of good software companies doing good work was limited—no more than five to seven, and all were struggling.
Perhaps some unique individual would start a company and create a distinctive business with maybe four or five developers. They worked mostly for foreign companies. Most companies were around 20-25 people in size, and a few larger ones had 50-60 people.
Microsoft was phasing out Visual Basic—it was dying. Yet there were some skill sets in Visual Basic that people clung to.
It was an awkward and complex time. In that context, building a software company in Bangladesh in the outsourcing space, where you need many talented people, was quite difficult. That's why we were trying to prove to ourselves that we could do world-class work.
We were fortunate that we could bring the right people together at the beginning. We wanted to prove that we were world-class. In that sense, the connotation in the name is accurate.
Ruhul: This is fascinating. I want to understand your journey from two perspectives. One is your personal evolution as an entrepreneur. The other is the evolution of Kaz. You entered the world of venture building somewhat accidentally. An opportunity came, you jumped in. As you said, you flowed with life. You took things as they came. You've also been fortunate to attract other similarly minded people.
Wahid: In this case, you've probably hit the mark. For my personality type, I think I managed to attract a group of people who were a little crazy like me and didn't mind taking risks. These types of people do well in creative fields. This is one of the reasons our alumni have done so well, which we discussed last time.
This was a small market at that time. In that small marketplace, all the crazy characters found a place to come together, like a club. So we were a group of unconventional people. No doubt about that.
Even now, although Kaz has grown in size compared to that time, I still think we have a tendency to attract slightly unconventional types of people—the type who are willing to take risks and go the extra mile.
Ruhul: This is important if you want to make entrepreneurial ventures work. Ultimately, it is people who make a company work.
Wahid: Absolutely.
For my personality type, I think I managed to attract a group of people who were a little crazy like me and didn't mind taking risks. These types of people do well in creative fields. This is one of the reasons our alumni have done so well, which we discussed last time.
Ruhul: And the founders' ability to attract the right people is a huge advantage that's difficult to compete with. Do you have any insight here? Is there any way to attract like-minded people? When you're building a company, you have to be able to attract resources. The first resource you need is people, who will then bring in other resources. I think many founders struggle with this. The ones who manage to overcome this challenge and get to a point where they can assemble an Avengers-type team—a team that gets things done—are the ones who do well. Without this skill, building a successful company is hard. Do you think this is a skill that people can learn?
Wahid: I'm not an expert. I've only built this one company. If I had experience building several more companies like a serial entrepreneur, I could make these assertions with more confidence.
But you're right that, at the end of the day, people matter. More so in businesses like software. The synergy among people matters. Like-minded people collaborate better and work together more effectively. If you have like-minded people with complementary skills, that's even better. If you can attract such people, then any enterprise should succeed.
In Kaz's case, this is definitely true. The way we operated was somewhat unconventional. We didn't have a marketing team until March 2024. In 2024, I thought I needed to explore at least what happens if there's a marketing team. The only reason we survived was that we got more work through referrals.
Business development is relatively complex for us as an outsourcing company. Products are an easier business. If a product is good, it sells itself. Outsourcing and IT consulting services work on pipelines. You have to work continuously for new clients. Anyone would tell you this. But I'm learning this at this late stage.
Despite these mistakes, one of the reasons for our surviving 20 years is that we've been able to deliver work and create software that our clients have been impressed with, and they've told others in their network or referred us. The reason we could deliver good work was that we had excellent people who did exceptional work. This has been our story.
The first project, which I mentioned earlier—that Silicon Valley startup—continued with us. Their data partner company became our second client. They've been our client since 2005. It's been 20 years that we've been working with them. Then their CTO formed another company, and they also brought us on board. This became our third client. If I connect the dots, our first 10-12 clients basically happened this way.
Over time, when we became established, many clients found us online. Still, I would say 80% of our international customers come through referrals. We've also been working in the Bangladesh domestic market for the last 4-5 years. The work we do in the country is more RFP-driven for NGOs.
Going back to your point, if you hire the right people, the delivery is good. If the delivery is good, the company will grow.
One of my favorite writers is Joel Spolsky, the co-founder of Stack Overflow and FogBugz. He had a theory where he said that in software, you first get the team and then they build the product. You don't even need to think about the product. Get your team first, and then think about the product you want to build. It's very idealistic talk because you need money. Without money, you can't get the team, which is a chicken-and-egg problem.
I digressed quite a bit. Your original question was whether this hiring skill or the ability to attract the right people can be acquired. I doubt it, and maybe you shouldn't try to hack it.
My feeling is that you should use who you are to attract your people. For instance, suppose you're not the crazy type, but you realize that crazy people do well in software, and you want to attract them to your company. You fake it, and you attract all these crazy people to your team. But at your core, you can't connect with them, and it starts to create all kinds of dysfunction. I've seen companies make this mistake.
People often don't realize that our environment matters. A person may deliver high performance in one company culture, and that same person can be quite mediocre if placed in a different culture.
I can give my own example. I do very well in some contexts. But if you put me in a strictly structured company where you have to arrive at the office at 10 AM, I would stop functioning well. Structure and regimented routines are challenging for me. I can deliver more than you can imagine, but you have to give me flexibility.
This varies from person to person. There are people who can't function well without structure and routine. You have to place these two types of people in two different environments to get their best performance.
The point I want to make is that if you hire a person who doesn't align well with the culture of your company or you as a leader, it will eventually cause dysfunction. If you attract people by being yourself, you will eventually end up in a better place. Your team will function better.
The tricky part is that if everyone is similar, it can create the risk of groupthink. You can all end up thinking alike, overlooking your collective blind spots. There is this concern.
If you're building a product and everyone on the team thinks the same way, no one will be able to point out if there are blind spots in your thinking. That's something you have to be careful about.
Have like-minded people, but prioritize complementary skills. Maybe keep one or two slightly different people. You can also ask one or two people to play devil's advocate and ask the difficult questions.
I'm speaking broadly. If people don't connect with the leader, it can create many different challenges.
Maybe a leader prefers structure and wants everyone to come to the office at 10 AM because he thinks structure is the best way to ensure the well-being of his team. It can help everyone maintain a good work-life balance. He might be thinking that if everyone comes early, they can also leave early. But someone who has a different perspective would not interpret that positively. He will immediately resist the idea. He might think, "I deliver good work, but my boss is still asking me to do something that I don't like."
That's why it's only wise for us to be authentic and try to attract people like ourselves.
Despite these mistakes, one of the reasons for our surviving 20 years is that we've been able to deliver work and create software that our clients have been impressed with, and they've told others in their network or referred us. The reason we could deliver good work was that we had excellent people who did exceptional work. This has been our story.
Ruhul: This is an excellent take. Changing your core personality can be a challenge.
Wahid: Who you are will come out eventually, and it will create problems later.
Ruhul: We talked about how you put together everything at Kaz. You said one of the challenges you faced was building the organization. Can you expand on that point about building the organization? Talk about the early years of Kaz, focusing on the aspects of organization building—an organization that would eventually survive 20 years. The challenges in those days, some of the mistakes you made, and the lessons you learned.
Wahid: I'll share something that will be interesting for you and perhaps your readership.
People like me who come from a pure technical background and then end up building a company, not necessarily in a planned way, often face this danger: they forget that whatever they're trying to do has been done before, and they can learn from the experience of others instead of trying to figure it out by themselves. I made that same mistake.
However, after struggling through it, when I started doing some reading, I realized that many people had gone through the same challenges before me. All I needed was to study and learn from others. I could have read up a bit or gotten some expert advice, which would have made my life easier.
That's the first advice I would give: read and seek advice if you're struggling with something. Your challenges are not new. Thousands of people have likely gone through similar challenges before you and solved them many times over. You simply need to be willing to explore and learn from others.
Technical people, including myself, suffer from a self-importance fallacy. We tend to think that we're the first person in the world facing this problem, and we have to solve it from first principles. This way of thinking is foolish and doesn't do any good. Following this path will only increase your suffering.
I made those mistakes. My number one advice to anyone building something: just ask for advice. You don't need to follow every piece of advice, but ask and take the ones that can help you. People are usually more helpful than we think when we ask for help.
Let me share my experience from which I learned this lesson. It, of course, looks obvious in hindsight.
Kaz started as a small group of technical people doing that six-month project. As the project progressed, we needed to hire more people and pay them salaries.
I was the manager in this situation and also a programmer. I could still do development and write software, so I was writing software.
However, some additional concerns automatically arose that fell on my shoulders: paying salaries at the end of the month, managing office space and amenities, ensuring everyone could work smoothly.
For instance, we had to install an A/C in the office. So I had to take care of that. I went to an A/C shop, talked to an electrician, and made it happen, though I wasn't good at these things. We were only four people at that time. I thought it was manageable.
The problem is that these things are time-consuming—time that you don't have or could put to better use. That's the point I'm trying to make. When I look back now, it was not a good use of my time. Had I hired an office administrator to do much of what I was doing, it would have been a much better approach. And I could afford an office administrator. Founders should think about this in their early days.
I understand founders usually need to wear multiple hats, but it shouldn't get to the level where you're literally doing things that add negative value. I did that for a long time and managed somehow without an office administrator. It was foolish, and that's how I learned it was not the best use of my time. The realization came slowly. Finally, when we reached 15-20 people, I realized that I needed an office admin if I wanted to run the company effectively.
As we grew, my home office was no longer sufficient. We moved from my house to a new place in Eskaton. It was an interesting and amusing location. It was in Eskaton but not on the main street. There's a market called Lorna Complex, which I think is still there. Beside that market, there's a passage like a tunnel—very interesting. There are shops, but there's this passage. If you go to the end of the passage, there's a field, which is again unusual. You wouldn't expect a field to be there. Behind the field, there's a house. The landlord lived on the upper floor. The floor below was previously a residence, but the landlord rented it to us as an office.
We were growing and hiring new people at that time, which meant candidates were always coming to attend interviews. So I had to give instructions to people on how to reach our office. It was not easy to explain. If I gave people the address alone—addresses are already difficult enough in Dhaka, and this was a particularly difficult one—they would end up at the market and would never find us. Moreover, these were software developers like me, not really street-smart people. They can't find places easily (laughs).
We had some bad experiences where people could not find us, and things ended in disappointment.
To address the challenge, I made a change. I turned it into an algorithm, which became the first part of our interview. If you could reach our door, you passed the basic level. I had a set of instructions that was well-crafted: "You will go here, see a lane on the right. You will go this many steps through that lane, turn left, find two stairs, take the right stairs, go up, you will reach an unmarked door. Knock three times there," and so on. That was the first step.
Those who could reach this point were the ones who could follow basic instructions and had an algorithmic mindset that we wanted in our people. So we turned a challenge into something positive.
I have many amusing experiences from this time.
In those days, I used to cycle to the office from my house in Shantinagar.
Kaz was an unknown company. The name Kaz Software also sounded odd. We had our office in an odd location and provided people with odd instructions to get there. Moreover, we didn't have a domain yet. We were using a Gmail address. All of it was quite suspicious if you think about it. People would naturally fear that they had fallen into some kind of scam.
Anyway, we used to post job ads on BDJobs, and candidates would come. When someone reached our place, "Kaz Software" was not written anywhere in front of our office. We never had a nameplate, not even on our entrance door. And I was often late to the office. One day, there was an interview, and the candidate had arrived at our office before me. Standing in front of the door, he called me. I knew there was an interview, so I was cycling fast. When I got the call, I stopped my bicycle. I was obviously breathing heavily. Breathing heavily, I took the call, and I understood it was from the candidate. He told me, "Brother, I came to Kaz Software and I'm at the door." Breathing heavily, I said, "Brother, please wait a bit, I'm coming in five minutes and will open the door for you." Of course, many people would find this unusual. The candidate said in response, "Brother, I'm not feeling right about this. I'm leaving." I think he thought this was a major scam and ran to save his life (laughing).
This was one of those early-stage experiences. I don't remember what we did to overcome this particular challenge. We probably cleaned up the place to bring some respectability. We didn't put up a nameplate, but I think we did something to address it.
I had many other interesting experiences from those days.
For instance, that office had a problem. There was significant electrical interference in that area. At that time, we used CRT monitors. This was 2005/2006. In some places, the monitors used to shake. It was a strange problem in that office.
Coming back to your question, initially, you don't have funds, so hiring is usually an issue, which it was for us. But you don't want to create an environment where your potential hires get scared and run away. It didn't become a major problem for us because there were few software companies at that time. It was easier to hire. If we were operating today, we would never be able to hire with those conditions. It would be impossible.
Our job ads were very specific. I can take credit for this because I wrote these ads. They were designed to attract people who had a similar mindset to us. Job ads usually talk about many things, such as responsibilities and skills. Ours, I don't remember clearly, used to be concise, about one paragraph. I don't remember the exact wording, but the summary was something like: "We don't care about your degrees or certificates; we only care about your coding skills."
Hiring can make or break a company, particularly in the early days. Kaz didn't survive 20 years because of me; it's because of the people we brought together. I might take some credit for our initial hires, but eventually, others also helped. We had the best sort of people in our initial group. Such a group of people will always make an enterprise successful.
A company is made by its people. You have to get the hiring right. I won't stress anything else as much as a company's initial hires. If you make mistakes in later hires, you can recover. But if you get the initial hires wrong, it's hard to fix. Your initial hires define the company, its trajectory, and culture. In the early days, there was no established culture, no rules and regulations. These people come in and create the culture.
Our job ads were very specific. I can take credit for this because I wrote these ads. They were designed to attract people who had a similar mindset to us. Job ads usually talk about many things, such as responsibilities and skills. Ours, I don't remember clearly, used to be concise, about one paragraph. I don't remember the exact wording, but the summary was something like: "We don't care about your degrees or certificates; we only care about your coding skills." I think we also added something along the lines of what kind of future aspirations you have: "If you think, given the right team, you could build Google yourself, you are right for us. Come and join us."
By default, we attracted people who were risk-takers, not looking for a formal job or asking for job benefits. People responded automatically to the understanding that this company, these people, seem interesting. "I want to join them and do what they're doing." By writing our job posts in a particular way, we directly spoke to people who had similar attitudes.
People often don't realize that our environment matters. A person may deliver high performance in one company culture, and that same person can be quite mediocre if placed in a different culture.
Now that I'm talking about it, I think the difficult location and the challenging way of entering that environment probably worked as a filter for us. Those who came there but left were probably not risk-takers. But those who came and entered through the door despite their doubts were, by default, taking a risk.
I believe that to build a company the way we have done it—a bootstrapped company, building it with limited money and growing slowly, where everyone has to play multiple roles and be entrepreneurial—you need risk-takers. You need trust and people who operate on trust.
Initially, of course, and even now, we don't give out paper contracts to new hires. We hire with an email. With our size today, someone could argue that this could be an issue from a legal point of view. But I still believe it's not a good sign if someone says they don't believe our word and would prefer a piece of paper.
A group of people is saying you have a job, but you can't rely on their words. If this level of trust doesn't exist in a group of people, you can't work together. That's how we've always felt. In the software world, this is not that unusual.
That also worked as another filter in those early days. Now, for example, with our size, we need formal processes and may need to adjust some of these approaches.
Going back to our original discussion, we finally hired for an administrative role that would reduce some of my workload. After that, around 2006-2007, I realized that I shouldn't be doing accounts either. Until then, I was the accountant for the company. I had an Excel sheet for accounting.
Again, it was foolish. Software engineers usually fall for these kinds of things. They think they can do everything better. "Managing finance is simple: you keep a record of money spent and money earned. I can do that." That was a mistake I made.
We should have hired an accountant much earlier. We did it very late. We hired our first accountant when we had over 30 people, and he's still with us. We've been fortunate that he's been with us throughout this journey.
If I were given a second chance, I would make those hires—an admin person and an accounts person—early on, as soon as I could afford them. We made these hires way too late. Much of my energy had been wasted ineffectively. If it were something I did well and effectively, that would have made sense. But that wasn't the case.
Another realization, which fortunately happened early on, was prioritizing productivity.
For software companies like ours, the key metric is development output. The software and lines of code are like what's produced in a manufacturing factory. Anything that hinders that production hinders the business. We introduced several support services early on to ensure uninterrupted production. Still, earlier would have been better.
For example, many software companies don't hire systems administrators. It's an additional expense. Many of these things are not that difficult. Founders can do them themselves, such as networking and other minor technical tasks. We didn't take that approach. I hired a systems person before hiring our admin. My thinking has been that anything that hinders the production of software, which we call facilities, must not be tolerated.
Over time, we became even more careful about this. For example, electricity was a big issue in our early days. Power used to go out once every hour. Long hours of power outages were common. We wanted to ensure uninterrupted electricity by implementing multi-layered electrical support, such as IPS, a generator, and then a UPS. We managed it well. We had that support infrastructure.
Another thing we insisted on was zero bureaucracy. Things like asking for leave were made simple. There was a leave request form. You take the form, write your name on it, get it signed by your team leader, and drop it in the leave request box. We used to call it the dak (post) box. The administrator, who also played the role of HR, would pick it up and process the leave. It's even more simplified now—it's verbal with an entry, of course.
The idea is to remove bureaucracy as much as possible. Bureaucracy is a productivity killer. If there's bureaucracy, production decreases.
People like me who come from a pure technical background and then end up building a company, not necessarily in a planned way, often face this danger: they forget that whatever they're trying to do has been done before, and they can learn from the experience of others instead of trying to figure it out by themselves. I made that same mistake.
Ruhul: You've mentioned many interesting aspects, each of which we could discuss at length. I'll ask a few more questions related to these things. Before that, I want to discuss two points from here: one is bootstrapping, and the other is risk-taking. How do you think about bootstrapping? How should people who are bootstrapping their companies approach it? Similarly, entrepreneurship itself involves significant risk. How do you see this risk aspect of entrepreneurship?
Wahid: Entrepreneurship is obviously risky, as we know most companies fail. If you have the mindset that you want to take a chance despite the apparent risk, then only should you try entrepreneurship.
At the same time, not all risks are fatal. You can fail trying and still get back up. I don't know how much AI will change the world, but in software, if you start early, it's possible to get back on track even if you fail. It won't be a do-or-die situation.
Although from what I've been reading and seeing, if it is a do-or-die situation, it might be better. You put in more of yourself. You try your best. Your chances of success increase.
However, that wasn't the case for me. I always thought that if this didn't work after one or two years, I would get back to the job market. As I told you earlier, it never felt like a huge risk to me.
Going back to your question about whether we should do it: I'm not an expert, but my feeling is that there are certain people who are natural risk-takers. They learn this fact about themselves in their youth—that they're the type of person who jumps into things without knowing what will happen. Sometimes, it produces good outcomes, and they enjoy the experience. So enjoyment is a factor. You need to have the feeling that you're having a good experience. That's one group of people who inevitably try business.
But doing entrepreneurship for the sake of entrepreneurship is not a good idea. "I'm not enjoying my tough and stressful 9-to-5 job, so I'll try a business instead." That would be the wrong approach. If you start from this mindset, you're not going to achieve much success. If you don't like the job, change the job. If you don't like the profession, go to a different profession.
Entrepreneurship requires something more than mere dissatisfaction with your current job.
In my case, I can tell that I've always wanted more control over my time and destiny. I love traveling, so naturally, I wanted flexibility.
If I were starting my profession now, there's a very good chance I might not create a company. I would rather choose to be a freelancer. I love coding. I've always loved coding. I still love coding. So freelancing is that thing where you have total control over your time while earning well.
My preference would have been, if necessary, to work 16 hours for three months, and then I would have three months off traveling. A schedule like that works for me and is possible in the freelancing world.
Remote work also allows this. I mean, the way things are now, it's possible. Back in 2004 or 2005, when I was in that space, it was kind of unheard of. You had to work certain hours.
Even when I was working at that startup in London, along with significant flexibility, it was still expected that I would be at the office by 12 o'clock. I would usually reach the office at 11:30 AM.
When I returned to Bangladesh and joined BDCOM, things were no different. BDCOM was an amazing company compared to many Bangladeshi companies of that time. The rule was that we had to be at the office by 10 o'clock. If you came one minute late after 10 and did it for three days, you would lose one day of your paid leave.
I never got a full salary in any month because I was always late. I used to cycle in those days from Shantinagar to Dhanmondi. I would enter the office sweating. I used to miss the entry time regularly and start my day in a bad mood.
Going back to your question, my opinion is that entrepreneurship is for a certain group of people. It shouldn't be like "entrepreneurship is good, founders do very well in life, so I must do entrepreneurship." I don't think that's the right approach. Particularly in the software world, where there are so many opportunities, you can have a great life doing your work well. If you want security and freedom, you have many better options than entrepreneurship.
While I've enjoyed the journey, I think if I had stayed in the job market, I would have done much better financially. I would probably have done better than this kind of roller coaster of an entrepreneurship journey. But here's the catch: I love the journey.
There's no such thing as free time for entrepreneurs, at least not in the early days. I worked way more than I would have in a job. But that control over time, doing something by yourself, defining the rules—if you enjoy that mindset, if you enjoy that process, then you have a good chance of success. That's my feeling. Entrepreneurship shouldn't be for the sake of entrepreneurship, but because you have that mindset and that enjoyment factor.
Other factors are more like parameters. Such as: earlier is better. If you're not married, even better, because your risks are lower if it goes wrong. But when there's a wife, there are children, or dependents, which happens later in life when we may have to support our parents, it can be difficult. You're no longer alone. If you fail, everyone around you suffers. This is a matter of circumstances. Earlier is definitely better.
I have another feeling, which is perhaps outside of the common theme of "do or die."
Whereas my feeling is—maybe because I came into it quite late, by the time I started the company, I was married—it's better to jump with safety in mind. That's just my approach. I don't know whether this is the right advice, but that's what I did. I always played it safe.
When I left BDCOM, I told Sumon bhai that if I failed in six months, he should take me back. I don't know whether it would have happened, but at least I wanted to have a safety net.
Maybe if you're later in life, doing it with a safety net is better. But as I said, many people say that then you don't push yourself hard enough.
I think the solution is: you have to know yourself. If it were an absolutely do-or-die situation, I think my personality type wouldn't handle it well. I wanted the comfort of safety. I was going to push myself to do this. I enjoy the process, but if things don't work out, I'm okay with it. I'll jump back into something.
Some people, I guess more successful people, probably think in terms of going all in. Like that story from the Muslim conquest of Spain. When they crossed the Strait of Gibraltar, Commander Tariq ibn Ziyad burned all the ships. You must have heard that story—burn the ships. That's a story from 711 AD. The historical truth of the story is not known, but that's a story that everyone knows. You have to burn the ships.
That's the first advice I would give: read and seek advice if you're struggling with something. Your challenges are not new. Thousands of people have likely gone through similar challenges before you and solved them many times over. You simply need to be willing to explore and learn from others.
Ruhul: How should one approach bootstrapping? I think one of the most challenging parts of entrepreneurship is the uncertainty. You have many responsibilities and risks; you need to worry not only about yourself but also about your people.
Wahid: And you always get paid after everyone else. This happened to me a few times. Those are some of the things that you have to accept.
Ruhul: In this context, how should one approach bootstrapping a company? This insight about having some sort of safety net is useful. If you don't come from a background with such safety, you may try to create some sort of savings or create safety in other forms. Then again, when you're bootstrapping, what are some of the best practices and strategies from your experience?
Wahid: Since we're not a product startup, my experience is essentially different. I think product startups are much more challenging than my experience. I'm speaking from the IT service kind of startup point of view.
In my opinion, revenue is the most important thing. I wanted to get to positive revenue as fast as possible. Fortunately for us, we started with that initial project. While it had a chance of running out, at least revenue wasn't an issue initially.
My main concern, if I remember correctly, was what happens when this project ends. At that time, we were probably 10-15 people. I was always worrying that if we don't get other clients and if this project runs out, what happens to all of us? The goal was revenue. It didn't matter how much revenue, but I needed to have revenue coming in.
It was never that we would keep working and revenue would come eventually. Rather, it was how fast we could get to revenue. Revenue is proof that people are paying for the service we provide, and there is value in our service. Because of this, I took on many projects that were not lucrative, but I wanted to ensure we were generating revenue. If revenue comes in, we would have a chance to add value; if we add value, eventually we would make money.
In bootstrapping, that's your biggest priority because you don't have much runway. If you have an investment, let's say I had an investment of one crore taka, then I could say I don't have to worry about the next month, six months, or a year. Let me focus on building the company. Let me focus on building the product. I'll think about revenue once I reach the end of that runway.
When you're bootstrapping, you don't have a choice. The money you have is limited. From day one, you have to think about generating revenue. And I think that's really beneficial.
The reason you're starting a company is to earn money. If the bottom line becomes your secondary concern, which I see in many startups that are well-funded, where the bottom line is somehow a secondary concern—"we'll make money later"—it can become a problem.
This comes from, again, the stories we hear frequently, the success stories of many successful companies that raised billions of dollars in investment before earning any money. We hear stories of companies like Google, Uber, Airbnb, and many others. They burn money for a while and then one day, some of them become multi-billion-dollar companies.
These are amazing stories, but they're not in the same league as small entrepreneurs like you. These stories are interesting and inspiring, but they don't connect with your reality. Your story is that you have five people and you have to pay them. You should always think about revenue.
This is a positive aspect of bootstrapping. From day one, you're focused on earning money. Your focus is on this single thing. The reason you start a business is to make money. Although it sounds mercenary, that's the truth. We can gloss it over by saying we're making creative things, which is all good, but without money, nothing works. This is a positive thing in bootstrapped companies.
Even in funded companies—fortunately, over time, I had the opportunity to connect with many companies that raised capital either as an IT service provider or sometimes as a partner, where we invested in the company. And I've seen the same thing: if the founders have that feeling that "we have to make money, no matter what, funding is not our goal," they do well.
There are companies where founders are more focused on raising more and more capital instead of earning it. In many cases, I've seen these companies don't survive. Well, I've also seen cases where these kinds of companies survive and do well, but this number is small. I think this is partly because their focus was in the wrong place. They were like, "We'll raise some more money, and we'll survive for two more years, and then our product will grow."
My feeling is that I may raise capital, but I must try to earn money from the product I'm building today. It makes a big difference. In bootstrapping, you have this focus by default. Bootstrapping pushes you in that right direction.
But we're also aware of the challenges in bootstrapping, such as running out of money. If you're building a good product and bootstrapping it, sometimes you just don't have the runway to perfect the product. You have to think about that as well, obviously.
Entrepreneurship requires something more than mere dissatisfaction with your current job.
Ruhul: We've been talking about the early days of building a company. Then one day the company grows up. As the company matures, challenges become different. How do you navigate these challenges of growth? At the same time, as the company matures, the founder needs to mature and grow as well. How do you navigate growth as a founder?
Wahid: That's a good question. I have a few important realizations. Some of these realizations come from a book, actually. I generally agree with the thesis of the book. The idea is that once a company somehow gets stable, the original founders should step back from day-to-day decision-making. Because for the founders, a company is an emotional thing. It becomes their child. And the book offers many cases and examples from various industries.
Steve Jobs is a good example, although it's a complex example in the sense that it didn't work out well for Apple when they pushed him out of the company. But in any successful company, as it grows, the founder should focus on developing new leadership and reduce his or her influence on decision-making.
The founder is too emotionally invested in the company. They run the risk of thinking about what was done 10-20 years ago when they started the company. But it's a different company now. Maybe the name is the same, but the organization has changed. The challenges, reality, and opportunities have changed.
This is one of the realizations. I learned it quite late. Again, I could have learned it if I had sought advice or read the book earlier. This is something I think I should have done much earlier at Kaz. I should have given control to a more professional group to run the company. We now have an executive team of six people who make the day-to-day decisions at Kaz. And I make strategic decisions on a smaller scale. And I think that's a good model. Given the chance, I would probably do it earlier.
My experience is that a founder, because of emotional attachment, can get things moving in the early days. They play multiple different roles in the early days. They get the company off the ground, generate revenue, and expand. Once the company reaches that point, they should take a back seat and bring in a professional group to run the company, which we did quite late at Kaz.
As a founder, I might say, due to some emotional reason, that this company should run in a certain way. In those instances, a professional group can offer suggestions and point out my blind spots. They can tell me, "You shouldn't do this. It will harm the company." I think that's really valuable. I missed that opportunity for too long.
I delayed doing this, but fortunately, in the last few years, we've built a structure where my decisions are more on the strategic side of things. I'm no longer the sole decision-maker. I have a platform where I can bounce my ideas around. I think that's essential as the company grows.
Ruhul: I have a related question. In this journey, the founder also needs some sort of strategy to grow personally. What can a founder do to grow personally as the company grows?
Wahid: Building Kaz has been an education for me. The reality is that founders really have to learn extensively out of necessity, for company survival. My strategy has always been: when you can't figure out something, read. I told you that I don't come from a software background. I'm a self-taught programmer. I learned by reading books.
Similarly, I became a founder by reading books. You've probably noticed I refer to many books. That's my primary source of information. I read extensively. If you have that habit as a founder, that's beneficial.
That's a free source of knowledge. The moment you read a book by Bill Gates, you get so much of his knowledge in a very distilled form for free. Books are a wonderful source of knowledge for me. Now there's YouTube. There are courses. You can choose whatever works for you.
Any challenge I encountered, I would go to Amazon, search for books on the topic, and I would read some of them.
For instance, what kind of culture a software company should have was a big challenge for us at the beginning. So I started reading on the subject. All the cultural aspects we've implemented at Kaz that have endured and been praised come from some books. I used to write many blogs in those days. I shared many of these ideas, including the names of these books.
Then we got to the point where we became multiple teams. How to interact within teams, how to maintain cultural values across teams without reducing the independence of the teams—each team was operating differently. We wanted teams to operate independently, but we also wanted the core values to remain consistent across teams. There are excellent books on that.
That said, maybe not everyone reads books. Another problem with books is that they're time-consuming. In today's world, there are online courses and in-person courses. I hear that in Dhaka, many people are going to universities abroad to study, and they benefit greatly from those experiences. You have to keep learning. There's no alternative. Otherwise, the company will struggle and fall behind.
Building Kaz has been an education for me. The reality is that founders really have to learn extensively out of necessity, for company survival. My strategy has always been: when you can't figure out something, read. I told you that I don't come from a software background. I'm a self-taught programmer. I learned by reading books. Similarly, I became a founder by reading books.
Ruhul: These are very useful insights. Learning is a constant requirement in company building.
Wahid: What you started with as a founder, you can't continue with it for long. You have to upgrade and grow.
Ruhul: I think this is a good place to end this part of our conversation. I'm eternally grateful for your time and invaluable insights. I look forward to the next session.
Wahid: Thank you for having me. I enjoyed the conversation.
