The Importance of Positively Managing Conflict in a Team

Tags

Teams don’t always just hum along. People have personal and professional differences, and sweeping them under the rug is not healthy long term, and could eventually cause a full breakdown. If there is a tiff, managing it correctly can actually reinforce respect and cause a team to function substantially better than it did with the pent up tension still unspoken.

I’m speaking here mostly from the point of view of someone managing 2 people who have had a conflict, but these could also be used to manage a conflict you are having directly with someone, although this is harder, and a facilitator can sometimes still help.

There are 3 main steps to successful conflict resolution:

1. Agree that there is a problem that needs to be solved

If one or more of the parties are not willing to address the issue, it will be substantially harder, if not impossible, to positively resolve it. It’s best to appeal to professional integrity (i.e. a professional would address this, so you should), zoom out to the big picture (i.e. to show the benefits that the project/organisation would have from a harmonious team), and alleviate fears that the process will be too scary or unpleasant. Many people fear conflict resolution because they don’t understand that it can be a very positive experience.

2. Hearing the other’s point of view

In order for each person to both get their say, and effectively hear and understand the other person, it is important that both of them go in to the process with an open mind, and allow the other person to speak without getting defensive (overly defending each point) or righteous (focusing on being seen to be right in the small things instead of having a good outcome).

Remember that any examples given will likely be not that big a deal on their own, and only in the context of the person’s frustration, will they have much weight, so don’t get fixated on any one example.

3. Compromise

Each person must be willing to compromise to find a solution that works for both. If there is a power imbalance, such as a conflict between an employee and a manager, beware the solution being the manager just 100% getting their own way, as this will often foster longer term resentment. There’s a great tongue in cheek saying that is “the only good compromise is where neither party is happy”.

Both parties benefit from positive conflict resolution. Discussion may even reveal that what you thought was the cause of the problem is inaccurate, incorrect or misleading. By remaining calm, showing patience and demonstrating respect, you can help resolve problems in a constructive manner. This results in effective long-term relationships and increased productivity. Conflict that results in punishment for one party may result in continued tension, stress and disruption. Focus on positive outcomes and you’ll get better results.

Advertisements

The 5 Technologies that Will Change Everything in the Next Decade

Here’s my take on the main technology areas that will make a massive difference to our lives in the next decade.

Artificial Intelligence

This is a huge one and encompasses something as simple as Amazon’s recommendation engine, up to self driving cars, and eventually expert systems such as IBM’s Jenkins that could potentially replace doctors and lawyers and any other information based career.

everis-NEXT-Artificial-Intelligence-Infographic-by-Virginia-Duran

Blockchain

The most famous blockchain technology is Bitcoin, but cryptocurrency is only one use for this technology, taking out the requirement for trusted third parties such as banks. Fundamentally however, it’s just a general ledger system and could be used to track ownership of anything, including property, votes, assets, contracts, licencing, or even identity.

Theoretically, this goes a long way to removing the need for currency, government, and banks, unless they can find other ways to stay relevant than being the “trusted third party”.

Here’s how a blockchain transaction works:

infographics0517-01

Quantum Computing

Computers have become approximately twice as powerful every 18 months, following Moore’s Law, but we are now approaching the physic limits of how small transistors can get and how fast this technology can be. The next big jump will be dropping binary transistors and adopting QuBits instead.

With this potential for quantum computers to become exponentially more powerful than transistor computers are today, this will enable much stronger cryptography (as well as also making current cryptography obsolete), machine learning algorithms to be run much faster (enabling AI), Bitcoin mining, and of course just doing everything we currently do much faster.

qubit

Brain Machine Interfaces

This technology will start with restoring lost function to disabled people, such as paraplegics, the blind and the deaf, will continue into solving Alzheimer’s, dementia, and mood disorders, and will eventually be the new way we interact with computers and potentially even each other.

Elon Musk has bet big on this and thinks it’s one of the best ways to make sure the AI revolution doesn’t leave humanity behind.

brain-machine-interface-ppt-6-638

Genetic Engineering

Mapping the human Genome to fully understand the source code behind life will allow us to, first of all, remove all genetic and hereditary disorders and diseases, and then move on to specify exactly what traits we would like to optimise for in our offspring. Future humans will be smarter, stronger, and more robust.

3234682_f520

The Sunk Cost Fallacy

Tags

, , , , , , , , , ,

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.

Orders:

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.

Pros:

  • 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

Cons:

  • 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

Enrolment:

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.

Pros:

  • 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

Cons:

  • 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

Tags

, , , , , , ,

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.

Utilisation

Utilization

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)

tech

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

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)

bookedindays

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

Tags

, , , , , , , ,

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 Things Every Scrum Master Should Do

Tags

, , ,

The larger a Scrum team is, the more opportunity for wastage there is, and so the more difference a good Scrum Master makes.

A team with a bad Scrum master can feel powerless, floundering, isolated, and overwhelmed whereas a team with a good Scrum Master generally feels well informed, connected, directed, powerful, and like they are working at peak effectiveness.

Be punctual

  • Set a regular cadence for the team.
  • The daily scrum is always at a predictable time so no time is wasted trying to organise it every day. The larger the team, the more important this is.
  • This of course also applies to the Review, Retrospective, and Planning meetings too.

Set a strict agenda

  • Tangent topics will come up regularly during meetings, and although sometimes these can be important discussions, they often take up a lot of time. Make sure that there’s never a time when 2 or 3 people are talking and everyone else is phasing out. If it’s on topic for a Scrum meeting, everyone should be involved, otherwise it should be taken offline (after the meeting with just the relevant people).
  • Make sure that someone takes a note of these topics as they can sometimes be forgotten otherwise.

Help your team

  • The people who know best how to make software are the people actually making it. If they raise an impediment, take it seriously and work towards a solution.
  • Help to motivate the team by showing appreciation for quality work. Doing this publicly often helps motivate other team members to strive towards the same level.
  • Encourage collaboration amongst team members. If one person is stuck, help them to realise that it’s always ok to ask for help.
  • Protect the team from excessive scope change. Adding a last minute Product Backlog Item (PBI) to a sprint should only be allowed if the team can drop an equivalently sized one.
  • Minimise WIP (work in progress) by encouraging the team to finish each PBI before picking up another whenever possible. This helps to minimise multitasking and ensure granular delivery of value to the stakeholders.

Help your Product Owner (PO)

  • A good Scrum Master should help the PO effectively communicate his requirements and priorities with the team. He should then reinforce those priorities and encourage the team to work in priority order whenever possible.
  • It’s a good idea to have high level conversations with the PO on occasion to work out what their more abstract goals are so you can help by making micro decisions for the team when appropriate. This way you can occasionally act as a Proxy-Product Owner when needed.

Coach your team

  • Make sure the team follows the Definition of Done.
  • Make sure the Product Owner creates well fleshed out PBIs with easy to understand Acceptance Criteria.
  • Ensure that the team has a uniform understanding of the estimation method being used (we use 2-Small, 4-Medium, 8-Large, where a Medium is about a day’s work)

The difference a good Scrum Master makes is well documented, and if you follow the above guidelines, you should be well on your way to empowering your team.

Along with my brother, I made a video on this topic which explains how the Scrum Guide defines the role of Scrum Master:

I’ve written many more specific tips on SSW’s Rules to Better Scrum

The Five Dysfunctions of a Team

Tags

, , ,

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