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 ;)
Oldest 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 :)
How do you explain Continuous Integration/Delivery and how has the explanation changed since you started the company? How has the culture around this topic changed?
CI/CD allows you to bring your product(s) to market faster. That's what it is all about at the end of the day in my opinion. It's a technical framework, but why every company that's creating software should use it, is because it allows them to create more value for their customers faster.
I think the dev community and our whole industry became more sophisticated when it comes to CI/CD. When we started, simply doing CI and still deploying manually every other week was considered "good". Now we see a lot more automation, a lot more tools in the space (e.g. Percy for visual testing, SourceClear for continuously scanning for security vulnerabilities, etc.) that companies can pick from (which is not just great; also means more tools to integrate for you as a company).
What made you decide to go remote-first and do you have offices anywhere?
Codeship started in Austria back in 2011 (maybe some of you know our old name: Railsonfire). We decided to move parts of the company to the US at the beginning of 2013 because a lot of our customers were already there, most well-known companies that sell to developers are in the US, and we assumed that we could learn from more people how to build Codeship in the US (vs. Austria). Because of that decision, we were distributed more or less from the beginning.
It took us a while to fully understand the advantages and disadvantages of remote-first vs. not being remote. For example, we tried for a while to have a dedicated office in Boston and a dedicated office in Vienna. Over time we realized that it would be better (more productivity, happier team member, a better fit for our culture) if we go remote-first. Part of the reason was that we made very positive experiences with remote team members that joined the team.
We do have offices in Berlin/Germany, Boston/US, and Vienna/Austria. Most of our team works from home. It depends on their personal preferences and where they can be the most productive. What's important to us as a whole team is that everybody has a dedicated office space. That can be a dedicated room at home or a desk in a co-working space/office.
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 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.
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.
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 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.