DEV Community

Cover image for I'm the founder & CEO of Codeship, ask me anything!

I'm the founder & CEO of Codeship, ask me anything!

Moritz Plassnig on November 15, 2017

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. Fe...
Collapse
 
andy profile image
Andy Zhao (he/him) • Edited

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!

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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 :)

Collapse
 
andy profile image
Andy Zhao (he/him)

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. 🙃

Thread Thread
 
moritzplassnig profile image
Moritz Plassnig

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 :)

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
moritzplassnig profile image
Moritz Plassnig

I think that's a duplicate: dev.to/moritzplassnig/im-the-found...

Collapse
 
annarankin profile image
Anna Rankin

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

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
ben profile image
Ben Halpern

Great questions

Collapse
 
moritzplassnig profile image
Moritz Plassnig

That was awesome & a lot of fun for me :)

Collapse
 
annarankin profile image
Anna Rankin

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.

Collapse
 
moritzplassnig profile image
Moritz Plassnig • Edited

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.

Collapse
 
annarankin profile image
Anna Rankin

Cool! I find this stuff interesting, especially as someone who's only been in tech a few years. Thanks for your answer :)

Thread Thread
 
moritzplassnig profile image
Moritz Plassnig

Happy to help. If you have more questions, just ping me on Twitter: @moritzplassnig

Collapse
 
annarankin profile image
Anna Rankin

What did you do before Codeship? Where would you say your journey to continuous integration began? :D Thanks for doing this AMA btw!

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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).

Collapse
 
annarankin profile image
Anna Rankin

That's awesome! It's great that you've gotten to see multiple sides of the business.

Collapse
 
ashuydv profile image
ashuydv

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?

Collapse
 
peter profile image
Peter Kim Frank • Edited

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...

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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:

  • Flying whole teams together ~2-3x per year
  • Weekly 1on1s not just being the manager and the individual contributor but also between the different individual contributors
  • Weekly team calls (Codeship-wide and team specific)
  • Lots of wiki articles and Google Docs
  • A bunch of policies, e.g. for using Slack, working remotely and so on

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.

Collapse
 
arakodesigner profile image
Ara Ko • Edited
  1. What is the most important aspect for a startup to be successful— is it money, time, people, idea or something else?

  2. 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?

  3. What is your biggest advice for the new startup founders?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

@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.

Collapse
 
jess profile image
Jess Lee

What's your day-to-day like as CEO? Do you get to code?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

Only for fun on the weekend.

Collapse
 
jess profile image
Jess Lee

Working on any side projects??

Thread Thread
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
darjun0812 profile image
darjun0812

What inspired you to start working on something like Codeship? When did you start to see the need arise?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

A couple of reasons:

  • We were frustrated by other tools in the space (e.g. Jenkins)
  • Once we talked with other people, they were also frustrated like crazy
  • There was a huge momentum towards cloud software (e.g. GitHub, New Relic) but there was no SaaS/cloud-based equivalent to Jenkins
  • I personally wanted to work on something more technical again
Collapse
 
tal_rach profile image
Rachel Tal

Do you still have a location in Austria?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
andy profile image
Andy Zhao (he/him)

Since I'm also in the business of developing for developers, it'd be great if you could share how you handle user feedback.

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
andy profile image
Andy Zhao (he/him)

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.

Thread Thread
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
maestromac profile image
Mac Siri

What is the longest test suite time that you've witnessed?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
maestromac profile image
Mac Siri

Wow, I did not expect that. 5 hours is CRAZY. Makes me pretty satisfied with our 5 min test suite. Thank you for that!

Thread Thread
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
tcelestino profile image
Tiago Celestino

What was your biggest motivation to create the Codeship?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
ben profile image
Ben Halpern

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?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
dvdmuckle profile image
David Muckle

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.

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
jess profile image
Jess Lee

What made you decide to go remote-first and do you have offices anywhere?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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.

Collapse
 
ben profile image
Ben Halpern

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?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

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).

Collapse
 
georgeoffley profile image
George Offley

How do you evaluate raises and pay for your employees? Do you have a system in place or a merit system based on starting salary?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

There are a couple of factors, and I will structure it into two buckets, new employees & existing employees.

New employees: Usually, the job description defines clearly what title a person would get, what seniority we are looking for and that then is used as an input factor for some market research to determine what the market value for such a position is. That's a bit hard when you are hiring in multiple different countries/regions. Then there's what a new employee expects from us. That's important as well (we on purpose don't ask what people are making right now; it's solely about what they expect to make once they work for us).

Existing employees: We focus a lot on performance and historically, most compensation increases were merit-based.

With that all being said, we are currently working on a project internally to better formalizing all of that and also clearly spelling out that it's not all merit-based. E.g., we don't want to punish somebody who is performing well in a current role, doesn't want to get promoted, doesn't want to take on more responsibility but is extremely valuable for us and has acquired a lot of Codeship-specific knowledge. That's one example where we would want to have a system in place that rewards that person too.

TL;DR: Starting compensation (base/bonus/equity) gets determined by the market value (different per location), and afterward it's merit-based with some exceptions.

Collapse
 
andreasklinger profile image
Andreas Klinger ✌️️

Why don't you openly acknowledge that you are a bot?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

I'm not a bot.

Collapse
 
rhymes profile image
rhymes

Just wanted to thank you for the product. It's my go to tool for our Heroku based apps and it rocks!

Collapse
 
moritzplassnig profile image
Moritz Plassnig

Thank you 😊

Collapse
 
nijeesh4all profile image
Nijeesh Joshy

Do you have any opening for interns ?

Collapse
 
moritzplassnig profile image
Moritz Plassnig

Not right now but please look at our jobs page again early next year - it could change.