Tag: Learning

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.

Tech Talks at Work

~ Adam ~ Leave a comment

One of the initiatives I sponsor at work which I’m most proud of are our weekly tech talks. The company had a long history of doing them, a small group of people would volunteer to talk about something for about an hour on a Friday afternoon. But the prep was hard work and there was no consistency. We could have talk three months in a row and then nothing for the next six. Worse still the same people always felt pressured into talking which seemed very fair on them.

Back in 2019 I went to the Leeds Test Atelier and attended a talk by Sophie Weston. She discussed what her company had done with tech talks and I was really impressed. She argued that the key requirements for any sustainable tech talks were:

  • Duration should be 20-30 minutes
  • The same time/location every week
  • DO NOT MISS A WEEK
  • Food

Inspired by this I went back to work and set about seeing if we could pull off something similar. Sophie had explained how important it was to keep the schedule going week after week. If you start missing weeks those odd weeks develop into hiatuses and then the entire thing stops. She also strongly advised bacon sandwiches but I didn’t have a budget so we relied on BYOB (Bring your Own Buttie) instead.

Over the next few weeks I set about pitching my idea and recruiting speakers. I wanted twelve. I figured that if I could find twelve people willing to give a talk and get them on a weekly schedule then it would be worth doing and I might stand a chance of the talks becoming a sustainable weekly occurrence. I got fifteen.

The Mic Drops began to take off. Photo by Christina Morillo on Pexels.com

We booked a meeting room and opened up Skype for anyone who wanted to dial in. We also made sure we recorded all the sessions so if someone couldn’t attend they could watch it at a later date.

At the time of writing we’ve had:

  • 60 consecutive mic drops pausing only for holidays
  • Over 20 different speakers
  • 20+ hours of recorded videos
  • 1700+ attendees

Even the global pandemic didn’t slow us down, we simply moved to 100% online!

So here are my steps for starting up your own weekly tech talks:

  1. Plan out your first three months in advance to make sure you have sustainability
  2. Hold your talks at the same time and place every week
  3. Unless for a specific reasons the talk and questions should take less than 30 minutes
  4. Record them
  5. Don’t limit to “Tech Talks” some of our best talks have been on sleep, agile, management practices, books, and communication skills. Encourage variety!
  6. Always have a back up speaker, try to have two
  7. Survey your department to find out what talks people are interested in
  8. Invite External Speakers
  9. Run workshops to coach the less confident speakers
  10. Anyone can talk and anyone can attend!

Have you run tech talks in your company? Did you follow a similar format to us? What worked well for you?

Communities of Practice

~ Adam ~ Leave a comment

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.

Teams collaborating and self directing through Communities of Practice is a hard, but powerful concept. Photo by Canva Studio on Pexels.com

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?

Why (and How) I Started Speaking at Conferences

~ Adam ~ Leave a comment

I did my first public speaking event at DDDNorth in February and then followed it up with a second presentation recently at the Leeds Testing Atelier. In this post I want to discuss why (and how) I went from audience member to speaker.

I’ve always been slightly in awe of people who have the confidence to speak in front of fifty, a hundred, or even more people! A friend of mine started doing technical talks a few years ago and after meeting a few more people who give talks I was rabidly running out of excuses.

I read somewhere that the fear of public speaking comes from our most basic tribe instinct. We’re afraid of making a fool of ourselves, of being ostracised from the tribe, and ultimately being seen as an unworthy partner. Even today, when we strive to create safe teams we’re still afraid of standing up and giving presentations to our colleagues.

So the question becomes what changed to make me want to push through this fear?

I’d been giving internal tech talks at work for several months. We used to do them over Skype, personally I found talking to a microphone much easier than talking to a group.

Something interesting happened when I started speaking about various topics at work. People came to talk to me about them!

I quickly realised that the natural progression of learning was to present. The work you do when you put a presentation together helps you focus your ideas, strip out what isn’t important, and ensure you have your topics clear in your mind. The best way to continue your learning is to allow other people to challenge you. In other words, the only way to become the expert is to act like an expert.

Now, I don’t claim to be an expert. But I like to think that the work I’ve put in pulling these presentations together has helped me learn the topics, but also clarify things in my own mind. There’s always the fear of a question you can’t answer, but there’s never any shame in not knowing something – that’s another opportunity to learn!

That brings us to the How. That part is actually surprisingly easy. There are loads of local tech community groups around, and you can quickly find a list of conferences in your area. Chances are they’re the same ones you’ve been going to for years!

Most of these conferences and groups are run by volunteers and most are crying out for speakers. Get in touch, get a date – nothing focuses the mind like a deadline!

Hopefully that’s encouraged you to go and give speaking ago – remember your audience want your talk to be a good one. Here are my top three(ish) tips to public speaking:

  • Submit the topic you want to talk about, not the one you think your audience wants
  • Don’t put bullet points in your slides, they steal your thunder and effectively makes you, the speaker superfluous
  • Don’t talk about pet projects (in the nicest way no one cares) or give sneak precious into something you’re selling (be generous with your knowledge)

And one for luck

  • Memorise your opening, the hardest bit is the moment just before you start speaking!

Talent vs Hard Work

~ Adam ~ Leave a comment

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!

The Importance of your Local Development Community

~ Adam ~ 1 Comment

I recently saw a post on LinkedIn, I’m fairly sure it was an advert for in house training but the message rang true. One manager turned to the other and said “If we train our developers they’ll get better and leave!” To which the other manager replied “But worse, if we don’t then they might stay!”

One of the most common reasons I hear from departing team members is boredom, that they want to go somewhere else and learn new things, use new technologies, and learn from other people. I myself have preached to friends on many an occasion that you learn more in your first few months at a new job than all the time afterwards combined.

You want the most eager, hungry, and interested developers on your team. You want to be able to retain them by introducing them to new ideas. It’s also your responsibility to keep your long serving members of staff from stagmenting and falling into a development rut.

The answer is often closer than you may think!

Local groups of developers are not hard to come by. I’m based in Leeds and to my knowledge we have Agile Yorkshire, Leeds Sharp, Leeds Code Dojo, and Leeds DevOps. Groups of people who meet regularly to discuss ideas, listen to speakers who bring new and exciting topics to the table. By visiting these groups I’ve been introduced to AngularJS, Microsoft Cognative Services, F#, .NET Core, and many many more…

By encouraging your developers to attend these events you motivate them to go out and find new ideas and technologies. Far better for them to have a night out, come back full of new knowledge than decide they’re fed up of using the same technologies over and over.

So how can you encourage participation in these events? Why not arrange to go as a group? Encourage someone to speak and bring the team along to support them. Plan a team night meal afterwards or ask someone to bring ideas back to your own internal training. Who knows, you may even bump into your next hire while you’re there!