Developer growth, Startups, Valuable Resources

2018 in review

As is the tradition I want to spend a few minutes reflecting on the year 2018. I find that taking time to reflect gives me a perspective of where I am on my journey. Reflecting also helps give closure and allows me to direct my thoughts and efforts towards what I want to accomplish in the future.

2018 has been one of the most exciting years from a professional perspective. From a personal growth perspective, 2018 has been both rewarding and frustrating. How can this be, you may ask (or not)? I’m asking at least and will be exploring that in this post.

Putting things into perspective

Having some perspective on where you are in life brings context. It allows you to understand where you need to focus your efforts and what you can expect from the outcomes. Without perspective, expectations run amok, and this has been a theme of mine for the last year.

Let’s add some perspective by looking at the themes of the past few years:

Change, Challenges, and Struggle

This year brought around a significant change – a shift in careers. I transitioned from a Web Developer / Team Lead with a path towards Agile Coach / Management / Leadership type of roles at a larger company to becoming a founding employee at the startup, Dolittle (more on this some other time).

The role I took, and currently have is User Experience Lead / Web Developer, and as with any (small) company; titles mean nothing. User Experience is a new field for me to dive in to, practice and build skills in. Even though I’ve been a developer for many years, building applications in modern JavaScript has been an exciting challenge.

Days have been filled with more frontend and JavaScript work than any before, both for our products and client projects as well as all the aspects of building a great culture and the fundaments of a company that will last for years to come.


Working in any startup is hectic, and that’s also what I experienced, even though we limited ourselves to regular workdays, the sheer number of balls we needed to juggle was overwhelming at times. The transition has been exciting, invigorating and also painful. On one side I’ve wanted to explore and establish what UX is at Dolittle, and on the other, coding and working with clients to bring in some income naturally took precedence. All of the while fumbling trying to get on board with modern JavaScript Web Development. This lead to a feeling of not feeling adequate or competent in any of the work I was doing.

Another consequence of feeling like all my energy was going towards not accomplishing things were the negative thoughts and the stories I was telling myself. Luckily for me, the people I decided to work with that Dolittle are some of the best humans I’ve ever had the privilege to know, second only to my life partner, and they offered their support. But the feelings still lingered – this was something I needed to work through and deal with for myself. Which leads to my next real failure – Not taking time to reflect and process how much I was learning.

On a related note, I realise that previous accomplishments have been holding me back from future achievements. I’ve struggled to put my self and content out there for several reasons, one of them has been constantly comparing and raising the bar based on those previous accomplishments, without applying any form of context or perspective. The word "should" has been used way too often, which leads to an internal dialogue of shame.


Things were looking a lot brighter towards the end of the year. I was more comfortable with the day-to-day challenges we had at work, as well being able to acknowledge my role and the contributions I was making. The brighter outlook gave me some space to reflect on my learnings. I was also able to identify a weakness I had (with help from colleagues), namely that I self-censor myself a lot. This weakness manifested itself in not speaking up in meetings, not sharing my thoughts on what I felt was important through other communication channels, and also it put a solid block over any attempt I made to write anything in public. Holding back thoughts isn’t to be confused with reflecting and pondering over a topic before forming an opinion (which I also do), but when it was evident that I had something to ask or say – I didn’t.

I was afraid. Afraid to not have the right answer, to appear foolish and found it easier to keep thoughts within. Identifying this specific behaviour has been a critical discovery. Being afraid of allowing myself to be imperfect is a root behaviour for quite a lot of the issue I’ve been facing, and is something I’ll be working on in the coming year.

As I mentioned earlier, being in a startup means wearing multiple hats, and this has been the year I re-embraced modern javascript web development with AureliaJS. It’s been a painful process of wanting to deliver and ship great products but stumble on "simple" things like identifying component abstractions, understanding es6 syntax, as well as learn the framework itself. My inner voice talking down these learnings as simple things is another manifestation of the "should"-problem with unrealistic expectations.

When I now look back, I’m proud of the progress I’ve made in this area. From feeling inadequate to be able to write and structure applications, write re-usable and business components, and drive application logic with TDD in less than a year has been a huge win.

None of my learnings would have been possible without the people I’m around me. They say that you are the average of the 5 people closest to you, and I’m surrounded by 5 of the most influential people in my career, not to mention them surrounded by others they are equally influenced by. I’m humbled, honoured and so privileged to be able to work in these conditions.

On a private note

On a private note, I want to mention running. 2018 has been the year I purposefully made running a habit. I have some big hairy goals for 2019 when it comes to running, namely complete a marathon towards the end of the year, which means taking the habit and applying running plans & structure.

I’ve also cut drastically down on phone usage around the family as well. Disabled my facebook account, removed twitter from my phone, and optimised more time to be present with them. It’s come in handy as our 3rd child has made the transition from innocent toddler to chaos monster (3 yrs old).

I’ve also been able to plough through quite a few books during my commutes. For anyone interested, you can see my progress on Goodreads.

In conclusion

