Flashover

At Slush 2018, Justin Rosenstein (software programmer and co-founder of Asana) mentioned blunt feedback as one of the things we should all learn how to embrace. I know from experience that blunt feedback is critical to my learning and yet I'm afraid to receive it. I know that I can elevate my co-workers by sharing feedback with them and yet I find myself focusing exclusively on project management when I try to boost team performance.

If embracing blunt feedback doesn't come naturally to me, how can I incorporate it into my life in a more thoughtful manner?

One possible way forward is to start paying more attention to defensiveness—both my personal defensiveness and the defensiveness of other people. Defensiveness is a simple signal that tells us we need to readjust our perspective or improve our communication.

We sometimes get defensive when we have personal issues with the individual giving us the feedback. But more often we get defensive because we are not able to separate our actions from our identity. We often fail to distance ourselves from the critique. When we interpret blunt feedback as criticism towards who we are as a person, we put our guard up.

It helps to change our inner narrative. For example, when I receive negative feedback about my communication, I can easily tell myself that this person is proposing that I'm a bad co-worker or that I'm a jerk. I tell myself that my identity is being challenged and that I need to disprove the other party. What I should do instead is to tell myself that this person is trying to point out the behavior that is currently conflicting with my true intentions and character.

We can help each other to avoid this unproductive inner narrative by focusing our feedback more towards actions and behaviors instead of characters and personalities. But unfortunately, we can't fully rely on other people to become better feedback givers. The sad fact is that often people will think that what you do reflects who you are. This is because of the fundamental attribution error which argues that we explain away our personal mistakes with circumstances but others' mistakes with character flaws (e.g. "I'm late from our meeting because the metro ran late but your lateness is evidence of your disorganized character").

You should acknowledge the fundamental attribution error and you should try to fight it. When you experience defensiveness from other people, you might be accidentally making vocal judgements about their character.

In some situations, to move the feedback more towards actions and behaviors, you can use the therapist and researcher John Gottman's XYZ statement "when you do X in situation Y, I feel Z" as a way to construct your feedback. In a software team setting that statement might look something like this: "when I raise an accessibility concern in a design meeting and you laugh it off, I feel unheard."

But most importantly, remember to pay attention to defensiveness. It's a symptom of something. And you need to figure out what that something is.

Late last year I wrote a post about the four agile software development values. Since then I've been writing separate posts for each of the values. Here's a link to the first post ("Individuals and interactions over processes and tools") and a link to the second post ("Working software over comprehensive documentation"). This week I'm going to write about the third value of "Customer collaboration over contract negotiation."

Not only am I going to continue from my previous posts about the agile values but also from my last week's question of what makes some software agencies more "successful" than others.

When I was looking for an answer to this question, I came across Frances X. Frei's Harvard Business Review article "The Four Things a Service Business Must Get Right" from 2008.

Frei's fourth thing that a service business must get right is the customer management system which underlines the importance of your customer's role for your service business:

In a service environment, employees aren’t the only people affecting the cost and quality of service delivered. The customers themselves can be involved in operational processes, sometimes to a very large extent, and their input influences their experiences (and often other customers’ too). For example, an architectural firm’s client may explain the purpose of a new facility well or poorly, and that will affect the efficiency of the design process and the quality of the end product.

When it comes to software projects, the customer is usually highly involved in the development process. Just like with Frei's example of the architectural firm, the efficiency of the development process and end product quality is not only influenced by the development team but also by the customer.

Customers are often also the most important source of knowledge. They are the people who understand the company, industry, stakeholders, and the end users of the software system under development.

However, none of this implies or dictates that the customer has any experience in software development. In fact, this might be their first software project. Unlike you, the customer hasn't yet experienced real-life scope creep or the perils of waterfall model software development.

This is why you not only need to collaborate with your customer but also manage them. There is a role you want them to take. There are certain software development concepts and philosophies that you want the customer to understand. There are behaviours you want them to partake in.

Some of the roles and behaviours won't come naturally to the customer. This is why there are moments when you need to manage the customer. You need to nudge them in the right direction. You can't expect them to figure everything out by themselves.

