CTO Talks: Dmitriy Stepanov and John Bentley

I am a Chief Product Officer (CPO) at 10XTS. My original occupation was Chief Technology Officer, but as my focus shifted to product management and product definition, I converted to being CPO. The person from my team was promoted to a CTO role, which was quite exciting.

I worked with a variety of other startups, advising as a CTO. I started this 47 years ago, learning to program on a TRS 80-color computer attached to a TV. My dad taught me how to program. So I'm a lifelong programmer. It was handed down from parent to child.

10XTS is, like many names now, just something that's made up. We designed it to be hard to say because it takes a while to get used to it. But what we're working with is this: about six years ago, we came together to do something on blockchain that many people needed to be talking about then and still need to talk about now.

Blockchain is about being able to settle regulated securities and trade them.

This is mirroring the world of more traditional financial instruments and combining it with blockchain and decentralization, so we can make it more cost-effective.

If you have a startup, and you want to achieve an exit, a lot of times you have to be acquired. And the cost of going public was very high. Smaller things are available for trading, but they're not very viable.

We provide the tools that help issuers record the ownership over time.

We have our first client who has filed a regulation, security, and SCC process to be approved. And once that's done, we'll have the first native stock that will be trading on a blockchain.

I started describing myself as a crypto heretic, and I described it a little tongue-in-cheek. But with the things like Bitcoin and Ethereum, these networks have value, and that value is represented by their coin.

So a Bitcoin or Ethereum is the gas or the fees you pay to use the network, but the value beyond that is very much speculation.

So I was just at a conference telling people that I don't own Bitcoin or any crypto, and I don't believe in the pure evaluation of it because a core blockchain network, many of them, can only do two things. All you can do is, you can sign a transaction and pay for it, or you can transfer funds. Everything else is built on top.

So you have to ask yourself, is the volume of network activity that's going on in those blockchains worth $40,000 a Bitcoin?

That's why I think you see the variance go up and down. So I think there's a place for crypto assets, and I think there are a lot of places for new financial instruments. But I have a lot of healthy skepticism.

Making any decisions or planning in this area is very tough.

Gold is a commodity, it's used to stabilize, but its value beyond utility is largely based upon the premium we put on it. So Bitcoin arguably can be the same thing. You start separating the value of the token from the value of the utility. I separate that from the financial speculation and investing side.

Right now, we're under 10. We do have a few skilled players now. We haven't quite got to the point where we split the front end and back end, or different modules of the product, so we're still mixing about. But we have separated scrum management, a scrum master, and DevOps from the development.

So we're starting to be able to scale the team. The next step will actually be dividing a little more in the front-end and back-end, just to allow more focus.

But really, for us, we have an application, we have a core technology we just call XTS. That's our core blockchain services and things we build on top of the blockchain. And then our application we call X Desks. So we'll start dividing the team between those in our next stage of scale.

Just like I'm a crypto heretic, I believe in the full-stack developer to a certain point. So I will tell you I'm a full-stack developer. And what does that mean?

What it actually means is that this is a self-assessment, but I'm recognized for knowing how to build endpoints, how to integrate with APIs, and how to work with databases. Those are my strengths.

I can build a UI. I have a long history in user interface development, but I'm better at constructing the UI, the form, and things like that. When it comes to the UX design and the more visible pieces, while I can do them, it probably takes me twice as long as someone more skilled in it.

Conway's Law states that your organization and your products really reflect your communication structures. So do your processes.

The challenge right now we have with a smaller team is that we're building components that are part of an application that sits on top of a platform core. But it's asking a lot of a team to scale.

So if you really want your components to get to what I call our current evolution. We can build a spec if you really want to define open API guides to your services for your endpoints and things like that or decompose your UI into crisp components that could be reused in different ways, which requires having a group of people focused on that aspect of the application.

If you go from two people to eight people, which is what we did at this location, and they're all full stack developers building everything just adding onto the code base, you get a more tightly coupled system over time.

