Dimitar Ouzounov, CTO At Documaster: A Strong Engineering Team Requires People Who Find Meaning In What They Do
Our guest today is Dimitar Ouzounov, the CTO of the fast-growing document management startup Documaster. While headquartered in Norway, the company has a core development team of over 50 people here in Sofia. In the six years since its inception, Documaster has helped over 200 public sector organizations improve the way they preserve and reuse documents.
Dimitar shares insights on many different topics – why’s the work on document management technology so exciting, and also what does it mean to develop products for the public administration and now that Documaster has entered the private sector – how is that different.
We also talk about Documaster’s technology strategy and what in Dimitar’s opinion are the fundamentals of strong engineering teams. And, of course, how he went about building one at Documaster.
Trending Topics: What’s the thing that excites you the most about document management? You’ve been working in this field for nearly a decade now.
Dimitar Ouzounov: Yeah, I’ve been working in the field of document management and records management for quite a few years now. I am not sure how many people realize this but the work of many organizations out there is based on documents – legal documents, reports, pictures, videos and this goes with many challenges. How to store electronic documents without much hassle but in a way that’s easy to retrieve them afterwards? If it’s too difficult for people to store a document in a system, they won’t store it and find it afterwards. Another thing which is an interesting question: How do you find the definitive version of a document? I think many people have something like this on their computers: “Final report_version 1”, “Final report_version 2,” “Final report_version 3”. Obviously, this doesn’t work very well so you need to be able to find the actual definitive version of a report. It’s also an interesting question – how to dispose of documents because you no longer need them or because you’re required by law (in the EU, a certain type of documents have to be deleted after a certain amount of years). Also, how do you preserve the organization’s most important documents so that they bring value in the future, not only now? How do you manage access to sensitive documents? For public sector organizations, this is really interesting – how do you publish your documents and thus increase the transparency of your organization? I know it’s not a big thing in Bulgaria but in Scandinavia, citizens love all public sector organizations publishing their documents, making them available online so anybody can search them. Mostly, journalists.
So, all these questions don’t have clear answers. The thing that really intrigues me to this day is that we keep looking for solutions, we keep researching, we keep experimenting and I still don’t feel like we have all the answers. And, I think we have a lot of work ahead of us and this is what makes me really ‘live’ document management and records management and that we can add value not only in Norway or Bulgaria but on a global scale.
How do you go about building the technical strategy of a fast-growing startup like Documaster? Over the years, what were some of the unforeseen challenges in scaling a public-sector-focused SaaS application?
Let me start with the stack. Most of us at the company have a very strong background with Linux and open source technologies. So, it’s not surprising that our tech stack has been build around the people and around what they know best – and this is open source. We have always tried to select technologies that may not be extremely popular at the time but, which our research shows, are production-ready and able to solve our particular needs.
We actually ended up building our own cloud in Norway and Sweden. This was done partly because of legal requirements for public sector institutions in Scandinavia – for the data to be inside the borders of the country but also because public clouds didn’t really satisfy all of our requirements.
When it comes to challenges, we wanted to build a SaaS application from the very beginning. What we saw is that..okay, we have our own cloud, we started getting our first customers..but there’s still lots of old-school thinking in Scandinavia. There are institutions that have their own IT department, their own server rooms and they believe they can do a very good job at hosting their own software. We started getting our cloud customers but gradually we also got some on-premises customers who got our software and installed it on premises. It took us a lot of time to convince them that it’s actually best for them if they run our software in our cloud – there are many reasons for that. We have a really nice monitoring solution, we have strategy and mechanisms for taking backups, we can guarantee a certain uptime. We also offered some other features – a secure cloud where they have site-to-site VPN and they can run their application basically as a service but on dedicated hardware.
I actually think we were the first company to offer such a cloud service in Norway and to scale really well with it. All the companies are in this on-premises business where they sell the software and it gets installed. I really like that over time we managed to convince most of our on-premises customers to move to the cloud – this is a great achievement for us.
Another thing I’ve been seeing lately, which I couldn’t see a year ago, is that we were trying to move our MS-Office add-ins from the native desktop application to the web add-ins technology Microsoft offers. Even though this technology is very good, we see that Microsoft occasionally breaks things – for example, APIs, things stop working and we have to adapt to this situation. I am looking forward to six months from now when this technology will be more stable and we will be able to offer a lot more features than with our native desktop applications.
Now you’re also starting to provide an offering oriented to businesses. Is the development of a product for the corporate sector different from that for public institutions and how?
It may sound a little bit surprising but our public and private sector products use the same back-end but the user interface is different. End users really vary between the public and private sector, even though the product serves roughly the same purpose.
Today, the state of development of our private sector product is in the state where we were with our public sector product several years ago. This is really challenging for some of us because we have to go back almost to square one with a new product.
The good thing about going back to square one is that you actually get to reinvent some old concepts and you try not to repeat old mistakes. And with the new product, we experiment a lot – we added new technologies, we are doing more frequent releases than in the public sector and we basically adapt the development process as we go.
Over the last year, we realized that what works for a mature product doesn’t necessarily work that well for a brand new product. I am actually curious whether when our private sector product matures our development processes will be pretty much the same or there will be differences.
Can you share a bit about what’s on the long-term technical/ product roadmap for Documaster? And did your planning process change given the coronavirus outbreak?
The coronavirus situation did change many things in our lives – to say otherwise, it’d be weird. But the funny thing is that we’ve been getting quite a lot of new business.
I can say that we are really certain about what direction we are taking, where we are heading from this point on. At the end of last year, we got our first private sector customer and it’s actually our biggest customer as a company. In the public sector, we are releasing a look-up portal that will allow public sector organizations to publish their documents and metadata, making them available to citizens. We are also working on a brand new user interface for the public sector product.
Finally, over the past few years we developed a niche product – we as a company don’t talk a lot about it – it helps archiving institutions preserve relational databases in the long-term. It’s not something anybody could use. But we’ve been getting quite a lot of traction now in Norway and we are thinking about expanding that product’s customer base in other European countries.
How is being the CTO of Documaster different now compared to when you started? How did your responsibilities and mindset evolve?
I am a developer by heart. Let me start by saying that. I started coding when I was in school and I was what you’d call a ‘geek’. I don’t consider myself a geek now but a lot of people are still saying that I am.
When I went to university I realized that technology is pointless unless it solves actual problems. I still remember when I got this textbook, one of the few textbooks I bought because they were really expensive. There was a forward by Bjarne Stroustrup, the creator of the C++ programming language. It said: “Don’t study computer science for the sake of being a programmer, study computer science to solve problems.”
Then I realized that to solve problems you have to understand the people whose problems you’re solving. Just coding doesn’t do you any good. You have to understand what kind of problem you’re solving, you have to be able to talk to the people whose problem you’re trying to solve. I quickly figured out that to be able to do that you require a slightly different set of skills from pure programming skills and I focused on acquiring those for some time.
When it comes to Documaster, my responsibilities have changed every single year. I don’t think I had two consecutive years where I was doing the same thing.
It all started with me doing coding with my only colleague at the time, Frode. But I was also talking to potential customers, talking to investors, participating in sales meetings. Next, I had to help open our office in Bulgaria and to help with recruitment, while still coding.
These days I am not longer coding, not because I don’t want to but because I don’t have the time. I feel like I can help more by doing high-level things and focusing on things like architecture, development processes, and the overall well-being of the company.
What are the fundamentals of building a strong engineering team and that you always kept in mind as a leader of the technical side of Documaster?
I will try to describe what a strong engineering team is, the thing we are imagining at Documaster, and that I have always thought of a strong engineering team. First, you need to have people who find meaning in what they do. They need to be free to share their opinion and participate in making important technical decisions. It’s very important for everybody to have a voice and to be able to propose a technical solution. Then, we can all gather and make the decision.
I also think that it is very important for people to be able to follow their passion. When I say that, it could actually mean very different things to different people. Some people want to be hardcore developers, some want to work with architecture, others want to organize the work in the team. Others want to talk to external parties. I believe that in a strong engineering team you allow people to follow their interests.
Not everyone can thrive in such a team. We, at Documaster, take the time to find the right people. We never do ‘mass-hiring’.
Recruitment is a part of the game: here is what we do to find the right people. For start, I am not really interested in whether a job candidate is a senior or a junior, or infrastructure engineer or a QA. I don’t get impressed easily by CVs or diplomas. We have a technical task that’s specifically crafted for each job position. And, it’s quite likely that if you provide a good solution to the task, you will do well on the job.
I’ve seen some marvelous solutions by people coming straight out of university and I’ve seen people with 15 years of experience doing not so well. I must say it’s all about attitude – if you have the right attitude that really helps.
Apart from the technical skills, there are three qualities that I really value in my colleagues and workplace, and in life. First, you have to be motivated by what you do. If you have the right motivation even if you lack some skills, you will acquire those skills.
The next thing is to respect your colleagues. You may be the best technical person, but there may be another one who is more experienced as a person. You can always learn from your colleagues and you should always respect them – and they will respect you.
Finally, you always have to try to help your colleagues. What I often see in our team is that if you get asked by a colleague, even if you’re doing something very important – you always help. It is really useful to promote the sharing of knowledge within the company.
You’re also an adjunct instructor professor at the American University in Bulgaria. What advice would you give to young software engineers, the ones at the very beginning of their programming careers?
Yeah, I’ve been teaching short courses at AUBG for some time now. I’ve been teaching a Java development course and a DevOps course.
The reason I decided to do that is very simple – I really wanted to share with students the things nobody shared with me when I was a student. I still remember the time when I got out of university, did my internship, and realized how much I didn’t know. It would have been so great if somebody had just told me: “Okay, learn this and be aware of this and that.”
My first job was a very nice experience, I learned a lot but it was very painful in the first month – I was even questioning whether I should be a developer.
That’s why I am trying to pinpoint topics students should be aware of when they get out of university.
So, one thing I tell everybody is that to be able to write great code, you have to debug and read tons of other people’s codes. It’s pretty much like writing an article or an essay. You cannot write a good one unless you read many books before that.
Another thing that I’ve been stressing is that being a software engineer is not just about writing code. It’s about writing good documentation. It’s about communicating well within your team and company. It’s about being able to describe your ideas clearly even to non-technical people.
And, of course, I always talk to my students about the three qualities I value in my colleagues – I tell them the importance of motivation, why it’s important to respect others and I tell them why it’s important to help others.
