Handling critical feedback

Handling critical feedback

Hand vector created by makyzz

There I was, on top of the world. I, who was about 6 months into my career as a software engineer, had just given possibly the best ever presentation to my team on how to inject custom VB code into an SSRS report. The knowledge I had imparted and the way I had delivered it was second to none. Next stop was probably running Earth or something simple like that.

As I went to stride out of the room with my head held high, my team lead pulled me aside. “Hey Gareth, do you mind if I give you some feedback on your presentation?”. “Wow”, I thought, “I’m not even out of the room and I’m about to be lathered in praise, what a great day!”. Not long after sitting back down, things quickly began to turn sour. I was hearing things like “your slides were too crowded with text” and “you spoke too quickly and glossed over some topics that nobody in the room had heard of before”. What the heck, how dare he ruin my day with this nonsense. My anger flared up. After we were done, I held myself together, thanked him for the feedback, and went out of the room; anger still bubbling away inside me.

It wasn’t until later that evening, as I rode the train home from work, that I really thought back on my presentation. Initially, I had convinced myself that everyone loved it. But thinking on the vibes I was getting back from everyone in the room, the disinterested and sometimes confused looks, the lack of conversations about it after I was done, it began to dawn on me that perhaps it wasn’t the greatest presentation since that person who unveiled sliced bread to the world. The feedback my team lead had given me was actually pretty kind and well thought out compared to what I might have said if I were in his shoes. It wasn’t until this point in time that I could actually reflect on what had happened and really begin to digest the feedback properly.

It starts with the urge to flip some tables

It’s hard not to get upset when somebody gives you critical feedback. It almost feels like an attack on who you are. How dare they! The audacity! Generally speaking, you’re not going to be ready to fully process that feedback on the spot. So how can you manage this? Well, it’s hard to stop the anger from bubbling up inside, sure, but you should aim to maintain politeness to the person giving you the feedback. Recognize that you’re upset, but don’t default to disregarding everything that’s being said to you. Try to keep a mental note of the feedback, even if you’re not ready to process it yet. If you’re able to, ask to get some notes in written form, as this will help with remembering what was actually said, and avoid some skew in your memory of what was said due to your emotional state.

Getting through this stage will obviously be different for different people. If you’re prone to fits of rage where tables get flipped because a passing kid looked at you funny, then getting past this stage is going to be tough for you, and I worry for the welfare of those around you. Also, you should probably go see someone about that. And conversely, if you’re someone who defaults to going super quiet if any form of confrontation occurs, getting through this stage will still be uncomfortable, but you probably won’t need to go to the police station to give your statement on why the office needs redecorating. Taking time to reflect how you handle situations like this is always a good idea. It’ll hopefully help you to continually improve yourself, and in turn reduce the company budget for buying new office furniture.

I was pretty mad all day about the feedback I received for my presentation. How dare my team lead burst my bubble and bring me down to earth. I stewed and stewed on this, and at this stage, I wasn’t ready to digest anything I had been told. Luckily 7-Eleven was running one of their awesome $1 days, and I was trading reality for a tonne of affordable sugar. Awww yeah.

Give your old buddy Time a ring and see if he wants to hang out

Your anger will eventually settle down. Once it has, you’ll be in a much better place to process the feedback you have been given. I know I can personally stew on something for the rest of a work day, and not really deal with it properly until I get some quiet time on a commute home (unless that darn kid two seats up keeps staring at me!). If you’re able to, try to refocus your attention on something else until you’ve calmed down. Be it going for a jog, challenging yourself to eating 12 donuts in one sitting (at the total cost of $12!), or just diving into some other work you’ve got to do, this will hopefully help to let your emotions settle somewhat.

As I said above, it wasn’t until I had gotten through the day (and starting riding a mad sugar crash) that I calmed down enough to begin processing the feedback I was given. With some top notch Nickelback cranking in my ears and 2 hours of time alone to sit and think on the train, I was ready to reflect.

Hold your clock up to a mirror. It’s time for reflection.

With all that anger settled down it’s time to reflect. This is probably the most important step here, without it, you’ll find it tough to grow yourself throughout your career, and even your life. Think on what was said and try to understand why it was said. Look back on what you did or have been doing to generate that feedback, and see if you can accept the feedback and look at how you could apply it in the future. Reflecting like this is a really useful way to better yourself through the feedback that others give you.

I saw that although I had shared some new thing that nobody knew you could do, I hadn’t delivered it in the best way possible. Slides that were crammed full of text meant that people could either read them or listen to what I was saying, but not both. The pace I moved through my presentation was quite quick, which was likely due to nerves and excitement. I also recalled that it wasn’t only critical feedback I had been given. My team lead had told me that it was really great that I could even give this presentation, as a lot of people would have been put off by having to speak in public like that. He had also praised me for the simple way that I had delivered most of the information. In the heat of the moment, I had completely disregarded this positive side.

Keep this in mind for the next time that you’re the mean person telling someone how terrible they are

Since then, I’ve not only began to better incorporate how I process critical feedback that I’m given, I’ve also used this insight to help with giving feedback. I start by keeping good feedback habits in mind like basing it on facts, not emotions, and writing it down in a clear way and sharing that with the person to help try and keep potential anger to a minimum. But ultimately, I accept that the person I’m giving critical feedback to will need time to process it before they can really process the feedback and take any learnings on board. I don’t nail this every time, but I often reflect on how I gave feedback and aim to continually improve myself to make the next time better.

And that’s all there is to say about that! Now, don’t get me wrong, I’m not some feedback guru who always takes away everything I’m told and makes myself 10x better because of it. I still get upset when I’m given critical feedback and I still need time to process it. But I do take the time to sit down, put my ego aside, and reflect on what was said, which is helping me to continually improve in this space.

Do you have any helpful tips for how you manage receiving or giving critical feedback? I’d love to hear about it! Drop a comment below and share your insights!

