Category: Coaching

A question I have been hearing a lot lately is how do you know whether an employee is putting in their hours, or not slacking off. This question seems to be particularly concerning for people in the context of working from home where the perception is that it is more prevalent.

The irony here of course is that being in the office is no measure of not slacking off, there have been many books written about different ways you can slack off whilst appearing to be busy.

I have heard tales of the productive worker that works hard all day long only later to discover they were working on a side project or even for a second employer. Long lunches, toilet breaks, extended coffee breaks, fake meetings, or just browsing the internet or discretely playing games on your mobile phone. Physical presence in an office is not an effective measure of whether you are slacking off.

The average American worker admits to wasting 2.09 hours a day, excluding lunch, according to 10,044 self-selected respondents in a survey released by America Online and Salary.com.

What does it mean to Pull your own weight?

Let’s take a little aside and explore the phrase “pulling your own weight” there are a few suggested origins of the phrase but the one I like best relates to the English Long-bowman, to be considered an ‘archer’ you had to be able to “pull your own weight” Longbows had a draw of up to 180 Lbs. You really did have to pull your own body weight. An experienced archer could fire 12 aimed shots in a minute at ranges of 200-300 yards, although in battle they were expected to fire at a slower ‘sustainable pace’ of 6 aimed shots per minute. For context a modern bow draws at around 40 Lbs for women and 60 Lb for men.

In a modern terms we usually mean contributing proportionate to your role. We tend to think in terms of productivity and output. Despite this we often tend to focus on hours spent – hence the rise of slacking off at work, even though we can easily slack off time without being noticed, but it is far harder to slack off output or deny outcomes.

So how do you know whether your employees are working?

Personally I think that is the wrong question. When you explore deeper you discover that the employee surveys on why people slack off are far more interesting than the ways which they slack off. Many described being bored as the primary reason, others felt that their job was easy. So it seems to be a question of engagement.

I suspect in other cases it is that you have hired the wrong people and better filtering at hiring would result in a more motivated workforce. Ironically when you have a motivated workforce getting them to take a break becomes more of a challenge.

So I guess what I am saying is that if you are a leader that is worried about whether your staff are working, then the issue is far more likely to be with you than it is with them.

Hire the right people. (Hungry Humble, Smart)*

Be clear what is expected of them.

Help them understand why it is important – and who benefits from their work.

Be interested in them as individuals.

Interestingly all of those actions fall to the leader rather than the employee.

If you follow these steps then I suspect that you won’t need to worry whether they are pulling their weight, you will be too busy trying to keep up with what they can achieve.

Where does the responsibility lay

If your employees are slacking off then it is a failure on the part of the leader not the employee. So when you hear someone ask how they can tell if an employee is doing their hours and not slacking off. Ask them if they have hired motivated people they can trust? Have they given clear objectives and set expectations? Do their employees understand the context and purpose of their role? Do you value them and do they know it?

If and when you do see someone slacking in a damaging way, take a look and see if the route cause is one of these 4 issues, you’d be surprised how often it is one of them.

What I am confident of though is that any efforts to monitor time in the office (or home) – such as time clocks, pressure sensors on seats, keystroke monitors, swipe cards on toilets, or a foreman to watch people – and of course a foreman for the foreman – obviously you need someone to watch the watchers. All will have minimal impact on people slacking but will have deeply damaging impact to productivity.

It may sound overly simplistic but in my experience products generally succeed or fail in correlation to the effectiveness of Product Ownership on the team. Mainly because we under-appreciate the importance and the difficulty of the Product Ownership aspects in the product creation process. In my opinion the choice of this role is far more important than the coach or other team members. The role is full spectrum, they go all the way from discovery to delivery and more.

Ironically, we tend to think of software applications as being primarily technical objectives, our focus is too often on the quality and ability of the engineers, the architecture and design. We will spend time on process and optimization and efficiency. All the while forgetting that the most common and most consistent failure of all software products is that no matter how good the quality, how optimized or efficient it is, or how good the engineers are that built it – if you build the wrong thing it is a failure. A perfectly designed but unused product is worthless.

History if full of great products that missed the mark, how many apps have you downloaded to your phone that are no longer used or were never used after the first 30 seconds. There are many many more products that fail to ever get in the hands of customers at all. Internal IT products are often culprits of this, the assumption seems to be that because the users are forced to use the product we don’t have to actually ask them what they want or how they will use it, we build great products that don’t fulfill the actual user need.

