26 Lessons From Being a Developer at a Startup

In the last three years, I worked for a small B2B startup in Berlin. I was the first backend developer and joined the ride of growing it from 200 to 720 business customers, from $200K to $3.2M annual revenue and from 5 to 25 employees.

The following lessons are a very simplistic, personal summary of what I have learned during that time. Nothing more, nothing less. Enjoy.

(1) Retrospectives are crucial. We regularly sat together as a team to reflect on the last iteration. The importance of looking back and evaluating cannot be overstated. Each participant was required to think about the things that went well and things that need improvement on their own first. The group discussion started only after everyone had presented their thoughts. This way, everyone was able to bring up important issues - much better than the kind of meetings where the ‘loudest’ dominate the conversation.

(2) Take the time for regular 1:1s. In a busy startup environment it might be hard to justify just talking to your manager for an hour each week. But that is what we did and it worked brilliantly. You can discuss issues in-depth, timely and simply feel more valued as an employee. There is no replacement for that.

(3) Just pay for developer tools. For computers, every GB or MHz contributes to being able to work faster. For software, every useful tool that makes you more efficient counts. Giving the developer a fast, modern toolset also shows that the company values him/her. There should be no discussion about that. Period.

(4) Meet your customers. We visited our local customers regularly and had an annual company trip to customer hot spots (New York and San Francisco, for example). This made all the difference. It is one thing to exchange emails with customers, but it is a completely different experience to meet them and hear their pains and successes first hand. It has a powerful and lasting effect on the way you think about your users when you are back developing.

(5) Don’t let the build become slow. You know you have acted too late when the slow build becomes a running gag in the office (XKCD anyone?). There is hardly anything more frustrating than having a slow feedback cycle. We have worked with Java in the backend and Webpack in the frontend. Both were getting slower and slower by the week. In the end, it made me want to smash my head against the wall. In the long run, slow builds cannot be fixed by buying faster machines. You need to think about the structure of your application to deal with it; modularising it, for example. There is no quick fix.

(6) Cross-functional teams FTW. Before we had formed cross-functional teams, we were only able to effectively tackle small projects. Once we had a team consisting of designer plus frontend and backend developer, things took off. It allowed us to work on much bigger, more impactful features. It brought its own set of challenges but overall it was a crucial step in the evolution of the startup.

(7) Trello does not scale well as a bug or project management tool. We have used Trello to manage our bugs. I love Trello but I always felt it fell short. It was difficult to search and only scaled up to a certain point. The same goes for project management. At a certain point the simplicity and ease of use fade away and it just becomes too overwhelming and ineffective. I prefer dedicated tools that actually support and facilitate what you are trying to achieve.

(8) Take on responsibility or wither away. To be successful at any company you need to take on responsibilities. The bigger the better. The difference to a corporate environment is that it is quite easy to do so: roles are not set in stone and it is easy to grab unclaimed or unwanted responsibilities. You must become the guy/gal for something to improve your standing. You need to be proactive and shape your own image - or others will do it for you. Bonus points if you align this with the company goals. You can be a great code architect - but when the company only values feature development, you are betting on the wrong horse.

(9) Adapt or leave… or fight if you need to. You might disagree with your management on certain things. In that case, you need to decide how important these issues are to you. If it is very important, you can take on the challenge and fight to stand up for what you believe is right. But often it will be an uphill battle. If hardly anyone around you supports you, or worse, does not even share your views, then you need to ask yourself if it is worth it. You can either ignore it and play along or look for another job.

(10) Look for benefits that actually matter. A lot of startups boast with heaps of benefits. Some take pride in their ping pong tables, some want to impress with an open bar on Friday nights and some show off their selection of high-fructose corn syrup candy. It’s a trap! Look for meaningful benefits like lunch and learns, an education budget or health benefits.

(11) The CEO should be able to take a vacation. When a startup is growing, the CEO has to give up more and more responsibilities since a single person cannot scale along with it. Basically, the CEO has to replace himself/herself step by step. A good indicator if this is working out is him/her deciding to go on a vacation.

(12) You need a strategy for real-time messaging. We used Slack and while it was fun at times, I think it killed a lot of the productivity. We did not have a shared mindset about how the tool should be used. It is very important to clearly define what should end up in a chat and what is better left to email, face-to-face conversations or the wiki.

(13) You (can) influence how people perceive you - at first. Whatever you say and do will shape how others perceive you. If you work weekends, you will become ‘the workaholic’. If you come up with new features, you might become ‘the wonder child’. And the thing is: it sticks. Often, the early impressions are the most important. It becomes increasingly harder to change how you are perceived by people around you.