Cultivating a team of ideal team players

Cultivating a team of ideal team players

Image created by pikisuperstar

Earlier this year I came across a book that helped open my mind to a great way to build great teams; The Ideal Team Player by Patrick Lencioni. I’ve since been applying some of the theory from the book to my team, and wow, what a positive effect it’s had! So, being the really kind person that I am, I shall now share with you how I went about it and look at the improvements I’ve seen in the team since then.

So are you going to tell me what The Ideal Team Player is actually about?

Well, I mean you could have just followed that link above and learnt this yourself, but I suppose I am writing this article to provide you with this very information… okay, okay, I’ll tell you. The premise of the book is that there are three key traits that, when all are working well in balance, make for a person who is an ideal team player. That is, a person who gets along with others, has a desire to grow and isn’t going to brag about themselves all day long. These three traits are Humble, Hungry, and Smart. The book is written in narrative form and makes for a very easy read, and I’d strongly encourage you to add it to your reading list (and if you don’t have a reading list yet, stop what you’re doing, create a list, add this book to the top of it, and come back once that’s done… I mean who doesn’t have a reading list… who are you!?).

So what are these traits all about? Let’s take a look.

Humble people don’t have a big ego. They will praise others for something well done, freely share credit and won’t go bragging about their own accomplishments. They will strongly align themselves to the goals of the team and will prioritize the team wins over their own.

Hungry people are always on the look out to grow; to grow their knowledge, their responsibility, their helpfulness. They are self motivated and have a desire to go above and beyond to do more. They require little to no motivation from their manager to keep going.

Smart refers to people smarts, aka, emotional intelligence. These people are very aware of how their actions and words have an effect on others. They take the time to think about how they can convey information such that it can be received in the best way possible. They are good listeners, ask good questions, and actively engage in conversations.

What happens when Humble, Hungry, and Smart are missing or out of balance?

Well aside from the obvious, where by you have someone who’s lacking in all three and is just all around unpleasant to work with, there are some fun characters that arise when someone is strong in one or two of the traits, but lacking in the others.

Celia is what some refer to as a skilful politician. She’s extremely motivated to take on more, she’s confident, and she’s everyone’s friend. When she wants to do something, she’s great at saying the right things to the right people to get her way. She’s also not one for sharing credit and will put her own goals above those of her team. She’s doing pretty well in the Hungry and Smart traits, but lacking in the Humble department.

When you bumped into Chester this morning he stopped in the hallway and called you out for a job well done on nailing that latest feature you’ve been working on. His upbeat attitude and big smile made you feel warm and fuzzy and set a great mood for the rest of your morning. What a great guy. The team has been trying to bring on some new technologies and processes to help them level up, but Chester has been staying out of that. He’s quite happy with how things are and isn’t in a hurry to have to learn anything new. Chester’s is a lovable slacker. He’s got the Humble and Smart traits in spades, but he’s not very Hungry.

In comes Xavier, you say high to him as he walks past but he doesn’t look up to acknowledge your existence, he’s here to get stuff done, not socialize with the likes of you! You’ve gone over the team goals with him a few times now, but he tells you that he knows better. His ideas are better than yours, and he’s quite okay rolling over you to get what he wants. This is Xavier, aka the bulldozer. He’s got Hungry down packed, but where on earth are Humble and Smart!?

As you can see, there can be some pretty down right disastrous outcomes if these three virtues get out of balance. It’s worth noting, of course, that we’re not here to pigeon hole people, these are just a couple of examples of how things could turn out. Each person will have some slight variation of level and balance on the three virtues that will make for some fun and exciting combinations.

Going from theory to reality

Let’s imagine a world where you’ve got a team of people who are all ideal team players. Each of them are well balanced across the three virtues, Humble, Hungry and Smart, and continue to grow across these traits. This is a team who is going to work together extremely well. You can picture a team where everyone is open and honest with each other, lots of stuff is getting done, and lots of new things are being learned and applied. This is the dream, but how can we get there?

Start by looking at yourself. How do you rate across those three virtues? Focus in on the one you consider yourself weakest in, and set yourself a S.M.A.R.T. goal to improve yourself in that area.

Let’s now assume that you’re the leader of your team. If you’re not, but you still want to apply this to your team, make sure you raise it with your team leader in your next one on one! Perhaps even share this article with them to convince them of its goodness. If you’re reading this because you were sent here by someone on your team, make sure to give them a high five and praise them for this incredibly valuable thing they’ve shared with you.

So, as the team lead, you will want to rinse and repeat the goal setting exercise with each member of your team. In everyone’s next one on one, talk to them about Humble, Hungry, and Smart. Ask them for what they see as their weakest of those three. Coaching them to identify their own area for improvement is important, because they’ll feel a stronger sense of ownership on improving as opposed to you just telling them from on up high. Once they’ve identified an area, walk them through putting a S.M.A.R.T. goal together to make the improvement.

Making it more substantial by getting the whole team involved

Now that everyone has their own area that they’re working to improve, it’s time to go to the next level; opening up to the team. During your initial one on one with each team member, make sure to ask them individually how comfortable they would be sharing their goal with the rest of the team. If you get some strong “no” responses, dig in a bit more to understand where that “no” is coming from. There may be an underlying feeling of distrust with one or more people in the team, and that in itself is useful for you to know so that you can start to manage improving that trust in a possibly separate way. This exercise itself will help improve the trust in your team, but if there isn’t a decent base level there to begin with, it might prove difficult to follow.

