Notes from a CTO #2: Building Remote Teams, Technical Debt, 2022 In a recap (AI edition).

Let's discuss the unglamorous and the not so sexy side of a startup.

Jan 05, 2023

Hey, it’s Bkrm from Docsumo.

You’re reading the second issue of Notes from a CTO: my raw canvas of thoughts and collection of interesting resources I found online.

If you are reading it for the first time, please know I am sending this to you because we have interacted in the past. My goal with this newsletter is to spread knowledge at scale and for free. If you don’t find it useful, you can unsubscribe at the bottom of the page.

But, if this is up your alley, have a read and let me know what you think!

1. Running a startup

This section is a dump of the various facets of startups that I have experienced while running one. This week, let's talk about work-from-home / remote culture.

WFH is a very sensitive subject. At Docsumo, we were discussing going remote even before COVID. We religiously studied the GitLab handbooks to understand how they ran big successful remote teams.

When Covid hit, a lot of people wrote on this topic as companies all around the world announced they will go fully remote. Though, threats came in later as companies in 2022 started firing employees who are not physically resuming office.

In the last two years, a lot has changed.

With all of the noise, you may be perplexed as to what to do. It's your startup; run it however you see fit; there are numerous ways to build it, and there are no right or wrong answers. Don’t base your decisions on what others are doing. Everyone has different shoes, no one has walked in yours.

Here is our framework (just for reference)

Remote work means different things for different people. For someone, it might be a “good to have” perk, but for others it is critical. If you have hired someone by telling them the role is remote, please respect that and don’t try and impose a WFO policy. Try to find a way that works for each employee.

Make sure the team has a defined structure for planning the day. It’s all fun and games till the project implementation starts.
1. Start the day with a short standup call and end the day with an update on your work/slack group or over a video call.
2. Keep “Videos On” for all calls. It’s low effort but has a high impact. We work as a team, and nobody likes to talk to a black screen.
3. Make sure people show discipline with their slack statuses.
  1. Slack focus guide
  2. Slack status and availability
4. Make sure the team has a proper setup for WFH
  1. Good internet
  2. Quiet environment
  3. Proper work station
Working from home doesn’t mean people can do random chores in between. There is a time and place for everything.
Have frequent events together, we have 3-4 events per year that everyone has to attend.
Have a Hybrid system when possible. We have 3 days of work from the office for team members in Mumbai and Kathmandu.
In our case, people who live outside of the valley are required to work two weeks per 90 days from an office in Kathmandu because personal connections are more meaningful than those made over zoom calls.
Always make exceptions on a case-by-case basis. If someone has proven their worth, give them more leeway. This is a tricky slope and can seem like you are acting on bias. But, you are not Willy Wonka selling candies to make everyone happy, it’s important to remember who showed up when you needed help the most.
For positions that need high collaboration start hiring for hybrid positions only. Run time-bound hiring drives: can you get your desired people for a hybrid setup? if not, then run a new experiment for two weeks at the office every 90 days. If that doesn’t work out then try remote in the same country or internationally.
If collaboration suffers and people are not following remote rules, then scrap the policy and get everyone together in one place. I don’t recommend this and keep this only as a last resort. Please ensure you weigh in on the pros and cons before you implement such a decision.

I often say, I am not running a kindergarten. If people don’t follow the setup rules, let them go. My suggestion is to talk to people before you take decisions, and don’t assume. Always give people the benefit of doubt and see if things can be worked or salvaged.
I don’t get frustrated when people make mistakes rather, when people are not able to follow a well defined process.

Things we have still not figured out:

How to ask people for help internally
Building better personal and professional relationships. I don’t consider the company as a family. I feel we are a pro sports team (taken directly from the Netflix deck). So collaboration between them is a must, they should know each other so that they can get the best out of each other. But on a remote setup, this is difficult. Events and time spent within the office are great, but Hybrid really works better.

2. Technology

There is a saying in life that “tax and death are truths of life,” but for developers, we need to add one more thing: “technical debt”.

