I'm Mo, one of the founders and the CEO of Codeship. I spend most of my day working with our team on helping our customers ship code more often. Feel free to ask me anything about building a developer tool company, all the different aspects of running a startup, culture/leadership, Continuous Integration/Delivery.
Codeship started out in Austria (where I grew up) and I moved to the US 4-5 years ago. Over time, we transitioned into a remote first company and the majority of our team is working remotely now. It took us a while to figure that out and I'm happy to share as many learnings as you want from our journey.
When I'm not thinking about Codeship, I try to spend as much time as possible outdoors, rock climbing, running, skiing, hiking - you name it. That plus my love for chess and sleeping pretty much makes up my days ;)
Top comments (56)
As a remote first company, what were some concerns that you had starting out and how did you work through those issues?
Also, Codeship has been the first CI I've used, and it's been a pretty great ride so far!
We didn't start as a remote first company, to be honest. In the beginning, we thought we should try to hire as many people as possible in the same location. We had a very hard time finding people who were equally interested in CI/CD as we were and also fit our other requirements (certain skills, value alignment, etc.). That was probably the main driver to become more flexible and eventually resulted in us hiring in multiple locations and then everywhere between certain time zones (PT <=> CET).
I think that the biggest challenges with a remote setup are around communication and building personal relationships. Communication gets easier and easier with tools like Slack, Google Hangout, etc. and dev-focused companies are having a slight advantage in my opinion (simply more used to chat based communication).
Building personal relationships is hard. What we do is making sure that our whole team does a lot of 1on1s with each other and also talk about non-work topics. That's only half of it, though. Meeting in person is key. We try to make sure that everybody at least 1x every 3 months sees some of her/his co-workers. E.g. we just had our Customer Success + Product team in Boulder/Colorado for a week and Customer Success + Engineering + Product will meet in Lisbon/Portugal in January next year.
Glad that you are happy with Codeship. Please let me know if we can do anything better :)
Yeah, seems like the biggest advantage to becoming remote is having more access to applicants.
Awesome that you have your teams meet up; I think that's key to building relationships, too.
Not sure how many junior devs you have, but do you have any advice for building up/supporting junior devs who are remote?
Since you're asking if there's anything you can do, there is one thing I would like, and it'd be great if the Slack notifications/webhooks linked to the GitHub commit, too. :) It would save me a click. 🙃
We haven't hired any junior team members remotely so far. That's primarily because we don't think that we as a team have figured out how to best support them. I hope that we will be able to do so, soon. We successfully moved junior team members from an "office setup" to be remote.
I think articulating guidelines for working remotely is key for junior team members, especially if they don't have any remote working experience. E.g., making it clear that they have to work in a dedicated space (at home or in a co-working space) or guiding them when it comes to work-life balance. If you are at home the whole day, it can be challenging to know when to stop working.
Additionally, I would focus on giving those junior team members more face time with the more experienced team members. E.g., flying them to other team members more frequently, especially in the beginning.
Thanks for the feedback - I forwarded it to our team :)
I think that's a duplicate: dev.to/moritzplassnig/im-the-found...
I'm always interested in entrepreneurship, but the thought of failure (not having enough money to feed my dog 😭) and not knowing where to start have always given me pause. What advice would you have for someone looking to start a business of their own?
Also, If you weren't the CEO of Codeship, what do you think you'd be doing now (and where)? :D
It's hard; I won't lie. The first half of our journey, I didn't make any $ of Codeship. I have a tremendous amount of respect for every founder who believes in a crazy idea and jumps right into it.
I think it depends on your situation. We didn't do Codeship full-time until we acquired our first couple of customers. We hedged our risk a bit. Once it was more obvious that what we do can be "real, " and other people are willing to pay for it, we went all-in. Maybe you could do the same? Maybe there are some ways how you could validate your idea on the side, make some progress to de-risk everything?
I don't know what would have happened if I wouldn't have started Codeship. Honestly, no idea (maybe I'm not creative enough). I hope something else that's pretty awesome would have happened ;) If I would do something different now, it would probably be in the same industry (dev tools), either doing a different startup or working for an interesting company.
Great questions
That was awesome & a lot of fun for me :)
As a primarily technical company, what's the relative size of the departments in Codeship? How did you decide who you needed to hire, and what roles you needed? I work for an educational tech company, and I'm always interested in the ratio of developers to designers to finance/accounting/HR/etc folks.
I happened somehow organically. In the beginning, we were focused a lot on product and how to build out Codeship to help our customers best. Once we felt we got something enough people were paying for and recommending, we became more focused on Marketing. Because more and more developers started using us, we decided to hire dedicated Support Engineers instead of letting everybody do support.
And so on. So TL;DR: We felt a need, talked, prioritized and then hired if we had the $.
The ratio is probably 2/3 design/product/tech, 1/3 marketing/sales.
Cool! I find this stuff interesting, especially as someone who's only been in tech a few years. Thanks for your answer :)
Happy to help. If you have more questions, just ping me on Twitter: @moritzplassnig
What did you do before Codeship? Where would you say your journey to continuous integration began? :D Thanks for doing this AMA btw!
I went to school in Austria, did a lot of programming until I was 19. Then I thought I should see "the other side" and studied business. Stopped with that I think when I was around 20/21 and started working on a project called "STARTeurope" where we tried to bring devs, designers + biz people together in Austria to work on projects (similar to Startup Weekend and other hackathons). That's where I met one of my co-founders, and we started talking about Codeship.
Since I wanted to do something more technical again, Codeship was perfect. That being said, being honest here, in the beginning, a lot of my interest also came from me hoping to get back to programming more again which never really happened due to my current role at Codeship.
Looking back, I've to admit that it's probably better that I'm doing what I'm doing and that I'm not in a hands-on technical position (there are simply far better people at Codeship for that).
That's awesome! It's great that you've gotten to see multiple sides of the business.
Hey, how can I use codeship, I know it's weird but I want to explain it to my team in more simplest way possible, what is it, is it something like GoDaddy or something like GitHub?
What do you wish you understood about being a remote-first company before you started? Any specific hardware/software recommendations for helping communication? And any "best-practices" (Slack expectations, regular meetings, etc) that have specifically helped? Very interested in benefiting from your insight here :)
On another topic — how often do you go rock climbing? We did a little company "summit" last week and my forearms are still recovering...
Hard to say, to be honest. I don't think there was anything that was completely surprising to me. Maybe that's because I spend a lot of my teenage years in the esport community and on IRC. Because of that, I think, I'm just far more used to online communication, not being able to meet people in person and so on.
The biggest learning was probably around communication. You have to explain everything very well (doesn't mean with a lot of words) all the time, ideally somewhere where it doesn't get lost (PRs, Google Docs, etc.). If you are all in the same office, a lot of stuff can get figured out over lunch, during coffee, random conversations, etc. That's not happening when you are highly distributed. We put a lot of focus on adequately conveying why we are doing what and how it impacts everybody and still have a long way to go to do it well.
A couple of things we do:
I try to go climbing a couple of times per week indoors. Recently there was a lot going on so it was only 2, 3 times per week max. I would love to do it 4x per week because then I feel I get better.
What is the most important aspect for a startup to be successful— is it money, time, people, idea or something else?
How did you come up with the “continuous integration and delivery method" (is it similar to agile?) and brought the value into the company’s working culture. What is the advantage of this?
What is your biggest advice for the new startup founders?
@1: People, first and foremost. Great people figure out a real problem and a solution for it and the rest (selling the product, etc.). I think the timing is the most underappreciated aspect of building a startup. It's unfortunately also something that you can't control.
@2: I/we didn't come up with it. There are a lot of smarter people who covered this topic before us, e.g., martinfowler.com/articles/continuo...
What we believed in when we started is that that methodology will become the mainstream and that companies need dedicated products like Codeship to apply the methodology properly.
The advantage is that you continuously test every code change and get every code change to a deployable state. That allows you to release a new version far more frequently, ideally in a fully automated manner through a platform like Codeship.
If you do that consistently, your software, your products will become better and better for your customers faster.
@3: Find great co-founders, think big and always put the customer first.
What's your day-to-day like as CEO? Do you get to code?
Only for fun on the weekend.
Working on any side projects??
Nothing real cause I want to stay focused on Codeship.
I recently played around with k8s for fun and before that build some stuff for fun on top of AWS API Gateway/Lambda/MachineLearning but nothing that would make sense to productize.
Maybe sounds boring but that's okay and necessary if you decide to build a company because I think you need an incredible focus and have to give up some things to get to that.
What inspired you to start working on something like Codeship? When did you start to see the need arise?
A couple of reasons:
Do you still have a location in Austria?
We are remote first now and do still have people working with us in Austria. That means that most of the people are working from home. There's also a little office, but we don't "force" people to work from there.
Since I'm also in the business of developing for developers, it'd be great if you could share how you handle user feedback.
For us, it was always about building a product our customers love. Part of our motivation came from the frustration we had with other tools, but we never intended to build Codeship only for us. That mentality influences how we think about getting feedback. We always want to understand what problems our users are facing and how we can help them best. It's often tricky because, on the one hand, we want to help them and understand their use cases, but on the other hand, we also are opinionated on how you should do things.
Happy to share more of our processes of how we handle the feedback, who looks at it, how it flows into our product roadmap and so on if you are interested in that.
For sure! Would love to hear how that all works.
For handling feedback, I always welcome requests but I wonder how to draw the line between listening to users and building what you think is best.
For us, it was a mix. We had some ideas, build an initial prototype and then iterated over it based on customer feedback. It wasn't well thought out, we just tried to balance our ideas as best as we can with what customers wanted.
Now, we try to do it a bit more formalized. We spent quite some time fine-tuning our product strategy and derive our product roadmap from there. E.g. we're heavily focused on Continuous Delivery, not just Continuous Integration. That means that we tend to prioritize CD features higher than new CI features.
What we think we should do is captured in our product strategy. How it should look like in reality is defined by the customer feedback. That's probably the best way of putting it.
Something that helped us a lot as well is clearly articulating what we won't do. E.g. Codeship currently doesn't do CI for iOS apps and clearly spelling that out and referring potential customers to other great solutions out there (e.g. Buddybuild, Bitrise, Nevercode, etc.) saved us a lot of time.
I think it's equally important to know what you don't want to do.
What is the longest test suite time that you've witnessed?
5 hours because that's the upper limit on Codeship right now ;) From time to time customers want us to increase that limit. How we approach that problem is usually by figuring out a way to help them get their build time down, though.
Wow, I did not expect that. 5 hours is CRAZY. Makes me pretty satisfied with our 5 min test suite. Thank you for that!
5 min is pretty good. Although to be honest, "good" depends on what you need. If it bothers you or your co-workers, it's not good ;) Different teams have different needs.
What was your biggest motivation to create the Codeship?
Seeing how unhappy friends and other developers we talked to were with existing products, e.g., Jenkins. That, plus realizing that more and more tools got moved to the cloud (that was 2010/2011) let us conclude that people would prefer something like Codeship over whatever they were using back then.
Additionally, to us, it seemed obvious that CI/CD is the future. In the dev community, everybody was talking about how Etsy or Netflix was doing it, but outside of those few examples, a lot of teams were still struggling a lot with it.
Are you concerned that Codeship could be "replaced" by the platforms that you currently hook into? How do you think about that kind of question in your line of business?
Yes and that's probably nothing unusual for a founder. That being said, if we look at the different platforms that surround Codeship, there are a lot of reasons why certain companies couldn't or don't want to offer a great CI/CD platform. Some already do, but that hasn't been an issue for us.
How might you convince someone that using a CI system is advantageous no matter how small the project is? Context: I'm a student trying to get my peers into using CI systems for homework assignments and smaller projects, as I think it's not only an important concept but makes running tests a lot easier.
I think so. You get used to the workflow and it saves you time. Even if you don't write any tests and are just working on a tiny Lambda function, having the deployment configured once and triggering it automatically when pushed to / merged into master is super helpful in my opinion.
Btw. students can use Codeship for free.