Summarising the ups and downs of an entire year in a post is challenging in itself, and writing this has been a lot harder than expected. I knew I wanted to write this before spending time on anything else, so it had the potential to become a blocker for me.

I also wanted this to be a personal reflection post, rather than a set of useful tips, things I’ve learned, quick wins — lists of accomplishments, contributions and side projects. There’s enough of that out there. Instead, I hope this post reminds people that life is messy. We all have our ups and downs, our cycles of growth, expansion, reflection. That doesn’t mean that you’re less than others in any way, just that you’re human and on your own journey.

At the end of the day, I’m privileged to work alongside some fantastic people, on a great mission together, building the company we’ve always wanted to work in. All the while, having a precious family life and being able to spend quality with my kids.

In retrospect, the year 2018 has been precisely what I needed to prepare for me for 2019. That’s how I choose to see it, at least, and perhaps that’s enough?

How has 2018 been for you? How are you doing with the transition to 2019? Please share your thoughts and reflections.

Cover photo by NordWood Themes on Unsplash

Agile, Startups

Proof of Concept? MVP? Just tell me when it’s done!

The meeting between iterative product development and a company used to approaching product development through the project-lens can be quite harsh.

On one hand, you have set budgets and revenue targets. The project deliveries have been planned out in detail for the coming months, quarters or even years, with a chain of dependencies for the rest of the year.

On the other hand, you need to follow up deliveries and make day-to-day decisions that affect the scope and the end product drastically in a true agile manner.

All the while nobody can give an answer to whether you’ll hit your targets or not. And you, as a stakeholder or project owner, just want to know when it will be done!

Here’s the deal…

There are a few things to note when moving into this world of digitalising organisations and iterative product development.

  • Agile™️ doesn’t mean faster or cheaper.
  • You decide when it’s done.
  • Product development is hard.

If you’re willing to take my word for it then you can stop reading now. Otherwise, please continue…

Agile / DevOps / Lean doesn’t mean faster, cheaper or easier

Digitisation has been sold into organisations as the “way to go” and alongside this the notion of some form of agile software development. The implication (or outright promise) is that this form of development will be faster, cheaper or both. There are no guarantees of this.

Instead, what these practices mean is that you are able to test your assumptions in a more iterative manner. This means you can create just enough of a product that will allow a customer to use it and give you feedback before your next iteration. So, in this sense, it’s a lot cheaper to verify you are on the right path, and the cost of course-correcting is a lower than if this was a project going over several months or years.

Working this way is more demanding of your time, as you are now part of the team that builds and discovers the product — you need to be available on a more ad-hoc schedule. There are more small follow-up meetings and constant changes to priorities based on customer feedback, or new opportunities. Working like this is engaging and fun, but it can also be draining. Especially if you’re used to the more traditional “ordering” of software through larger “waterfall” -projects.

Product Development is Hard

The hardest part of building a software product is knowing what to build. You may have an idea of what you want to create, but will that actually meet people’s needs? Saying you need an app or a service doesn’t instantly make it something that people want to use. The only way to find the market-fit is to test it out with real customers and users. This is what an iterative development methodology offers — the chance to test assumptions before you run out of budget (money, time, goodwill, etc).

Gone are the days where business and in-house customers accepted sub-par products to be able to get their work done. Consumers are used to sleek, intuitive apps on the web and their devices. There’s no magic switch that causes these same people to lower the bar of what they expect when they enter their work setting.

This expectation of quality becomes a challenge for businesses wanting to raise the bar. As the quality of the products improves, so does the need to build the right thing. It is crucial to verify whether the pain you are trying to address is one the people using your product actually feel, and want dealt with.

To keep up with this pace means focusing more on product development as a core discipline, instead of something to be outsourced or managed from afar.

You decide when it’s done.

The dirty secret is that “it” is never really done — the elusive product remains a moving target. Getting something out the door is just the first step. Instead, the focus should be:

  • When is the product good enough to be valuable to the people using it?
  • How much are you willing to spend to find out how close you are to fulfilling those needs?
  • How do you know the product is actually attending to the needs and delivering value?

With an iterative process, you have the opportunity to approach answering these questions and respond by changing the direction of your product. But the only way I’ve found to get real feedback is to give full slices of functionality in front of real users.

Sketches, prototypes, proofs of concepts and minimum viable products are all viable approaches to elicit feedback — the earlier the better. Pick your flavour, be harsh with the scope, and get a working product out there!


Organisations’ need for fixed budgets, scopes and roadmaps can hinder you from realising the tantalising promise of value in a truly iterative product development cycle. That value is the agility to be able to respond to changing needs, and new opportunities.

Embrace experimentation through continuous feedback cycles and adjust the reality of where you are with a product based on them. Based on these feedback cycles you’ll know when you’re done.

Clap ? or follow Dolittle to read more about how we believe in enabling others to create products that help users feel like superheroes.

Cover Photo byJosé Alejandro Cuffia on Unsplash

This post appeared originally on the Dolittle blog