Small, cross functional autonomous teams formed a part of nearly every talk at the UXDX Community conferences. The benefits of this structure are being recognised in a number of companies but for those coming from more traditional enterprise backgrounds the ability to shift to this way of working might seem unachievable. A number of our talks touched on this subject and this leads us to our first trend from the conference series: Agile Transformation.

Tony Grout, Enterprise Agile and DevOps Transformation Director at Atlassian, gave a great talk about his experience running agile transformations at Lloyds, Skype, Microsoft and in his current role at Atlassian. What is his formula for making an organisation agile? Trust, Purpose and Alignment. Easy! Although Tony was quite clear to highlight, this approach might seem simple at first it can be very challenging to implement.

Trust

Trust was a common theme across multiple talks throughout the UXDX Europe events. Tony used Douglas McGregor’s Theory X and Theory Y view of workplace motivation to highlight trust issues in many organisations.

Theory X assumes that people only work if they are forced or threatened and will avoid responsibility if left to themselves. It assumes that people have no ambition and will slack off if they are not supervised. A pretty bleak view of your staff and colleagues!

Theory Y assumes that people are self-motivated to complete work and enjoy taking ownership and responsibility. They take on responsibility and can work on their own with limited managerial oversight.

Most people say they know Theory X people but the vast majority believe that they themselves are Theory Y — something here is wrong, the math doesn’t add up!

Actually according to Tony, “there is no such thing as Theory X and Theory Y people, where they work is what makes the biggest difference”. People react differently in different situations according to their environment. No company sets out to hire demotivated employees but the workplace structures and processes can remove the intrinsic motivation that people have. Unfortunately a lot of companies treat the symptoms of a demotivated workforce by layering on additional processes and checks to manage these untrustworthy employees. There is a psychological phenomenon known as the Golem effect whereby when lower expectations are placed upon a person it lead to poorer performance. So this approach is, in fact, self fulfilling.

A bad system will beat a good person every time – W. Edwards Deming

There is an opposite version of the Golem effect called the Pygmalion effect whereby placing higher expectations on people lead to improved performances. This is what companies need to be reaching for. Some leading companies are now investigating their “organisational drag”; activities which take a lot of time but add no value. Trusting people more has been proven to be cost effective for these companies who have taken the risk. For example, many companies have onerous policies for approving and claiming expenses, assuming that if unchecked expenses would be abused. Numerous studies in companies such as Google, Statoil and Netflix demonstrate that removing expense policies, but making people’s spending public, actually reduces the overall expense spend while simultaneously removing all of the admin overhead in submissions and verification.

How does Trust relate to product development?

Data is a very valuable, and highly sensitive, asset for companies; it can be used to understand the company’s customers, its areas of excellence and its areas of weakness. Due to this, some companies are very restrictive in terms of who can access customer and analytical data which hinders the ability of product development teams to build the products that their customers actually want. In their talks Lisa Trumpstedt in Stockholm and Will Demaine in London touched on this point from a product owner and a lead developer point of view respectively. Product teams are constantly facing choices about how to build their products. In order to be successful they need to understand the full details of their customers and their behaviours, how the product is meeting those needs today and where the weak points are that need to be resolved. A lot of the concerns can be dealt with through contractual obligations around sharing data, you just need to trust your people. To paraphrase a famous quote about training:

Security : “What happens if we share customer data with our people and they leave?”

Product : “What happens if we don’t, and they stay?”

Purpose

Trust and Purpose are both necessary to enable self organising teams. They provide the teams with the knowledge and motivation to do excellent work. David O’Donoghue, the Head of Engineering at Zalando Ireland, gave a talk about motivating teams at our Dublin event. David described the different motivational methods available to companies based on the type of work that is being performed. The traditional carrot and stick motivation approaches (bonuses and minimum targets, known as controlled motivation) are successful when work involves repeatable processes but these approaches fail where the work requires creativity to resolve complex situations. For product development, which is classified as knowledge work, we need to foster autonomous motivation. The key drivers of autonomous motivation are:

• Competence — people have a natural desire to improve their skills
• Relatedness — people want to belong to a group
• Autonomy — people need to feel some control over their work
• Purpose — aligning to a greater good keeps people motivated to see a task to completion