I think probably my favorite and most over used quote is:

There is surely nothing quite so useless as doing with great efficiency what should not be done at all.

Peter Drucker

I use the quote far too frequently but in 25 years developing software this remains the most frequent sight I see, more products fail for not meeting the most basic customer needs than for any other reason. And yet when I say this, it generally gets scoffed at, until you start asking how many people have worked on products that have been abandoned or shelved mid development. Teams rarely believe their product is at risk of being cancelled, or are too far removed from the customer to appreciate that the user liking and using the product is infinitely more important than whether they are efficiently re-using a section of code. We have created a mindset that ‘done’ is delivering code. A product/feature/story is only really done when the customer is using it.

Product Ownership does not need to be a single person in that role, but it should be a mindset within the team. Ideally I’d love for this to be a shared responsibility. Unfortunately in my experience a true appreciation of Product Ownership is as scarce as Hen’s Teeth, and generally unappreciated and vastly underpaid, those that do it well make it look easy and doing it badly or being indecisive can really destroy a product so it can be a risk to spread the responsibility beyond one person. I have heard people talk of teams where the teams do it well and they don’t need a PO, but I have yet to see this for myself. Because of this experience I think of the Product Owner as the most important ‘hire’ for the team, getting the right person in this role can be crucial to the success of the product.

A good PO these days is hard to find…

So why is a good Product Owner so hard to find and what makes the role so difficult?

1: Differentiating what is needed from what is wanted

A significant part of the role is identifying what is needed to solve your users problems or to fulfill their needs, to enable them to be better at their job, or to maximize their fun or relaxation. The role is about understanding the problem and creating a vision of how that could be solved – not the technical solution but discerning the true need or true problem.

Henry Ford stood next to his ‘Faster Horse’

If I had asked people what they wanted, they would have said faster horses.

Henry Ford

The reason this skill is so tough is that users rarely know what they need, typically a user’s vision is constrained by what they currently do. As a result many products become re-works of a paper system or re-engineering an old system. A poor product owner gives a customer what they want or what they ask for, a good product owner listens and watches and blends wants and needs to solve the customer’s problem and give them what they need.

I often seen backlogs that are full of stories that are unfiltered customer requests, it is lazy and it is easier to do what is asked. But to find what is needed typically requires experimentation, feedback, conversations and observation. It is far harder to build what is needed than it is to build what is asked for. Similarly this can manifest itself when department managers decide what their team needs or wants without involving them in the discussion, a good Product Owner will spend time with the users of the product and ideally see how they use it.

A Product Owner with the creativity, the initiative and the Vision to create a great Product is worth their weight in gold,

2: Understanding what is required to create a successful application

A second aspect of the role is the one I see most frequently overlooked. Perhaps because of the emphasis on 1, the need to understand the business, I see people choosing someone from the business to become the Product Owner, their knowledge of the business is seen as their primary qualification and in many cases their only qualification for the role. And worse they are often asked to do the role in addition to their normal job.

However, a great Product Owner understands not only what to build but is familiar with the development process, they understand the ebbs and flows, they understand the implications of technical debt, automation and testing. The understand how crucial it is to have working software in the hands of users as soon as possible. I am sorry to say that business POs often lack this knowledge and experience, they will mistakenly perceive a desire for a fully working product rather than appreciate the value of early feedback. Many are plagued with the last bus syndrome, trying to include every imaginable feature rather than working towards a minimum feature set to get feedback and derive value early.

Personally I’d invariably trade an experienced Product Owner with zero business knowledge for an expert in the business with zero software delivery experience. Business knowledge can be gleaned from effective conversation, observation and feedback. The understanding of a good Agile Software Development lifecycle is far harder to learn and there is no substitute for experience.

Typically the best products result from experiments, reviews and feedback, a willingness to be flexible and respond. The other disagreeable quality of a Product Owner taken from the business is that their knowledge is about how the work is done now, and they are often blinkered to the possibilities.

Remember that the Product Owner sets priorities and interprets the Vision, they have more influence on the product creation than anyone. Their choice of priorities can profoundly impact the value, and the quality of the product. If they lack the understanding of the importance of testing, feedback and good software principles it can lead to conflict and disharmony in a team.

