Weekly blog posts about creative work in the tech industry

Productive Conflict Is a Journey Not a War

Nov 18, 2018

Conflict at your workplace is unavoidable. It will happen. People will disagree: Everyone won’t see eye to eye on a budget estimate. There will be a product feature that divides opinions. The coffee brand served at your office will not be everyone’s favorite.

Conflict is not a negative thing or a thing to be afraid of. First of all, it’s bound to happen. Second, it can move your organization forward. Conflict forces us to listen, open our eyes to new ideas, and vocalize real problems.

But our way of dealing with conflict can be good or bad–productive or unproductive. And none of us are perfect. While we can be skillful with some areas of conflict and communication, we will fall short with others.

There are also ways of communicating that come more naturally for us. This is stuff that's part of our personality. Or stuff that we carry with us from our childhood homes, personal relationships, and cultural contexts.

Conflict avoidant vs. conflict seeking

To simplify things, your default way of dealing with conflict can be considered as conflict avoidant or conflict seeking. Instinctively, you either hide from conflict or you seek it out. Neither is better than the other but in the extreme, they are both unhealthy.

I have heard these two types of conflict styles compared to battle tactics: you either build a bunker and hide from the enemy or you jump into a tank and charge the enemy position.

The problem with these kind of tactics is that you are preparing for a war where there are winners and losers. You are not preparing for a journey where everyone will better off in the end.

By default, I personally seek out conflict. When a conflict suddenly emerges I usually charge towards it rather than run away from it. This means that from my side, poor conflict resolution is often caused by over-aggressive communication. I push too hard instead of calming down and really listening what the other person has to say.

Being present in conflict

Even though you might be aware of what’s your conflict style, you won’t automatically learn how to avoid unproductive communication. This is because with conflict comes feelings and emotional responses. Feelings make it harder for us to control ourselves. We get an urge to either shut down or attack.

Instead of denying your feelings, you should acknowledge their existence. After that, try to dig a little deeper and articulate your feelings for yourself. Try your best to be honest. Do you have a need to be right or a need to be seen by the other party? Are you afraid that the other party doesn’t care about the issue as much as you do?

If you know your default conflict style and you are able to identify your feelings, perhaps it will be easier for you to prepare yourself for situations where conflict might arise.

This is a hack from author and business thinker Nilofer Merchant that I want to give a try. It’s taken from Merchant’s article about the importance of listening when creating change. It's a practice you can do when preparing for meetings, workshops or any other events:

Find an index card or sheet of paper (a paper napkin will also do). On one side, write key ideas that could be useful for you to share. […] On the other side, brainstorm questions you want to ask and things you hope to learn.

This practice forces you to make a physical act to acknowledge that it’s at least as equally important for you to listen than it is to talk.

It’s not important if you don’t get to ask the questions as they are written down. What’s more important is that you have primed yourself for curiosity and listening. You have primed yourself for a journey, not for a war.


Are you conflict avoidant or conflict seeking? What can you do to become better at conflict resolution?

Skip Mockups When Building Skateboards

Nov 11, 2018

If you need to deliver a usable product version in two weeks, you should stay away from mockups.

To explain more, I need to start with a software development picture from Henrik Kniberg that I keep seeing more and more frequently:

Henrik Kniberg's drawing of the MVP process

This picture teaches us that iterative product development doesn't mean that we deliver the final product in unusable parts to our clients. Instead, iterative product development should mean that we try our best to deliver usable versions of the product that we are building.

When building a car for the purpose of moving around in the world, our first deliverable isn't a car tire—it's a skateboard. This might feel like a useless or an unproductive development step. But it's actually a step towards true learning and meaningful software.

We can't give our client a car tire and learn about how they use it to transport themselves. A car tire won't enable you to move around. Our clients can't test their product assumptions with a tire.

The skateboard is different. Our clients can use the skateboard. When using the skateboard, our clients will learn more about what are the most important things about transport in general. We the developers will learn how our clients actually interact with a vehicle.

The problem with mockups

When a client comes to you with a goal or a problem they need to solve with software, your first design step should be to figure out what's the smallest useful thing that you can build for that client. When you have that figured out, you can start thinking about the minimum amount of functionalities and requirements needed to deliver something useful.

If your first design step is to open Sketch or Adobe XD on your computer, it's very likely that the north star of your design process won't be the smallest possible usable thing. Instead, you will draft a non-embarrasing version of a product and let that guide your development.

We don't turn mockups into actual software with one iteration. High-definition mockups are never that small in scope. Because of this, we break mockups down into smaller parts; we figure out in which order to build the final product. Our deliverables become car tires and not skateboards.

Additional notes

This post is mainly inspired by a discussion between Ben Orenstein and Adam Wathan on Full Stack Radio.


Junot Díaz and Being a Playful Creator

Nov 4, 2018

Last year the Pulitzer Price winning writer and professor Junot Díaz visited the city I was living in. I snuck into one of his talks he gave to the writer students in the local MFA program.

This week I came across my notes from that talk. They were short and they were primarily about the art of writing. But I feel like I need to share them with you. The notes reminded me how writing code should mainly be a source of joy, not anxiety.


In addition to writing his own novels, Díaz teaches writing students at MIT. One of the things he is able to sense from the students is the massive stress they have from writing. There is an intense pressure to perform well. It’s much rarer to find true joy and gratitude among the students.

These are three points that Díaz would like you to remember if you are feeling a little less joyful and a little more anxious.

