When I saw a copy of The Advantage on the shelf at the airport I picked it up straight away. I read Five Dysfunctions of a Team a few years ago and considered it leadership gold. Learning about organisational health from the same author, sign me up!
I’m disappointed to say that for me, The Advantage just didn’t hit the same high notes. Despite only being 216 pages the book took me around eighteen months to complete and that’s simply because I wasn’t engaged and I felt I had to force myself through the final few sections.
The early part of the book recovers a lot of the same ground as Dysfunctions, I have no problem with that. Creating a leadership team who feel safe and can operate together as a team is no doubt a key part. Then we moved onto organisational values, both desired and acididental. I found that part quite interesting but when we moved onto creating and reinforcing clarity I drifted and drifted.
It’s quite possible I missed the point, the book is highly rated on Goodreads so many people have clearly got a lot from it. Unfortunately, this won’t be one I pick up and re-read again in a hurry. I will however go away and try to define my teams’ values – I grant, that’s a very valuable exercise!
Have you read The Advantage? Do you disagree with me? Let me know either on Twitter or in the comments, I’m always happy for someone to point out something I’ve missed!
I recently did a talk at DDD2020 on People Skills and one of the questions I recieved afterwards intrigued me enough to want do write about it.
How relevant do you feel non verbal communication is while we’re all work remotely?
At a very simple explanation high level I’d say absolutely essential because of the increased reliance on Email and IMs during the Covid-19 pandemic. The fact that this question was asked over Teams really hammered that point home.
But what I thought made this question especially interesting was when I started thinking about the most effective communication mechanisms when working remotely. Doist have written some brilliant blog posts on working remotely and async communication which I highly recommend you read. This means our non-verbal skills have to be absolutely on point. Doist recommend overcommunicating, making timesales clear, and really thinking about your mechanism for communicating (as well as many many other great tips). You can’t just fire off a skype message when your colleague is on the other side of the world, at least not if you expect a response any time soon. Proper thought out communication and strategies for sharing and storing information and making decisions is key.
There’s also a lot to be considered in the non-verbal of verbal communication methods. It’s much easier to get distracted during a phone call when you’re sat at your computer with your email and web browser open. I mentioned in my talk how people pick up on signs of a higher cognative load, how many times have you been speaking with someone and you’re aware they’re tapping away on their keyboard. While we may see it as efficient multitasking I can assure you the person you’re speaking with considers you rude and distracted.
Where and how we use the camera is also a key factor. I use a built in webcam and a secondary monitor. This means that if I want to see what someone is sharing I drag them over to the larger monitor and read it there. This, means that even though I’m paying complete attention to what the person is telling me I have a distracted, uninterested look to them. It’s often worth ensuring that you’re looking at the camera, rather than the image when you’re speaking with someone. At the very least make sure you’re looking vaguely at them and not off into the distance somewhere. A piece of advice I was given recently was to think of a video call like an interview for the BBC. Consider what you’re wearing, consider your background, and look into the camera – not at the interviewer. It’s extreme, but it is all true!
Without non-verbal communication our remote work would be much much harder, we’d be forced to sit on phone calls all day and we’d have no flexibility in our calendars to do the important stuff like, you know, work. Unless our written communication is organised and clear we stand no chance in cutting down the number of meetings we’re in. However, we have to be extremely important when we are having verbal communications, webcams – although an amazing technology can help us send the wrong message. Consider how you’re being perceived by the other person, being visible isn’t enough. And remember, those 1:1s are just as important whether you’re on the phone or sat around a table, resist the tempation to check your email at the same time!
It’s getting towards that time of year again, where have conversations with our managers about what they expect us to achieve over the upcoming year and we throw in a few “personal development goals” which won’t really matter when we’ve forgotten about them in twelve month’s time.
Somewhere personal development and annual performance have got mixed up somewhere here. Most companies base some element of their employees’ performance on how well they’ve met their goal. Personally I disagree with this. I believe there are three types of goals.
Goals which you need to meet to successfully perform in your role
Goals which form part of the team’s improvement plan
Goals which are designed to help you meet your long term career aspersions.
Ideally a goal should fit in to two or even three of these. However it’s the third option, goals for personal development I want to discuss in more detail.
My grandad was a train driver, he drove everything from The Flying Scotsman to the first diesel Deltics. When he joined the railways he was given a number, everyone who subsequently joined would get a higher number. As the years went by and he progressed in his career The drivers with the lower numbers, who joined before him retired and he became the senior driver on the east coast mainline because he had the lowest number.
In today’s organisations we can’t sit and wait for the people ahead of us to retire for us to gain our promotions. I’m not suggesting that there wasn’t a lot of study involved to progress on the railway, however there was a lot more structure. If we want to progress in our careers we need to identify not only the gaps, but our long term objectives.
List a few of the people you believe are very successful. I admire Barak Obama, Dwayne Johnson, Bill Gates, and several others. None of these people became successful by chance. They envisaged their careers, their successes, and they made them happen.
Ok, enough motivational writing and comparing ourselves to famous millionaires. In his book Seven Habits of Highly Effective People, Stephen Covey advised his readers to Start With The End In Mind. In order to get a big picture view of your goals in life he suggests you write your own eulogy, or perhaps less morbidly, your retirement speech. What do you want people to say about you? What accomplishments would they list? If you find this too difficult visualise where you want to be in five years. What role do you want? What skills do you want to have?
The next step is to break down those ambitious goals into smaller steps. For example if you want to start your own business but don’t have any knowledge of sales then you may set yourself a goal to complete a sales training course. If you want to be working as an iOS developer then perhaps you have to release your own personal app to the app store?
Lets stop assuming that major change in our lives and our careers will suddenly happen. Successes like Microsoft, the presidency, and film careers don’t happen by accident. They happen because those people took small, measured steps, and smaller goals which we set ourselves and complete on a daily basis.
This is why your annual goals are so important. They’re your commitment to your personal progression and an opportunity to seek support from your manager and organisation.
Our annual goals should reflect where we want to be in 12 month’s time, a step on the ladder of where we want to be in our grand vision. If we want to deliver on them we need to manage them, quarter by quarter, and even day by day.
This is why personally I don’t believe our personal development goals should factor into our annual performance reviews. However, as managers we want to coach people on their careers (not to mention meeting department goals). These are people’s personal and private goals and I don’t think any bonus or annual performance should be tied to those. But we work within the systems we’ve got!
So what should you do now?
Create a vision of what world domination looks like – what’s your super goal which you want to achieve over the course of your career (this can evolve as you go, today it just acts as a lighthouse of where to aim for).
Understand WHY you want to achieve that.
If that’s the end goal what significant steps could you make towards that vision in the next 12 months?
Discuss (if you wish) these 12 month goals with your manager.
Create an annual schedule, what will those 12 month goals look like as you move through the year? How will you know if you’re on track? Schedule these times in so you don’t forget
Reserve a little time each and every day to move one of those goals forward.
Don’t wait for that big ambitious career goal to mysteriously drop out of the sky. Make it happen, a little each day until you’re there.
Many larger companies are following the lead of companies like Spotify’s to create engineer led communities, sometimes called Guilds. The concept is simple, and very good. Creating a cross team culture of engineering excellence to drive best practice forward among employees sounds like a brilliant idea. In this post I’m going to discuss my experience of working with Communities of Practice and my thoughts on their true value.
Companies usually start a CoP initiative when they want to engineers to take ownership of:
Defining Standards and Best Practice
Training and developing it’s members
Breaking down Silos around teams
Hiring and building a better team
It sounds great right?
As with most things the reaslity isn’t quite as straightforward as that.
As anyone who reads my blog may pick up I enjoy a little amateur psychology, I believe it helps me in my role as a team manager. One of the things I’m acutely aware is the tribe mentality of scrum teams, when people get so focused behind their products they often find it difficult to see other teams as allies – too often they’re seen as impediments to deliveries or competing products. Forming a Community of Practice asks people to shift their focus and split it away from their scrum teams to think as a wider team. It can be hard to sit with two hats on!
So, how do you get started?
There’s a very good book by Emily Webber called Building Successful Communities of Practice which outlines a very good approach. She talks about a Community Maturity Model which outlines various objectives the forming community should aim to hit as they grow. By splitting out into distinct Potential, Forming, Maturing, and Self Sustaining phases. It’s important to realise that giving someone a goal and letting them go is not enough to build a Community of Practice.
With CoPs I’ve helped develop it’s crucial to start with a small group of engaged people who set goals and achieve them. Using these successes and achievements as an example to recruit more members and take on more ambitious goals. You can force dozens of people to join a meeting but you won’t get engagement, you want to be able to hold up what the community has achieved, show it off, advertise it, and ask other people if they would help deliver the next goal.
Communities should set their own goals. They need the ability to ask their members what work is needed and the autonomy to be able to go and make it happen. Otherwise they’re simply a vehicle for management to share project work between teams.
Finally, these formative and fragile communities need real organisational support. They need people to have goals set around forming the community, these people need time (I recommend setting the expectation of a day a week out of regular team duties), they also need a discretionary budget. Breakfast, coffee, prizes, and events go a long way to getting people in the door to hear what you want to achieve and once you’ve got them a social budget is a great way to help those cross team relationships form!
If you’ve been involved in Community of Practices or “Guilds” as they’re sometimes known let me know. What advice would you give to someone who wants to form them in their organisation?
I recently listened to the audiobook version of Matt Skelton and Manuel Pais’ book Team Topologies. It was so good I bought the kindle version while I was still halfway so I could make notes and highlight the good bits (most of the book it turns out).
The book takes several principals such as Conway’s Law and really applies them to business teams. This is something I’ve seen first hand. When several teams work on one large product the codebase becomes decoupled if the teams are given ownership of particular components. However, if teams are expected to work across the codebase the solution becomes monolith and the teams become a super squad.
In the book the authors argue that there are actually a very limited number of team types in a modern organisation. I don’t want to list them because I’d strongly recommend you to buy the book and read the descriptions for yourself. However, if the various types it was the concept of platform team which intrigued me the most.
I actually think Matt and Manuel underplay the huge value of a platform team. They discuss brilliant ideas about consumable APIs and documentation for product teams which consume them. However, a data driven business like mine I believe we should run far more platform teams and far fewer product teams. If we want our Product Owners to be able to innovate and prove the value of ideas quickly we need our data sources and components to be as plug and play as possible. This allows any product or concept to be built and tested very quickly. If all these services were owned and managed by platform teams, instead of falling down the gaps between product teams the solutions would be more robust and the lead times far lower.
If you’ve never given any thought to how teams are created and assigned areas of ownership then this is a brilliant book to read. If you’re not sure how your teams communicate and share information then this book is essential.
A few weeks ago I went to a talk at Agile Yorkshire by Tom Hoyland where he discussed the how he formed an agile team. In it he claimed that Velocity is a Vanity Metric.
If you haven’t read it then I highly recommend you pick up a copy of The Lean Startup by Eric Ries, this was my main introduction to the term. In the book Eric talks about how a Vanity Metric is any figure which is skewed to inflate the success of a product. One of the example he gives is Number of Registered Users, a figure which will clearly go up and up over time. A better metric, Ries argues, would be Number of Active Users. Obviously if you’re looking for a successful product you’re more interested in how many users are currently using it than how many people completed the signup process.
He claims that by basing metrics and KPIs on these Vanity Metrics is akin to giving yourself a pat on the back for building a successful product while sticking your head in the sand about why your business was losing money (or the startup running out of runway as he describes it in his book).
So, to return to Tom’s question – is Velocity a vanity metric?
Most Scrum Masters calculate a teams’ velocity by taking an average over the previous sprints. The number of sprints varies but six (around 12 weeks of work) is the norm. Using this figure the the team can then calculate how far a particular story is away from delivery or epic from completion.
There’s no doubt that Velocity is a useful forecasting tool (although, as one of my colleagues pointed out recently that if you plan a sprint on your average velocity then you will, by definition, fail 50% of the time). However, is it deluding us into thinking we’re a successful team and detracting us from more accurate measurement?
I think this comes down to how you measure success. Most people would agree that judging a development team on how many features they can deliver is fairly narrow minded. A development team includes a Product Owner, their remit should be to develop a product not to simply crunch features. If that was their goal then they could simply create huge numbers of easy, yet useless features just to score points.
In this new age of DevOps a Development Team should use their PO’s expertise and take ownership of the success of their product. For them to be judged on how much work they produce, rather than how much success they’ve had is a limited measure. It reminds me of the from the book The Goal where they measured and optimised the workstations rather than asking whether the system was effective.
Therefore, although shocked when I heard it I agree with Tom. Velocity is a useful tool for the team to forecast. But if it’s chased as a KPI or used to measure the team then it is indeed a vanity metric and will distract the team from trying to improve their product. If we want to measure our teams’ success then we should look at the metrics of our products, not try to calculate some kind of Hours to Story Point ratio or chase an ever increasing Velocity. We should focus on Number of Active Users or Number of Requests via the API, this will measure the teams’ success, rather than it’s productivity. As a friend of mine is fond of saying, effective rather than efficient.
I’ve written quite a lot over the last few weeks about Safety in team discussions. What I haven’t really discussed is how to detect when the safety is starting to fail. Imagine you’re in a conversation with someone, at work or at home and they’re starting to feel unsafe. We know that this means they will stop sharing and will result is poorer group decisions. But how do we know if someone is feeling like that and what can we do to prevent it?
If you haven’t read it already I strongly recommend picking up a copy of the book Crucial Conversations. In it, the authors discuss that people generally go one of two ways when they’re feeling unsafe. They either go to silence or violence.
When someone goes silent they often stop talking or become very monosyllabic in their responses. Perhaps they want to shut down the conversation or move onto another, safer topic or maybe they’re only sharing certain parts of the story – the parts which support their argument rather than discussing the potential problems with it. However silence manifests it’s usually because the person doesn’t feel comfortable with the topic and wants to move on or gloss over the real issue.
Other people tend to go to violence. I’m not talking about physical violence (at least I hope we’re not making people so unsafe they have to lash out). I’m talking about attacking an idea or, even worse, a person. Comments like “that’s the stupidest thing I’ve ever heard” or “only a moron would say that” are attacks. People raise their voices and try to dominate the conversation through shear volume rather than calmly discussing the topic with someone else.
It’s important to realise that both of these are natural reactions when someone feels insecure discussing something. It may be that you’ve said something which has upset them, or it may be that they’re worried about the whole topic of conversation.
In the example I gave a few weeks ago the developer had an idea which he refused to share with the group because he didn’t think the team would listen to his opinion. However, he could equally have turned to violence and tried to force his point on the group by making them feel unsafe challenging him. Both of these are defense mechanisms. It’s our role as colleagues, as human beings, to look for signs that someone is starting to feel unsafe in a conversation and to look for ways to reassure them so we can resume constructive dialogue.
Collaboration is hard, if we really want the best decisions then we need to hear all viewpoints and listen to everyone’s experience. We can’t do that if we bulldoze our view too firmly. The next time you’re passionate about an idea take a look around you and see how others are reacting to you… are they going to silence or violence? We cannot change other people’s behaviour but if we try and support other people’s confidence then we’re likely to get ideas and suggestions presented which we’d never have considered ourselves – after all, isn’t that the point of a team?
I’ve been posting a lot about communication and safety recently and I want to give credit to the book which kickstarted my renewed interest.
Crucial Conversations is by Kerry Patterson, Joseph Grenny, and Ron Mcmillan. In the opening chapters the authors explain that a crucial conversation is any exchange where the stakes are high and emotions are running rampant. They describe how avoiding these conversations or handling them badly can leave lasting repercussions on our wellbeing.
Over the following chapters they describe how to recognise safety, how to reinforce it, and how to reach a positive outcome. It’s really strong stuff, in fact I’ve incorporated many of their ideas in my own style and recent talks.
The book isn’t targeted to a work environment, in fact many of the examples are close to home and personal scenarios. Asking for a raise or disagreeing with someone over a design choice will seem like small fry compared to some of the issues the characters in the book face.
However, I believe strongly that by using these techniques teams can communicate more effectively. By using some of the ideas Kerry and his fellow authors use to monitor safety in a conversation we’ll have better retros, planning sessions, and general collaboration.
If you’ve not read it then I strongly suggest you pick up a copy – it’s one of the few books I’ve rated 5* this year.
I recently read an article by Chris Brecheen, I follow his page on Facebook and his post about dungeons and dragons caught my attention on a slow Sunday morning.
In it, he discusses a D&D player with an unbeatable magic sword who saunters up to a dragon and, through lack of preparation, is reduced to a pile of ash. Meanwhile the team who have battled against ogres, orcs, and trolls for the last three years eventually manage to bring down the monster after several hours of hard fighting.
The message was that having “talent” in something (or at least believing you do), makes you overconfidence, brittle, and actually limits what you can achieve.
In his book The Art of Learning Josh Waitzkin discusses how children are given positive reinforcement in one of two ways. Either they are told that they’re really good at something, maths for example, or they are told that they worked really hard.
The difference comes, Josh explains, when they meet a challenge they can’t overcome. The kid who is told that they’re good at maths immediately assumes when they face a question they cannot answer that they are not good enough. The child raised to believe that they succeeded because they work hard has a different outlook, they believe that they’re stuck because they’ve not worked hard enough. One child will continue to work the problem, the other will assume it is beyond them.
Believe it or not I’ve seen the same thing in developers, some with fifteen or more years of experience. When a developer is faced with a bug they cannot solve, either they assume they are not smart enough (or, far more often, that they have not been provided enough/correct information), or they simply shrug and say they’ve not found the problem… yet!
This behaviour, in my mind is one of the key differentiators between a good developer, and a great one. The outstanding developers on the team will continue to look at a problem without frustration, continually attacking it from different angles until they reach the next breakthrough. Even if that victory is only one small step to resolving it.
So what can we do to encourage this kind of behaviour in our teams? Try thanking people for their effort, rather than their smarts. Understand that real success comes from hard work, not from a bolt of inspiration.
Also, one more thing before I put aside my soap box. If we want to continue to grow then throw aside any delusions of being where you are by being the smart one, you got there through work – just like everyone else. You didn’t inherit a magical sword or extraordinary talent. So make sure you’re not relying on it the next time you meet a particularly scary dragon!
I wrote recently about safety and how I’d describe it, I gave an example of a developer who suspected that a particular approach chosen by the team wouldn’t work but didn’t feel confident enough to speak out and challenge the design.
In this post I want to discuss just how serious that lack of safety is. Beyond that lack of a warning a lack of safety can lead to bugs, disengagement, and even resignations.
If you’ve not already read it then I suggest picking up a copy of 5 Dysfunctions of a Team but Patrick Lencioni. It really is very good!
To back up my statement over resignations I want you to think of the last time you disagreed with your spouse, friend, or family member folder what to do one evening or weekend. Maybe they wanted to go shopping or redecorate a room. I want you to think about how you felt doing that activity and question whether you really gave it 100%
Not really being engaged is hardly unsurprising. Let’s say you wanted to see one film but you were talked into seeing something different. Are you really going to admit that you enjoyed it or will you secretly (it not so secretly) believe that your choice would have been better?
The point of this simple example is that humans struggle to commit to an idea while they still believe that their option would have been better. When we have joint design discussions if someone has an idea and doesn’t voice it or has concerns but gets shot down then they will never feel like their voice has been heard. They become disengaged from the end result, because they never wanted to do it that way anyway. It’s not malicious, it’s a defence mechanism because don’t want to admit that out way wasn’t better.
Only be encouraging all team members to openly discuss their ideas so we gain not just consensus, but buy in. As for staff retention, if your team member never feels bought into the work because they don’t feel like their view is listened to, how long do you think they will remain in that team?