Back to the Future Development: Product Execution with CTO Vinod Chandru (part 3)

Making smart and calculated decisions for the future is paramount with any codebase. Our Co-founder and CTO Vinod Chandru (the Master Builder behind so much of our success) discusses his decisions for the well-being of Kloudless’ development as well as his outlook on how the company and codebase can evolve to stay ahead in an ever-changing tech space.

How do you stay on top of the newest technical trends?

I read HackerNews a bunch and mostly follow the news. In addition to these, I maintain very close contact with a lot of our customers who fortunately are senior enough in their organization to get feedback from their customers on the requirements for their product and how the market is trending. So, I indirectly get a pretty good sense of where people’s needs are in terms of the integration space at least and what kind of functionality the market is looking for.

For example, we received requests to enable integrations to Slack and MS Teams as they rose in popularity. We also notice more of our customers are deploying on Kubernetes now, which we’re now taking steps to streamline.

How do you balance reliability/stability and innovation?

Our internal engineering processes push the boundaries of how far we can progress on new features and functionality within the constraints of our performance requirements and SLAs. Similar to how APIs handle rate-limiting, we slow down and improve our stack’s performance and reliability if we notice any decreases in efficiency or regressions.

What is your vision for the Kloudless platform?

My vision for the Kloudless platform is to enable applications to connect and work with each other without having to offload that to end-users to figure out themselves. I view the Kloudless platform as a kind of middle layer; an abstraction layer that allows applications to communicate with each other through defined protocols and extend that functionality to essentially allow more connectivity between applications.

Why did you choose Taiwan to build your developer team?

We chose it for several reasons. It’s hard to hire engineers in the Bay Area because there are so many good companies here offering competitive compensation. We looked for other locations around the world, including Asia and Europe, where we could set up shop without having such a hard time hiring.

Some of our investors from our seed round were familiar with Taipei and thought it would be a good location. They offered to help us establish an office there, complete the legal paperwork, and recruit our first Director of Engineering to head up the office. That was a major reason for moving forward with Taipei since we’d be able to get off to a head start.

On top of that, the software engineering talent in Taipei has been nothing short of excellent! Taiwan is so well known for hardware that the web app development talent can sometimes be overlooked. However, companies like Google seem to be catching on since they just announced they’re expanding their AI and ML opportunities in Taipei with a new office. We’re trying to make the best use of our head start, especially with the Python development community, by sponsoring events such as PyCon Taipei and recruiting as fast as we can! I think you’ll see a lot more companies opening software engineering offices in Taiwan in the near future. I’m very happy we got ahead of the trend and I think some of that is attributed to our investors pointing us in the right direction.

What are the pros/cons of working with a remote engineering team?

I enjoy that I’m able to split my time during the US hours on more business-facing items as well as during the evening hours and overnight on engineering items. That’s been pretty convenient actually, and I really like the Taiwan team’s business hours. They work day-time hours on their side so it lines up very nicely with scheduling development activity on my side.

One negative is it’s definitely trickier to work through major project planning and brainstorming architectural items due to the lack of face time, so I tend to fly over once a quarter to work on our product roadmap with the development team. It’s pretty beneficial to chat with the engineering team about the product in-person.

What methodologies and practices did you have to implement?

Since everything needs to be asynchronous, we use tools like Slack, Google Docs, GitLab, and JIRA for development. This allows us to communicate asynchronously and put everything down in writing. That really helps with a team that is essentially operating around the clock.

The one time we see less activity is on Saturdays PST when both the US and the Taiwan teams are out of the office, so my weekend is from Friday evening to Saturday evening which is pretty nice.

What are your favorite programming languages, frameworks, and development tools?

At this point it’s kind of naturally Python because of how much work I’ve been doing in it. I like Ruby though; I used to code in Ruby a bunch. I actually used to code in Perl early on, which lead me to Ruby.

I’m a huge fan of the Vue.JS framework. I’m rarely an early adopter for development tools, but this was on I began using early on. I recall discussing bugfixes with Vue’s creator, Evan You, back when a minor version release would just break everything. We still adopted it and I was able to re-write a Gmail extension we had early on in three weeks with full unit test coverage. I was very impressed and we continue to use Vue now internally for our current stack.

Regarding editors, I still stick with Emacs, although I use Vim on our remote servers because I’m pretty sure our Head of DevOps would attempt to revoke my AWS access if we installed Emacs on them, which is admittedly a pretty large set of packages. I’d like to think my left little finger has superhuman strength with all of the Emacs key combinations I’ve committed to muscle memory over the years. I also keep a grip strength trainer on my desk now for the rest of my hand though…

What do you do for fun outside of work?

I love traveling! I think traveling via points has become really mainstream and popular now. It’s been a fun escape from the Bay Area. I’ve visited East Asia (Japan and South Korea) a couple of times, and try to stop by if I’m on my way back from our Taipei office. I plan to visit Europe this summer as well.

One of the nice benefits of Kloudless is that you can work from home sometimes, so the entire asynchronous communication part that I mentioned earlier kind of lends itself to me being in constant contact with the team even when I’m out of the office and traveling. So if anything comes up I’m always available to jump in and assist. It’s been pretty convenient in terms of being able to be out of the office even with the hectic pace of a Series A stage startup.

Read it on Kloud Blog