3: Communicating effectively with both technical and business stakeholders

Finally there is a need for effective communication. We always talk about effective communication to the point that it becomes background noise. But the importance cannot be overstated.

A great Product Owner, listens, they observe, they probe and they reflect. The ask for feedback and they read between the lines, they watch body language, they see and hear what isn’t said as much as what is said. When it comes to understanding the user they have great attention to detail and they look intently for pain points and points of pleasure, they are looking for a way to serve their users in the best way they can. Most of us think of communication as speaking, but for a Product Owner watching and listening are so very important. Empathy with the user, the customer and the ability to communicate using their terms and understanding their domain and conversing with them in a meaningful way is crucial, and if you don’t understand the terms develop an attitude of attentive student ask questions and show you are interested and are learning.

A great Product Owner learns to say ‘No’ powerfully respectfully and does so in a way that conveys they understanding to the person asking, a great Product Owner should not be seen as an obstacle or a hurdle but a steward of good decisions. The word ‘No’ should be delivered in a way that leaves me feeling confident that the Product Owner will deliver the best product within the parameters and leaving me confident that this decision is right even if it is not what I initially wanted. The Product Owner should be able to convey the implications of saying ‘Yes’ so that I understand why I am being told No. A great Product Owner has any number of tools that can help people see this and yet we regularly see backlogs full of feature requests that will never see the light of day because the PO doesn’t feel capable or sufficiently empowered to say NO!

But the PO must also communicate with the development team, they must understand technical development terms, to have a grasp of the technical implementation, even if they do not have authority over the ‘How’ I’d expect them to have a vested interest in understanding it. They also need to be able to communicate the business needs and the business terms in a meaningful way to the development team, This requires a versatility in speech and communication that is unusual to say the least. Being respected and understood by both the business and the technical team is a major feat, and as we all know any cloistered group speaks in three letter acronyms that only they understand and the audible sign when they have to explain to an unlearned outsider can demoralize the best of us. Do not underestimate this ability.

But there is more, they need the creativity to communicate design ideas or if the ideas come from others the scope to understand that creativity, to imagine what could be and express that to the business and to the technical team. And then we get into the really tricky realm of the stakeholders as opposed to the users, this generally is the group that funds the product, they want to see progress, they want to see good stewardship of their investment, they may ask for forecasts and may even press for commitments.

We have now loaded our Product Owner with the need to communicate with senior people that make financial decisions, to express Risk and Forecasts in a manner that it concise but meaningful, we want to be transparent and informative, but confident. If we are using forecasts especially mathematical forecasts we had better understand them and be able to back them up with explanation and confidence. A Product Owner my stand their ground in the face of authority and speak truth to power. A Product Owner that makes unrealistic commitments or promises, will lose the confidence of her team and her stakeholders in a flash.

If a Product is to be sold it is likely that you will need to be involved in Sales and Marketing, which brings a whole host of other skills and communication issues to bear, understanding the implication to the market, and how you measure that and how you engage with that is a new realm of understanding and confusion.

A great Product Owner is a master communicator, they have an insatiable desire for knowledge, to understand and be understood.

Summary

As you can see the skill set of a great Product Owner is monumental, and yet the good ones make it look easy. If you have a mindset suited to Product Ownership it is likely you already have good communication skills and enjoy learning more domains.

It is likely you are the sort of person that thrives on the delivery of a product and revels in the feedback, enjoying the flexibility and change, is unmoved at the thought of redoing something twice or even more to get it right.

Solving problem is a thrill and being able to see beyond the obvious and draw out information from users and then present something back is a joy.

That doesn’t mean it isn’t incredibly difficult, overwhelming at times and sadly unappreciated, and very often underpaid.

At some point the industry dismissed all these skills as unimportant and we see a flurry of Product Owners that write stories exactly as dictated by users, that input data into forecasting tools without the vaguest notion of what the forecasts mean or how they are calculated.

As I said at the start a great Product Owner is the lynchpin of a great Product, we should be seeking them out and rewarding them appropriately, you will be amazed at what can be achieved with the right person in that role.

Over the years I have discovered that the more I learn on any subject the more I come to realize that I know very little, it doesn’t seem to matter how much I study or how much I learn, the awareness of scope of my ignorance grows far faster. Does that make me wise or just aware that I know very little? I suspect that I’m slowly fighting my way out of the valley of despair.

