Flashover

I started a podcast. It's called 0-100 and you can find it at nollaviivasata.fi. The show is about how to start your own digital consultancy or agency. In it I interview founders of different Finnish agencies (in Finnish) and ask them how they got started on their journey and how they grew their company during the early years. In this post, I want to discuss why I started recording these interviews in the first place.

As a developer working with software consultancies (first at Kisko Labs and now at Wunderdog), I've overheard and sometimes participated in conversations about growth and strategy in the context of a consulting company. Some of the most interesting questions tend to be how to find better projects and how to transition from a vendor to a trusted advisor in the eyes of your client. At home, often inspired by a discussion at the office, I have tried to find more advice or opinions online (or for example from podcasts) to no avail. There's a plethora of great material provided by generous people from product startups. But when it comes to consultancies and agencies, it's much harder to find advice from seasoned entrepreneurs.

Whenever you do find people discussing consulting, often the advice seems to boil down to "do great work and the rest will follow." Doing great work is critical – I'm not denying that. But there has to be more to how to build a successful consultancy, hasn't there? Many times I have wanted to just walk into the offices of one of our "competitors" and ask them how they do X and have they ever considered Y.

Am I planning to start my own consultancy? No. So why do I ask my interviewees how to start a consultancy instead of how to run one? The reason why in my interviews I ask about how did you get your first customer as opposed to how do you currently get your customers, is that discussing current tactics can be uncomfortable to some and therefore lead to overly abstract discussions about sales and marketing. In addition, when we discuss stories from the past, I can make sure that the interviews won't only be about ideas but also about tactics that were tested in the real world.

I believe that even established consultancies can discover new ways of approaching different business opportunities when they get to hear how other founders kick-started their businesses with different offerings and different client bases. I do hope you get a chance to listen to an interview or two. You can find the show on Apple Podcasts, Spotify, Pocket Casts or wherever you listen to podcasts by searching for "nolla viiva sata." While the episodes are in Finnish, I will write (in English) about lessons learned later on this blog.

Customer: What do you mean you have used all the budgeted developer hours? There's so much stuff missing from the product! How much of the original spec is here? 50%? 25%?

Developer: I hear your pain. Many of the original features had to go because of budget constraints, and yeah, some of these features that did make the cut could use some more work. But you are not taking into account our new analytics features that were not in the original spec. We built those features so that we can get real data from real users. We shouldn't measure our progress in lines of code written but instead look at the impact we create. And how can we judge this impact if we have nothing to measure it with?

Customer: But this... this is just embarrassing. I can't believe you shipped this to our users. What am I going to say to my managers and my team?

Developer: Don't worry. We kept the core features. With this product we were still able to test out your idea with real users. And thanks to those analytics we added, we got actionable insights into what's working and what's not!

Customer: Yeah? I guess that's better than nothing. So what's the main insight?

Developer: People hate it.

Customer: Hate? Who hate it?

Developer: The users, they don't like using our product. Do you see this number here? It takes roughly ten seconds for the average user to realize this product isn't working for them and after that they just leave and never come back. It's actually pretty great that we get to learn these things with our analytics reports.

Customer: How on earth is this great? First you tell me that I have to go to my colleagues with this unfinished piece of junk. And now you are saying that there are also real numbers for pointing out the epicness of our failure? What is wrong with you! I'm going to be the laughing stock of the whole department.

Developer: I'm sorry, I got distracted by this analytics dashboard. Did you say you wanted to show these numbers to your team? It's really easy to export the data from here. Would a CSV file work for you?

Customer: Get the hell out of my sight!

***

What's wrong with this scene?

Let's start with the obvious problem: our developer has been building stuff without keeping the customer up-to-date. The fact that the status of the budget and the prioritization of different tasks comes as a surprise for the other party is clear evidence of miscommunication between the developer and the customer.

But what I'm trying to describe here is a situation where people might be better off by not allocating any serious resources to analytics than to get real data on how their product is being used.

How is this possible? First, when a team is delivering more features instead of doing analytics work, other people in the organization might look at the team and applaud their productivity ("this team is delivering new features so fast!"). Feature development is easier to measure and more visible than business impact and because of that features can get more positive attention. Features are where the focus of our customers, managers, and peers naturally go.

Second, when there are no analytics there are also no negative reports. It is true that when you can show your product is a hit with analytics, you get more leverage with others. However, it's also true that disappointing results take some of that same leverage away. Since time and time again we overestimate the upside of our projects, it is more likely that the end results of our projects fail to live up to expectations. It's more likely that you get to report bad news instead of good news. So why would you want to report any news at all?

How could you prevent that scene from happening at your work place?

2019 was the first full year for Flashover. In this post I'm going to share the five most read posts of that year. I hope this post can serve as an opportunity for you to see if you missed anything interesting or to revisit a post or two. Maybe you are new to the blog and in this case I'm sure this post is a helpful starting point for you.

Customer Collaboration over Contract Negotiation - The title is a bit misleading. In this post I'm not writing so much about customer collaboration but rather about customer management for software agencies. Successful software projects don't require only great teams but also great customers. And it's your responsibility to try to help your customers become great.

