This post describes my first job after graduation from university at a startup called DemoUp. It’s a follow-up to the post describing my student job.
What stuck
In retrospect, it feels like DemoUp engraved a certain work style and preference set into me: Small team. No superfluous fuss or “politics”. The right amount of process for the team size.1 Time for uninterrupted deep work. The trust that people will do their job if left to their own accord, as long as help is provided when needed. That — of course — a small, tight-knit team can solve nearly any challenge with code, as long as the willingness to invest the required time is given. That a single developer can — on their own accord, and as needed — do front end work, back end work, statistics-heavy “big-data” crunching, cloud infrastructure and DevOps work, as well as customer support, user interface and -flow design, or really anything else even if it’s their first time. I’m grateful for having matured in this school of thinking.
Thesis, first failure, and the come-back
Accidentally, I stumbled into a free GoTo conference ticket in London.2 That conference pushed me to go where new software was built, and where it was central to the businesses activities. At the “Agile”-themed conference, attendees told stories over bonding Martinis about their well-paying jobs in the banking-heavy London. Afterwards I despised the idea of ending up in a cost-center where the transition to “agile” or CI/CD would be a year-long fight against five dusty layers of management and heavy regulatory frameworks. I wanted a fast-paced environment where personal growth would be unavoidable.3 Startups in Germany were clustered in Berlin, so that’s where I wanted to move. DemoUp was on some “top 20” up-and-coming list, and I passed the friendly “interview process” — aka a 30 minute long conversation on the phone. That’s how I ended up at DemoUp. The company was 6 months old and had just pivoted. DemoUp re-started at 0, exactly like I was in the unique, strange Berlin.
The thesis was about using machine learning classification to match data sets. It was early days for me, machine learning in mainstream computing, and there wasn’t much of a pre-existing data set to speak of. I produced a mightily nice thesis touting the ML algorithm I had trained to solve the problem, with supporting stats to prove success. The thesis won a prize as best thesis of my study-program for the year. DemoUp offered me my first full-time job, which was a good bargain — because the work was innovative, DemoUp got a government grant paying half of my salary. My task was simple: Ship the ML algorithm I had spent half a year researching. I was in for a rude awakening: Despite warnings, I had not designed the system to sufficiently counter-act overfitting of the ML algorithm. So when I proudly rolled out the fancy ML system, and first new, unique real-world data started to hit it, the output was utter garbage. The system was crucial to a business process tied to the value proposition of the SaaS, so this launch was a failure that impacted all of my new colleagues. They were gracious to not laugh at me or put me under pressure. I pulled dopamine-filled all-nighters. There was just no way that I was going to have my start into the world of being a grown-up employee stained by disappointing work outputs. With success: Within weeks I launched an entirely new system that — fine-tuned over more months — was leap and bounds beyond what I had hoped for. It was so good that it was repeatedly discussed to drop the workforce of 5—10 people quality-checking the results — a sign of what was to come with AI today.
Scaling
With that business process taken care of, my work’s focus shifted towards building out the SaaS’ feature set, and to help scale it. As more and larger and larger customer purchased the solution, traffic exploded, regularly taking our systems down. There were countless and fruitful hours of talking in front of whiteboards, discussing how to systematically solve scaling related bottlenecks. Once a certain routine over handling and remediating scaling issues started to settle in, systems groaning under load became less scary and more of a daunting brain-tickle, a fun challenge to solve. One got an intuition for where the next issues would pop up and why. There was a thrill to not knowing how to make something 10x more efficient, to not know whether such a thing could be done (in such a small team) — until we did it. And then all over again. Only today I’ve become aware how valuable this experience has been of being allowed to do “system architecture” at this stage of my career. The scars lead me to a level of big-picture thinking that does not seem to come natural to developers not having gone through something similar.
Moving on
But at some point we had optimized the systems more than the customer base kept growing. The business had achieved decent product-market-fit and reached break-even, but years-long sales cycles made it hard to maintain a high growth rate in a centralized market. As the startup’s growth tapered off, so did my personal learning curve. I knew I had to move on in search of new challenges. The CTO was about to have a child, and the other developer in our team of 3 also handed in his resignation. I offered to stay a few more months so that the CTO could do a paternity leave. Being the whole IT team on my own was only possible because of the company’s stagnant situation and because the systems had been so well-optimized. Still, seeing that I could operate an entire SaaS on my own was nice to see.
Knowing that I could do a decent-enough job in front end, back end, cloud and DevOps tasks, as well as manage myself, I exited DemoUp with my head held high, full of self-confidence and willingness to take on ownership. This attitude was likely part of the reason that I got the chance to go from being hired as fullstack developer, to being proposed and accepted as front end team lead within 3 months at my next job, even though I was so young and inexperienced. That job taught me quite different, similarly valuable lessons about professional, collaborative development in larger teams in larger orgs, and the step-change from IC to responsibility for a team.
But let me pick my poison today, and I still gravitate back towards the “DemoUp work style”. Thank you, Stefan and Björn! I’ve been lucky to have worked with you. I couldn’t think of a better first job, especially after the years of Covid, where this level of learning likely wouldn’t have happened for an inexperienced young peep like me.
Footnotes
-
We didn’t even have a “proper” ticket system. Nevertheless, we dared to make fun of the other startup in our office, which ran full-fledged scrum at the same team size. They seemed to spend half of their work time with pointless self-management activities. I miss sitting right next to my whole team and being able to do all alignment necessary by shouting a friendly word after ensuring that they were free for a chat with a side-glimpse at their monitor. ↩
-
I could barely pay for the flight and stayed at the most run-down Airbnb, sharing a bunk-bed with a South Korean guy wanting to apply at TransferWise — it seems that he had a good feeler for Wise’s future trajectory. ↩
-
Probably not an accident after my student job, that was closer to a “real first job” than a temp job, and that was startup-like in terms of learning, ownership, and company size. ↩