Meet the CTO is a new series about CTOs, their daily lives, roles, and responsibilities. In our second edition, we talk to Susanne Kaiser from Just Social.
[otw_is sidebar=otw-sidebar-1]
What does a typical day look like for you?
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 focusing with my team 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.
How are your dev teams structured?
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, 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 back then 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 automatically. Along with it responsibilities has 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, e.g. 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 an organizational perspective – is to establish not only full-stack teams each responsible for product specific apps, but also cross-functional, autonomous teams.
What got you interested 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 nonsense “software” pieces that my passion for technology ignited. In 1997 I started studying computer sciences and have dedicated now more than a decade to software development – and 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.
[otw_is sidebar=otw-sidebar-2]
Would you recommend to other people interested in software development to go to college 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-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 definition if a CTO. How do you interpret your role as a CTO in your company?
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.
How do you handle 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”.
[otw_is sidebar=otw-sidebar-3]
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 tess 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 to replace the majority of them 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. So, 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 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).
[otw_is sidebar=otw-sidebar-4]
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.
