Interview by Thomas Peham
June 22, 2016
Photos by Jakob Fröhlich
Susanne Kaiser - an inspiring and ambitious CTO in the German tech scene.
With a degree in Computer Science, and practical experiences in software engineering, Susanne is responsible for the development of the next-generation collaboration software at JUST SOCIAL.
Share this interview:
Thanks so much for your time, Susanne! Could you please tell us a bit about yourself?
Sure, I am Susanne Kaiser - the CTO of Just Software - a startup located in Hamburg, Germany. As the CTO at Just Software I am responsible for the software development of our collaboration solution JUST SOCIAL. I have a background in computer sciences and experience in software development since more than 15 years.
What does a typical day in the life of Susanne Kaiser look like?
I guess there is no such thing as a typical day. My day starts off with an indispensable coffee followed by a standup-meeting with my colleagues to catch up with the current development status.
Everything beyond is pretty dynamic. Currently, I am focused on transforming our monolithic software architecture into microservices - a process which will keep us busy for quite a while.
At some days you can see me attending meetings, workshops and speaking occasionally at conferences. At other days you can watch me putting heads together with my colleagues and digging into heap, thread and tcp dumps tracking down technical issues. At some moments you will notice that I am programming, but these moments of writing code became - unfortunately - very rare.
Designing new ideas with my team, interviewing new potential team members, giving feedback to my colleagues, pitching to investors, talking to customers to seamlessly integrate our solution into their infrastructure are part of my CTO life as well.
Could you give us some insights on the structure of your organization and your development teams?
Our organization is characterized by flat hierarchies, agile processes and continuous changes and progress. It’s currently structured into software development, sales & marketing, product & support, and UX/UI design.
At the very beginning we had only one small full-stack development team. While we evolved, this one team got larger and larger with the downside that everything, such as meetings, discussions and decisions took too long to get things done. In addition, with no explicit code ownership no one felt instantly responsible when e.g. a bug or issue occurred.
The demand for a change was pretty clear after a while, so we divided our one big team into multiple smaller full-stack teams. But just splitting your team into smaller ones does not solve all problems at once. Clear responsibilities have to be shifted and clearly assigned as well. Fortunately, we were about to optimize the user experience of our product by dividing the one big chunk back then into single collaboration apps - each of them taking care of a specific use case. These collaboration apps built the perfect concept to assign distinct responsibilities. For example, JUST DRIVE is handled by one team, while JUST CHAT is developed by another team.
In the sixties, the programmer Melvin Conway stated that the organizational structure has a strong influence on the system we provide - also known as “Conway’s Law”.
After we have split our product into single apps and divided our one big team into smaller ones with well-defined responsibilities the next logical and reasonable step was to split our monolithic software architecture as well. That started our journey of transforming our monolithic software architecture into microservices - which was in our case product and organizational driven.
The next step - from the organizational perspective - is to establish not only full-stack teams each responsible for product specific apps , but also cross-functional, autonomous teams.
Could you share some insights on how you ended up in software development?
My path is not straightforward at all. After finishing school my classmates had a pretty clear understanding of their professional future - except for me. I grew up in a family running their own mechanical engineering business. My parents regularly presented slight hints what positions would be an excellent fit to the family’s business. Even though I was exposed to all kind of machines and was even soldering and welding (quite miserably), my desire for engineering was somehow not ignited. In my ongoing disorientation I picked a traineeship in sales. Well, I must say sales is not my favourite area, but fortunately programming was part of my traineeship as well. I had so much fun creating tiny “software” pieces that my passion for technology ignited. In 1997 (_that_ long time ago?!) I started studying computer sciences. After a decade in software development I still love it.
I love the combination of creativity, technology and team spirit.
It’s fascinating that we can easily create our own product derived from our own ideas by just mingling our brain, laptop and internet connection.
Would you recommend other people interested in software development to study or to get practical experience first?
Last year I’ve been to Silicon Valley for a few months, where I have met a lot of people graduating from coding boot camps, that focus on providing the most relevant technical skillset to become a software developer within 3 to 6 months. After graduating they started their jobs as junior developers. This concept seems to be quite successful.
In general, I would recommend getting as much practical experience as possible. You don’t need to have an university degree to become a software developer.
When talking with other CTOs I have the feeling that there's no standard role definition of a CTO. How do you interpret your role?
My role as a CTO has changed over time, but in general the CTO at our company is involved in technical, organizational and cultural domains. When we started our business, I was mainly focusing on hands-on, building-from-scratch activities such as establishing a development team, workflows, our product’s initial software architecture and its technology stack.
But also establishing a working environment consisting of transparent communication, mutual trust and respect, flat hierarchies was and is still counting to the CTO’s responsibilities, too.
Right now, my role as as a CTO is changing as I’m more outward driven than in the beginning. Representing our business and to be more present as a speaker on tech events is something that I am focusing on more today than before. Especially, when we still see only a few women on tech stages, I am trying to push myself to be more visible to demonstrate that there are women out there having fun in technology.
Are there any great resources out there which you’d recommend other people when pursuing their career as a CTO?
What helped me a lot is to have a fostering environment and network - and to be visible. Attending meetups and conferences as participant and speaker provide great opportunities to get in contact with fantastic people.
Supportive networks - in my case “Hamburg Geekettes” and “Women Who Code” - helped me to “kick my introvert ass” to talk on tech stages. Finding people who are supporting you is an incredible beneficial resource. But also giving back in terms of supporting others is essential for a solid network.
bugtrackers.io is also about tracking bugs. Could you give us some insights on how you handle the topic of testing & bug tracking?
Testing is handled by automated unit tests, integration tests and end-to-end tests as part of our continuous integration & delivery pipeline - followed by manual testing. Since with microservices we are now dealing with a lot more APIs than before we need to guarantee that we are not introducing unknowingly breaking changes. To quickly identify breaking changes of our APIs we are going into the direction of consumer-driven-contract tests as well.
From a tools perspective we use JIRA from Atlassian for bug tracking and user stories. JIRA is deeply integrated into our workflows. When a bug has been reported it will be prioritized and shifted to the backlog from where the developer picks the next bug to be fixed. In this case the ticket will be marked as being “in progress”. As soon as a developer is pushing his code changes into the git source code repository the code review process and automated test chain get triggered. The related JIRA ticket gets automatically updated reflecting the current status. When the code review has been completed and submitted the ticket status will switch to “testable” after the continuous integration & delivery pipeline has automatically deployed a new version to the test environment. As soon as all tests were successful the ticket status will be changed to “done”.
What's your biggest challenge when it comes to testing?
Well, to be honest: The ratio of unit tests, integration tests, end-to-end tests and manual tests does not look like a well-formed test pyramid. We still do too much testing manually - a very time consuming process.
We are facing the big challenge of replacing the majority of manual tests with automated tests.
Another task on our todo-list for testing is to push the consumer-driven-contract tests.
Is there any project or tool out there which you would like to explore more?
Since we are in the middle of transforming our monolith to microservices, I’d like to explore more tools in this area. We are going to focus on tools related to design for failure (e.g. Hystrix as circuit breaker), monitoring of server and service metrics (e.g. Graphite) and logging across service boundaries (e.g. the ELK stack, consisting of Elastic Search, Logstash and Kibana).
Is there any advice you would give your 14-year-old self?
Life is not plannable and whatever happens is not predictable. Simply be open to everything that could happen in your life.
Stay open-minded and curious. And if something is bothering you, change it. The “next time” I would cut my detour into sales a little shorter. However, it taught me to figure out, what I do not want.
What do you think will be the next major trends in software development in the next 12 months?
I guess serverless architecture will become more important in the next few months. Managing servers with physical capacities and limits will become irrelevant - instead code execution as a service or rather “function as a service” is emerging (see AWS Lambda).