Assuming you get everyone on board with the idea of sharing their goal with the team, the next step is to gather the troops. You could do set a dedicated meeting for this, or do it as part of your next standup, whatever seems easiest. Go around the room, starting with yourself, and share the area you’re trying to improve on and the goal you’ve set for yourself. As you go through each person, also ask them how they’d like the rest of the team to help with their goal. It may be that they let Celia know when she starts bragging about something she did, when in fact the entire team contributed. It might be letting Chester know that he once mentioned he had done some TDD before, and it’d be great if he could give the team some training on it. The goal here is to set some criteria in which each person would like to get feedback from their team to help achieve their goal. Make sure to specify the communication method as well, as some people like in person feedback, whereas others would prefer an e-mail or IM so they can process the feedback asynchronously.

Keep it fresh to keep it fizzing

It’s great that everyone has shared their goal with the rest of the team, job well done! Now it’s important to keep this fresh in everyone’s mind. I’d start with talking about it at standup for the next few days, and then checking in once a week for the first month or two to see how we’re all going. You’ll likely find that feedback between the team isn’t happening as freely as you’d imagined. This is pretty normal, as giving constructive feedback can be quite daunting to some. If this is the case, make sure to coach your team on how to give feedback and help them as much as possible to deliver it.

The goal here is to keep the topic at the top of everyone’s mind. It takes time and commitment to give an initiative like this legs, so don’t be that person who just drops a zinger of an idea on everyone, and then runs off on to the next idea leaving this one crying and lost like a toddler who didn’t follow you like they were told to.

Don’t forget about the hiring process!

A brief but super important thing to note is that if this is something you’re driving with your existing team, you’ll really want to make sure you incorporate it into your hiring processes. Screen for these traits and talk to the candidate about them. Explain to them the culture of the team and how it incorporates these ideals. This will help both of you decide if the team is the right fit.

We’ve found using these terms has made it really easy to talk about traits you noticed in people, but historically couldn’t quite put your finger on. Make sure to talk about this during your post interview debrief and be very mindful about hiring “a gun” who doesn’t seem to show balance across the three virtues, because as Admiral Ackbar would say, it’s a trap!

You can’t catch the rainbow, but you can keep running towards it

At some point, assuming you continue your focus on your goal to improve in one of the three virtues, you’re going to get to a point where that virtue is no longer the weakest; it may have even become the strongest! You’ll want to check-in with yourself and your team semi-regularly to review this and adjust your focus to another of the Humble, Hungry and Smart traits as necessary. The idea here is to constantly improve one trait at a time, but also to keep all three in balance with each other. We don’t need another Xavier the bulldozer on our hands!

So come on, time to share, how did this pan out for your team?

Really well! It was a really big boost for trust and psychological safety within the team, as we all allowed ourselves to be vulnerable in front of one another while talking about this. It’s also helped everyone, including myself, to reflect on where we’re at in our Humble, Hungry and Smart journey, and to make use of the team to help drive our own improvement with their feedback. I’m really excited by the incredible progress we’ve seen so far, and I’ll be continuing to keep this as one of our focal points as we all keep growing.

And that’s a wrap! By following this concept you’ll be able to develop yourself and your team into an unstoppable force of ideal team players. Everyone will be able to work together more effectively and start smashing through all the challenges that can be thrown at them.

Are you already a supporter of the Humble, Hungry and Smart philosophy? If you are, I’d love to hear how you’ve applied this to your team!

Effective one on ones

Effective one on ones

Designed by Freepik

The time was coming, he was almost here. I looked back on the decisions I’d made throughout my life that had lead me to this point. What could I have done differently? Oh if there was only more time! I heard a creek of the floor behind me. He was here, this was about to happen. My first one on one.

The nerves I felt before my first one on one were, with hindsight, quite irrational. It was just a casual catch up with my boss, nothing to be nervous about. But I was nervous. Why? Well, mostly due to the uncertainty of what such a meeting entailed. Would I have a list of everything I’m doing wrong laid out before me? Was I about to have my imposter syndrome fears confirmed?

Then I got a few one on ones under my belt, and I realised it wasn’t so bad! I started looking forward to them. A time to talk, a time to reflect and a time to plan. It became a great block of time where I was able to step away from the daily hustle and really look at where I’d been and where I was going. This was greatly helped by the fact that I had a great team leader who knew a thing or two about making these catch ups go so well.

Since that first one on one, I’ve had hundreds since, both with my team leader and as a team leader myself with my own team members. I’ve found that there are several things you can do, regardless of whether your the leader or not, to make your one on ones more effective.

So, what is a one on one?

“So, I was reading this blog article the other day, and the guy was talking about wetting his pants because he was nervous about something called a one on one”, said an imagined future reader of this article, who I like to think will be called Batman. “I guess he was talking about some kind of fight that was about to take place? I suppose I best be going to find the Joker, because it’s about time for our ‘one on one’.”

Batman has a point. I’ve referred to the term “one on one” no less than 7 times already, and not once have I stated what it is. But sorry Batman, unless you’re looking to help the Joker grow in his career, you’re misusing the term.

A one on one, at it’s core, is an informal catch up between a team lead and a member of their team. I say ‘informal catch up’ because that’s how I like to have them run, but it’s not unheard of to see them being made more formal (like by having each participant have to wear a tuxedo or a ballroom gown). It’s like a shorter and more casual version of a more traditional yearly review process.

So at it’s core, it’s a private conversation between a team lead and a member of their team to help share feedback, reflect on how things are going and plan for the future.

Start by making it regular

It was end of year review time. I was walking in to my catch up with a quiet confidence. I’d managed to tick off everything agreed on with my boss at my half yearly review, and now it was time to bask in the glory of praise for a job well done. Only, that’s not quite how it went. As it turns out, the goal post had moved somewhat. Some of the things that were important 6 months ago hardly mattered any more. I could feel the sweat dripping from my brow, nervous swallows coming in waves. How on earth had I not managed to know all this? If only there was a way to have found all this out sooner!

Effective one on ones begin by making them regular. Leaving too large a gap between catch ups is a sure way for feedback to be left unshared and for leaders and their team to fall out of sync with each other. You can easily see this happen in organisations where the only time an employee sits down with their boss, to talk about how they’re doing, is as part the yearly annual review. Goals that were discussed at a previous sit down have now become stale and mis-aligned with both the business and employee themself.