The Drama Triangle - Karpman drama triangle is a social model that can help you make sense of conflict situations happening at your work place.

You Don't Have to Manufacture Psychological Safety - Do you want high-performing teams with high levels of psychological safety inside your organization? Then make teams the smallest unit of your organization instead of individuals. This post is not a recap of Google's Aristotle project but instead tells you why manufacturing psychological safety should be your plan B instead of plan A.

Don't Try to Create and Analyze at the Same Time - Writing and editing are different processes that require different types of thinking. When writing code, the same is true for adding new functionality and refactoring existing code.

Exams Are for Students, Experiments Are for Learners - By grading our work and continuously comparing us to our peers, schools and exams teach us to avoid failure. Because of this, we might steer away from projects where failure is likely but that are still important for our organizations and meaningful for us as individuals. We should approach challenging projects from the perspective of experiments instead of exams.

***

Happy new year and thank you for all the reads and shares!

The term agile gets used so much that to non-developers it might seem like jargon devoid of any meaning. Developers might know what agile looks like but can struggle to explain it to others (or even themselves). And since no one wants to admit they aren't agile, both non-agile and agile teams claim they are agile lessening the term's value even more.

One definition of agile I hear often is that agile is the opposite of waterfall development. However, to say that agile is the antithesis of planned sequential development doesn't do justice to everything it holds.

According to Martin Fowler, agile software development is "adaptive rather than predictive" and "people-oriented rather than process-oriented." The practice of agile requires teams to have the right technical practices (such as continuous delivery) and discussions instead of detailed requirements. Here is a link to Fowler's Agile Software Guide for more information: https://martinfowler.com/agile.html.

According to Robert "Uncle Bob" Martin, agile teams deliver code every week or every other week, collaborate with stakeholders, and write tests. This definition raises an interesting question whether teams that don't do TDD are agile or not. Here's an interview about the basics of agile with Martin: https://changelog.com/podcast/367.

I myself wrote a blog post series about agile values to reflect more about the meaning of agile. However, I have later found out that the agile principles are much more helpful when it comes to defining agile in practice. While agile values help teams prioritize their activities, agile principles provide actual practices for them.

You can define agile in surprisingly concrete ways. If one way of defining agile classifies you as a non-agile team, it doesn't necessarily mean the particular definition is wrong. It can be that your team isn't, in fact, agile – not every team is.

I came across David Emerald's book The Power of TED when I was doing research for a post about the Karpman drama triangle. In this post I'm hoping to write some of my thoughts about the book in order to help you figure out if you want to pick up the book for yourself or not.

Let's start with a brief introduction to the Karpman drama triangle. In Karpman drama triangle, people in conflict take the roles of victims, persecutors, and rescuers in order to deal with tension. A victim sees themselves as a victim of circumstance or being oppressed by the persecutor. A persecutor sees the victim as a problem and therefore blames and criticizes them. A rescuer validates the victim's stance by trying to fix the situation for them. Again, here is a link to my post about the drama triangle if you want to learn more.

The Power of TED helps you transcend the drama triangle and enter the empowerment dynamic (TED). In TED, victims become creators who focus on outcomes instead of problems, persecutors become challengers who fuel creators, and rescuers become coaches who support creators in pursuing their envisioned outcomes instead of taking responsibility for the outcomes.

This is the core of the book. It's not a lot for content. But that's not really a problem since the book has very little filler text. The paperback version of The Power of TED is only 150 pages. The book is also written in fiction form which probably makes it an even faster read for many of us.

Here is why I enjoy Emerald's writing: I can see parts of myself and others in the stories of the book's characters. I'm able to identify victimhood I've experienced in the past and through TED tell better versions of those stories to myself. I feel better equipped to take the role of a coach instead of a rescuer when people come to me with their problems. And perhaps most importantly, I had to face the fact that in some past and current situations I am probably the persecutor to others.

It can be useful to look at your situation through the lens of the drama triangle because it allows you to structure your thinking when emotions run high. It's so easy for us to end up thinking in circles in moments of stress and anxiety. Having vocabulary for your feelings and the feelings of others can help you navigate through conflict instead of drowning in it.

The Power of TED is all about the tension in our personal and professional lives that direct us to destructive patterns of thinking and behavior. Has it been a while since you asked yourself what you want instead of what you don't want? Is it easy for some people to get defensive around you when you try to argue your point? Do you ever think it's your responsibility to fix a situation for someone? These are just some of the questions Emerald makes us ask ourselves in order to help us make sense of our interactions with the world and the internal and external conflict we experience with others.

Here are some possible reasons for criticsm: I have friends who steer away from books that don't come with citations and validated research sources. I can say that I have absolutely no idea how much of Emerald's writing is based on psychological research but I'm also not really worried about that. Consider The Power of TED as a tool for meditation and self-reflection, not as science.

In addition, the book is not heavy with spirituality but it also doesn't shy away from it. That might be an issue for you.

And yeah, The Power of TED is not officially business literature but I read it as such and I don't see a reason why you can't do it too. As a business book, The Power of TED is written for organizations made out of people with souls.