I was reading Software Illustrated: I'm just trying to change this lightbulb and could not stop laughing.

My programming journey was not easy, as I am an industrial engineer by trade. In my first semester, I received a 33 (the cutoff was 32) in C programming. 😂 I thought programming would not be my cup of tea, but well, here we are. (Long story, let’s talk about this some other day.)

Here are a few things I wish I had done early in my career to be a better programmer.

Learn about design patterns, i.e. when to use what
1. Design pattern (refactoring Guru)
2. Python design patterns
Used Pre-commit hooks and static code check like sonarqube.
Know how to make proper documentation and type hint in python.
There are certain sins in programming that you should never commit. Below are a few.
- Not using .get to get value from dict or any object that supports it
- list operation like, get element or slice, min, and max, which fails if the list is empty or not of the correct size.
- Multiple return type and inconstancy no of return items return function
- Code repetition which can be solved using a function or loop
- Multiple core logic inside functions
- Using dataframe in logic. Convert to tuples and work on that.
- Not having retry on HTTP request or database connection.
- More than 3 labels of nesting in function.
Anyone can code, just give five monkeys a computer, and infinite time they will write better code than me. Remember, writing code that doesn’t break on edge cases, is scalable, and doesn’t have code smell, is an art that very few will master. You can find multiple excuses for “why the code is bad” or it is just a “rough draft” and I will make it better later. Know that a true artist will paint an awesome picture no matter the time, place, and constraints. And this takes a lot of practice and patience.

3. Podcasts

If you skipped the technology section, just a small recap: “I am a bad programmer”. But I need to improve, and here is my favorite channel that has taught me a lot.

ArjanCodes: This week, I was looking at functions.

P.S. All his videos are nuggets of gold.

4. Interesting links

Repos:

Live translated: Inspired by Cyberpunk 2077: I go through 50+ CVs every week and am fed up with the titanic or housing prediction projects. These are the kinds of projects I want to do myself on weekends and also want other people to try.
Argilla: We mostly work with documents where we need to combine text with position information. But there are constant problems, especially with contract information extraction where we just need information from the free following text. Argilla provides a very clean data annotation tool with MLOps & Feedback Loops for such use cases.
Omnivore: I am a big fan of read-later apps and omnivore is an awesome open-source alternative. logseq-omnivore combines two of my most used app.

Articles:

Twitter code vs. George Hotz: This happens a lot when you first join a new company; you can find a lot of deficiencies, but when you comprehend why things are set up a particular way, you will be able to more fully appreciate the work that has been accomplished. However, this is not always the case; occasionally, people write shit code. No ifs, no buts.
End-to-end encryption: I am a big fan of excalidraw. With the recent hacking of LastPass, I am very interested in end-to-end encryption and this implementation on excalidraw is mind-blowing.
A Review of AI in 2022: Well-curated list of major achievements and list of AI articles from 2022.

5. Quotes/ Books

Book recommendation: Shoe Dog
It’s fun to read, and has many valuable lessons for startups. It is easy to look at Nike and say it was destined to be success, but not many talk about the how many times it was about to shut it’s operations.

“I think the root cause of a lot of unhappiness is comparison. People compare their possessions to those of others and are unhappy with what they have”

But I think comparisons can be used to our advantage too. When I am sad about things, I compare our startup with other companies that started around the same time and are either dead or just alive. On the contrary, when I am bullish, I compare myself to companies with revenue ten times larger and funding twenty-five times larger than ours. This always brings me back to reality. Anyway, we always find the grass to be greener on the other side. It's a simple trick, but it's worked wonders for me on numerous occasions.

Our Slack channels have a great collection of memes.

That’s it for this edition, I hope you find it useful.

See you in two weeks!

Best,

Bikram Dahal

P.S. If you learned something new today, please share “Notes from a CTO” with your friends and spread the love. ✌🏻

Share Notes from a CTO

Notes from a CTO