Initially the idea of customer management sounded a little strange to me. I work for the customer. The customer is the one who is paying me. The customer is my employer, not my employee.

In reality, there is no employer-employee relationship between me and my customers. The relationship resembles much more of a teacher-student relationship where we constantly switch roles. We both need to teach and we both need to learn. We need to listen and we need to show.

Here are some questions to help you start managing your customers:

• What roles do I need the customer to take?
• What do I need the customer to understand or learn?
• How am I helping the customers to achieve these goals?

This week, inspired by a discussion with co-workers, I've been trying to understand why some software agencies are more successful than others.

This is basically the question to which the field of strategic management tries to find an answer: Why do you see differences when you measure individual company profitability within a given industry? Why do competitive advantages exist, and how do companies achieve those competitive advantages?

Strategic management as a research field got started in the 1950s. After 60 years, it's still looking for the answer for the same questions. It still hasn't been able to produce a reliable handbook for the business founders and CEOs of the world.

This is no wonder. When you assume that there is a handbook to follow, you assume that the world is predictable. You assume that you don't learn through discovery but through building models.

The other problem is the fact that unique competitive advantages are not unique if they can be achieved by everyone else. Competitive advantages that can be articulated and attained with modest resources will eventually become industry standards. Industry standards are the bare minimum for your business--not the thing that will make it stand out.

How does your company solve a strategic challenge? Does it enter into discovery? Or does it start assuming? Do your co-workers and managers say they aren't learning fast enough? Or do they say they don't have enough data available?

Disclaimer: I’m going to talk about serverless architecture only from the point of view of my personal projects. I'm not making an argument for or against serverless architecture on a professional level. The aim of this post is to only encourage you to experiment more with different approaches to building software.

Two weeks ago, Go was announced as a supported language for Google's Cloud Functions. Go is one of the programming languages I'm learning this year. I have already gone through some basic tutorials for Go and now I'm trying to build something real with the language.

For a while I was struggling to think of a great hobby project for Go. But when Cloud Functions support for Go was announced, I knew I had to build something using the platform; not only would I get to write Go, but I would also get to experiment with serverless architecture for the first time.

I mainly work with Ruby on Rails projects which have a monolithic architecture. Monoliths are almost the exact opposites of serverless projects. While serverless means that you break down your application's logic into small, autonomic components, monoliths hold all the required logic inside the same application. Monolithic architecture is the traditional way of building web software.

When you hear the words "monolithic" and "traditional", fast and agile development patterns might not be the first things that come to your mind. However, compared to serverless architecture, monoliths tend to be much more simpler to develop, test, and deploy.

This is because serverless architecture forces you to separate your application logic into smaller entities that are harder to work with in tandem. Good code is all about separating logic into different modules and classes. But you can have this abstract-level separation inside your monolith. You don't need serverless architecture for this.

The separation of logic introduced by serverless architecture, means that you now have much more concrete boundaries between different parts of your application. If you want to introduce a new feature for your application, you have to make changes in bunch of different codebases instead of one monolithic codebase. You also have to deploy a new version for each independent service that you have to change. With a monolith, you would introduce the new feature with a one-time update for the whole application.

Example of monolithic vs. serverless development

Imagine a simple web app for to-do lists. Users can create new lists, add to-dos to them, and mark the to-dos as done.

Previously, the to-dos only had a text field for description. Now we want our users to be able to not only write text, but also attach images to their to-dos.

Let's think for a second what kind of changes we have to make into our code to make this work: First, we need to have some sort of graphical upload widget for the users. Previously, when users submitted a new to-do, they sent out an HTTP request with the to-do description. Now our handlers for those HTTP requests need to have support for image data. That's a second task. Third, we want to process the incoming images before saving them. We want to scale down very large images and we want to create a thumbnail version for each individual image. Finally, we need to actually save the images somewhere and display them to our users.

