The Sunk Cost Fallacy


, , , , , , , , , ,

The sunk cost fallacy is in action every time you:

  • Sit through a long boring movie even if you decided after the first half an hour that is was terrible
  • Finish a meal that tastes bad and after you’re already full
  • Continue a bad relationship or friendship, purely because of the time and energy you’ve invested in it so far

Put simply, it’s the motivation to continue on a bad course of action, where logically the future does not look bright, only because of the time/money/energy you’ve put into it up to that point.

These already spent costs, that cannot be recovered, are known as “sunk costs”, and there is a strong human resistance to giving them up. It feels like admitting failure. But being able to be agile and “pivot” when needed is the mark of an intelligent business, and the sunk cost fallacy is generally the main thing in the way of that.

A pivot is when, part way through developing a product or service, you decide to take it in a different direction than the current planned path. This might mean changing the main focus of the offering, or even making it do something completely different to the original plan, and should be informed by early feedback as much as possible.

The problem with the sunk cost fallacy is that you end up investing much more than necessary in to whatever you’ve sunk the costs into, leaving you with fewer resources to go down productive paths. For example, if you’re stuck in a bad relationship, you can’t open yourself up to a future good relationship. And if you’re constantly paying for ongoing product development on a dead product, you can’t be working on a useful product instead.

All you’re doing in this case is throwing good money after bad… but there’s a silver lining. What you’ve paid for up to this point isn’t all wasted. The validated learnings you have gained will stop you from repeating the same mistakes. You have tested the market, an idea, or a product line, and you’re better positioned for your next endeavour.

How to Delegate Effectively (Orders vs Enrolment)

There are 2 ways that you can allocate work. You can give orders, or you can enrol people.


This is most people’s default way of delegating work. To do it well, you speak to the person involved, give them sufficient context, and enough detail that they can get the job done to your specifications.


  • Appropriate for outsourcing of very specific tasks to free you up to do other things
  • Good for if you have a new employee you’re still not sure you trust to do things their own way


  • Their main goal will be to not make a mistake, rather than get an optimum outcome
  • People will only do enough to not get in trouble, as micromanagement can be a disincentive for going above and beyond (as they’re more likely to make a mistake if they go off-script)
  • They feel no ownership of the task, as they’re just an extension of you
  • The best possible outcome is the one you envisaged, no better


This is trickier but has a huge payoff if done correctly. Instead of giving them extremely specific instructions about both what to do and how to do it, you instead describe the problem that needs to be solved, give a recommendation for how you would solve it, but also the assurance that if they think of a better way, they should go for it. It can also help to give them resources to call upon if they hit a roadblock. Once enrolled (i.e. once you’re convinced they care and are on board), they will put the full power of their intellect behind it, and if you have good people, you should get a great outcome.


  • People have the same goal as you
  • They feel ownership of the problem, and personal achievement for its success
  • They feel valued
  • If they are smarter than you or have a better idea than you, you can end up with a better result than you could originally envisage
    • Since you hire specialists who are great at certain things… you’d hope that they’re better than you are at their job, or you’re probably not hiring the right people
  • Appropriate for any task that really matters


  • Generally not appropriate for new starters who don’t yet understand your business
  • May require some early input from you to make sure they’re on a path you can be on board with

Power BI – The Six Reports Every Consultancy Should Have


, , , , , , ,

I’ve been at SSW,  a medium sized custom software consultancy, for over 10 years, and in that time I’ve asked for a number of SQL Reporting Services reports to be made, but due to the difficulty in getting exactly what I needed out of the developers, I still had to make many decisions based on best guesses.

In the past year, since I’ve had access to Power BI and can make many of the required reports myself, this has sent me down a serious rabbit hole of discovery into what metrics I really need to run a software consultancy.

So here are the most important reports that I think every consultancy should have.

Financial Reports

Profit and Loss

Every responsible business owner / General Manager needs to keep their finger on the pulse of the financial health of their business. It’s also important to be able to drill down by both time (years, quarters, months) and expense types (salaries, fixed costs, variable costs, etc) to investigate anomalies.