Relatedness and autonomy might seem to conflict with each other, however David addressed this common misconception. Autonomy does not mean independence from everyone else, it means that you can exercise choice in your work, within boundaries. As David puts it

Hierarchy may be bad but flat is not the answer: Leadership is critical

Building a sense of purpose isn’t about a cheesy internal marketing campaign or other superficial approaches. By involving the team in the decisions on what they work on they will start to take greater pride and ownership in the product that they are building. For example, instead of telling a team they need to build a new widget or feature for a product you present a problem that needs to be fixed along with the outcome that you are trying to achieve and you let the team decide on the best way to fix it. The team will be much more invested in the features and much more willing to drive it to conclusion. By allowing the team to come up with the solution they begin to realise they are being treated like owners of the business and respond accordingly — the company’s goals become their goals.

In Zalando, to track the success of the work environment they measure the affective commitment of their staff — are people invested in the outcome and willing to go the extra mile to get something over the line. By creating an environment based around motivating knowledge workers Zalando have seen measurable improvements in their staff morale and commitment. Investing in motivation pays off handsomely given that productivity and staff retention the key issues in a number of organisations.

Alignment

Autonomous teams operating without alignment will lead to chaos.

There are two necessary levels of alignment for teams to work effectively; cross team alignment and internal team alignment.

We have already mentioned the need to get teams focused on the business problem and the customer outcome to be achieved in order for the team to build a sense of purpose in their work. This focus, once business problems and outcomes are effectively distributed, ensures alignment of teams across an organisation.

The second area of alignment is focused on ensuring that the members of each team are all “rowing in the same direction”. Because teams are made up of people from multiple different functions this can lead to conflicts where different team members have different priorities which align more closely to their function than to the overall goal of the team. For example the UX function might have a goal of improving the user experience, the Dev function might have a goal of speed, the QA function might have a goal of zero defects and the Ops team have a goal of keeping the lights on. By focusing on their functional goals teams can hurt the ability of the team to deliver — the focus on zero defects might be increasing the overall length of the testing period when the company may have a higher tolerance for risk as long as the Mean Time To Recover (MTTR) is low enough. Equally the Dev focus on speed and the Ops focus on stability will result in a mismatch between high and low risk tolerances. These mismatches lead to tension within a team with people pointing fingers and blaming other team members for delays and problems.

The team need to focus on their goal — why they were brought together. Teams are formed to deliver products. Each team member brings an important skill set and perspective to the table so these viewpoints need to be discussed and the team need to agree on the right level of risk for their circumstances.

There are two critical points to note here: the team need to embrace conflicting viewpoints and alignment does not mean consensus, avoiding design by committee is critical.

For embracing conflict, the team needs to be open to dialog because avoiding conversations where you don’t like the other people’s point of view will lead to differing expectations and poor team performance.

For alignment, the team needs leadership, not consensus. Everyone should air their concerns and these should be noted but the team needs a leader to make the decision on the right level of risk for the team. After providing justification for the choice the full team need to get on board with the decision and adjust their roles appropriately. Like in sports, the goals of the team must trump the individual goals of the team members.

Trust, Purpose and Alignment — What next?

So having learned about the three core elements of organisational agile transformation everyone should now be equipped to go and implement your own agile transformation initiatives in your companies….

The challenge that you will encounter is that while people may love change people hate being changed. You will encounter push back against implementing new ideas because your colleagues are experts in what they do today and they don’t want to have to re-learn their way of working. New processes are scary!

In a future article, we will share the trends and approaches that people have adopted to implement these changes in their organisations.

UXDX Community

UXDX has a mission to help teams accelerate product success. We believe that this is done by incorporating UX into the product lifecycle and breaking down the silos within teams. Throughout May and June 2018 UXDX ran community events in 8 different cities across Europe. The core concept was the same; bring together different speakers, from UXers, designers, product managers and developers, to give insights across the whole product life-cycle. This series of blogs will go through the trends uncovered during the events.

• Agile Transformation
• Product Vision
• Execution: UX
• Execution: DX