Setting a regular time to catch up means that feedback can be given and received in a timely manner. This means that any proposed course corrections are minor, and any problems can be dealt with at the spot fire level, before they escalate to anything more serious.

Keep it casual

Part of the nervousness I felt before my first one on one was my worry that I should have prepared rigourous notes on my personal performance, much like I would do for a half yearly review. Traditionally preparing these notes had taken me a large amount of time, and I’d had my one on one meeting sprung on me with only days to plan! It was around then I’d started considering wearing sweat bands to work to help keep me dry in these moments of stress.

Making these catch ups casual helps to create a friendlier environment, where people are more open with each other. Feedback given and received in a casual setting is often easier to digest, and therefore more likely to be useful. Going to a meeting room in the office can work, but it might not be ideal, as the office ‘vibe’ will follow you in there. A place that is typically associated with casuallness is ideal. This could be a lunch room, game room, cafe, or even a pleasant walk in the great outdoors (those exercise endorphins can really top it all off!).

Give feedback, ask for feedback

One of the key components of a one on one is the sharing of feedback. I say sharing, because it should be a two way street. A team lead is providing feedback to a member of their team, and the team member is providing feedback to their leader. The two way sharing of feedback is important.

As a leader, it’s your job to provide meaningfuly feedback to team members to help them improve. This should be a combination of what they’re doing well, and what they could be doing better at. It’s useful to write your thoughts down during the time between one on ones, as memory in the moment can sometimes be lacking. This will prove most useful when giving feedback on something you’d like to see improved, as you’ll be able to cite past examples of what you’re talking about.

As a team member, it’s useful to provide feedback to your team lead for much the same reasons. Share what you think they’re doing well at, what they could do better at, and cite examples if you can! This can be massively useful, as it ultimately helps them to be a better leader to you.

Be sure to make the feedback useful. Be specific, be immediate, tie it to goals, ensure it’s actionable and use the right language. In order to save some words in this article, I’ll direct your attention to The Six Qualities Of Good Feedback if you’d like to learn more.

Ask for feedback about other team members

As a team lead, you’re not going to see everything that goes on within your team. Unless, of course, you’re part of some secret government spy agency. When you don’t have the power of a Get Smart agent behind you, the next best thing can be to ask for feedback about other people on the team.

Ideally, you’re team is comfortable enough with each other to share this feedback directly. But often that isn’t the case. If it’s useful feedback, start with looking at ways to get them to share it directly with each other. This should be a reasonable asking for positive feedback; “That new bat suit looks great Batman, it really helps keep criminals at bay”. But can often be more difficult for ‘negative’ feedback; “The nipples on your new bat suit were a terrible idea, no criminal will take you seriously now, just look at Dr. Freeze, he shows no respect!”. Start by talking it through and see if you can get them to share it directly. If that doesn’t look to be an option, ask if they’re okay with you sharing it with the other party. If that’s okay, you can incorporate it in to their next one on one.

Reflect and plan

Reflecting on the past and planning for the future are a big part of creating alignment. It helps to keep the team member aligned with the goals of the company, and the team lead aligned with the goals of the team member.

Start by talking about how things have been going. This can be since the last one on one, since the start of the year, or since breakfast. This is a good opportunity to talk about what’s been going well, what hasn’t been working well, and to review any previously discussed goals. Once you’ve had a time to reflect, it’s now time to plan. Talk about what you want to be doing going forward, and look at setting some S.M.A.R.T. goals if it makes sense. The scope of the plan can be grand, years out, but try to create actionable goals that can be worked on in the imediate future.

Get to know each other

Being an effective team leader means knowing your team. Knowing what their interests are, their values, and what’s going on in their life will greatly enable you to give the support and assistance that great team leaders provide.

Once you have a reasonable relationship with your team, you’ll be able to tailor your feedback and ideas for growing them to their personal needs. Julie might be really good at something and always be given that to work on, but deep down she might really want to branch out and work with something new. John might be having a bit of a hard time at home, and needs a bit more flexibility in his daily schedule to help sort things out. If you don’t know your team well at a personal level, you might never discover these things, and therefore never be able to truly help your team be the best it can be.

Where do I start?

The first step is to set some time asside on a regular basis. Anything between 2 weeks to 1 month is a good place to start. For someone new to the company, or for someone quite junior, weekly catch ups can prove useful. Anything longer than a month between catch ups is likely too long, as you’ll miss out of many of the benefits discussed above.

It would also be useful to explain to your team what the purpose of a one on one is, so as they don’t get the cold sweats like I did before my first one! Point them to this article, or talk it through with them before you send out the calendar invitation.

One on ones are a key ingredient to being an effective team leader. They enable you to better direct your attention to where it’s needed, and to create an environment in the team that everyone loves to work in. So what are you waiting for? Get to it!

Learning with the mob

Learning with the mob

“The angry mob” (CC BY-NC-SA 2.0) by Oblong

Time was running out, the mob was coming; this was it. Luckily, this was not the kind of mob carrying torches and pitch forks, this was a new breed of mob! This mob was made up of a group of people ready to learn from each other.

Mob learning sessions were inspired by an idea that has been been gaining traction in recent years, mob programming. In mob programming, the idea is that a group of developers gather around a single computer and write code as a collective. Learning with the mob takes some of the key concepts of mob programming, leading to a much more effective learning experience.

An inside look into a mob learning session

The door swung open and in burst the mob; they’d found me! Which was good, because the room was listed on the meeting invitation. Step one, complete. Each person found a chair around a round table. There were no rows of seating where someone could hide up the back. This was a mob learning session, and participation is a must.