It gets very hard to do any kind of independent build. If you've got to start off with the web app, and you want to add mobile, if the services only meet the needs of that web app and there's not a good separation between them, it's much harder to build a mobile app using the same services. That's where the separation becomes very important.

We're full stack because we don't have enough capacity to split yet. We already have people that take the lead on the X Desk front side and people that take the lead on the X Desk back. So we're beginning the centers of concentration, and as we bring on the next folks, we will go from one team to two subteams because we'll have enough capacity for the work to be divided.

Yeah, we're in a growth mode again. Last year rather than bring on any more developers, we decided to bring on a scrum master in DevOps, so that we could start separating those responsibilities from the developers. It was the problem of getting code written and the issue of the environment. They have to go off the code to come back, and you have that changeover cost.

We honestly weren't that good at running Scrum by ourselves because, from my experience, when you're working on the actual production of things driven by a process, it is very hard to also manage the process. You tend to favor one over the other, and typically you favor building the product. So you don't have a lot of discipline.

We used to run sprints on a two-day basis, two days of conversation to lay out the work, and then we'd have the next two days. Since bringing those people on, we've created a more scalable structure.

So as we're bringing the new people in, it'll be much easier to start creating these subteams and helping the product as we're transitioning from MVP to a baseline product, which is also going on. We'll be able to get people in areas of focus.

What's interesting about growth is our CTO is still writing beta code. So as we start looking at growing, the first thing we'll be doing is bringing somebody on to take over his coding capacity.

We're always looking at a six-month lag. We figure it can take up to three months in the worst case. Up to three months to find somebody and bring them on, and then three months for them to become truly professional on the team, adjusted, and everything. So first we're replacing that capacity for someone to bring other people aboard.

I think it's easier for the younger members of my team, who have done more interaction online. I was on bulletin board systems, dial-ups and AOL, so I've been communicating online, but I like to have a whiteboard behind me. I sometimes draw notes for myself.

I miss having a group of people in a room on a whiteboard. But we've gotten pretty good at using the lucid sketch to do the same thing and draw quick diagrams and go back and forth with each other. So we've adapted very well.

I think people overemphasize in-office types of interactions. One of the things we do is we use Slack as a group tool, and we have a channel open that we call Chatter, which is just for water cooler type of talk.

Covid-19 brought it out to understand what works well remotely versus in person. I think the error in remote work is the idea that we're just going to save all that money on rent. Instead, you need to look at the money you're spending on facilities. And, look at how you make sure that your staff is properly equipped.

We're unusual. It is where I think the pandemic impacted a lot of startups. We just had to keep going at a steady pace, so we had two years of non-growth before we could go and pick up a few more team members.

That was a real challenge because we've been at this early stage a little longer than you'd want to be. It means you're doing too many jobs, and it does present challenges.

I've passed the age of learning. I'm still learning, but I'm at the age of wisdom when you have to start throwing a lot of stuff away.

I'm trying to get rid of many preconceptions, find principles, and be very open to what newer folks in the industry bring, look at them with fresh eyes.

I can marry it with the experience of the past but only bring forward the things again with purpose, not out of habit.

Some general thoughts, maybe. One of the things, as people are looking at blockchain in this newer technology that we're discovering, is an old lesson that we keep relearning in the industry. Standards and interfacing are very critical to making things scale.

So as much as everybody's fascinated by Merkel trees and cryptography, the Ethereum standard process, the ERC 20, which defines a token, and then the one for NFT, those standards do more to make the applications work than anything else.

That's why one of the key pieces of our strategy is not proprietary technology but creating an open standard. Once we write a smart contract that settles a token on a chain, everyone can read it because that's the only way it's secure.

So we're under no delusions that we can keep it a secret, but keeping more of that mindset. I'm not a fan of software patterns. I think we're better off working on open standards or working together when we bring that approach to the extent it makes sense again for our investors at 10XTS.

We even have an idea for our security authorization system. We have hopes to turn it into an open-source project. Because we think that application authorization is still too much replication, we have some ideas on how to extend some emerging standards on the resource side into the application space that we're excited about.