For sentimental reasons, I recently bought a ZX Spectrum from a dear colleague, but what to do with it? I could play games from my childhood, but why not make my own?! The Speccy, after all, was what created a generation of bedroom coders. Because of the 8-bit hardware limitations, this would be an excellent opportunity to flex my programming muscle, something I do not get to do all that often.

In July 2013, I posted my workplace manifesto on a Tumblr blog I had back then. It was a list of five priorities I wanted for a current – or future workplace; some of them felt a bit far-fetched or maybe even utopian, so how do they stack up today? The Manifesto Without further ado here is the manifesto: Be able to work on projects that excite you! Be able to put in the hours to finish the project and NOT be bound by the project’s price-tag. Be able to work when and where you are motivated, even if this is at nine o’clock in the evening or in a café or at home. Be able to choose the right technology for the project, and not the other way around. Be able to work with the right set of tools on the job and not the workplace “default” that has been decided by IT or any other who have no idea of what works best for you. When I wrote this manifesto, I worked as a consultant and solution architect at Creuna, working on various enterprise solutions often limited by its contract. I was frustrated about the limitations to how many hours I could spend on a specific project, dictated with a fixed-price-contract, and the types of projects I had to work on; not all of them motivated me. I worked on predominantly CMS-solutions, so new projects were described as either a Sitecore – or Episerver project, not by the site’s actual goal. Also, I had not yet become a dad, so the restrictions of a traditional nine-to-five job felt very limiting.

A current trend in our industry is to formulate your goals as Objectives and Key Results (or OKR). However, there are a few challenges when implementing OKR, especially on a team level. This post is an overview of how we use (or misuse) OKR on a small development team. To give you a little context, our team consists of 3 developers and a product owner (that is I). We have a daily stand-up every day at noon and do refinement session once a week. Everyone (including myself) are attending all team meetings (including retrospectives). We use a Kanban board to support the prioritization of work and tracking progress. We do not use sprints or commit to work that we need to deliver within a specific deadline; instead, we communicate expected delivery dates based on our lead time.

When asked to do a presentation about something or the other, I struggle to find the motivation from time-to-time. Here are a few tips on what I do when preparing for a talk. To quickly summarize, these are the steps I go through: Somehow make the subject exciting Challenge myself Think about the presentation; can I make this entertaining to the participants Make the Subject Exciting Often I am asked to make a presentation about something I know by heart, which is great because this means that I probably have a presentation already on the subject tucked away somewhere that I can reuse. On the other hand, this means that I probably have talked about the subject so often that I might come off sounding a bit uninterested and unexcited when I give yet another talk.

I work as a Lead Platform Architect at the LEGO Group, where I am the acting product owner of our analytics platform supporting the digital consumer space. In my spare time, I like to work on old retro 8-bit computers. I have some experience speaking internally and externally. I would, however, like to sharpen that tool even further. Therefore, I am seeking speaking opportunities outside of my work, be it conferences or local events (virtual or in-person).

Although I’m not a big fan of New Year’s resolutions, I like the idea of a new year = new habits, so here are mine: Start blogging again Quit social media and YouTube Start lifelogging …and here is why: Make a Personal Blog I used to write more in my previous jobs as a developer and solution architect but stopped about six years ago when I started working in my current position at LEGO. Now it is certainly not because I am not allowed to do it, it was just no longer a requirement as part of my job title, so I directed focus elsewhere. However, I miss having a voice outside of what I do every day, and when given the change/permission, I would also love to share the things I work on there.