The sessions are set up in such a way that encourages all participants to, well, participate. This is a world apart from the traditional “one presenter, with questions saved until the end” talk. One or two participants will act as facilitator, but as more of a guide than a teacher. These facilitators are usually the ones that have the most knowledge or passion about a topic (or have been volunteered by good meaning mob members), but don’t necessarily hold all the answers. They will direct the learning and regularly encourage mob discussion and knowledge sharing.

Due to the openness of conversation that is encouraged, tangential conversations will happen. Sometimes these can be very useful conversations, other times, they can get too far off track. When this happens, it’s the responsibility of the entire mob to help bring the conversation back on track. If that isn’t happening, the facilitators may need to step in and sheppard the mobs focus back to the topic at hand.

Theory is great and all, but practice makes perfect!

“These ideas for clean code sound fine on paper, but how can we even begin to use them on our code base?”. The gloves had been thrown down, it was time to get practical! Visual Studio flew open (well, it opened in a kind of reasonable amount of time). After a flurry of keyboard shortcuts, we had some spaghetti code up on the screen, ready to jab pitch forks at. And that’s exactly what we did. We practiced some of that “mob programming” and refactored a bunch of hard to follow code. We discussed some of the different ways things could be done better, and followed through with a couple to see how they looked. The mob was alive, and sh%t was getting done!

Adding a practical element to most sessions is a very effective way to help cement learning in to the group mindset. It takes a concept, and gives the mob a concrete way to move forward with it. This can be tricky and may not be relevant for some topics, and that’s okay, but where it can be made practical, it should be! One of the funner sessions we’ve run made use of some of the puzzles on CodinGame. This is an amazing site full of programming challenges that often provide a visualisation of your code being executed in the form of a game. I’d highly recommend making use of it when giving the mob learning sessions a go; run a session on mob programming and have at it!

Split the mob and pit the sub-mobs against each other in a challenge

“Test driven development is too slow, I could outperform a TDD developer any day!”. Game on! The mob was split, the challenge was on. The string calculator TDD kata was brought to bare. Each sub-mob was given a computer to use, and the battle began. Keyboards were mashed, eavesdropping was plentiful, and the energy in the room was amazing. The timer went off, and after several attempts to pull the sub-mobs away from their keyboard, the challenge was done, and TDD won!

New concepts that challenge existing practices are often met with resistance. Proving their merit through a powerpoint presentation can be tough, no matter how many of the animated powerpoint transitions you use. A friendly competition can help to settle these arguments. Be careful to limit the scope of the challenge to something that can be done in about half an hour, allowing you time at the end to look at how things went. Also try split the group up in such a way that people who like the concept are on the team proving it works, and nay sayers are on the team attempting to disprove it. Get that mixed up, and all sorts of sabotage might ensue!

Topics should focus on what the mob needs, and sometimes what they want

In they wandered, a few interested looks, but mostly they were just here because everyone else was. This was a session on the merits of testing. Nobody had asked for this session, I’d just gone ahead and teed it up. By the end of the session, the seeds were already starting to take root. Although not entirely convinced, each mob participant had engaged in the conversation and taken away something that resonated with them. The journey had just begun, but the boat was well afloat and currently on course not to hit an iceberg.

Topics that are picked for mob sessions should be a mixture of mob needs and wants. If a mob collectively wants to learn more about a topic that will help enlighten them, great! Find a champion of the topic in the mob, and go for it! On the other side, sometimes what a mob needs isn’t what a mob wants. Automated testing was something that had not played over so well in the past and had a bit of stigma associated with it. Because of that, the mob didn’t have a lot of interest in learning more about it. Without a suite of good automated tests, the mob was producing a product that was slow and cumbersome to validate, and thus hindering their ability to deliver good quality software quickly. And thus, it was evident that the mob needed to learn more about it, and so, several testing mob sessions were run. And the results were amazing! The mob members who were most reluctant to join the testing revolution are now some of its loudest advocates.

Mob learning sessions have now become a regular thing within our team. Collaboration is at an all time high and the sessions continue to be interesting, engaging and, most importantly, useful!

Do you have a topic you’d like to engage your team with? Why not try a mob learning session this week! All you need is a meeting space, a topic, and a mob. Just don’t forget to ask nicely if they can leave their pitch forks and torches at home.

Finding time to get sh%t done

Finding time to get sh%t done

Often we find ourselves with some great ideas we’d like to try out, but we can’t seem to get the time to work on them. At work, there’s always another deadline looming, so getting your manager to allocate you some time for your idea is tough. At home there’s a million things pulling your time one way or another (binge watching another season on Netflix sure seems tempting). So what’s the secret to finding a bit of extra time to get sh%t done? Set some time for yourself!

Time to get carving

Ever noticed that at certain times during the day you’re not super productive? Perhaps it’s the first half hour after you sit down at the office. Maybe it’s the hour after lunch when you’re body is screaming at you to sleep those two pizzas you ate off. It could even be that last hour before you head to bed where you mindlessly browse the internet for any new cat videos. These are the small windows of time that you should start setting your sights on.

The idea is to identify a block of time during your average day that you’re currently not making the most use of. To start off easy, pick a small block of around 15 minutes. You’ll want to experiment a bit to find which part of the day works best for you; morning, lunch time, afternoon, evening, whatever time you feel like you’d be awake enough to get sh%t done!

The block of time for me varies week by week, but I often find the first 15 minutes of my day to be quite productive. I’ve usually got the feeling of immortality as caffeine begins to pump through my veins and the feeling of power as all my motivation is sitting there at the ready. Getting something that I value done first thing in the morning is also a nice way to boost my motivation for the rest of the day.

Time to get effective

If you’re not careful, that beautiful 15 minute block of time you chose will fly past and you won’t have gotten anything done. To counter this, you need to do a bit of planning.