No need to improve

One of the most challenging aspects of being an Agile Coach and working with teams is that to improve you first need to accept that there is room to improve. There are a some teams and team members that believe there is nothing more that they need to learn, they are so supremely confident in their own capability and knowledge that they refuse to consider that there could be a better way to do things than the way they have always done things.

On the other-hand I can’t be confident that there is a better way, only that we won’t find a better way unless we look. I don’t like the notion there is a ‘best practice’ as this limits our thinking. But this puts unwavering certainty that this is the ‘best practice’ against encouragement to explore the possibility of a better way, certainty is very powerful.

Sometimes this ‘certainty’ is founded in fear, especially when dealing with transformations where former roles are called into question, I find this an understandable reaction, but the situations I struggle with most are the team members that become blinkered to opportunities, they have found one way that works (even poorly) and simply are unwilling to try anything different. Their Ego, prevents them considering anything else.

As a coach I have no desire to force processes or ideas on people, only to open their minds that there could be opportunities and alternatives. So it can be heartbreaking when people refuse to even consider alternatives, or worse impose their views on others through sheer force of will.

Perhaps I am mistaken and maybe the right answer is that if something isn’t broke don’t fix it, but that notion doesn’t sit well with me.

So how do we persuade people to open themselves up to learning new things?

I recently had an experiences that I found tough, there was a QA who refused to ‘leave his column’ on the board, he would not do anything that was not ‘testing’ and resisted anyone working with him in ‘his column‘ thankfully it is not often I see that level of obstinance. But this situation was further compounded by the rest of the team enabling his behavior. The developers were all too happy not to be involved with the QA aspect and were seemingly unmoved by his unwillingness to cross boundaries.

The QA column was regularly a bottleneck but rather than addressing this the team wanted to mask the issue by pushing cards through and raising new cards for rework. What was tough was that the team saw no need to experiment with alternative ways of working: suggestions included either helping the QA, or even getting the QA involved earlier, and despite raising QA as a bottleneck repeatedly in retrospectives the team didn’t want to change behavior even in the form of an experiment.

As a coach you can shine a light but not force a change. I felt the team was capable of far more but the team were getting things done and were seemingly content with the status quo. For me this is the dark side of coaching, where you must watch a team not reach their potential, out of respect for their independence. Ultimately it is a trust issue as things so often are.

Ownership of Columns

In general I dislike explicit roles when there is a shared responsibility, and I dislike the notion that a column on a board is in anyway related to a person or a specific role, the board should reflect the progress of the work (stories) not ownership of the work and when the two become muddled people become defensive and territorial.

When there becomes an association between a column and a person the focus moves from getting a story done as a team, to moving a story on to the next column, we switch our context of efficiency to a narrower view.

This is often seen as a subtle and unimportant distinction. But when the team loses a cohesive sense of ownership for getting to done and can hand off responsibility to another sub section of the team, bad habits emerge. At it’s worst I have seen teams (thankfully not one I coached) where at stand-up one part of the team will brag about how many stories they are ahead of an other part (be it front and back end or Dev and QA). In one extreme case I saw a team decouple testing from development by splitting stories and I overheard one standup where the developers were gleeful that they were now 3 sprints ahead of testing (the sprints were 3-week sprints). It is 9 weeks before they will see value from their work or even know if their work had value, and yet they were so proud.

Dunning Kruger Effect

Adjusting your mindset to one of learning rather than certainty can be tough, especially for those that grew up in a culture that rewards confidence and certainty, but accepting that you don’t know everything and being aware that there is always the potential to improve can enable you to become far more capable, the only thing stopping you is your ego.

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.

With a natural or assigned Maverick on our team and a level of vulnerability and trust we reach the point where actual decisions can be made. Up until now we could consider the efforts to build the team to be the foundation, but now we have to put it in to practice.

This is also the point when it starts to hurt, this is where it really tests whether you truly have trust and are truly open to input and discussion and healthy conflict. Many teams say they have built trust, and many teams seem to have open discussion and healthy conflict, but this is where you test that.

Can you make a decision and follow through on it?

Consensus

