The product team
Our product team is 50 people today, including developers, QA engineers and product managers, organized in 4 feature squads, 1 data engineering team and 2 special project teams. We work in Scrum-like agile sprints (2 weeks), using Jira and Github for the development, Jenkins / Travis for continuous integration and Lambdatest for automated testing. In addition to that, we have 3 system reliability engineers and a SaaS operations team of 5 people, running the production infrastructure.
Tech stack
Today, AODocs runs on Google Cloud Platform, on a platform as a service stack: Google App Engine (Java runtime), Cloud Datastore, and Cloud Storage for the main application and BigQuery, Cloud Pub / Sub, Dataflow for data analytics (both for internal usage and customer-facing dashboards). To give just a couple of numbers, we have between 100 and 200 App Engine instances at any given time, and about 120 TB of data (not counting the content of the files our customers manage in AODocs) in the Cloud Datastore. On the front end side, we have a mix of GWT and Angular, and Flutter for the mobile app.
Its core document management functions (document repository, metadata, workflow engine, audit log, etc) are implemented in a backend application that exposes a JSON API. This API is used by all our frontend applications (a web app, a mobile app, a Chrome extension, a Gmail addon, etc.) and to communicate with other modules (also running on Google’s PaaS components) providing advanced features such as importing content from other document repositories (SharePoint, Lotus Notes, CSV, etc), converting documents to PDF, integrating with DocuSign and AdobeSign, and other.
AODocs is also deeply integrated with Google Workspace, in particular with Google accounts and Google Groups (via the Google single sign on flow and the Google Directory API), and with Google Drive (AODocs manages close to 400 million files in its customers’ Google Drive, and makes between 30 and 100 million calls to the Google Drive API every day), and over the years we have built a robust an efficient scheduling system to manage the error retries, API call rates and sharding between accounts to optimize the global performance of the system, in particular in the context of large migrations where we have to ingest millions of files in a short amount of time and apply a lot of access permission changes.
Our challenges
As we continue to grow our business, we have an ambitious roadmap and a number of exciting technical challenges that will be on our next CTO’s agenda, among which:
- To support the growth of the business: after being focused on the Google Workspace market since its inception, AODocs is now available for all customers since January, including the ones who use Microsoft Office 365. This change dramatically increases the size of our addressable market, and it also requires us to learn and integrate with a completely new ecosystem (Microsoft Office 365, Active Directory, Azure, MS Teams, Outlook, SharePoint, Azure AI, etc.)
- To improve our performance and reduce production costs: AODocs relies today exclusively on the Cloud Datastore for its application data, which mixes very different types of data entities, with different life spans, consistency requirements, transaction requirements, etc. This “one size fits all” approach is not optimal. Similarly, all of AODocs code runs today on App Engine, mixing different workloads, from async tasks which take a few milliseconds to complete, to long running jobs that have to be split in multiple pieces to work around the 10 minutes maximum task length in App Engine.
- To be more scalable: today our largest customer manages about 100 million documents in AODocs, and we are in talks with prospects who will have 1 billion or more files to import into our platform. To get to that scale with good performance and in a cost effective way, we have to improve our ingestion API which is too “sequential”, each document being processed separately. This limits our ingestion throughput (how many million documents per hour we can import into AODocs) and keeps our ingestion cost (how much cost is added to our GCP invoice per million documents ingested)
- To improve our search experience: today we rely on builtin search functions provided by the App Engine platform, and on Google Drive’s own search engine. This combination is limited from a functional point of view: no faceted search, no advanced search operators, mediocre response time, no “search as you type” user experience.
- To ship more features faster: we are limited by the current architecture of the code, as the core services of AODocs (document repository, permissions management, metadata, workflow, audit log, etc) are built together in a monolithic Java application, preventing multiple development teams to work in parallel without impacting each other, and increasing the risk of unwanted side effects when adding new features.
- To improve our security: our customers trust AODocs to handle their most sensitive documents, and we have to earn this trust by continually investing in the reliability and security of our platform
- We never, ever interrupted our service for “software maintenance”. Our availability was 99.977% in 2021 with a single incident, where file uploading was broken for about 2 hours, while the rest of the product features were still working fine. We want to preserve this great track record.
- Our security is regularly probed by external penetration testing and yearly SOC2 audits. We plan to get more certifications, like FedRAMP and PCI, allowing us to sell to more regulated markets, and to get there we’ll have to continue to improve our security features and processes
- Security is not just about preventing unauthorized access to customer data: most security issues are caused by human errors and it is our responsibility to help our customers avoid them. Our platform must allow them to easily identify (via our own dashboards or by integrating with their security monitoring tools) the potential configuration errors, and to alert AODocs administrators when they are about to apply a security setting that could result in information being shared too broadly
- Auditability is also a crucial feature of our platform: every user action (admin or end user) must be recorded in a searchable audit log, which sometimes conflicts with our goal of maximizing performance. We have to design our architecture to achieve both.
Responsibilities
- You will lead the technical strategy, and ensure that we make the best technical and architectural decisions, balancing the requirement for reliability and security with the fast innovation we need to continue to grow
- You will define the internal processes, best practices and quality standards which will ensure that the software we produce is reliable, performant and secure
- You will have the final word on the technical design choices, and will be deeply involved in reviewing the technical specifications, and reviewing the code for the most important components
- Security is particularly important for us, and you will be responsible for defining and enforcing, in collaboration with our security officer, secure development practices and processes, and to train the product team on security
- You will be the technical stakeholder in the establishment of the product roadmap.
- You will speak on behalf of the company in front of key customers, prospects and partners when needed to help with large deals or strategic conversations.
- You will report to the CEO
We have offices in Paris and Milan, however the role can be remotely-based anywhere in Europe.