Now don’t get too scared off by the word “planning”. What I’m talking about here is figuring out what tangible thing you can do inside that block of time. If you wanted to learn to code, that could simply be working through a “learn to code” course for 15 minutes. If you wanted to write a book, you could realise it’s a fools errand and instead resort to writing blog articles for 15 minutes each day. Focus on figuring out what you can actually do with that 15 minutes each day; you don’t want to spend all those blocks of time stuck thinking how to spend them!

In some cases, having a more concrete plan will help. This could be along the lines of “add a fancy feature to my app”. If this is the case, try to look at what you want to do and chunk it in to pieces of work that fit your time window. Ideally, you’ll ‘deliver’ something after each window, be it a class of code (with tests!), or a button on a screen. By working in this fashion, you’ll be building on your successes every day, and there are few things more motivating than that!

Time to see how it’s going

It’s quite likely that you’ll find out that the “ideal” block of time you’ve carved out for yourself isn’t so ideal. It could be that your cat chooses that time to drop it’s business off each morning. Or perhaps that cute sleeping child of yours has read this article and decided to make their very own 15 minutes of “look at me!” time. Don’t let this disparage you! Chances are there are several points throughout your day that you can squeeze 15 minutes out of, so just move on to another one. Eventually you’ll land on a time of day that works well for you (at least for the near term) and you can get back to business.

You’ll also likely find that different tasks are better suited to different points in your day. Working on my fitness goals usually works out most effectively during lunch time, but trying out a new software library (looking at you AppMetrics!) works best first thing in the morning. Don’t try to cram an afternoon activity in to your morning if you don’t need to, you’ll likely feel less motivated to do it and won’t get the best return on investment from your time.

And that’s it, it really is that simple. Pick a time, figure out what you want to do, and go do it. If you are able to stick with this for a couple of weeks, you’ll be well on your way to getting to where you want to be!

Creating a feedback culture in your team

Creating a feedback culture in your team

Feedback is such a useful thing to give and receive, yet we often miss the day to day opportunities to do it. Often, we rely on our team leaders to provide us with feedback about how we’re going, what we can improve on, etc. Sometimes this may happen every week or two as part of a one on one catch, or it may only happen once a year as part of an annual performance review. Timeliness is everything when it comes to feedback; the closer in time to the event or behaviour the feedback is for, the more effectively actions can be made on it.

The good, the bad and the ugly

Our team had just been told that we’ll be running a group feedback session. This would involve each team member writing up two positive and two negative feedback bullet points for everyone else in the team. Nervous laughs were heard all around.

Each of us got to work jotting down a persons name at the top of a post-it note, followed by two + and two - bullet point markers. We then got to work on filling in the blanks. We were all careful to keep our notes away from prying eyes; all the time aware that they will soon be put up for public display.

Game time. Up they went, each post-it note stuck on to a glass wall for all to bare witness to. Then, silence. Everyone was scouring the wall for their names and quietly digesting the content that lay underneath. It quickly became evident that there were a lot more ‘+’ items then ‘-’. It turns out, we didn’t seem to like the idea of giving negative feedback to our peers. Well, when I say “we didn’t seem to like”, what I mean to say is, “the rest of the team didn’t seem to like”. I’d followed through and put up two negative points for each person. My chances for “favourite team member of the year” award weren’t looking so promising.

We proceeded to read through each of the points and get clarification on any that weren’t clear. When reading out the negatives I’d given for one of my team mates, he turned to me and said, “you gave me the dash!?”. With the tension broken a little bit, we continued on. Some of the points were useful, others were vague and based on feelings, and some just seemed misplaced. After we were done, we all agreed as a group never to do this again, and went back to doing real work.

Why is feedback from your peers useful?

Our usual feedback provider, the team leader, isn’t usually the one that works closely with you day in, day out. They have some level of visibility about how you work, often gained by short times working directly with you along with whatever they may have told to them by your colleagues. Your direct peers, those you work with every day, have a much closer perspective on how you work. They can often identify more clearly those things that you do well at and the other stuff that you could improve upon.

“You really know a lot about docker, you should run a session with our team to help up skill us.”

“During daily stand-ups, you have a tendency to go in to lots of detail about your tasks, which leads to the meeting taking longer. It’d be great if you could instead give a brief summary of what you’re up to, and hold off on the details for those interested until after the meeting is over.”

“Pants off Friday is not a thing. Please put some pants on.”

So what went wrong during our group feedback session?

The intent behind the group feedback session was to help start a feedback movement within the team; a noble goal. But, there were some problems that lead to it not playing out as hoped. Running it as a public gallery lead to everyone feeling uncomfortable, both with everyone reading feedback about them, as well as everyone reading personal feedback they’d given to others. This then meant that the group wasn’t in the right state of mind to give and receive quality feedback, especially the negative feedback.

At this stage, we hadn’t yet discussed what makes feedback good. This meant that a lot of the notes up on the wall were too general, spoke about feelings, weren’t actionable and used poor language. So not only were we receiving feedback from our peers for the first time, we were also receiving it in a way that meant it was hard to do anything meaningful with.

Speed feedbacking

The team was slowly coming around to the idea that feedback from peers was useful. So, we decided to give a variation of speed dating a go. Speed feedbacking.

It was 3 PM, time for our first speed feedbacking session. Tables with our names were drawn up, hard time limits were agreed upon, beers were involved. There was a bit of uneasiness in the air, nervous excitement even, but we pushed forward. We looked down at the hand drawn table of names, paired up with someone in our row, and sat down somewhere together. Some nervous laughter was heard, and then we began.

I start to share my feedback for my partner, who nods, takes notes and asks me to clarify things when I’m not clear. I then hand the microphone over to them, and they begin to nervously tell me a few positive pieces of feedback. Positive feedback is great and all, but what I really wanted to hear about was where I could improve. “Lay it on me”, I say, “Let’s hear about something I’m not so great at”. A nervous pause as they contemplate their response. “You shield the team from a lot of external pressure. It’d be useful for us to see some of that pressure so we can better tailor how we work to suit the situation.” Wow! This was great, I hadn’t even considered this as something to think about before. It was at this point an obnoxiously loud alarm went off, signifying that our 2 minutes was up, and it was time for us to switch partners.

