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.

Failure

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.

Growth

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!

Finally

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

Communication, General, Teams

Hitting Refresh

Unlearning is one of the hardest parts with any transition. You bring with you many years of experiences, expectations and biases. These have built up over time through different work situations you have adapted to. Past experiences allow you to hit the ground running when it comes to work and communication. They can also be heavy baggage, slowing you down. In a startup this baggage could be the very thing that’s holding you back. You’re looking at completely new problems with views that don’t match your situation.

Here at Dolittle, we’re hitting refresh on many of our previous assumptions. Looking at old problems with fresh eyes. How we approach our coding practices. How we are working with customers. How we are approaching contracts. How we are building products. We’re re-learning, and allowing our culture to grow.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind there are few. ” –Shunryu Suzuki

An example is communication. Coming from a very distributed team, a few of us wanted a more formal process. More documentation, more written communication. This is important down the line as we grow, but not so much in the beginning when priorities change almost daily.

Hitting refresh is an important part of starting anything new. Making it explicit that you need to take a step back and reconsider your expectations. You’re going to have new problems and you can’t deal with them if your focusing on solving the problems you had in the past. At the same time, it’s importatnt to leverage universal learnings and principles. It’s also important to recognise the context in which those are valid.

Are they really valid to you now?

Photo by rawpixel on Unsplash


This post appeared originally on the Dolittle blog

Developer growth

Tribes – a search for belonging

Finding your tribe isn’t easy. It’s a long journey of many missteps. You may be part of a tribe your entire life. You may wander to look for other tribes out there and dive back into your old tribe for safety. Other times you need to find another to call your own. Sometimes you need to start your own with your closest around you. Other times you need to just start, and hope others will follow.

Tribes

But, what do I mean with a tribe? In this context I’m using it as a community where you feel a sense of belonging. Originally, tribes were defined by proximity, the land you belonged to. So changing tribes was a physical action. Moving from one area to another. Going through rituals and sacrifices to leave your original tribe and be accepted in your new one. It took a lot of friction.

In society today the sense of belonging to a certain part of land isn’t what defines our tribe any longer. We define it in other ways like: race, nationality, gender, faith, community, workplace, hobbies etc. Some are hierarchical, like your team, that resides within your department in your organization and others are virtual, like social media groups, forums, interests, programming languages.

In our digital age there is a lot less friction to switch between tribes. You can find a virtual tribe, where switching could be as simple as joining another group. You can physically move across the world and still stay in the same virtual tribe, even though you may change your physical one.

A sense of belonging

As we grow and mature, we all go through our own versions of “the hero’s journey”. Moving through life, searching for a place of belonging.

My family tribe has always been important to me, it’s the most rock-solid tribe I belong to. Our shared values define the core of my belief and value system, and in extension is the lens I see the world through.

Another tribe that gives me a sense of fulfilment is meaningful work alongside caring individuals. Working to make a change in this world for the better. It’s what’s guided me unconsciously so far, and now what I’m starting to become more aware of and act upon.

The search

It’s become easier than ever to find and change tribes. It’s also easier than ever to get distracted in your search. The best we can do is follow our heart, and not settle. As we grow, so do our needs and finding a tribe that allows you to grow to your full potential is something I think is worth searching for.

As I’ve become more aware of my journey and what is important to me, I’ve also been more aware of what I want from my tribe. I’m sure this will evolve and change as I grow, and I’m sure that no tribe will be a perfect match. I do know that when I see something that is closer to my own values I need to make the move. How else will I know if it’s what I need?

“If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on.” ― Steve Jobs

So, if you’ve found your tribe – cherish it, nourish it and consider yourself lucky. If not, work through the friction and don’t settle.

Communication, Teams

Please, break the build!

The feeling when you hit the button and push the code to server. You’re done! You’ve implemented a new feature that’s going to be ready for the end-user. Soon. You see that the code has reached the build machine, and a new build gets scheduled. You get up to take a quick break and end up chatting with a few colleagues on the way. When you get back you see there are 10 messages in your inbox and the same number of notifications on your team chat.

Looking around, you see that the scheduled build has failed. And now there are 5 other schedules builds that ended up failing. It looks like you’ve just broken the build. The rest of the team of 20 developers are now blocked from committing in their code.

You sit down feeling… Continue Reading

Developer growth, Practice Empathy

Rituals of Shaming in the Software Industry

The career of being a software developer can be a bumpy one. From the very start you are challenged by technical challenges you have no idea how to solve. Some grasp the concepts and principles easily, while others struggle. It’s an uphill climb of continuous learning. Constant failure, and success just a semi-colon away.

One of the biggest challenges during this process isn’t technical, but rather social. Around each turn you uncover new wonders, and new challenges. When you start a new job or position, publish a blog post, submit a pull request or even make a product. There will be people lined up to tell you how wrong you are and as a result; how you’re not good enough. I’m here to tell you, that you are!

Continue Reading

Communication, Practice Empathy

Adding more Empathy to Pull Requests

Using tools like GitHub or BitBucket allow developers to able to submit their changes through pull requests. One of the challenges with pull requests is that they often contain very little information, apart from the change itself and perhaps the issue or case in question. Bad pull requests make the lives of reviewers a lot harder, and mean they need to spend a lot of time understanding the context. Instead of focusing on the change itself.

So, how can you improve your pull requests? Continue Reading

Community, Valuable Resources

Reflecting on 2016

We’re coming upon the end of another year. An eventful year that may have left you with a mix of feelings. Some people wish for 2016 to just get over with and hope for a more positive 2017. I won’t dwell on those aspects. Let’s let the years events be and do what we must to improve and make it better.

On a personal note, I’ve come a long way in the past year and as a result, so has this blog. It’s hard to imagine I was just coming out of a period of burnout, struggle and depression. My recovery manifested itself into the journey that is this blog and everything that’s spawned out of it. I’ve made some wonderful connections along the way, and what better way to celebrate the end of the year than to celebrate these connections? Continue Reading