Skipping the Bad Startup Advice

Blackbird Ventures host weekly AMAs over on The Sunrise. Tune in Thursdays from 1pm AEST to take part or sign up to be notified via email.

Chris Hexton I have heard that you use an internal algorithm to transparently measure engineering quality and productivity. If that’s the case, can you share more about how this works and the culture it has created for your team?

Manish Rai Jain I was also unimpressed by how subjective a typical performance cycle is in companies. And, so what we wanted to do was to bring objectivity to performance evaluation. What we do is in essence GTD for teams. We jot down what needs to be done in Asana and assign the tasks to the team members. Then, when the task gets done, that team member is going to give the task a color. Red means the person spent more than 2h of dedicated time doing it, green is less than 30m, and blue is in between. Note that the color does not equal the complexity of the task, which is again subjective. It equals the time taken, which is objective. Then, a script would tally all tasks are done over the last week and assign a score to each team member. We plot that score daily, and over time you have a nice chart which shows how much work was done by each team member.

This system seems easy to break, but it’s very hard. Because all the tasks and their scores are transparent, if some team member decides to cheat the system, that pattern will be detected very quickly in our weekly review of all tasks and by other team members. And even if the task takes more than 2 hours, it would still be red. So, you’re incentivized to find a good way to get the job done, without getting too stuck on it, because there’s no added value.

The culture this system has created is of focusing on tasks being done, as opposed to the time being spent on the tasks. More time spent != more rewards. But, more tasks done is. And most importantly, its fair to everyone. When I need to have a conversation about low performance with a team member, it’s super easy. The member already knows it and expecting it.

Niki Scevak What do companies get wrong in terms of creating an environment for developers to do their best work? What common assumptions are wrong in running a product team?

Manish Rai Jain Middle level management. There’s a saying that most engineers don’t leave companies. They leave their managers. But, it’s also impossible to get rid of them entirely. So, its a tough thing to get right. The concept of bottom-up innovation directly conflicts with the role of a typical manager, which is to pass down and execute orders top down. Also, most managers are not judged on the value that they brought to the people they’re managing. And this is the big flaw that makes good engineers leave.

What I find wrong with the common understanding of a typical product team is that you need someone else to explain to an engineer what’s important and what’s not. Typically these are business folks, that so different from a typical nerd engineer that both these groups find very little in common to bond over. So, engineers tend to detach from the whole client sales cycle, instead just focusing on executing whatever the business guy wants. That’s when the product takes a downturn. This is very easy to fix. Remove the business guy, and bring the engineers who’re spending their life building your product to client meetings. Let them understand and have an influence on how they’re getting paid, and you’ll get a more devoted and effective engineer and hence a better product.

Duncan Anderson what are the top three things you see to keep developers happy at a company? has your view on this changed vs what it was 3 years ago?

Manish Rai Jain Solely talking about great developers. It’s not the money. Money is important, but that’s not what’s going to keep them in the company. It’s not even equity. Again, that’s important, but they’ll jump ships as soon as the first quarter of it vests, typically after a year. What keeps developers happy is the company culture. The feeling of “fairness.” A great developer will willingly get paid lesser if they realize that every one is also getting paid that much. Developers are inherently competitive, and they need to feel like they’re an important part of the company. Also, that they’re working on hard problems.

The thing which I was blind to back in 2013, and see it a lot more at play now, is the language of choice at the company. As a developer, you play with many languages, and so most developers don’t really consider which language is being used at the company, as a factor when joining it. But, after joining it, they start to realize that their favorite language X could do so and so, so much more easily, compared this language Y, which the company is using. And that causes inherent friction between the developer and their team mates, and causes fragmentation of code.

Each new developer would want to write a chunk of code in X, which developers who’ve been using Y for a while now, would not want read or maintain. So, then this developer becomes the only person who can write or understand that chunk of code. That is a problem for the product, long term. It’s a bigger problem than most people realize.

To sum it, I both parties, developer and company, should try to understand how happy they’re going to be writing in Y, before they join the company. And that’s where, a bootcamp comes handy.

Rick Baker How are you finding juggling being a new dad with being a founder? Any tips?

Manish Rai Jain It is hard. I’ve reviewed pull requests from team mates while burping my baby in the other hand. The early weeks are the hardest because you’re barely getting enough sleep, so focusing on any important issues is almost impossible.

I think one thing becomes clear is that if you want to get anything done, you need to delegate effectively. To that effect, hiring an effective assistant has been the single most productive thing I’ve done since I got a baby. Any time you get to work, you seize it like the opportunity of a lifetime. And do a lot of denying. There’s a social gathering you can do without, deny it. Someone wants to meet, let that meeting come to you, instead of you going to it. Lunch? Have it at your desk. Facebook/Instagram/Snapchat — Remove them from life. The only social thing I do is to spend time with family and on Twitter. But, the most important thing, get some exercise. If you’re already cranky and then the baby starts crying at the top of her lungs, you need that extra patience that exercise will get you. All this might sound boring, but being boring is better than being ineffective.

Nick Pelly Do you think transparent equity will become problematic given the pie will naturally be cut smaller and smaller as the company grows? For example, Employee 1 might receive ~1% equity, but an otherwise equivalent employee 100 could be 0.01%. Do you think this can be managed with careful explanation or will transparent equity have a limited lifetime?