As a services based business, how many hours you bill vs how many salaries you’re paying is a very good success marker. Keep track of how well each of your employees and offices are going with a Utilisation report. I’t s a good idea to look at this kind of report monthly to ask questions like:

  1. Should I hire / fire someone to grow / shrink one of the offices?
  2. If some people have low utilisation, can they be up-skilled, or is there a good reason that they need to work on internal things?

Client Overview

Client Overview

Your employees will need a nice easy way to get up to speed on the history of a particular client when they join a project or are speaking to them about potential new work. An Overview Report like the one above is a good way for them to get acclimatised. It shows:

  1. When / how much previous work has been done
  2. Who did that work
  3. What projects have been worked on
  4. What technologies those projects are/were built in

Technology (i.e. Income Streams)


As a software development company, our main way of splitting up income streams is by project technologies, but for you this could be any way of splitting the service you’re offering by skill types. The importance of this report is it allows us to know what technologies we should be focusing on with new hires, internal work, or up-skilling. For example, we can tell from the Trends visualisation on the top right above, that SharePoint is becoming less relevant for us, and Dynamics CRM work is becoming a larger proportion of our income.

Current Sales Opportunities


As a services company, you’re probably dealing with a relatively small number of high value companies, and it’s vital that your sales process is strong to keep work coming in. This report shows which of your sales people are dealing with which opportunity, and where those opportunities are coming in from. This report is the reason we opened up an office in Victoria, as we could easily see that there was enough demand there to justify it.

Booked in Days (Forecast)


In order to run a services company, you need a service calendar so you know who is available for client work and who’s already booked in or on leave. We use Dynamics CRM but built our own “booked in days” report as the out of the box one was hard to use. This was built in SQL Reporting Services, but will soon be redeveloped in Power BI.

The Rest

We have other reports that we use to drill down on a lot of the above info, such as conversion rates reports to see how successful our sales process is, or detailed invoicing and receipting reports to see how our clients are paying us and who are main clients are, but the above 6 will get you most of the way there.

Do you have any others that you think I should make? Please let me know in the comments below and I’ll see what else I can spin up.

Seven Tips to Being a Great Product Owner


, , , , , , , ,

Every software product in development has a Product Owner who is in charge of supplying the requirements, and it is often misunderstood how important this role is. You can have the best engine in your car (the development team), but if you steer in the wrong direction, you’re not going to get to your destination.

Here are seven tips to make sure you’re doing this job well:

Represent the business

As the Product owner, it is your job to take requirements from any other business stakeholders, your own direct manager, feedback from the developers, and also the actual users of the software, and order them into a single funnel of prioritised work for the development team to work from. This is called the product backlog and is the main tool through which you can influence the success of the team.

Talk to the stakeholders

As well as taking requirements from the business, you also need to be able to report back to your various stakeholders with what the progress of the project is, and potential ETAs for features that they’re waiting for.

Maximise business value

Backlog prioritisation is all about making sure that the development team is always working on the most important thing that will provide the most business value. You can use a two dimensional matrix to help you with this decision. Think in terms of urgent vs important, and work in the following order.

  1. If a PBI (Product Backlog Item) is urgent and important, work on it 1st
  2. Work on important but nor urgent PBIs next
  3. Then urgent but not important
  4. Finally work on the PBIs that are neither urgent nor important

Since new work will constantly be coming in from feedback and other new ideas, if you follow this rule you will often find that your team almost only works on category 1 and 2 above, meaning you’re never working on unimportant work. Often you’ll find that if a PBI is urgent but not important, it will either no longer be urgent after a little while, or else it will become important.

Think in terms of Minimum Viable Product (MVP)

As a Product Owner, you have to be able to say when a feature is good enough for the team to stop polishing and adding bells and whistles, and instead move on to the next feature down the list.

This is especially important when budgets are tight (i.e. 90% of the time) to make sure that the business gets what it needs before you work on what it wants.

Be aware, however, that there is a slight cost in this, as if you want to come back to it later, you will have to let the developers get re-accustomed to that area of their code.

Manage Technical Debt

Technical debt is code or documentation that builds up over the course of any project, where some parts become legacy or shortcuts that were taken earlier cause headaches for work done later. Even diligent teams often find themselves with a buildup of technical debt as best practices change or new technologies emerge.

