Why I work

A “Scrum”, photo by Olga Guryanova on unsplash.com

The answer to this question is quite bland, so let’s get it out of the way right away, shall we? I work to earn a living. Nothing else. No noble motives, no making dents in the universe, no caring for our users, not even to party with my colleagues.

If the answer is so simple, why do I even write this piece? I do so in preparation for another essay that I volunteered to write for work, “How do we want to work?” To understand the “how”, it helps to think about the “why” first. The piece for work will talk about we, the company. Obviously, the “why” for we, the company, will be quite different from me, the computer scientist gone product manager. But, it shouldn’t hurt to dig into my personal motives first, if only to better consider the motives of my colleagues.

And, it was not always like that. In the beginning of my career, I enjoyed myself so much that many times I found it quite unfair to ask for money for my work at all. But let me give you a bit of background on me. I am a computer scientist and earned my degree of Diplom-Informatiker in 1989. In 1995, I defended my PhD thesis on Encapsulating Tools into an EDA Framework. I worked in academia, led technology teams through the dot com era, ran an internet agency for seven happy years (we specialized on Drupal and content management), served as head of technology and lead developer for several venture-funded startups, did a short stint as technical customer service rep for a Drupal SaaS company, followed by some more agency work, and finally arrived at my current employer, first as senior developer and for a little over year now as product owner of a Scrum team.

Obviously, I am a very experienced software developer, doing so professionally for nearly 30 years. I am also something of a programming language nerd. Sadly however, I totally missed the opportunity to get into Smalltalk in the 80s, although this language was quite strong at my university with Georg Heeg nearby. Instead, I got early exposure to YACC & Lex, immersed myself in the scripting revolution of the early 90s with languages like Tcl and Self. After some aberration into the lands of pain I somehow got stuck with the ugly duckling PHP. Sadly again, I never managed to get a sustainable foot into Python territory, although I very much love the language.

After some early euphoria, since the exposure with Java and the mess that is object-oriented PHP, I am very skeptical of the merits of object orientation in its modern form. Although I am not alone with this notion, of course my fellow Symfony developers are indoctrinated to think differently.

But I left these discussions behind, at least for my day job. My current position is quite a privileged one. We run a very successful website (one of Germany’s biggest), are liked by our users, and we have a solid business. I have bright and highly motivated colleagues, who strive to give their best for the future of the company, maybe a little bit for their personal careers, too. We use the latest technologies, agile processes, have established a solid value system, a sound vision, and are currently defining a strategy that will carry us through the years to come.

As product manager, I have direct influence on the direction of our product development efforts and can give positive value to the everyday lives of our users. Through my involvement with our internal content management system (which recently relaunched on Drupal 8 — yay!) I also get positive vibes from our internal editors as well as from our sales people that use the CMS to device native integrations for our valued corporate partners.

All nice and dandy, you would think. The thing that bugs me though is that I am still selling my time, much the same as I did in my agency years. Even then did I have the nagging feeling that there should be a better, more scalable way to spend my time. I am now 53 and feel that the time I invest into work should contribute to me having to work less in the future.

Not that I don’t enjoy what I do. Being a product manager really helps me to focus on the product, and not get distracted by some technology under the hood. Ultimately, the technology is irrelevant, if only the product is useful and commercially sustainable. But, there are probably more valuable ways to spend my time, if only I could afford them. One thing I very much enjoy is to give workshops on technology for children and teenagers. I currently prepare for a workshop on Physical Computing and the Internet of Things at the Deutsches Museum Bonn. I would love to do more of these.

But, until I haven’t found a more lucrative mode to run these workshops or found some sources of passive income, I am stuck with my day job. At least then, I can try to make my work there as effective as possible. Which leads me to another — besides object-orientation — pet peeve of mine: The delusion that Scrum — the process — is all it takes to run a successful business. No it doesn’t! It even doesn’t if you replace Scrum with Kanban or some other agile process that is nicely supported by some Atlassian tool or copious Post-its. I am totally in line with Eric Ries that, if both your problem and your solution are unknown, you better embed your software development efforts into some grander scheme, at least involving some customer discovery, but certainly lots and lots of Hypothesis building and validation. Unfortunately, Eric chose to name his methodology The Lean Startup. For much too long, we where convinced that these tools don’t apply to us. After all, we are a mature business, successfully in operation since 1998. But times are changing. No longer are banner ads, optimized for desktop, an attractive and sustainable business model. We have to find new ways to keep the wheels running, and better do so fast and effectively.

And, if you don’t know what the perfect organization would be for such an endeavor, most certainly the vanilla agile development team isn’t at your core, with all the other departments like SEO, UX, design, BI, and sales feeding the product owner of that dev team with there notion of what the requirements are.

Now you know why I volunteer to write that paper, “How we want to work.” I believe I have some background, experience and world views to contribute. Maybe you agree.