First, you should play. Díaz compares writing to basketball. You can earn money from both writing and playing basketball. You can also write and play basketball just for fun. Here is one major difference between these two: it’s really hard to imagine a basketball player being afraid of the ball the same way a writer can be afraid of the typewriter. That’s because it’s so much easier for the writer to forget that there is play and joy involved in the process of writing.

Second, Díaz says that you should sometimes avoid your art culture. In this context, your art culture are your peers, critics, audiences and other relevant authorities.

Why should you avoid these things? Won’t this ecosystem make you stronger in your art? Díaz argues that your culture will try to destroy your childlike wonder and genuine love for your art. Your culture says that your art doesn’t have value if the critics don’t praise it or the public give money for it.

Third, there is no one right path. Not every writer will take the same journey. And more importantly, not every journey is suitable for every writer. There are options for you. So instead of stressing over your next move, just do something. Or don’t do anything and just play with your art.


When Díaz sees a student in their twenties struggling with writer’s block, losing sleep because of stress, and generally taking no joy from the fact that they get to write, he can’t but wonder where will this person be in their sixties. Will their mental state still be dictated by external validation? Will they still write from a place of misery? Will they spend the next 40 years basically torturing themselves?

The problem with being a writer is that there is no guarantee that your hard work will result in success. There is no formula for writing a best seller. There is no mind control device you can use to make people like your book.

It’s so easy to set yourself up for disappointment.


Interruptions That Lead to Interruptions

Oct 27, 2018

You have probably experienced the frustration of not being able to focus when a book, research paper, tutorial, or a cognitively challenging task needs your undivided attention. Depending on your job, the majority of these feelings of frustration might occur at work.

It’s easy for us to understand how a loud office and constant calls to your phone create interruptions for you. These interruptions reduce your ability to focus. You can’t hear yourself think. You are not able to get in to flow.

But maybe after a busy morning your office quiets down. Or maybe you move yourself to a quiet space after the interruptions become too much to handle.

The interruptions disappear. Your issue with focus and attention should now be solved.

Except you will still struggle to focus. Why?

Researchers Laura Dabbish, Gloria Mark, and Victor Gonzalez have found out that external interruptions lead to self-interruptions (Why Do I Keep Interrupting Myself?: Environment, Habit and Self-Interruption). External interruptions are interruptions caused by other people or, for example, software notifications. Self-interruptions occur when you abandon an ongoing task or switch your focus without an external cause.

A classic self-interruption is you switching your browser tab to Twitter or Facebook just because you felt like it.

Even though external and self-initiated interruptions differ in their nature, they are connected to each other. If you experience a lot of external interruptions you are more likely to have increased amounts of self-interruptions throughout your day. In their research, Dabbish, Mark, and Gonzalez conclude that “external interruptions experienced in the previous hour significantly increase the incidence of self interruption in the subsequent hour.”

We get used to a certain interruption level: People working in open offices experience more self-interruptions. People who feed their habit of multitasking experience more self-interruptions.

We are interrupted in our work every 4 to 11 minutes. And half of those interruptions are self-interruptions. The significance of self-initiated interruptions in your ability to focus is much larger than you probably thought.

What are the actions that you will take in order to reduce those interruptions?

1f6a3 1f3fe.192x192

Individuals and Interactions over Processes and Tools

Oct 21, 2018

Two weeks ago I wrote about the four agile software development values and how it would be great for all of us to every now and then stop and think what do these values mean to us and our communities. Here’s a link to that post.

The very first agile value is ”Individuals and interactions over processes and tools.”

For example, author and software engineer Scott Ambler decodes this value to mean that the most important factors you need to consider in a software team are the people and their ability to work together. Processes and tools aren’t of any use if the team doesn’t have the required technical skills or they just can’t work together effectively.

Before reading Ambler's essay, I had already started unraveling the first value by myself. My conclusion was a little different.

First of all, I interpreted “interactions over tools” as “discussions and experiences over Slack and email.” I’m willing to argue that in order to build shared understanding inside your team, you have to have real discussions around user stories or mockups. You can make communication more efficient inside your team with different tools but you can’t replace meaningful discussions with them.

You as a developer should also have empathy with your users and customers. This is where the experiences come in. For example Kevin Hale of Y Combinator suggests that your developers should work in customer support every now and then in order to live through the problems that your users have to deal with.

Second, a month ago I wrote about appreciating craftsmanship in your work. After sharing this post with my friends, one of them pointed out Daniel H. Pink’s book Drive. In Drive, Pink argues that employee motivation is a result of autonomy, mastery, and purpose. We are motivated when we can be self-directed, we can improve our skills, and when there is important meaning in our work. For a great summary of Pink’s book, I suggest you check out RSA Animate’s video about it.

These three sources of motivation were on top of my mind when I read the word “individuals.” Bureaucratic processes can reduce your sense of autonomy. Tools that do their job, but are out-dated or poorly maintained, can reduce your sense of mastery and craftsmanship.

I believe that purpose and empathy go hand in hand. When you have a deep understanding of how your product solves a problem in someone’s life, you get a sense of meaning in your work.


This is what my interpretation of the first agile value looks like:

Autonomy, mastery, shared understanding, and empathy over tools and processes.

I get it, It’s a mouthful. It’s also one possible interpretation of the first agile value. I’m not disagreeing with Ambler here. I think Ambler’s explanation is an important reminder that we can’t make all teams greater than the sum of their parts by trying to invent the perfect processes and tools.


Let me leave you with a question: What does “individuals and interactions over processes and tools” mean to you?

Next page