Tag: Management

Radical Candor Book Review

~ Adam ~ 1 Comment

Radical Candor, by Kim Scott is a book I’ve been aware of for a while but haven’t actually got around to reading.

I was expecting lots of information about giving feedback but I was pleasantly surprised that there was a lot more in there than that.

Scott discusses that to be great leaders and team members we must both care personally and challenge directly. Without these two qualities we fall into one of three other quadrants.

Feedback & Radical Candor | Our Simple Approach To Guidance

People who care but don’t challenge fall into Ruinous Empathy. These are the people who won’t tell a friend that they’re unzipped because they’re afraid of the conversation. They’d rather let their friend continue to embaress themselves rather than push themselves out of their comfort zone.

People who don’t care personally are split into one of two categories. If they do challenge but don’t do it with someone elses best interests at heart then they display obnoxious agression. Or, simply put are just jerks. If they don’t challenge then they see what they could do to improve and don’t do anything to help them. This is manimulative insincerity.

Scott teaches us that we must always strive to give direct feedback to people we work with because we care about their success and their feelings. She also discusses lots of ways to do that.

I’d been expecting much of this content before I started the book but what delighted me was the actionable advice on how to go about this. I want you to read (or listen) to the book so I won’t give it all away here (plus, you know, plagurism). Suffice it to say that if you do now feel you should give feedback there are lots of tips in there to help.

But this is just for managers right?

Wrong!

Kim discusses that everyone should feel they can give feedback. Peer feedback is one of the most valuable thing we can give, it shows we care about our colleagues.

So, would I recommend it. Absolutely – go and have a read. Stop being ruinously empathetic today and start supporting your friends and colleagues directly!

Let’s Talk About Goals

~ Adam ~ Leave a comment

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.

Insert Cheesy Goals Picture Here

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.

Large scale change doesn’t happen by coincidence, it’s planned and happens through a series of small steps.

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?

  1. 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).
  2. Understand WHY you want to achieve that.
  3. If that’s the end goal what significant steps could you make towards that vision in the next 12 months?
  4. Discuss (if you wish) these 12 month goals with your manager.
  5. 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
  6. 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.

Team Topologies Book Review

~ Adam ~ 3 Comments

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).

Team Topologies

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.

Why is Safety So Important?

~ Adam ~ 3 Comments

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?

What Exactly is Safety?

~ Adam ~ 4 Comments

When I first heard about someone taking about safety in the workplace I assumed that it was part of an anti-bullying campaign, a Health and Safety initiative, or perhaps some huggy feely thing from someone in HR. It took a little while for me to realise that not only is safety everyone’s responsibility, it is perhaps the most important component of an effective team.

To try to illustrate what safety is I’m going to give you a fictional scenario.

I dropped in on the last few minutes of the team’s planning session. As their manager I’m not strictly required to attend but I like to join occasion to keep up to date with what they are working on.

One of the developers was up at the whiteboard, pen in hand, and he was gesturing enthusiastically at his design. The rest of the team nodded, some eagerly, others showing the fatigue so typical towards the end of a long meeting.

Seeing that the group were wrapping up I caught the eye of one of our senior developers. We had a 1:1 scheduled and I wanted to get started quickly so I wasn’t late for my next meeting.

A few minutes later, coffee in hand, he had just finished telling me about the new data access module he’d created for one of our legacy products. After giving him the appropriate thanks I shifted the conversation onto the upcoming work.

“So it sounds like planning went well?” I asked.

He shifted awkwardly in his chair, obviously not enamoured with the change in topic. “Yeah… but I’m really not sure it’s going to work.” He muttered “I tried something similar a few years back and it just got way to complicated too quickly, the code became unmanageable and we had to abandon the whole thing.”

My blood ran cold. There was a lot riding on the next piece of work. Deadlines, client expectations, the team’s reputation. Forcing calm into my voice into my voice I asked the most obvious question.

“Did you mention this in the meeting?”

“No…” he said “I didn’t think they’d listen to me…”

I’ve deliberately tried not to give extreme an example here. It’s all to easy to discuss nuclear reactors or operating theatres when taking about safety but that implies that the requirement to feel safe only matters in life or death situations. That’s not the case. The more confidence people have the better our teams will function at all times.

So, let’s talk about the problem here. The team has decided on a particular design for a piece of work. One of the developers believe that the solution is doomed to failure and has failed to share that concern. It’s very easy to blame the developer here, or the guy holding the pen for not listening, but in truth it’s everyone’s responsibility to make sure that people feel they can contribute important, and often unwelcome views without fear of reprisal.

But where does this fear come from?

Unfortunately it’s hard coded into our DNA. Based in the same rational as our irrational terror of public speaking the fear of speaking out and voicing unpopular views is grounded in our history as a tribal species. Millennia ago, if a member of the tribe appeared weak, either because their view had been successfully challenged or if they’d lost such a confrontation then they risked being ostracised from caveman society. We are programmed with a strong herding instinct not to challenge dominance or listen to viewpoints which may make us appear weak or incorrect. Unfortunately in the modern workplace these fears put projects at risk of failure.

