At Blossom, we care a lot about workflows and how people interact in order to get a certain task done. We strive to understand what processes are in place at different companies to make Blossom easier to use for everybody involved in a project. This series is intended to show you how different companies approach the software development process and what matters to them. This is the third part of the series. If you haven’t read it, check out the first interview with Johannes Nagl from “Die Socialisten” and the second one with Thomas Peham from Usersnap.
The development workflow of Codeship
For this interview, I had the opportunity to talk to Florian Moltik, Co-Founder and CTO of Codeship. While managing a fast growing engineering team, Florian still tackles the small bug fixes and helps out different departments when needed. Describing himself as the “Jack of all trades” at Codeship, he shares his knowledge whenever possible.
Florian, welcome! Please tell us who you are and what you do!
I’m Flo, the CTO and one of the founders of Codeship (Together with Manuel and Moritz). As CTO at Codeship I’m basically helping out in many different ways. From implementing small fixes in code that I’ve written a long time ago to helping with Marketing, Sales, helping guide our engineering practices or Customer Support. I’m basically a Jack of all trades here at Codeship.
I also write regularly on our Codeship blog and give talks from time to time about Developer Productivity, Engineering Workflows and how to build infrastructure.
Can you tell us a little bit about Codeship?
Codeship was founded in late 2010 to help teams be more productive by taking away the need to build your own Continuous Delivery infrastructure. On our service you can run your tests, but also deploy into production. We support tons of different technologies so you can get all of your builds working.
How is the company and the teams you are working with structured?
We’re currently 18 full time people and several Freelancers. We started in Vienna, but moved our Headquarter to Boston. In 2013 we took part in the Techstars Accelerator program in Boston and we all moved to the US for a while (we moved to Berlin a couple of months before that). We still have our office in Vienna, which I run, and have remote people in Berlin and Austin at the moment.
The Codeship web interface
We’re definitely looking to grow in the future as well and see remote work as an important part for growing our team. But by having 2 offices in Vienna and Boston it’s also easy for us to fly remote people into those locations regularly so they can meet up with the whole team on a regular basis.
As you have people remote: did you start working with people in different places than your headquarters because you couldn’t find the right people near your offices or do you think there is more value to a remote workforce than “a bigger pool of talent”?
Both. At first we weren’t able to find the right talent only in Vienna or Boston, so we decided we wanted to basically start looking everywhere. In the end the most important question when hiring a new Person is the quality they bring to the company. Everything else is secondary and can be figured out. If we build a team that is fully focused on getting high quality engineers and we can set up a structure that allows for them to be productive in working together we can have a much better long term result.
We’re definitely looking to grow in the future as well and see remote work as an important part of growing our team.
How do requirements come to your team and how do they progress through your company?
New requirements typically come from 3 different areas:
- Customers talk to Support and let us know what features or improvements they might want
- We’re talking internally about the next steps our platform should take and where we want to get the company to
- We talk with partners about potential integrations and features we can build in the future
Alex, our head of product, then takes all those suggestions and discusses with various people in the team their view on the importance of specific tasks. That then leads to our timeline and those tasks are then picked off by engineering and worked on. We have a weekly team call where we present next tasks, status of the tasks and future product direction.
Florian discussing on a Team Building Event
What tools (Project Management Tools, Issue Trackers) help you deliver your product and why?
We use PivotalTracker for managing all of our tasks in the engineering team. Other teams use various other tools (Salesforce, Trello, …). Once a developer wants to release something she opens up a Pull Request and we can have discussions about that PR on GitHub. Then obviously we’re using Codeship extensively to deploy our applications.
We have to do quite some work to get the different tools working together and data available to everyone on the team.
Are there any tools missing from your setup? Maybe there is a gap somewhere which makes things uncomfortable or unproductive?
Yes, making those tools work together is still not easy. We have to do quite some work to get the different tools working together and data available to everyone on the team. But just for the development workflow we’re pretty fine at this point.
How did your development workflow evolve over time?
As we’ve grown the team, the processes definitely changed a lot. Its much more formalized now than it was in the past. We do weekly sprints and features get discussed with many people before they are put into the timeline. We really try to think very hard about the features, talk to customers and really make sure we nail it early. Of course you want to move fast as well, but that’s the tradeoff between moving fast and still shipping features.
Make sure there is no loss in focus from anything and you’ll get way more done in your engineering team.
What are your plans to evolve your development workflow in the future, if any?
We’re definitely going to grow the team, probably splitting it at some point. We will have to figure out how to manage that in the longer term. We definitely want to keep all the automation that has helped us so far and extend that even further so that we can make sure that even though we’re growing our engineering team, the team can still focus 100% on the most productive work.
Thanks! Anything missing you want to point out?
I’m working with many engineering teams and one of the biggest problems I see again and again, especially in small teams, is the missing focus on making your team as productive as possible in the medium or long term. Automating everything in your stack so scaling, health checks and replacing faulty parts becomes automated is such a boost to productivity that you have to do it. You can’t afford having your developers do small tasks to keep the system running every day as even small tasks take so much time away from getting something productive done. Make sure there is no loss in focus from anything and you’ll get way more done in your engineering team.
There is a lot of content within these answers. Thanks to Florian for taking the time and making it possible to get some idea of how a growing startup works on the inside and how the development workflow looks like for Codeship. There is a lot of value in having a Head of Product who is responsible for the product at large and talks to everybody involved. Unfortunately, it’s common for the product team to only fulfill a wish list of feature requests. This time-sink can pull the team away from developing value for its customers and is something we should all try to avoid.
If you want to work at Codeship, make sure to check out their current job openings!