After everyone had given and received feedback from everyone else, we were done. Laughs and smiles all around. Success!

So why did speed feedbacking work?

The speed feedbacking session had a few good things going for it that meant it worked for our team:

  • It was face to face, so anything that was unclear could be clarified then and there
  • It was one on one, so it didn’t feel as though an entire team of your peers were ‘judging’ you
  • It was short (only 2 minutes per pair!), so we only had time to cover the most important feedback and not get stuck talking about little things
  • We each had a better understanding of what good feedback looks like and how to give it

So what does good feedback look like?

Think about the most useful feedback you’ve ever received. It may have been from a team leader, a friend, or even a work peer. You’ll probably see that it had one or more of these attributes:

  • It was specific, not vague or general
  • It was based on facts, not feelings
  • It was timely, while the thoughts were still fresh
  • It was linked to a goal, to help give context as to why the feedback was being given
  • It was actionable

Making it work for your team

Each team is different. So the way you incorporate feedback in to your team will likely be different to the way another team may do it. Speed feedbacking worked well for us, but it may not be right for you.

So how do you figure out what to do? Take a page out of the Lean world and “build, measure, learn”. Try something out, look at how it went, adjust what you did to be more suitable, and repeat. Chances are you won’t get it perfect the first time around, and that’s expected! Keep at it and you’ll soon land on something that works for you. Just make sure to involve the team in the entire process. Don’t spring a feedback session on an unsuspecting and unprepared team, unless you enjoy awkward silences and talks of mutiny.

Good, quality feedback is one of the best ways to improve yourself and those around you. It’ll lead to higher performing teams that are better aligned and happier for it. So get out there and start a feedback revolution!

Got some feedback about this article? I’d love to hear it! Even if you have to “give me the dash”.

Prototype faster by leveraging the power of testing

Prototype faster by leveraging the power of testing

For some reason, one of the small joys in life as a developer seems to be writing code and not writing tests. It almost seems like a form of rebellion against the ‘rule book’, and you’ll get laughs if you mention the word prototyping and testing in the same conversation. I’m all for writing some down right hacky code to quickly try something out, but I’m also all for writing tests for some of that code. I know you probably think I’ve lost my mind, but stick with me just a little bit longer while I explain this concept.


  • Manual testing is too slow as your prototype grows
  • Set up the ability to run unit tests with your project very early on
  • Be comfortable treating unit tests as you would scrap paper
  • Benefit with faster prototyping and learning how to test earlier on

What is testing used for anyway?

Tests exist to validate that some piece of logic is doing what we expect it to do. Sometimes these tests can be executed programmatically, other times we simply run up the program and manually test it. We’ll generally lean towards the latter when building a prototype, we’ll hack out some code, spin up the program, see if it works or not, and then rinse and repeat. So when it comes down to it, we already are “testing” our prototype code, just not necessarily in a nice repeatable manner.

It’s fast to test manually, until it’s not

So there you are, hacking out some premium code for your prototype and spinning it up every now and then to see if it works. For your first few lines of code, the turnaround time of spinning up the program to manually test it is likely pretty quick. A few lines of code doesn’t usually take long to execute, and with so few logical paths to follow, it’s pretty straight forward to manually assert if it works or not. As the code size and the number of logic paths grow, this process of manually validating gets slower and slower. This is around the point that I used to find myself getting increasingly frustrated at how long it takes to validate that a tiny change is working or not.

Treating unit tests as scrap paper

What I find I’m doing more and more these days is setting up my projects to have a way to run unit tests very early on. At this point, I’m not really in a hurry to unit test everything, instead, I use unit tests as I would use scrap paper. I scribble down some code to quickly test out something in the program, play around until it works as I expect, and feel very comfortable scrunching it up and throwing it away. If I feel that the test will continue to add value in the future (as a spec for the non-prototype version or to help with future changes in that area of the code base) I’ll keep it around, otherwise off to the recycling bin with it!

The usefulness of this approach is that I can quickly test parts of my code in isolation while not feeling it necessary to make the tests perfect. Writing clean tests takes time, and during the prototyping phase you’re usually looking to validate an idea as quickly as possible. By taking this approach, you get the benefit of being able to quickly test your code without having to spend extra time perfecting and maintaining a test suite.

Increase your understanding early on

One of the big upsides I’ve found with this approach is that when I am prototyping in a new language or with a new library, I am learning how to write tests for it very early on. This is enormously useful when it comes time to write the production friendly code, as I don’t have to waste additional time at that stage figuring out how to write tests.

You might also find that it’s very slow and difficult to write tests for the language or library you’ve chosen. This is something that’s very useful to figure out early on, as you’ve likely not yet become too attached to the language or library and still have the opportunity to try out something else that is hopefully more test friendly.

All in all, a faster way to prototype

If you follow this approach, you get the best of both worlds for prototyping, you can still write hacky code quickly to validate our ideas and you can also validate your hacky code quickly, without having to spin up the entire program every time.

Give it a go and share your thoughts!

Running a secure blog with Caddy and Hugo

It’s about time that I got my feet wet in this bloggin’ world of ours. Great! But, oh wait, which blog software do I use? And a secure HTTPS site sounds good, but how on earth do I do that?

Show me the technologies!

As per usual in todays world, we’re going to be bringing a collection of technologies together to achieve glory.

  • Docker - we’ll be using Docker to run all the things and simplyfy life as we know
  • Caddy - this great little web server will host our static site and provide glorious HTTPS using Let’s Encrypt certificates
  • Hugo - a great little static site generator
  • Let’s Encrypt - a free, automated, and open Certificate Authority