When I work with Ruby on Rails, I can implement all those tasks without switching between different services or codebases. Once I'm done, I can deploy all my changes with a single update. In my mind (or on paper) I break down the new feature request into smaller tasks. But there are no actual concrete boundaries between all the code that needs to be changed. I break things down to make my work easier, not because I have to.

Working with serverless architecture has been a totally different development experience. To start with, I need to have two separate projects for my front-end and back-end logic. But moreover, I have not been able to share state between my back-end functions automatically.

This has forced me to think about code and application logic in new ways. For example with Ruby on Rails, I don't have to first think about where each part of my application logic lives. I can always figure that stuff out when I need to. With serverless architecture, you have to do lot more upfront planning. Stepping over to another part of the application is a much more of a pain.

Developer happiness and experimentation

Serverless architecture has made me work slower. Writing with a new language while discovering a new production environment feels extremely tiring at times. But right now I'm also feeling excited and energized. Not because I believe that serverless architecture is the future of all software but because I have had some genuine moments of creative joy.

There are two things that I think made me experience such high levels of developer happiness. First, serverless architecture forced me to make hard decisions about the scope of my independent services. This meant that I had to introduce creative constraints and actual limitations to my hobby project. We usually dream about creative freedom instead of constraints. But constraints help us focus and ship. With creative freedom comes analysis paralysis and never-ending tinkering.

Second, experimenting with serverless architecture was a form of play for me. I'm a strong believer in habits when it comes to coding or pretty much any aspect of my personal or professional life. However, sometimes habits can make life a little boring or make us forget to stay curious. It's nice to shake things up every now and then.

I hope that this week you all get to play a little as well.

Additional notes

I'll share my live hobby project and the code for it here when I get a working version out.

Edit: here is a link to the live project and the source code for it:

• Cola Inventory Functions
• Cola Inventory PWA

I have a friend who feels inspired every time she suggests an idea to her manager. Almost without exception, the manager will tell her that she should try out the idea. By saying this, the manager does two things: she shows that she trusts my friend, and directs her towards concrete action.

It costs nothing for the manager to tell my friend to go try things out. Because here are some things that this manager isn't saying to my friend: She's not saying that the idea will be a success. She's not saying that she will do all she can to help my friend. She's not saying that she will promote the idea to other people.

Instead, she is communicating to my friend that the best way to find out if an idea will work is through trial-and-error.

Maybe my friend's ideas aren't always pure gold. None of us have only good ideas. But that fact doesn't stop the manager from cultivating a culture of autonomy, creativity and iteration.

You can't always tell if an idea is bad

You don't have to believe in an idea 100% before encouraging someone to act on it.

First of all, we all have to learn some stuff the hard way. Most of us have to experience working with bad ideas before we learn how to pick out the good ones that are worth our time and resources.

Therefore, maybe you shouldn't always prevent people from wasting their time with a couple of flawed projects. Yes, your co-worker or employee might end up spending their time on an idea that was bad from the get-go. But they will learn some important lessons along the way. Even their next ideas might still be kinda crummy. But at some point their work starts to become exceptional because they have kept on trying out different things in the real world instead of just drawing up plans and pitching ideas.

Secondly, you might be the wrong person to judge the idea. Maybe someone pitches you a solution to a problem that you don't experience. Does it mean that there is no demand for the solution? No. It means that you are not part of the target market.

Every idea, solution, or product isn't for everyone. In fact, specific and focused solutions trump generic ones. In marketing, having sharp edges is better than playing it safe and trying to please everyone.

Responding in a more productive way

I have catched myself criticizing ideas that don't really need my criticism. I thought I was helping when I was actually discouraging people or just being annoying.

These days, this is how I try to remember to construct my response to ideas that aren't made for me: I can criticize and point out possible problems but at some point I have to show a thumbs-up for the idea. I won't promise that I will be a customer or a strong proponent for the idea but at the end of my response I will urge the person to take concrete steps towards turning the idea into a reality. I imagine pointing my index finger towards the door and saying "go get 'em tiger!"

First a thumbs-up, then a pointing gesture and a word of encouragement. In most cases, it's the best advice I can give.