Please do not confuse decision making with getting consensus. The goal of a team is not to please everyone on the team, it is to get things done, to make decisions that help us – for the team reach our team goals. If we waste time trying to please everyone we end up either paralyzed, or with a watered down decision that accommodates everyone but satisfies no one.

“Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.”

Patrick Lencioni

The funny thing is that most of us do not want consensus, nor do we always want to be agreed with. Most of us are not unhappy when a decision is made just because we disagree with it, but we are very unhappy when our opinions and concerns are avoided; ignored; overlooked; or given only lip-service.

I want to feel valued

If I feel that my input is valued; listened to; if my concerns are discussed fairly and sensibly but the decision is made to proceed despite my concerns, then I can still buy in to that decision and crucially I can support it.

But if the decision gets made without me, or my input is so obviously not going to be given a fair hearing, then two things happen, first it won’t get my support, or my support will be shallow and half-hearted. Second, why would I speak up next time? We will just regress to a lack of healthy conflict.

It should be simple, if someone is on the team then their opinion counts, otherwise they should not be on the team. If you cannot accept that, then perhaps you should not be on the team. Being a part of a team has an implicit commitment to value each other.

Unless commitment is made, there are only promises and hopes… but no plans.

Turn decisions in to plans

Getting to a decision is not enough, you need to turn those decisions in to plans and you need to turn those plans in to actions.

Plans are only good intentions unless they immediately degenerate into hard work.

Failing to commit to a decision is as bad as not making a decision – possibly worse. We should be clear what the decision is, and who and how it will be implemented.

Failing to follow through on a decision renders all the time and effort spent discussing and debating the right choice, null and void, it becomes waste. A waste of time and energy and will undermine a team as surely as the inability to have the conversation.

Be decisive and be clear

Whenever possible any decisions should be associated with a specific action, a date for it to be completed and a clear understanding of who will do it.

If we make the extra effort to identify who will perform the action and when it creates a foundation for the best chance of success, there is a clear and measurable outcome. Everyone knows what to expect and when. This is crucial for being able to hold each other accountable.

Wishy washy action items, that are for everyone with no expected date will generally get ignored, but something specific combined with the certainty that you will be held accountable and it will be followed up will likely mean it gets done.

Pointless conversations

If you find you get to the end of a discussion with sufficient healthy debate and the result is to take no action on a frequent basis, then this is cause for pause. Could you avoid wasted conversations by injecting a Go/No go break a few minutes in to a discussion and ask the team: “If we reach a decision are we empowered to act?” or “If we reach a decsion would we be willing to act?” if your answer is No to either of these, then save yourself some time and heart-ache, if there can be no action then the conversation is moot.

That is not to say all conversations must result in action, but all conversations should have that potential or they are waste.

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility. But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

Have you ever been on a team where the boss presents a new idea and looks around the team for a response and there is this one guy that breaks the silence by saying “What are you drinking boss? That idea is a bunch of crap” well maybe he was a little more polite but still the message was clear. Everyone else holds their breath waiting to see what happens.

Desire for harmony

For most people the desire to be liked and accepted leads us to have an overwhelming urge to conform with a leader (or the group majority) to maintain harmony, regardless of what we might think. Sadly most people also have a very strong subconscious desire to be agreed with, especially leaders. When people agree it affirms their leadership and those that challenge are perceived as challenging them personally – rather than the idea itself.

This all combines to create another horrible dysfunctional team, one where there is an absence of conflict. Well, apart from that one person stupid enough to speak their mind, and they’ll likely be fired soon, then we can all get back to agreeing with each other.
Now I am making light of it, but a leader that is able to understand conflict as healthy is rare, and one that can, in practice swallow pride and engage in healthy debate is rarer still.

The invisible threat

The problem though is that even with that rarest of leaders there is an invisible threat, the leader himself knows that he values conflict, that to be truly successful ideas need to be freely expressed and freely challenged, but everyone else can see the threat that is invisible to the leader, they know he still holds the power even if it is not overt, that invisible threat still causes teams to hold back and to create a false sense of harmony.

You may think that I am overstating the point but just think back over your career and how often does the yes-man or yes-woman get promoted over the more capable but outspoken. How many leaders surround themselves with people that will affirm their decisions rather than pushing for more. It is natural and normal to like those that agree with us far more than those that push us. But get over it! That behavior is limiting your team.