Creating a Hugo site

You can download a statically compiled executable for most operating systems, but, I dislike adding too many tools to my path. So instead, let’s just run this thing in Docker!

$ mkdir ~/my-hugo-site
$ cd ~/my-hugo-site
$ docker run -it --rm -v $(pwd):/usr/share/blog publysher/hugo hugo new site .

Here we are creating the directory we want to put the site in to and then running Hugo (from inside the official Docker container) to create a new site.

Want to see what the site is going to look like? Great! Let’s serve it up with the Hugo server.

$ docker run --rm -p 1313:1313 -v $(pwd):/usr/share/blog publysher/hugo

I won’t go in to how to add all of your words of wisdom in to this flashy new site, but feel free to take a detour and check out the official documentation.

Let’s get Caddy-ing!

Caddy is a small web server that is very easy to configure and run.

Let’s take a look at how easy it is to spin up a server with the default settings:

$ docker run --rm -v $(pwd)/public:/srv -p 2015:2015 abiosoft/caddy

This will spin up a Caddy server on port 2015. Check it out, you should now see your site running on http://localhost:2015!

But, default settings are not exactly what we’re after here, so let’s take a look at configuring Caddy.

Caddy is configured using a Caddyfile. You can read up more about the Caddyfile on the Caddy website.

Here, I’m creating a file called Caddyfile-prod (i.e. my production Caddyfile). Inside it, I’ve defined a HTTPS redirect as well as the blog address I want it to server up.


# Permanent redirect to HTTPS {
  log stdout
  errors stderr
  redir https://blog.garjon.com{uri} 301

https://blog.garjon.com {
  log stdout
  errors stderr
  tls gareth.jones@garjon.com
  root /srv

I also created a separate Caddyfile-dev to make developing off the line a little easier.


localhost:80 {
  log stdout
  errors stderr
  tls off
  root /srv

Tired of typing all those characters? docker-compose to the rescue!

I don’t know about you, but I sure hate having to remember and type out those long Docker commands all the time. What if I told you we could encode all of that in a pretty little YAML file and then run it with docker-compose up!

First, let’s stop any running docker containers.

WARNING: This will stop ALL running Docker containers. If you have other containers running that you want to keep running, don’t use this! Instead, shut down your Hugo + Caddy containers manually

$ docker stop $(docker ps -aq)
$ docker rm $(docker ps -aq)

A docker-compose file is a YAML file that describes the different Docker containers you want to run. You can then use the docker-compose up command to spin up all containers defined within that file.

I find it useful to maintain two versions of the docker-compose files, one for production and another for development. So, I went ahead and created a directory called docker-compose/ and dropped put two files in it, prod.yml and dev.yml.


  image: publysher/hugo
  command: hugo
    - ..:/usr/share/blog

  image: abiosoft/caddy
  restart: always
    - 80:80
    - 443:443
    - ../Caddyfile-prod:/etc/Caddyfile
    - ../caddy:/root/.caddy
    - ../public:/srv


  image: publysher/hugo
  command: hugo
    - ..:/usr/share/blog

  image: abiosoft/caddy
  restart: always
    - 80:80
    - ../Caddyfile-dev:/etc/Caddyfile
    - ../public:/srv

With those files in place, we can now spin things up!

$ docker-compose up -f docker-compose/dev.yml

Similarly, if we want to run up the production instances.

$ docker-compose up -f docker-compose/prod.yml

Version control time!

If you haven’t already, created a new (or clone an existing) Git repository to hold all these wonderful files. The has the obvious benefit of versioning all your changes, but will also help getting this site online for you to host.

Let’s get hosting!

So that’s everything working locally. Amazing! But now it’s time to get serious, well, fun serious.

Since we’re running everything in Docker containers, we have a vast array of options for where we can host the site. I’m a big fan of Digital Ocean, so that’s what I’m going to use.

Create a new droplet

So, I went ahead and created a droplet using:

  • The “Ubuntu Docker 1.12.6 on 16.04” One-click App
  • $5/mo droplet (512 MB / 1 CPU / 20 GB SSD / 1000 GB transfer)

Log in, clone the blog and spin it up

Now that a droplet is up and running, we can log in and get things running. This is an almost identical process to what we did locally, but, well, it’s on the line.

This example shows me pulling down my blogs git repository. Clone your own one for maximum awesomeness!

$ ssh my-droplet-server-ip
$ git clone https://github.com/Garjon/blog.git
$ cd blog
$ docker-compose up -f docker-compose/prod.yml -d

If you point your browser at the droplet’s IP address, you should see your magnificent blog on the line! Notice that I’ve used the prod.yml docker-compose file here, as this is production.

I’ve added another argument to the docker-compose command here, -d. This instructs docker-compose to run the containers in “detached mode”, meaning you don’t need to keep your console session active for the containers to continue to run.

Point your domain at your droplet

An IP address is all fine and dandy, but it’s not the easiest thing to remember. So, put your domain or subdomain in front of it!

I wanted to have the blog.garjon.com hostname resolve to my site. So I’ve gone and set my DNS records up to reflect that. Configuring your DNS records is usually relatively straight forward, but if you get stuck, a quick Google should help set you on your way.

My Digital Ocean DNS Records

DNS Records

And there you have it!

Assuming all went spectacularly, you should now have a static Hugo site hosted on the line, with your domain name pointing at it and all super secure with HTTPS.

Show me the source!

Alright alright, I’ve hosted the source for this site on my Github account. If something is not working for you, you may be able to find some kind of helpful hints in there.

Where to from here?

The next step will be to look at setting up some nice CI and CD systems to help automate the propogation of changes into the wild. So stay tuned!

Got stuck? Leave a comment!

If something in this article wasn’t quite clear (or just plain incorrect!), please leave a comment. I’ll try to answer any and all questions and make any corrections to this article as best I can.