The solutions for this are varied, and include re-architecture, adding more measures such as unit tests or automated UI tests, and, most commonly, refactoring. Creating and prioritising these PBIs is one of the hardest things for Product Owners to do, as only the development team really knows extent of technical debt in any project, and often they won’t speak up about it because they caused the issue. See my other post about trust in teams to make sure you get full transparency in this.

My advice is to have a little bit of technical debt reduction in each sprint, as well as in your Definition of Done

Have a vision for the product

As well as taking requirements from others, the Product Owner should be in a very good position to have a holistic overview of the long term goals of the product, and this is known as the Product Vision. Keep this vision in mind as you’re shaping the product, to make sure it’s heading for a good destination.

Motivate and empower the team

There are plenty of ways for a Product Owner to impact the productivity and motivation of a team.

  1. Show gratitude for work well done or particularly useful features delivered
  2. Share the team’s success with others… always giving the credit to the people who did the work
  3. Be available throughout the sprint for clarifications to PBI Acceptance Criteria (i.e. the requirements)
  4. Try not to change your mind on priorities and requirements part way through a sprint as it can ruin the flow of a team that is on a roll

For a whole lot more, check out SSW’s Rules to Better Product Owners

The Five Dysfunctions of a Team


, , ,

There are five interrelated issues that undermine the performance of a team, and they can be viewed from 2 angles:

The Negative Angle

This is popular because as managers we’re often looking for what’s wrong so we can fix it:

  1. Absence of trust. 
    If the members of the team do not trust each other, then they cannot be totally honest with each other.
    This is the hardest to fix as it’s often personality conflicts or deep-seated issues that cause this, but if you get this part right, the rest normally follows much more easily.
  2. Fear of conflict.
    Without trust, people will not have the healthy debates that are necessary to arrive at better thought through decisions.
    People who don’t trust each other will not openly say if they have made a mistake, or don’t know something, so you can’t get to the heart of any matter discussed. They are also less likely to proffer an idea if they might know another approach but are not 100% sure in case of looking silly.
  3. Lack of commitment.
    If the team has not aligned behind a decision, then the individual members who did not agree with the final decision will ultimately be less committed to that decision.
    This will lead to the bare minimum being done by that person, and a lot more micromanagement needed to get the desired result, which is a waste of good team minds and management effort.
  4. Avoidance of accountability.
    If an individual is not committed to the course of action, then they are less likely to feel accountable (or hold other people accountable).
    Another way of thinking of this is taking ownership. If they are not committed and don’t take ownership of a task, they’re much less likely to hold themselves and others accountable for successful delivery.
  5. Inattention to results.
    Consequently, they are less likely to care about the group results (and instead focus on achieving their own goals).

These are from the excellent book, The Five Dysfunctions of a Team by Patrick Lencioni.

I have found these principles so useful that I have printed this summary and I have it on my wall at work, both to remind me, and to help explain to others where team breakdown problems are likely originating.

The Positive Angle

Sometimes it’s also good to look at these from a positive side, so as a manager you know what you’re aiming for in your teams. These are the pillars that underlie exceptional teamwork:

  1. Trust and vulnerability
    When team-mates trust each other, they are not afraid to be vulnerable in front of each other, and will admit mistakes or shortcomings, allowing their team-mates to help fill any gaps.
  2. Healthy debate
    One of the main pillars of teamwork is healthy debates, where each team-mate feels empowered to contribute, ideas can be shared, and plans formulated.
    Part of this is each team member being able to let go of any ego and talk about the topics from an objective viewpoint, which is why team trust is so necessary.
  3. Commitment to decisions
    The outcome of the spirited debates should be a decision on a plan forward, and since each team-mate felt empowered to contribute to the plan, they should then also fully commit to the agreed decision.
  4. Accountability
    With everyone fully committed to the plan, they should then be comfortable to be held accountable (and hold each other accountable) to the KPIs.
  5. Attention to results
    If the group has a shared feeling of success, they will all strive for the same results, and will pay attention to if those results are met.

I have also written about this topic on the SSW Rule: Do you know the 5 dysfunctions of a team? 

arctree-5-dysfunctions-of-a-teamFigure: A nice info-graphic that covers this quite well