One of the things I’ve always been passionate about is building a team from scratch. When I look back on my career the most fun I’ve had is assembling wonderful groups of people together and building something amazing. When the opportunity to join Oneiro and run ndev came, one of the most compelling reasons for me to join was that I’d have the opportunity to do that again. After a year of working on this, I can honestly say, the ndev team is the best team I’ve ever worked with.
When you build a team from scratch you obviously need to think about a lot of different things and identify the type of culture you are hoping to build. However, I try very hard to not hire a bunch of people that are very similar. You need diversity. Diversity of strengths creates a stronger team.
There were only two traits that we required from everyone we hired:
One, they had to be critical thinkers. Critical thinkers tend to be problem solvers. And for this project, we need problem solvers. The ndau protocol is complex and many of the technical challenges we faced required creative problem solving.
The second thing we required of all hires was they had to have an open mind. What I mean by that is people that have strong opinions about how to do their work, but those opinions are loosely held. They are willing to look at new data and change their minds about things as new data presents itself. That’s an aspect that is shared not only on the ndev team, but everyone involved in the ndau project. This concept of seeking the the right answer (despite preconceived beliefs) is definitely a guiding principle for ndau.
Something I’ve spent a lot of time thinking about is how the CTO role and VPE roles interact and collaborate. Sometimes there’s little difference between the two, sometimes it’s hierarchical, often times its contentious. I’ve often come across people that can play both roles. When I started ndev I knew I had to have a VPE rockstar that could solve a series of difficult technical challenges, all with production quality code, lasting design and FAST. I don’t mean fast as in the code runs fast, I mean a prolific developer cranking out a lot of code, that could also lead a team and put out fires. That’s why my first hire was our VPE, Kent. No one fits that bill better than him. Kent’s one of those rare individuals who’s good at thinking at scale, but also in the weeds. His designs tend to be simple at the detail level but able to solve complex problems at scale. He can architect, design and code with the best. He can contribute at any layer of the stack. He sees solutions before people are finished explaining the problem.
With a VPE in hand, I turned my attention to figuring out exactly what we needed to build. Essentially, ndev’s job is to take the vision set forth by the ndau collective and the Blockchain Policy Council and make it real. We were given a lot of great guidance in the form of the ndau white paper, guiding principles, and specific deficiencies in other digital currencies that we wanted to address. The job of understanding what the ndau collective and the BPC gave us and turn that into technical specifications for the desired capabilities started to take the shape of the CTO role. We needed someone that had deep tech chops, but also could think system design, but also someone that understood how to design incentives into a system to align the behaviors we wanted. In stepped Ed. Ed used to run the Lotus Spreadsheet engineering team… back when 1-2-3 was king and Excel was trying to catch-up. Ed was the CTO & VPE at One Laptop Per Child. Ed also designed the contests at XPrize. XPrize is a non-profit that “creates incentive competitions to entice the crowd to take action, and bring us closer to a world of Abundance. The solutions to the world’s problems.” Sounds perfect right? I have to admit that I’ve known Ed for about 40 years, and when I first started to realize what we needed for a CTO, Ed was literally the first person I thought of.
I won’t bore you by going through each team member, but I can tell you it’s an amazing assembly of talent. Besides critical thinkers and open minded individuals, we also looked for people that got shit done. Like most start-up, timing is critical. Oneiro, being a traditional VC-backed start-up, we’re not sitting on millions from an ICO. We’re using an A-round to build an amazing product. But time is money and we had to move quickly. Therefore, we needed people that knew how to ship products. Every person on the team is willing to put aside their ego for the sake of the product. The best ideas win. What I’ve found is that a smart, egoless team, that’s building off a good foundation can solve almost any problem they run into. In past projects I’ve been part of, there was at least one (usually several) technological challenges that hit us along the way that dropped our momentum like a 2×4 to the head. I’ve been blown away by how many times I’ve seen our team encounter these, and as I brace for a multi-week hit to the schedule, hours later someone comes into my office and says, “we figured it out.” Usually figuring it out entails members of the team talking out the problem until a simple solution starts to form. And then they work on that iteratively until the solution is obvious, the code base is left better and simpler than it started. I cannot tell you how rare that is. Often solutions to these problems tend to add complexity to the system, not make it simpler.
Lessons Learned from ndev
As we got close to announcing ndau, one of the things I thought would be fun would be to ask the team the biggest lessons learned from the project so far. Realize that for many on the team, this was their first exposure to blockchain. Here’s what I got:
- Don’t sit in your ivory tower trying to figure everything out ahead of time. Be Agile.
- Much that we’ve done looks simple but has major complexity in the design process. We’ve learned a lot of ways to not make a lightbulb.
- Learn from what has worked in the past, especially in other disciplines.
- Identify hidden problems that have not been solved for so long that they are currently being ignored or accepted as “just the way things must be.”
- Blockchains are immutable. That makes traditional “build and iterate” tricky. We’ve been able to abstract out some of the variables that the BPC may want to change. But blockchain development requires more upfront and complete thinking than web app dev.
- Read, but don’t try to read everything. Stay up to speed with what’s happening but don’t get paralyzed. There’s just an awful lot of amazing things happening in the space.
- Know what problem you are trying to solve. Don’t try to solve the other ones.
- Know who your customers are and build for them. Meaning, we’re very early in digital currency. We don’t need to build for the mainstream right now.
- Momentum is more important than being right. Move, even in the wrong direction, and then course correct.
- Be open to feedback
Chris Quirk, CEO, ndev
