Interview by Thomas Peham
March 26, 2015
Photos by Codeship
Florian Motlik - from Vienna to Boston.
The success story of Florian began in his early study life when founding his first startup with other college students.
Even eariler he got into technology, while being fascinated by building things at high school.
Share this interview:
Thanks Florian for your time. Can you please describe yourself.
I'm the CTO here at Codeship. Codeship is a continuous delivery service, so we test and deploy code for thousands of companies. I'm from Vienna and I studied Software Engineering at the Vienna University of Technology, and founded the company at the end of 2010 with two friends, Manni and Mo. We're now about 18 full-time people, and have been growing for quite a bit over the last 6 to 9 months. In terms of the team and are working on a lot of new and exciting things.
Codeship is a hosted Continuous Integration and Continuous Delivery service.
How does a typical day in the life of Florian Motlik look like?
Different than before. I think when the team size changed, my role changed more into a managers role now. In the morning I'd get up and just answer emails for like most of the day. Then it depends on what the specific tasks of the current day are. That can be that I'm writing a blog post, I'm talking to companies about new products, or being at a conference. It’s a wide variety of things. My job is currently very wide in what has to be done.
You studied at University of Technology in Vienna, could you share some lessons learned during your study time?
I think that the most important thing was definitely starting to build a network at University, because basically you have so much time. You’ll never have that amount of time again. Especially when you start a company, you never have the time to build that network again. I founded the Java Student User Group there, which helped me with a lot of contacts to developers. Then I founded STARTeurope with a couple other people, which is now the Pioneers Festival.
I did a lot of networking in the startup and tech scene here, in Europe, relatively early which really helped me later on.
I think that in university, getting these things that are really important for your career. Making sure that you start building that network and that group of people that you're going to work with for a long time is really key. Because most of the people that I've worked and I’m working now with, are people that I've known either since my childhood, or that I got to know at university or at all the side-projects in university. As I said, you have so much time. It's just the best time to really start building a network and then really start meeting the people that you're going to work with for the next couple of decades.
You mentioned starting with STARTeurope. What was your main motivation to get into the startup ecosystem?
I think that starting something got clear when I joined university. At some point I wanted to do something on my own. Even when I was a teenager, I thought about things when I saw a problem. Like, how could we build something with that? As soon as I joined university and saw and understood the tech ecosystem much better, it was like, "Okay, that's even more interesting now."
Starting STARTeurope was simple. I know a lot of people that studied business administration, and just know the business-related stuff. But I've seen very little other tech people have that kind of network where they know business people. That's one of the reason why we wanted to start with STARTeurope. Bringing tech and business people together, just because all of them are necessary when you start a company.
One of my co-founders at Codeship is a designer and does marketing now, and one of them has a tech background, but now does business administration. So it's a very diverse set of people. And I think that's something that really helps a lot when founding a company.
In the beginning it's a little harder, because you have less engineering people, which is why stuff takes a little longer. But now it shapes the founding DNA, which is something that we're talking a lot about. How do you set the DNA up that - in the longer term - there are different people with different viewpoints on every single issue. Also knowledge-wise, of course, to grow in many different areas. I think that's all of the kind of stuff that started when I was younger. Then at some point, once I got into technology, it was pretty clear to start something.
Was there any "Aha" moment when technology clicked for you?
Yes. At high school, when I was 15, I joined a special engineering & IT courses. Once I started programming & understanding the power you have with a machine, at the age of 15, once that curtain is removed, it's not magical anymore. That felt really great. I really got sucked into that for at least the first year. I really enjoyed that kind of power of the machine, and being able to express my thoughts and having the machine do them. That felt really great. When I started high school I always had the idea of studying law - for whatever reason. However I lost interest very quickly. Or studying history, or something like that, which I still want to do at some point. But once I found technology, it was very clear very early on that I wanted to do that.
I think a lot of people struggle when finishing school. Which direction do they want to go? At least for me, that was never really a question.
Could you tell us one thing you really love about your job as a CTO of Codeship?
Sure. Working with great people and talking to great people all the time. For once, just working with a team and helping to build the team is really rewarding and seeing where it goes. On the other hand, just being out there, showing the new stuff that we're building, showing that to others, getting feedback. That is really cool.
I think the CTO job varies a lot, which is why you have many different things to do. Sometimes you have to zoom in totally and work very focused on something and then you have a lot of different stuff. I certainly learn a lot. I think, especially coming from the engineering side where it's a completely different skill set that you need when you go into that management role. It's a completely new challenge for me. It's completely different than engineering.
Do you miss being an engineer sometimes?
Sure. I mean, sometimes I just need my technology fix, so I'll just go and build a small prototype or play with something or read about it. It’s important that you’re able to put these things away. Something like travelling. I really like travelling. But I'm doing a startup. There is not a lot of travelling that is going to happen in the next couple of years. So compartmentalizing that, putting that away and like, "Okay. This is just not going to happen."
Especially in the beginning I had a really, really hard time letting go of the technology stuff. I definitely stuck with it way too long, which is a problem because code gets shitty, because you don't have a lot of time. Managers schedule don't allow for good coding.
I read a lot, so it's more of a reading and talking about technology. I read and talk a lot about technology, I just don't build it anymore, which just doesn't allow at the job that I'm currently doing.
Can you share some tools with us which you are you using on a daily basis?
Sure. I've written about that a while ago on my blog. I had a "Tools and Services" blog post where I went through a lot of the list that we use.
We use Google apps. Gmail is really good. Gmail with a specific process from Andreas Klinger. That really helped me. Being able to cope with email is a huge skill that needs to be learned, that at least I didn't have and I think not many technologists really have, once they get a lot more emails.
So having a proper process on that and especially all the things that have to be done as a manager, being very process focused and being able to do all that very efficiently is very important. It took me a while to get there. But that really helps.
I'm using Wunderlist a lot for keeping my own personal tasks. Then we use iDoneThis for tracking what everyone is working on, basically. So I use both of them a lot. Obviously Google Calendar is really important for me because I have to schedule meetings all the time with people. Other than that, company stuff like Slack. Skype for calls. But I think productivity-wise, it's really Mail or Gmail, depending if I'm online or offline, Wunderlist and iDoneThis.
Is there any tool, technology or project you'd like to explore if you had more time?
If, let's say, we sell Codeship and I have unlimited time and money, the thing that I'd really look into is all the AWS services. AWS has so many different services now, where I maybe have played with them a bit, but not a lot. Really experiencing all of them and how they can help building infrastructure is something that I would do immediately, and then want to share with others as well.
The way we build software and the way we build infrastructure and products, is still so seller-heavy. We build our service, we set up our service, we manage them over months. Then we do all that stuff ourselves. I think that's just a huge waste of time. Being able to start with all the stuff that AWS gives you and some of their stuff is very high level. Some of them is very low level, but you can glue them together very nicely to build something that is really powerful. Although, I think that knowledge around how all their services work in AWS, and how they can help in every case, isn't there, especially for small to medium-sized companies. I guess if I wouldn't be working at Codeship, that would be the thing that I would be working on. Because it changes how the infrastructure is built in our industry, and I think that's really, really interesting.
Going back to your childhood, is there any advice you would give yourself as a 14 year old?
Yes, definitely. I’d tell my 14 year-old to be better structured. I often told my parents a quote from Albert Einstein when I just didn’t want to clean something up:
Fools tidy up, a genius rules over chaos.
But when I have children who say that, it's like, "Yeah, but you're not Albert Einstein. So get on it." Get structured.
I think that is something that has been extremely destructive, especially during the time from being a technical person where technology is relatively easy in terms of how we structure it. Because you get a task, you finish the task, you take the next task. That's a simplification. It's not that much more, typically, in terms of the work process that you have to do. You can sink very deeply into it and you just work on it until it's done basically.
That's totally not how a manager's schedule works, because you have to manage so many things at the same time and be available in so many ways. You can't just say "I'm just not going to answer my emails for 2 days." That just doesn't work. Being very structured, being very punctual, that's something that I haven't been very good at in the past but I've really changed now. All that kind of stuff would help so much now. That’s the same regarding soft skills. Like how to deal with people, how to better understand people, how to better understand what people want to achieve, where they're coming from. I think that's something that's more important and much harder to learn than the technology skills.
Technology is so easy compared to people.
For people who like doing technology, learning a new language isn’t really hard. However, learning to fundamentally understand people and how to keep people motivated and engaged, that is definitely something, I’d wished I’ve learned earlier.
Especially when you've found a company where nobody cares if you're structured or not. You either get the job done, or not. If you don't get the job done, nothing is going to happen. Definitely, being structured is an immense superpower. That's the thing that I would tell my 14 year old self: "Get super-structured. Get your workflows right. Write everything down. Make sure you have all your mental capacity to focus on interesting and innovative stuff, and everything that you just need to do and remember, write that down. Be structured, keep your tools in place. Learn it now so that in 10 years, you don't have to learn it then."
Going to the field of software testing, can you share some pains or challenges you experience in the field of software testing?
One of the biggest trade-offs that we see, and that many other teams see as well, is the trade-off between the complexity of test and the speed that you want to have. Best case, you want to test everything in every browser to make sure it work everywhere, and run the whole suite through everything. But that takes forever.
I mean obviously, and I'm totally plugging our tool where you can do a lot of stuff that makes it really fast, but there's always a certain trade-off on how much speed do I want to have and how much real-life or production-like set up do I want to have? That's a very big trade-off to do and you have to find the right balance. You either kill productivity or you kill your application all the time. That's something that is really hard to get right.
On other areas as well the challenge is to determine at which level you start testing. I think that is something that is very hard for many teams to get started. Many teams wonder on how to build the biggest test suite and human suite test suite available, or if it can be done differently. I think that’s the moment where I say: "No, you just write one test. For example testing your login. And then you write another test that tests your apply button." And if you have those two, that's already pretty good. Then test the next most important workflows. The main thing that we think differently about testing than others do, is that testing isn't there to validate that technology works.
Testing is there to make our users happy.
We make our users happy by being able to ship more stuff, ship more features. So, being productive has a lot to do with testing, since testing helps that we don't have to go back and fix stuff all the time.
What would you describe as your main passion building software? What motivation drives you?
I like to build software for other people to build cool stuff with. I think that's not just technology for me, but that's a general thing that I like to do. I like to be the man behind the curtain that does something cool, so that other people can do something even cooler with that.
It's really cool to work with developers, because you work somehow with yourself and others, and you always feel part of the cool team, part of the customer’s team. That's what I really like. I feel I'm part of thousands of teams, and when they do something really awesome and we help them with it, I feel like I am a little part of that team. That's something that really motivates me.
Do you see any major challenges coming up in the next couple of years?
Certainly, and many of these challenges and changes are already here. I've recently given a talk at a conference about "Service of Debt along with the Service" which basically means we're in a big change right now where the cloud has gained a lot of traction. The cloud is still a collection of services, and a collection of services is still something you have to manage, which I don't like to do. What we should have is a service for that.
The main reason why I think that's going to be so important and why it's definitely going to happen, and why that decision has been made, is because for once these services are out there and for many companies and for many ecosystems and markets, somebody in that market is going to move that way. Somebody is going to make it right and be really, really, really fast. Much faster than you can every be when managing your own service. So it’s the same with the decision with the cloud. That decision has been made by the competition, because somebody in the competition will do it, and they will be so much faster.
It might take some time to really figure out exactly how to do it, but somebody will come along and they will kill your business, because software is such a core part of so many industries now and it's really the core product. So many things are not defensible anymore.
Also, so much more software has to be built, and there's so little engineers available. So that's another trade-off where you need to get all the productivity out of everybody to be able to tackle the markets, because if you don't do it, there's definitely going to be somebody else who does it. That the huge change. It's not a revolution as the cloud was, but it's definitely the next evolutionary step in my opinion, where software and software development and software processes really are going. I think what people really need to understand and just get comfortable with because it's just happening. It's either happening with you, or it's happening without you.
Just one last question. Can you share a couple of resources?
There are two videos that I really enjoyed. One is from Chad Fowler, the CTO of Wunderlist, about building new infrastructure and the way they build a beautiful infrastructure. That's something that I found really, really interesting.
Another one I recently watched was from the last AWS re:invent, where AWS laid out their event-based infrastructure structure. It was less about Lambda specifically but just about presenting the strategy behind Lambda.
I recently read Ben Horowitz's book, "The Hard Thing about Hard Things." Although, that is less of a CTO thing, it's more of a CEO thing.
Generally I think the most important and by far the best resources for being a CTO is a mentor.
Everybody needs to get a mentor.
I think that's always by far the most important tip that I give people and the one I haven't followed up early enough. Somebody who is on your career trajectory, but 2 or 3 years ahead. Then talk to that person at least once a month or more, and discuss your problems. Because they've seen it. They've been through that. They know exactly what it feels like, and they can help you through it, and they can help you so much faster through it by specific tips. The cool thing about that mentorship is that you start catching up. That really starts becoming very interesting because you start talking about their problems as well and their stuff as well. It really starts building that kind of relationship and you start having somebody who you can really trust and talk about.
The problem with the CTO role is there's like a million books about CEOs. There's not a lot of books about being a CTO, because it's also so different in different companies. I'm a very external facing CTO. I don't manage a team. I've never really managed a team internally. Once we really grew, where we really needed more management, we got a VP of Engineering. So I'm very more of a marketing person at this point. But there's the CTO whose job is to run the engineering team. So that mix of CTO-VP of engineering, and then there's everything in between. That's the hard part of what exactly a CTO does.