Flashover

Page 2 of 8

Previous

Next

Customer Collaboration over Contract Negotiation

Feb 10, 2019

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?

Handbook for Strategic Challenges

Feb 3, 2019

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?

Creative Constraints, Play, and Serverless

Jan 27, 2019

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:

My Response to Bad Ideas

Jan 20, 2019

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.

I Dread Sales

Jan 13, 2019

There is a high chance that you are currently trying to sell. Your job title might have the word "sales" in it. If you work in consulting, your employer might be expecting that you are able to identify your client's unarticulated problems and offer them the tools and resources to solve them (this is what selling is basically about). You might be selling your freelancer services or you might be selling yourself as a job applicant to future employers.

You might be even able to identify sales tasks in your work that other people don't traditionally consider as sales.

There is this idea that we are all in sales. We are all trying to persuade people to take action. We are all trying to connect and build trust for some mission.

You might agree with this idea. But you might not identify yourself as a person who is good at selling. You hear people tell their sales success stories and you wonder why you struggle with sales so much. Someone tells you that sales is easy but that's the exact opposite of what your personal experiences tell you.

I feel this way constantly. I personally believe that we are all in sales whether we like it or not. But I often also get discouraged. I think to myself that I'm not made for sales. There is some natural talent or a personal trait that successful sales people have and I lack.

But here's the thing. For the most of us, selling is not easy. Selling is hard and selling is scary. Don't feel discouraged if the idea of calling a client makes you sweat.

The story of Sara Blakely (founder of Spanx) is all I need to remind myself that the fear of selling doesn't mean I can't do sales--or have those moments of success in sales.

Before founding Spanx, Blakely was selling fax machines door-to-door. She had to deal with rejection constantly. And sometimes she just wasn't able to handle all the noes. She felt defeated. She would drive around a same block multiple times before she was able to convince herself to walk in through a client's door. On some occasions, she had enough courage to walk in through the door but when someone asked what her business was, she would instantly turn on her heels and walk away.

Blakely's story is not the story of a perfect sales person bursting with confidence. It's a story of a sales person who is human and who has to deal with human feelings. And most importantly it's a story of hope. After all, Blakely didn't quit sales. Instead, she built a billion dollar company on top of her sales skills.

Do you think sales people are born or made?

Page 2 of 8

Previous

Next