Diario del capitán, fecha estelar d262.y37/AB
We love hearing other people's stories, especially if they share the highs & lows of being an entrepreneur. As a first-time entrepreneur, owning a business is like reading a thrilling book: you don't know what you can't expect every time you turn a page, but you can't stop going forward.
Reading other people's stories and blog posts about what they did wrong or what worked for them is really helpful. That's why in our first two years we wrote a couple of blog posts about what we had learnt every year: Lessons Learnt: One Year Running Our Own Business and We Don't Need a CEO (Lessons Learnt in Two Years Running a Development Consultancy). Save them for later!
Let's get into it!
Working for startups is risky (they might shut down, run out of funds, pivot, etc.) and this is a fact. But the truth is that we also find working for big companies equally tricky.
Big corporations and long-standing businesses have got their own rules and they will force you to adapt to them. Some will drag the negotiations very long, others will pay months after you invoice them while others will have too many stakeholders in the project, thus causing bottlenecks and many different blocking situations you might not be prepared for.
Mark Suster wrote about client size, advising startups to be deer hunters instead of chasing rabbits or elephants, and, similarly, Howard Love talks about How a Large Customer Can Kill a Startup on his blog and his book The Start-up J Curve. But we really identify with the situation Dockyard experienced during their third year.
As it was the case with Dockyard, during our third year we were approached by a very large corporate client. In our case, we had saved enough to be able to sustain the long negotiation and their payment schedules. However, not every company can survive this, especially if you're tight on cash and have both hands tied to your cashflow.
Luckily enough, we have got enough other projects to compensate these situations and be able to withstand delayed payments for just one client. But we couldn't have two clients like this.
We have been working for this client since July, and we have proved our worth enough for them to change some of their policies. If they really need you, they will find a way to speed things up, by taking money from another department or forgoing some of their workflows by escalating to the C-levels.
We are really grateful to have come across this opportunity, but we understand that not every company is ready for this.
Lesson learnt: Accumulating cash in your bank account is not only useful for long dry spells but also to make strategic movements with big players. If you wanna play big, act big.
Last year, Angular (aka Angular v2) was released, and with it, we adopted TypeScript in the company. So far, everyone seems to like it, and it has definitely contributed to boosting the performance of our Angular projects. Luckily enough, the learning curve was not too steep, and we could adopt it smoothly.
Our first project with it started during the summer, before Angular was officially released, so we had to use the Release Candidate version 4. We agreed with the client that it was stable enough and in hindsight, it looks like we did the right move. However, as it happens with all new technologies, not everything is documented, and there are still a lot of bugs to be fixed, but we're proud to have switched to this version and become one of the pioneering companies to adopt it. This has earned us new clients.
Similarly, we also adopted Ionic2 for a new project shortly before it was released. In both cases (Angular and Ionic2) it was agreed with and understood by the client that our lack of experience with the newer versions might cause delays in the project, and we both took it as an investment. We learn by doing.
For the backend, nothing has really changed. We still use Ruby for all the projects, and we don't see this changing in the near future. Although we are working on a project using Node.js for the backend, we would rather stick to Ruby and Ruby only.
However, for the frontend, we're getting our hands on new frameworks like React and Vue.js to have a broader toolset.
2016 has seen us developing our first mobile app for a group of companies in the HR sector. Ruby was chosen for the server part and the administration panel while the app was built using Ionic.
Ionic v1 turned out to be quite limiting and the performance was not ideal. In our case, however, it was a good solution as the app was simple enough and didn't have complicated workflows or too many interaction possibilities. Definitely, not having a map neither scrolling was key to having a performant app with a good user experience.
The Ionic ecosystem is great, and we've taken advantage of their nice emulators & tools to develop seamlessly as if it were a web project.
Back when we were only a web development consultancy, we had to tell our clients to find another provider to develop their mobile apps, but we're happy to have incorporated mobile development in-house so we can help our clients further.
Internally, being able to explore new business lines and technologies boosted the morale of our employees. Developers find it always interesting to play with new frameworks, and Ionic provides a great way to transition from web to mobile without changing your routines completely.
There's a big fight between those who prefer native development versus those who do hybrid. Certainly, we have found very pleasant results doing hybrid, and we feel like this will only improve over time. Time will tell!
Finally, Ionic has given us a lot of insight on hybrid mobile development in an easier way coming from web technologies. Still, it hasn't been a bed of roses, as we've had to optimise our apps for different kinds of devices using the native APIs in every project.
We missed great opportunities because some startups required React Native. Above all, we're very honest as a company and we preferred to pass on them than jeopardising our reputation as a 100%-trustworthy provider expert in the technologies we offer.
Lesson learnt: In this case, one size does not fit all, and we will invest some time during 2017 to find alternatives to be able to select the right tools for every project.
The most interesting highlight of our third year is that we increased the number of time & materials contracts (aka "retainer" or "agile contract"). This is especially difficult with Spanish clients, who are just not used to be billed by the hour and prefer closed scope estimates on both time & money.
There's a lot of (good) literature about this, including Thoughtbot's Why fixed bids are bad for clients too and this other one by SauceCode called Why We Don't Do Fixed-Price Software Projects (And Neither Should You). Dev shops should always strive for agile contracts, as described in the previous posts (we will eventually blog specifically about this subject).
We have found it easier to work with time & materials contracts when dealing with foreign companies, so that's the way we're going now. Seldom do we find ourselves accepting fixed bid contracts.
Sometimes, a fixed bid might be acceptable if the project is small enough or depends solely on your company (or if the client is really strategic). Nowadays, we see fixed bid projects as the least ideal way to start working with a client, provided we can agree on a time & materials extension afterwards for later phases or maintenance.
Lesson learnt: It is better to let some opportunities pass in order to be able to satisfy a better one. If a client is not willing to work on a time & materials basis, he might not be your right client.
In our third year, we have also learnt how to replace team members. As the business grows & changes, some people are just not the right fit anymore and they need to be replaced.
People grow too, and we've had a couple of our employees that left voluntarily to do grander things. In February, Javi, our first hire, left to pursue a more corporate culture in one of the biggest Spanish consultancies, and our former UX specialist Marina went on to work for a VR company. We wish them the best of the lucks!
Not every company can say this, but we're happy to say that we keep a really strong connection with all our former employees and see them regularly in our events & afterwork meetings. We're also happy to see them thriving in their new companies!
Lesson learnt: Firing sucks, but has to be done. Do it as fast and transparently as you can and do it with the utmost respect. If done properly, you're saving your business and your employee's career.
Our blog entry about our first year contained a list of things that helped us to get new clients. I'd like to update it.
First of all, the main source of new projects for our third year has been happy clients that hire new stuff or else recommend us to their buddies. The guys who spun off Rundit, from a previous company we had worked for, hired us to continue the development of their platform.
Also, our friends from Cylinder, a San Francisco Rails consultancy with whom we've collaborated in a bunch of projects, also introduced us to new clients and even hired us to develop their website. These are just some examples, but the list could go on.
Another thing that worked is Startup Grind. We have been organising this event for three years now and curating one of the most passionate communities in Barcelona, and we've got a steady average of 130 people per event. We started working for the Swedish consultancy Prototyp because one of the founders attended our event in Barcelona. But most importantly, we've been nurturing the culture of helping others before helping yourself and this has ended up resulting in business opportunities from some of our guest speakers. We've recently started working for one of the hottest startups from Barcelona: Mailtrack.
Also, during 2015 we generated a significant amount of leads coming through our blog + website. SEO paid off even during our first year, but now we've got a solid & recurring number of opportunities thanks to our website. We'd really love to test whether publishing more will also increase the number of leads, but we can't find the time more than a couple of blog posts per month (if even!).
I would like to take some time to explain also what has not worked for us, in terms of generating new business opportunities.
First of all, going to events and conferences is plain useless for a niche technology provider like us. We explained in the past how outbound marketing was not working for us (might be that we're also not good at it) so we're 100% focused on inbound efforts. If we were a jack-of-all-trades company with really low prices, we could find more clients, but that just does not cut it for us.
Referral contracts/bonuses don't work if you don't really know the other company. Instead of signing partnerships with new companies, we just sign them with companies we've been working at least 6 months for or with. This has worked well with Cylinder and a UK-based marketing freelancer.
Finally, another thing we invested relatively in in the past, which hasn't generated any lead, has been giving talks & mentoring at events, companies and/or communities. My senses tell me that we have been just spreading too thin and we should just do it for the right ones, being more selective & strategic, but in the early stages of the company, one tends to catch the low-hanging fruit too hastily. We have learnt from that after seeing the results (or lack thereof).
Since we're committed to building community and train the new generations of entrepreneurs and developers, we can't just simply quit. We will be focusing more on the communities we can add more value into.
Even if this sounds corporate, we need to look into the future. Some of our employees have been over two years working for us, and we need to think where we want to go together.
Talking to our employees regularly helps a lot, but it also helps to ask long-term questions like what kind of job do they want to do in the future, what would they like to specialise in, what would they like to learn next, whether they would like to manage projects or not, etc.
Lesson learnt: Keep expectations aligned to avoid finding out too late by doing one-to-ones regularly.
As a full-remote company, we have spent a lot of time figuring out what are the best practices to keep a good balance of information in our online channels. Everything needs to be informative enough, without being too overwhelming nor distracting.
We have consolidated our tools (Basecamp + Github Issues + Slack) for our projects and when and how to communicate. We have moved away from Trello for most projects, and we're managing them using Github Issues + Waffle to show them to clients.
Outside of work, we have also incorporated a nice initiative: the Martian playlist. Every Friday, everyone adds a couple of songs into a Spotify collaborative playlist and gets three votes. At the end of the day, the best song of the playlist is selected and the winner gets an extra song for the next week and also gets to choose whether the next playlist should be theme-based. Themed playlists can be "only songs from 2014 exclusively", "just cover songs", "epic songs" or "soundtracks from videogames".
Surprisingly, everyone has adopted this very well and it's bringing a fresher & casual watercooler conversation for Fridays. This is paramount, in a company where all of us only meet in person once every two months.
Lesson learnt: As your teams grow, you will need to create some dynamics to help to bond. The more people, the more ideas you can execute as well.
All that glitters isn't gold. While it might look appealing to work from wherever you want, sometimes we struggle to find stable wifis or good working environments without background noises.
Working from home has got other challenges: partners not respecting the working hours, crying children, and even the ever-present feeling of working alone. In an office environment, most of these things would either not exist or be taken care of, but we'd rather have these issues than having to deal with an office and its derived problems.
The aforementioned Martian playlist helps us to bond further despite the remote factor. It compensates the fact that you're working alone, but we also do other actions as a team.
Recently, we started doing the Zerg Rush™, whereby the entire team works once every two months for an entire day on the same project. The Zerg Rush can be used mostly to speed up stalling internal projects (open source, internal tools, blog, website...), investigate new technologies, create a prototype or else work jointly on a client project that needs an extra push.
During the Zerg Rush, we touch base a couple of times during the day, and we work on the tasks we have previously planned. We normally use the Martian Day to plan the next Zerg Rush.
Company get-togethers are becoming a reality as well. In 2015, a couple of us worked from Berlin for some days, while in 2016 half of the company attended the Euruko in Sofia. We also meet five or six times during the year for the Martian Day, the Christmas dinner and the Summer dinner.
Since we don't spend a lot of time together, we like to invest in making the most of it when we meet. Both retreats worked well in the past, as will the upcoming company retreat we're doing in Tenerife this summer, or attending EuRuKo 2018 in Budapest.
Lesson learnt: Founders have to take care of potential issues before they arise. Reading about other companies and how they deal with this is paramount, as well as keeping a fluid conversation with your employees about it at all times.
Since the very early days we have been investing heavily in the communities of startups & developers of Barcelona.
Quite remarkably, during 2016 we've partnered with our favourite coding bootcamp in Barcelona, IronHack and we have started curating everyone's favourite newsletter for startup events: Startup Digest. It had been abandoned for a couple of years in Barcelona, so it felt only right to adopt it as another way to give back to the community we belong to.
Last year, we stepped up our game with Startup Grind, bringing more and better speakers, some from foreign companies such as Zynga, Airbnb, Stripe or Blablacar. Thus, we upped our average attendance to 130 people, peaking at about 250 attendees in our Third Anniversary event.
After three years seeing the same format and the same event month after month, we decided to go for grander things.
We are organising a Startup Grind conference for October 10-11th in Barcelona! We should expect 800 people and about 20 speakers from Silicon Valley from companies like Stripe, Couchsurfing, Pocket, Angelist or YCombinator, in a conference that will bridge the sister cities Barcelona and San Francisco. If you want to suggest speakers or sponsor it, get in touch with us!
Lesson learnt: Investing in community will most likely not bring immediate results, but when it comes back, it comes back ten-fold.
2017 will most likely see us playing with some new frontend frameworks while focusing on growing our client base and organising a kickass conference. But if there's one thing we have learnt in these first three years, is that it's difficult to make accurate predictions.
If you liked this post, please, share it on your social profiles!
Read about what we have learnt in our second year operating as a development consultancy.Leer el artículo
Announcing our new corporate logos, slogan, the Spanish version of the site and our newsletter.Leer el artículo
The COVID-19 pandemic has affected everyone differently and we are no exception. We want to share our ups and downs from 2020 in our annual post about lessons learnt, including management, finance and mental health, among other topics.Leer el artículo