Team members feeling safe enough to voice their ideas is crucial if you want your team to reach its highest potential. We need to build teams where everyone, not just those with fancy job titles or big egos feels safe to voice their opinions.

I plan to write more about safety over the next few weeks, however if you’re interested in learning more I highly recommend Leaders Eat Last by Simon Sinek and Crucial Conversations by Kerry Patterson.

A Different Sort of 1:1

~ Adam ~ Leave a comment

I met up with my line manager the other day, a nice change to our more common video chats. Spare meeting rooms at head office are seen less frequently than unicorns so instead of sitting in the open plan work area he suggested going for a walk.

The idea resonated with me and it’s something I’m determined to try with my team. Here are a few reasons why

  • Meeting rooms are very formal, 1:1s don’t have to be
  • Fresh air and a little light excercise is good for all us office bound geeks
  • Getting away from the office environment can lighten moods and change perspectives

Now, I don’t suggest you try a walking 1:1 on a wet, cold, or otherwise horrible day but the next time the sun is shiny why not take a walk?

Have you tried outdoor 1:1s? What was your experience?

The Cost of Fixing Bugs Late

~ Adam ~ 1 Comment

Have you ever been in a situation where you’ve written a piece of code and it’s almost there but there are a few niggling issues which “can wait for V2?”. Have you ever wished, maybe months later that you’d gone back and resolved them at the time? You’re not alone!

More and more developers and managers are beginning to realise the true cost of fixing bugs late, not only on their sanity but on the company’s time and money.

Let’s say for the sake of argument that you’ve finished a piece of code except for a few edge cases. You’re under a lot of time pressure so you decide it’s of a high enough quality and you push it through to QA. The cost to the business of fixing that issue actually increases dramatically the longer it’s left.

Let’s look at a few scenarios:

You fix the issue immediatly

  • Fix time – 30 minutes

You send to QA and it’s rejected there

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Fix time – 30 minutes

QA passes as an “edge case” but the customer disagrees

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week

Missed in UAT but discovered as a significant issue in Live

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week
  • Customer live deploy – 3 hours

 

As you can see, even with these rough estimates the time it takes to resolve the customer’s issue increases dramatically the longer it’s left. Not only that but the cost of time to the business of paying staff to run extra QA cycles or rounds of UAT spirals out of control. We haven’t even considered the final case where it goes to the bug queue to die and a completely different developer has to learn the feature and resolve the problem.

The graph is actually a very common shape*.

graph-2

I’m a big fan of practicality, no software is going to be perfect and it’s unrealistic to expect that you’re going to find and fix each and every issue before shipping to a customer.

However, hopefully this has made you stop and think and has provided a strong argument for making that extra 30 minutes to resolve the issue before it causes a real headache for the business!

*Thanks to fooplot.com for the graphing software.

Stay Technical

~ Adam ~ Leave a comment

I recently spent a Sunday night in a hotel in Hatfield prior to a customer meeting on the Monday morning. For some unknown reason I felt an urge to learn Python.

Why? I have no idea… I’m a .NET developer, my team are all .NET developers but it seemed ages since I’d picked up a new technology and had a little play… not because I’d needed to for some project but just because it looked cool!

As IT Managers and professionals we got to where we are by working very hard and having a natural curiosity about technology. Our roles may have changed but I believe it’s crucial to keep that inquisitive nature alive – especially if we want to engage with and be relevant in our teams.

Of all the managers I’ve ever worked with the ones I’ve respected the most are the ones who find the time to stay hands on. I always told myself that it was something I’d hold onto through my career.

With so much of my recent time being spent reading about the Theory of Constraints, Agile Principles, and Scrum practices… it was a refreshing change to think about immutable data types and significant white space!

The next time you have a quiet few hours do consider picking up a book or opening up pluralsight. Remind yourself why you chose to be a developer in the first place and maybe even write some code in a new language!

Driving Technical Change Book Review

~ Adam ~ Leave a comment

Driving Technical Change is a great little book who wants to understand how to influence different people in a technology organisation.

If you’re expecting a book on mind control then you’ll be disappointed. If you’re looking for a book which will explain why people react in particular ways to new ideas and technologies then that’s exactly what you’ll get.

Terrence Ryan discusses a series of personality caricatures. These are a little extreme, but you’ll be amazed at how closely they match up with people you know!

Then, the book discusses why these people may resist change or disagree with your proposals and how you can help to win them around.

For example, one of the characters in the book is “The Overworked”, this guy has far too much to do and never enough time. They can’t spare the time to pick up your idea, so how do you convince them? Show them how your project or proposal will save their time and help them complete their neverending pile of work.

I don’t want to plagiarise Terrence work, I’d much rather you picked up a copy and let him explain them first hand.

Would I recommend this book to someone working in a development team? Absolutely! Not just to help them drive powerful ideas forward, but also to help them appreciate other points of view – understand why The Boss, The Overworked, and The Burned may not necessarily agree with every suggestion.

Scrum Is Not Enough!

~ Adam ~ Leave a comment

Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.

The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.

We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.

This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…

What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).

Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.

So what went wrong?

This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…

Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.

The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.

This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.

If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.