(14) Balance senior and junior people. In the backend, we almost only had senior developers with a combined number of 55+ years of experience. But to my surprise, this led to a plethora of discussions that rarely yielded great results. Those discussions were fierce. Sometimes I wondered whether everyone would make it out alive. On the other hand, in the frontend everyone was junior level. They displayed a lot of enthusiasm and creativity which - while meaning well - would often miss the bigger picture and lack high-level best practices. The key is the right mix of junior and senior people.

(15) Always have a visual mock before you start coding. A new feature has many stakeholders. There is the project manager, the designer, the product owner, the CEO, the developer and the customer, for example. All of them have their own expectations and agenda. The best way to communicate the vision for a new feature seems to be a visual representation as close as possible to the final result. Again and again this has helped us preventing misunderstandings and bringing everyone on the same page.

(16) One office per team. It has been shown again, again, again, again, again, again, again and again that an open-plan office is a bad idea. I think a company usually wants to save money on office rent and sells it as a collaboration and creativity heaven. From experience I can tell you that you need a quiet environment to get work done - but you still need to be able to communicate easily with your team mates. I found the ‘one office per team’ rule strikes a good balance, if you keep teams small.

(17) Extroverts dominate every discussion, unless mitigated. For an introverted person like me, the workplace can be challenging. Extroverts like to talk and write - a lot. Introverts usually cannot compete. We are at a serious disadvantage since extroverts can respond quicker, more confidently and more elaborately. Any company that does not address this issue loses out on great ideas and contributions by its ‘silent minority’.

(18) Developers need to talk about their shared mindset. Once you go from a single developer to a team of developers, there will be conflicts. Everyone is different. That is why it is so important to share a common mindset about things like code style, architecture, development and bug process, code reviews and so on. Simply writing down rules in a wiki does not work. It needs to be lived, understood and changed when circumstances require it. There is no substitute for regularly talking about it.

(19) Regular status updates are motivating. Knowing that, at the next day’s standup my entire team will listen to what I have worked on motivated me. Even more so for weekly status updates. When our startup was still small, everyone shared last week’s successes and failures in a few words. When the company grew bigger and only the team’s joint efforts were presented, it was not as motivating anymore.

(20) Learning budget needs to be measured in time, not money. Although we have had a learning budget, it was hardly ever used for something other than attending conferences. Workshops can be a hit or miss - often there is not even one for the latest technologies. But like many of my colleagues, I am able to learn new things from blogs, books and videos just fine. So I propose to allow developers to invest a few dedicated days a year to learn things on their own. It is what we have to do anyway - often on weekends - but this way the company can support these efforts directly.

(21) Pair programming is underrated. A nice tool to share knowledge across team members or even across teams is pair programming. Personally, I find it more effective than reviews. The interactions and discussions during coding are invaluable. How good it works often depends on how well the two developers can get along - from experience I can say that putting together very different people can actually yield the best results, though.

(22) Features get stuck without a proper release process. This one might seem obvious but can easily be missed. I have witnessed features stuck in limbo for months because nobody really knew how to progress with a finished feature sitting in a branch. It is paramount to have a clear understanding about who has which responsibilities or, even better, have someone who’s job it is to take care of that.

(23) Great things happen when there is autonomy. Giving developers the opportunity to work on things on the side can become a powerful source for innovation. When a company supports this natural drive excellent developers have, great things happen. If it does not, the most dedicated developers will make their own opportunities anyway (e.g. working overtime or weekends) which can lead to unhappiness or even burnout in the long run.

(24) When you want a message to stick, say it again and again. You have an important message you want everyone to understand, share and remember. You cannot just say it once. Or just put it on a slide, in bold letters. You need to repeat it, again and again. It needs to be crystal clear. There should be no doubt about what you say. For further advice read the excellent book Make it Stick.

(25) Hacks are a big part of startup culture. A startup always has more things to do than resources to do it. Prioritization is essential. And this often means to quickly hack together a solution that barely works. Sometimes for good reasons, like prototyping a feature and seeing if it sticks. But if it does, you rarely have the time to go back and make it better. However, what I have always found very irritating was how much a hack can be celebrated. It always felt like cheating to me. But I have come to terms with it: Hacks are a necessary evil at any startup. Just don’t overdo it, please.

(26) Deadlines are stupid. In today’s ever changing world, a deadline is an artifact of the past. Deadlines only make a manager feel good, but kill everything that is good about software development. The further the deadline is a way, the more ridiculous and dangerous it becomes. The only thing that is worse are deadlines plus a set of requirements. This brings us back to the ancient beginnings of software development. There is no place for deadlines in the future.

Thank you for reading. I will join another startup soon, this time in Toronto. I am certain I am going to learn numerous new lessons there.

comments powered by Disqus