Solution

My solution to this problem is for every team to have an maverick, someone that is Not afraid, someone who will break the harmony spell and get the conversation started, push ideas to be better, force plans to stand up to scrutiny, to trigger others into sharing their opinions. If you are lucky you have one already. Turns out every team I’m on has one 🙂 but if your team doesn’t already have one (or more than one) then take turns, at the start of a meeting roll a dice, select one person to be devil’s advocate and it is their role to challenge ideas look for flaws or weaknesses, this will push the team to be better and can do so from the safety of an assigned role.

Devil’s Advocate:

The term a devil’s advocate describes someone who, takes a position he or she does not necessarily agree with (or simply an alternative position), for the sake of debate or to explore the thought further through discussion.

Try playing Devil’s advocate:

If you sense that some of the team are not buying in to a proposal but are not speaking up, make a challenging statement

If it is your proposal, invite disagreement by questioning your own proposal, by saying maybe I am wrong, or I think I missed something

Be clear on your motives, you must genuinely want healthy debate. If you invite disagreement but brush it off then it can further encourage artificial harmony

There is a difference between healthy debate and someone that is just obtuse, and conflict alone will not get you to results. But an maverick that is also a genuine team player is invaluable on a team. I’m not talking about jackasses here, but people who are not afraid to speak their mind, for whom honesty is more important than acceptance.

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility. But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

Once trust has been established the next step is to build on that trust with healthy conflict where ideas can be shared without fear, where opinions are heard and considered.

Have you ever found yourself alone listening to music and you take a look around wondering if it is safe to dance? Safe because your dancing is so bad it is unfit for other eyes, in fact it is so bad you are not sure you should look. Perhaps your car is a little safer, it is a capsule of invulnerability, so when you are alone you can sing at the top of your voice and no one can see, or not until you stop at the lights and notice the person in the car next to you looking at you.

Feeling safe enough to be vulnerable is not easy even when you are alone, but it gets progressively harder when there are other people around. Now I’d never sing or dance in front of others, but the other day I found myself at lunch with four of my closest friends at work – if asked I would say I trusted the four of them a lot, I consider them really great friends, so I felt able to be a little bit vulnerable and I told a slightly inappropriate joke.This may not seem a big deal but I immediately became embarrassed I glowed red and went quiet for a while, I found vulnerability is tough even among such good friends.

Vulnerability is tough even among close friends

We all want to be liked and accepted, to be included in a group, and so it can be hard to be vulnerable, and yet the irony is that taking the step to show vulnerability may well be the step needed to make those friendships and your team stronger.

Trust in a team

In a team environment it is so important that you can feel enough trust with ALL of your team mates that you can truly feel able to say things like:

I need help

I don’t understand

I disagree

I made a mistake

I find those tasks difficult

Show me how to do that again

I feel uncomfortable when you do that

I wanted to do the task you took

I am unhappy with this decision

But if I struggle to trust even my best friends, how can I possibly trust co-workers that I know much less, after all the same rules apply. I want to be liked and accepted, I definitely don’t want to look stupid or uncooperative, I don’t want to discourage others or waste time, I have a burning need to feel valued and part of the team. I need to show my worth to my boss, etc.

Is it safe to dance?

Essentially when you are part of a team you are asking yourself “is it safe to dance?”
If you keep that in mind it gets easier, what would make it safe to dance for you. For me it would take a lot!

I’d need others to dance first, probably all the others, but certainly the leaders, the people the others respect. I’d need to see that some were as bad as me, I’d need to see that no one was laughing at them (only laughing with them) and that everyone was encouraging and supportive, then and only then might I feel able to be vulnerable and join in, and frankly it would take a few repeats before I would truly feel comfortable.

We can dance if we want to, we can leave your friends behindCause your friends don’t dance and if they don’t danceWell they’re no friends of mine…

How does that relate to work?

You may think that dancing is not like working in a team and that the humiliation of dancing is far worse that simply doing your day job, but I think this is one of the reasons teams suffer from an absence of trust so often. We dismiss both the importance and underestimate the difficulty of building trust in a team.

In a team environment you are sharing your ideas which are deeply personal, your knowledge and judgment which may be closely associated with your sense of self. Doing something wrong could affect your job, maybe even your career. Sure you may not look and feel like a buffoon but the stakes are much higher. And even if you get past the work related barriers you still have to contend with our inherent desire to be socially accepted, to be liked and valued.

