Deepak ChhuganiIn the past 18 months, I’ve been a solo nontechnical founder with remote dev teams for two startups. One failed fast. One got me into Y Combinator. My learnings are summarized in 7 points below.
This Post Is Helpful for…
…People building an early-stage software-driven startup and managing a team of developers who are not in the same city, country, or timezone.
It will be especially useful if you’re trying to improve productivity, accountability, or to get a good operating rhythm on shipping product.
Context
In the past 18 months, I’ve built two different products with two different remote developer teams. Both times I’ve been nontechnical in the sense that I don’t write usable code (even though I’ve learned to code).
Both times I have also been the person defining which features to build and how to prioritize them.
For the first team, I listed out the features I needed up front, was told it would take a few months, and then I was cut out of the process (don’t do this).
For my current team, I am on Slack, Trello, Github and more with them on a daily basis and we never scope work beyond a 2 week period (this is the way to go).
The most recent product & startup I’ve been building, The Lobby, got me into Y Combinator as a solo nontechnical founder.
As I was recently talking about how we manage our team to a founder friend, I was shocked at how much we had improved over time and how much I had learned, so I’m sharing those learnings with you.
This post also sheds light on how our team works, and I’m hoping it will attract the technology leader I’m currently looking for.
Recently, we saw some huge improvements by instituting the below changes, but we still strive to keep on improving.
1. “Remote” doesn’t mean random overseas developers. Choose your team carefully
If the remote team you choose isn’t hard working, entrepreneurial, scrappy, and fast learning, you probably won’t find much success with them, regardless of all the advice listed here.
That’s the main reason what we’re doing is working — our team is amazing.
Invest the time to find great remote developers, whether it be from personal referrals, great ratings on sites like Upwork or YouTeam, or vetting them with quick projects where you can see if they are reliable & hard working.
2. If possible, validate your product manually so you can align your team on what to build
Unless you’re building something highly technical — I would really push you to validate your idea with a manual iteration of the product. Here’s one story of how we did it.
Our team always knew that we were building features that users needed because we had paying customers before the first line of code was written.
I did everything with spreadsheets before asking our developers to write any code, and even when we started it was a very “lean startup” approach.
If The Lobby’s “spreadsheet product” had 30 manual steps, we’d only focus on automating 2–4 of those every few weeks, in order of most painful to least.
Even today, we have a few steps that are manual and are the hardest to automate, but getting manual validation makes us very confident in what we’re building.
Since real people were paying/using this before the feature was built, we were always aligned behind what to build and what to prioritize.
3. Formal sprints, tools & processes are instrumental (Trello, Slack, etc.)
Once your team is on board on with what to build and why you’re building it, you need to have processes. These are really daunting to put in place at first but are incredibly worth it. We learned this the hard way.
Until not so long ago, we were scoping out what to build on Slack (example below). I would hold a weekly call with a written agenda to discuss what needed to be built, how long it would take, who would build, etc.
This system was horrible for organization, accountability, and only got worse as the app grew in complexity.
Our process today: During Y Combinator earlier this year, I had the privilege of hearing Michael Seibel talk about building product at an early stage startup, which changed everything. That talk is summarized in this post.
Thanks to that and learning from other fellow founders, today we have a very organized system. We have bi-weekly sprints, we intensely use Trello, track our speed over time, hold team members accountable, and more.
Below is a screenshot of our Trello board today — you can see that there are points (the blue numbers) representing the amount of work we’ll do this sprint, individuals assigned to each card, detailed descriptions for each feature and more labels that help us stay organized.
There are also columns like “backlog”, “doing”, “bugs” and more where team members add specific cards as they get work done.
Here are some specific things we did to get here:
- Work in 1–2 week increments (sprints). What you need to build rapidly changes given what you learn about your users, so build iteratively.
- Institute best practices to your sprints. Examples: having your analytics up to date for decision making, leaving proper time for testing, and having one long meeting at the beginning to discuss everything so that everyone is aligned and gets uninterrupted work time throughout.
- Daily standups (10–15 min meetings where each team member says what they worked on yesterday, what they’ll work on today, and what they’re struggling with). Key for accountability.
- I now actively try not to bother my developers mid-sprint with anything non-urgent. It’s also not in your best interest because you want them on a maker’s schedule, as Paul Graham aptly puts it in this amazing essay. Today, unless we have a life/death bug that needs to be solved now, I just add it to Trello in the bugs columns above.
4. If you’re nontechnical and your team is remote, designate a leader
Since I am not in person with my team and I’m not technical enough to gauge what they’re doing, I promoted one of our individual contributors who is more full-stack in nature to a “project leader.”
He is now responsible for measuring our team’s speed and efficiency and has the responsibility of keeping everyone accountable for moving fast and getting things done. It has been a huge help and I painfully learned how necessary this was because after YC, while I was fundraising, no one was leading our team (my fault) and everything product-wise fell off a cliff.
5. Track your speed and improve it over time
I’ve learned that speed is everything with early stage startups. The way we tracked speed used to be very disorganized or nonexistent.
Today, aside from our sprint system, we use something called Scrumble to track our speed over time. Below is a screenshot of our Trello with sprints over time, the number at the top right of each “sprint” is how many points we did.
As you can see — it makes it seem like our speed is diminishing, when in reality we were just bad at estimation. I’ve found estimation only gets better over time with more practice.
6. Get into the weeds and try to lead by example
I have been continually getting incredibly nitpicky about small examples where I feel my team can take more initiative. I think the little things reflect how everyone works on all things.
Example: I recently asked for a text change in the footer of our landing page. As part of our system, I created a Trello card for this, one of our teammates worked on it, and it got done.
Then the week after, I realized that this was fixed in our landing page, but not in our app (i.e. once you log in). This happened many times and with multiple teammates— it looked like no one would take initiative to change both of these at a time unless I told them to.
I knew this was a really small and insignificant change, but I felt it reflected how we work as a team. Instead of creating another Trello card, I messaged them this:
This was me being really frustrated/disappointed. The team felt this too — and they changed behavior almost immediately.
I think nagging about these small examples is key to instilling a sense of ownership and encouraging people to go beyond what is initially asked, because that affects your overall speed over time. If I was actually in the weeds of the code, I would do this with code syntax as well.
7. Try to involve everyone
I try to share our wins, struggles, learnings, and concerns with all team members. It’s awkward at first to do this via Slack or video chat, but it’s well worth it. Remote dynamics can make people feel isolated or excluded, so you have to be conscious about improving that if you want your team to really be on board.
The End
If you have questions, reach out — deepak@thelobby.io. I’m looking for a technical partner to lead and build our tech team in NYC. Read more here.
Svetlana Shevchuk
YouTeam Editorial Team
