What I Learned in Year One
A little over a year ago I wrote that I’d started a company. As with most start-ups, the ideas had been forming for a long time prior to that, but now there was enough certainty about the core technology to make it official. And, as with most start-ups, as soon as we got going building a team and first product, we learned a lot about what we should actually be doing.
I’ve been involved in enough early-stage work that this wasn’t surprising. If you’re building something new to solve for unique challenges (which we’re doing in spades) you should define the smallest possible solution, use that to go ask questions, and learn how to grow. The process is iterative, and works well when you can take that kernel of an idea as running code into big companies and use that to connect to real-world need. If you haven’t watched Guy Steele’s talk on Growing A Language, stop reading this post and go watch it now.
What has been surprising is just how much I’ve learned about the nature of corporate leadership, and the challenges they face in scaling their businesses. I thought I’d share a little about this, how it’s influenced what we’ve built, and where it’s pushing our core technology in year two. But first, I’ll tell you why we’re building what we’re building.
Motivation for the Company
Tranquil Data came out of the observation that as companies are transforming to get more value out of data, there’s an underlying question about whether that data is being used as-intended. This isn’t about security, and it’s not compliance per se. It’s really about needing to understanding that business requirements are aligned with technical execution.
Data doesn’t exist in a vacuum. Companies have business opportunities around building products and partnerships, which means taking on customer or partner data, so Master Service Agreements are written. Those agreements speak to what the company can do with data, and what protections the company will guarantee. Applications and services are then built, which are supposed to enforce those guarantees, and which store data that is subject to the agreements. What companies need to understand is if the initial, or any additional applications or users are adhering to agreements, and what the business context is of the data sitting in one or more databases.
When we started the company, I was pretty sure this meant we should do two things. The first was to build software, transparent to developers, that made business rules operational. The transparency part is important to make adoption simple, and to focus on accelerating development by taking away complexity. Developers today lose time talking with lawyers about whether code supports common concepts like user-isolation, so we knew that if we could take the burden off coders and turn it into something like an external policy, we’d make engineering teams more effective and happier. So, we started by building software that proxies databases, speaking wire protocols and requiring no changes for applications.
The second focus was on creating a new meta-data model about data. Since our software was in the stream of database commands we knew enough about what was happening, without having to see code or structure, to build that model in real-time. That fills in the business context of data. We modeled this as a graph, and since our earliest ideas this graph has been about lineage, connectivity of data across users and databases, and a way to connect this view of lifecycle to the facets that are called out in service agreements. We knew a few pointed questions we wanted to answer with that new data-set, but at the start we didn’t dig deeply into what it could tell us.
What have we learned?
My co-founder and I had independently observed an underlying concern. We believed there were a few pieces of technology needed to accelerate developers and surface confidence that systems are “on the rails.” We also believed that surfacing confidence was important to helping companies build new products and partnerships, move to new verticals or geographies, acquire new teams, etc. As we took those core technology ideas and turned them into a first product, we started learning a lot about the stakeholders, and the underlying challenge.
Internal Alignment and External Business Value
Above all, we learned that the opportunity comes down to alignment. We knew that pulling rules out of code and into policy was about visibility for compliance and business roles, but we didn’t appreciate how leadership alignment is as much of a challenge for technology transformation and adoption as are the understanding systems. Revenue and Marketing Officers are much stakeholders in data as are Compliance and Product Officers, but they each have a different perspective and understand different pieces of the challenge. What we’ve learned is that while we’re building a product for a VP of Engineering, it’s the CEO who really needs to get her team aligned to get past the technology discussions and focus on what opportunities are best for the company.
If you want to create alignment, then you need solutions that are proactive. Again, we knew that the technology needed to be proactive, which is why we put it in the path of data, but we’ve learned that this holds for the project lifecycle too. There’s tangible, quantifiable value (below) if a leadership team learns early in the development of a new product exactly how that technology meets business requirements. Tranquil Data is designed to go into production and solve hard segmentation and contextualization challenges at-scale, but what we didn’t understand when we started is that simply dropping our software into integration tests can surface knowledge that helps all stakeholders get on the same page.
To that end, we’re now building something we were 100-percent certain we wouldn’t do as a core piece of the product: a visual front-end. Even though the product is designed for software engineers to use in test and for operators to use in production, the UI we’re building is really for Compliance or Legal roles. It lays out authoring in a manner that’s familiar to anyone working with MSAs, and streamlines the hand-off between stakeholders who need to collaborate to get rules into running code. We’re shifting the responsibility of writing and maintaining those rules from development to compliance. This lets developers focus on applications and picking the right technologies, and gives the business stakeholders real confidence about exactly what applications are doing with customer or partner data.
We knew that Tranquil was going to be a powerful tool for developers to validate their code in test before moving to an enforcement role in production. Quantifying that value, however, was challenging. When we figured out that we should be giving compliance roles ownership of writing the rules, and that this was in-aid of aligning stakeholders, the final piece fell. It takes 30 minutes to drop Tranquil into a software team’s integration tests, and from running those tests we surface tiny ground-truth about common requirements like whether customer data is being unambiguously identified, or whether each customer is being isolated. That’s critical knowledge for development teams to run faster, but it’s also certainty that accelerates your next RFP, that goes onto your website, that informs diligence processes, and is the starting-point for aligning each line of business relationship.
Representation and Discovery
On the tech side, most of what we laid out for year 1 has been surprisingly unsurprising. We knew what the core construction should look like, and that’s been solid. We picked Golang mostly to accelerate our processes and give us a broad range of projects in the community to draw from, and that’s worked out well. The few patents we’ve worked on have been in the spaces where we expected to be building novel constructions. There’s been some re-writes of internal components as we’ve learned more about how the architecture of the codebase holds together, but that’s all pretty normal for enterprise software development.
The biggest surprise (which, in retrospect, should not have been a surprise at all) had to do with the context graph. Originally, we assumed that it would be an internal artifact, something designed to address our immediate needs and nothing else. To accelerate development we bootstrapped with Neo4j, which meant that we could show visualizations of the context model to early testers. Everyone we demoed to asked if they could have access to the graph. What we came to understand is that anyone who cares about meeting intention probably also cares about lineage and lifecycle of data. Long-term, we’ve now come to understand that this graph is a resource for our customers to identify patterns in their systems, watch for outlier behavior, and identify new business opportunities.
We also, purposefully, started with an expression model that would get us started, but wasn’t going to be long-term. We chose something simple, both for our Domain Specific Language and for the graph representation, to get product and partner discussions moving. It has the core concepts and semantics that we want, and gave us just enough to prove out the product end-to-end and start learning what we actually wanted to build. This decision worked well, and what we’ve learned in year 1 is now being applied to our future expression model. Specifically, feedback on how prospects would use our graph model, and on the specific business use-cases that matter from domains like GRPR/CCPA, PCI, 27001, etc., is getting folded into how we build a graph at scale, what its data model looks like, how rules are expressed around that model, and how this model is used to prove something about the construction of a Tranquil service at-scale and over time. We’re pretty excited about this.
On to Year Two
Bottom-line, I’m really happy both with what we built and what we learned in year one, and couldn’t be prouder of the team that got us there. As with all start-ups, it’s as much about being open to what you don’t know as it is running with conviction at the heart of what you know you must build. As we near a first version of the product, and start to focus on what will define v2 with a small number of development partners, it’s satisfying to be doing that with a solid core of experience. If you’re in the midst of transforming your organization, and you recognize the challenges I’ve described working with your peers on the leadership team, I’d love to talk with you, and tell you all about what we’re doing going forward!