So how do you build trust on a team?

Actually this is not that complicated it is not really any different to building friendships.

Spend time to get to know each other, take a few minutes during meetings to get to know each other, this is not waste, a few minutes spent building relationships could well be the most productive aspect of the meeting in the long term.

Chat over coffee and as you work – about personal stuff

Have lunch together as a team – this works best if the whole team is together.

Play games! One of the best ways to build relationships is to play a game something simple like a card game is great, it is inclusive and leveling, the most junior member of a team can challenge the most senior in the safe confines of the rules of a game this makes it much easier to discuss work ideas on a level playing field later.

Time, trust and relationships take time, do not underestimate it.

For all of these it works best if everyone is there to avoid creating pockets of trust which could undermine the team later.

The last one was time, and warrants an extra note. Building relationships is a slow process you can’t simply flick a switch, allow teams the time and space to grow the relationships will build and grow stronger and stronger, and once the team is stable changes can be made so long as a core remains to keep the identity and trust that has formed.

Trust takes time

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility. But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

You cannot uncover better ways to deliver software without first uncovering better ways to work as a team. And the basis for an effective team is Trust.

Building trust should be your top priority, spend the time, make the time, it is an investment in the future of the team. Without trust anything else you do will suffer.

The capacity to learn is a gift;
The ability to learn is a skill;
The willingness to learn is a choice.

Brian Herbert

It is pretty safe to say that most learning involves some kind of cost, whether it be that you are slower as you learn or have to explicitly take time to learn something new. There is a time aspect, an effort aspect and sometimes even an overt outlay of cost for a training course a book or a subscription. But all are a cost to you or our employer. But the question is: Is that cost simply a necessary expense or is it a worthwhile investment for the future?
Is that cost simply a necessary expense or is it a worthwhile investment for the future?
This is a tough question and I am sure many employers and employees wrestle with on a regular basis. For the employer there are concerns that time spent learning is time that is not productive (or not as productive) the time could be better spent generating income. In the case of formal training or qualifications there may be an opportunity cost of the time spent AND the cost of the training which can be significant, and perhaps more concerning the employee becomes more employable and more valuable as a result so there may be a consequential increase in turnover or a necessity to pay the employee more as a result. In essence it is easy to become focused on the expenses and forget the benefits that come from a better trained and more fulfilled workforce.

As an individual/employee it often is expected that you do your learning on your own time, you are motivated for self-improvement and your employer may focus on the benefit the employee gains rather than the benefit to the employer. The difficulty with this is that learning time tends to be when you are least energetic, or at times when you are sacrificing other activities.

Short vs Long-term thinking

In the simplest form the choice may often come down to the type of work and whether an investment in people will benefit the organisation. My initial thinking is that if you expect to have a high turnover of staff or the type of work you do is low skill, then investment in people may be perceived as an expense rather than an investment but even then I wonder if an investment in learning may reduce turnover and increase skill. But in the field of software where the world changes almost daily, with new techniques and new approaches appearing regularly, then an investment in learning is not just beneficial it is almost essential just to keep up. To not invest in learning could be very detrimental to the long-term prospects of your organisation.

Choosing NOT to invest in learning could be very detrimental to the long-term prospects of your organisation.

In ‘software fields’ good people are hard to find, and even harder to keep. Many organizations now operate flat structures with little or no hierarchy, promotion in the conventional sense is no longer the main form of advancement. Individuals grow through learning new skills and becoming experienced in new techniques, and not simply hands-on learning and experience. We rely on intrinsic motivation – Autonomy, Mastery and Purpose, to keep employees engaged, happy and productive.

A key element to both Autonomy, Mastery and even Purpose is time for learning and reflection. People that are not supported in this are likely to be less fulfilled, less happy and more likely to look for work elsewhere. Entropy sets in, and in software that can be fast and devastating for both individuals and organizations, individuals with outdated skills can find it difficult to find work and become demoralized and trapped, organizations can find that motivated individuals want to be working on new technologies and embracing new techniques.

What is our goal?