Manish Rai Jain I think if it’s very clear even before you join a company, which is the case with transparent equity, then it won’t be a problem. But, to touch the basis of this question, I think the main concern is, equal work does not mean equal pay. That particular issue, everyone is already okay with that. Most engineers would agree that their managers don’t do as much work as they do (tongue-in-cheek), and yet get paid more. The engineers continue to operate effectively. They also know that anyone who joined earlier than them got a higher equity, and stands to gain a lot more than them. They’re okay with that as well. Different times, different risks, different returns.

What they won’t be okay with is, if someone joins at the same time as they did, and yet got either paid higher or got more equity than then — despite both having a similar background — or because their peer had another offer from another company — that is something that would cause conflict. In other terms, engineers look horizontally, not vertically.

So, I honestly think, transparent compensation is for the lifetime of the company. Note that doesn’t mean the formula wouldn’t change, but the concept of transparency around it, that IMHO, would stick.

Rick Baker How are you finding building a software engineering team from Sydney? What are the pros and cons?

Manish Rai Jain Honestly, I’m finding it challenging. I think it’s very easy for good engineers in Australia to move to the US (EB3 visa), and it appears like most do. A lot of them who stay back, are here either because they tend to enjoy the relaxed lifestyle, so they’re happy at Google, getting their nice salary and making US trips. Or, they are doing their startups, because there’s a huge entrepreneurial culture here.

There was a report just yesterday about how Australia, along with the US, UK and Canada are the top 4 countries seeing the largest influx of skilled migrants. Australian tech industry needs to seize that. 70% of engineers in the SF Bay Area are foreigners. I think Australian companies would need to bring in a lot more engineers from overseas, if they’re planning to compete with US based companies, who see a lot more talent coming their way, by having a lot of big players concentrated in the same area. And also see a lot more movement of engineers between companies, which makes it easier for good startups (VC backed) to hire.

I found it very interesting that IIT, India’s top university, which is solely responsible for the majority of Indian engineers and CEOs in the Valley, didn’t have the option to specify salary in AUDs. That goes to show how untapped Indian market is by Australian companies.

The big pro that works for Australia is that the dollar is significantly higher than any Asian currency, and Asians want to move to Australia. The con is that Australian engineers tend to move abroad, and there isn’t a concentration of world-renowned companies in any particular location in Australia yet. So, it’s not a tech magnet yet. And, movement of engineers within the country is a lot limited, which makes it harder for highly tech startups to find engineers who love what they do, and not just doing it to earn a salary.

In essence, my take is that, for every engineer that Australia loses to the US, it needs to bring a foreign engineer to fill that role. In fact, make that two, if you want to take into account smaller population.

Mark: DGraph seems to have been very thoughtful about company culture from an unusually early stage. Can you say a little bit about how you think about it — was it a conscious decision based on past experience, or more something that happened naturally?

Manish Rai Jain It was based on past experiences. I’ve worked in 3 different companies, and have interacted with more. Back at Google, I wondered why such talented people decided to stay back here, and why others leave. And then, another startup I worked for, which seemed very attractive from outside, but had a pretty bad attrition rate. Interestingly, this company also had a very big bias towards secrecy.

With Dgraph, my intent always has been to hire the best talent we can find, and then keep them. Any engineer who has spent a significant chunk of time on Dgraph’s code base, and gotten their head around the strict code review process and quality assurance that we have in place is a major loss to the company. And we know that we can never pay enough. Also, salary shouldn’t be the main factor in keeping an engineer. So, the main pillar on which to base this responsibility, becomes the company culture.

I wanted to build a culture where every major issue that we can’t get right — examples being compensation, promotion, etc., is so transparent, that even if it’s not right, it would be fair. And being treated fairly is what most decent humans want.

Samantha Wong “Fundraising is so hard, and then so easy.” You once said this was so true and that it was hard to pinpoint when fundraising goes over the top of the hill, and becomes a down hill ride. With the passing of time, has it become clearer to you what the catalysts are that make it so much easier? Any tips for first-time fundraisers out there?

Manish Rai Jain I think the tipping point was the network effect. I started off with knowing two people, namely Cliff from Canva and Mark from Pointy. After making that trip to the US, I got to know a bit more and talked to more people, who then talked to more people invisible to me. In fact, my first trip to the US was a zero-result trip. I had no more money after that trip than I did before. But, what continued to happen was that people continued to talk about Dgraph after I was gone. And that network effect is what put me in touch with Bain Capital, who I hadn’t known or met before.

Engineers, or at least I, tend to not socialize any more than I absolutely need to, so the work of good samatarians, who even though themselves decided to not invest, kept on spreading the word, was a huge help.

So, my advice to people raising money, meet VCs, even if you’re going for angel round. You’re going to be in front of VCs eventually anyway, so you might as well get to understand what traction they want to see in your startup before they put in the big money. That would help you shape your startup, and shield it from all the bad advice that’s spilling out of it’s seams in the startup world.

Our AMAs are held every Thursday at 1pm AEST over on The Sunrise. To be notified via email sign up here or follow us on Facebook, Linkedin or Twitter.