An organisation is generally interested in making money and growing either in size or in effectiveness, understanding this we can attempt to visualize how individual learning can support that goal. Learning and personal development leads to a sense of Mastery, empowering the employees by giving freedom to use the time as they see fit provides autonomy, and sharing your company vision and how they can be a part of that provides the purpose. Employees that feel these motivations will be happier and will be far less likely to leave, turnover is hugely costly to an organisation especially when it is the better employees that are more likely to leave. The reduction in turnover alone may be enough to justify significant effort. But improving employees will use those new skills in their work, they will encourage others and it is highly likely that productivity and creativity will improve. In short providing opportunities for learning supports the goals of most organizations.

How much time should be assigned to learning?

At a previous company they set aside 2 hours a week for each employee to dedicate to personal development, this was in addition to any formal training. This is close to a 5% increase in overhead per employee, which is significant but set aside a reduction in turnover may be immediately beneficial. In practice however it was not always observed, pressures from projects would often squeeze this time as it was seen as secondary to business objectives. The frequency in which it was observed undermined the policy.

In environments where time is billed to clients it becomes even harder for a company to see the value of learning, it becomes un-billed time which is even more costly but that doesn’t reduce the importance or value in the learning time. I’d like to see organizations regularly set aside 1/2 a day each week for personal development, and provide the tools necessary to make this effective – pluralsight subscriptions, purchasing books for employees even if they are not directly relevant to their work – remember the goal is to motivate and create an environment for improvement. At 10% of employee cost this is a significant ask, but I would hope that if introduced in the right way with enthusiasm and support, employees will embrace the way you are valuing them and their personal development and this investment will pay dividends.

Our danger is not too few, but too many options … to be puzzled by innumerable alternatives.

Richard Livingstone

Can you have too much autonomy and too much choice?

One final observation is that when presented with boundless autonomy we generally become lost and confused. Most people will respond to this with confusion and more limited actions than when provided with a framework. Imagine a restaurant with no menu, you could order anything you like. Most people would be conservative in their responses, they will not challenge themselves or their boundaries instead choosing something they already have confidence in and confidence that it is easy for you to provide – some will challenge but most are cautious. Also most people don’t like this, they want a restaurant to have a menu. They may grumble that something isn’t on the menu, and may ask to switch X for Y on their order or for the cooking to be modified, but the framework of a menu provide scaffolding and enables choice, the lack of the scaffolding stifles it.

It is the provision of boundaries that enables us the pleasure of pushing them, and having some guidance of what our options are for learning enables us and empowers us far more than a blank slate. With some ideas of what is available we are able to ask for more or suggest alternatives.

Summary

Make Time: In my opinion an organisation that is in the software field needs to make learning a pre-requisite, this is the most important task of the week. Learning time is very important, so set aside time for it, and make the time such that it doesn’t conflict with the team or other business activities, Maybe set aside Tuesday morning as personal development time and challenge anyone not using it. Teams where there are pressures or pairing may feel that this time impacts on their peers or their project this message needs to be challenged regularly. This is for the long-term health of the business which outweighs any temporary short-term pain.

Scaffolding: Create a framework where it will be used and is not just a hollow gesture, have a menu of options, and people who’s role is to support and guide, set development goals, provide subscriptions to online training, a budget for formal training, encourage in house peer training in this time. Encourage people to present their learning, acknowledge them for their efforts and especially for sharing it with colleagues.

Broaden Scope: Don’t limit this to technical skills, or to skills your organisation currently uses, this is about personal development, so team building, soft skills, and even time to reflect on learning or their career/interests all help with that.

Support: Some people will need more encouragement and support than others and so a group that is dedicated to professional and personal development could be invaluable to get the best out of this initiative. All of us can benefit from someone to help us identify our goals and a plan, and to encourage us stick to it.

Persist: Finally this will take time to become habit, starting the initiative is not enough, for a while it will require reminders and reinforcement to get the best from it, but if you are able to provide your team with the opportunity to grow as they want, I believe they will become far more engaged, enthusiastic and energetic.

Meta

Author

I am the Operations Manager for World Wide Technology's Virtual Office - supporting teams of software consultants collaborating to deliver amazing products and solutions.
I am also an Agile Coach, coaching teams in developing an Agile, Lean and Theory of Constraints mindset. I am a regular speaker at conferences on related topics and am the designer of a Kanban based board game - "Motor City" I have 25 years experience in software development, working on projects in both the UK and the USA