Category: Training

Holding a Tech Lead course in Sydney

August 31, 2015 / Patrick / 1 Comment

With a one-time only opportunity this year, I am running a course for Architects and Tech Leads on 22-23 October at the ThoughtWorks Sydney offices. After interviewing over 35 Tech Leads for the Talking with Tech Leads book, I recognised there is a gap about teaching developers the special leadership skills a successful Architect and Tech Lead demands. The class size is really limited, so reserve yourself a place while you can.

In this very hands-on and discussion-based course, participants will cover a wide breadth of topics including understanding what a Tech Lead is responsible for, the technical aspects a developers rarely experiences and is not accountable for, and the difficult people-oriented side to the role including influencing, relationship building and tools for better understanding your team.

This is a two-day course that will quickly pay back dividends in accelerating you on your path or further developing your Tech Lead skills as developers. Register here on eventbrite for the course 22-23 October.

Tech Lead – Circles of Responsibility

June 19, 2015 / Patrick / 6 Comments

One of my projects this year is a training program for developing Tech Leads. In preparation for the course, I developed this diagram below to explain what areas we focus on and found the model resonated very well with people who interact with Tech Leads, but probably don’t really know what Tech Leads do. I also found it has been a useful model discussing it with new or current Tech Leads about areas of potential growth. This model explains the Tech Lead role as intersection of three other roles – A Developer, a Leader and an Architect.

A Tech Lead is developer who is a Leader

A Tech Lead wouldn’t be the same without being technical and there are a whole bunch of development skills I would expect any capable Tech Lead of having. In today’s age of agile development practices, there are a whole set of engineering practices, I would expect Tech Leads capable of doing such as refactoring and Behaviour/Test-Driven Development.

What makes a Tech Lead different from developers is their breadth and depth using leadership skills to help the team move towards a goal. Unlike developers who can avoid giving feedback to their peers, a leader must be able to give and receive feedback to help people develop and be more effective. This means not only focusing on the technical aspects, but also the team and people aspects such as relationship building, motivating, delegating, and influencing.

Tech Leads must work to resolve conflict. Conflict itself is a sign of a healthy team, but only when the Tech Lead creates an environment where conflict is resolved.

Developing skills in the Leader role

Developers have little opportunity to practise leadership skills. Tech Leads are fortunate to have many resources that address the leadership circle. Leadership skills are important to all leaders regardless of industry or position and you can find a plethora of books, training courses and websites.

A Tech Lead is hands-on Architect

I have written in the past that I expect effective Tech Leads and Architects to have some level of coding ability. I have even gone so far to suggest they should ideally spend a minimum of 30% of their time in the code.

Developers spend much of their time in the code, but unless they start thinking of the bigger picture, it is difficult for them to start thinking beyond that. Tech Leads must help the team to:

Build systems, not software

This mindset shift helps developers think about a lot more than just the software – to start thinking of the quality attributes of software systems (or the Cross-Functional/Non-Functional Requirements) as well as the whole interaction with the deployment environment in which the software lives.

When someone plays the Architect role, they are naturally taking a broader view of the software – how long it’s going to last for and how it is going to evolve over time.

Developing skills in the Architect role

The Software Architect role is much newer compared to general leadership and although there are some resources available, I cannot recommend many of them because they either focus on the tooling, or they teach little that help people bridge the gap.

Although people are writing books, articles and training courses that address this circle of skills, more still needs to be done.

What I’m doing about it

Most training courses that exist focus on a single tool, a single approach but rarely focus on a broad view that also gives developers a better understanding of the Tech Lead, particularly the Architect side to the role. I have run a hands-on course for Tech Leads that helps people build more awareness and gives people and opportunity to practice some of the skills outlined in the model above.

Although we touch about some of the skills in the “Leader” role, I focus the contents more on the “Architect” role because there are fewer resources available. If you’re interested in this course, please get in touch and I plan on writing another blog entry detailing what we cover.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Three Days of Clojure Joy

June 30, 2011 / Patrick / 1 Comment

A couple of weeks ago, I sat in a training class run by Stuart Halloway, CEO of Relevance and who ThoughtWorks happened to bring across from the US to give us the low down of Clojure.

We covered a lot of material in the three days – covering pretty much every aspect of Clojure. We learnt all the basics such as core data types, namespaces, how to get documentation and examples, and many of the key functions that come as part of the core clojure libriares.

I appreciated the time spent discussing the background of why clojure exists, and the alternatives that are present in many other languages. It was great to have someone as knowledge as Stuart as we could ask as many questions as we like about things.

The training wasn’t just all talking and we did do a few exercises. I have to admit because I hadn’t touched any real functional programming since university, many of the exercises towards the end of the three days went over my head a little bit – a combination of needing to know some key clojure functions, and probably needing to re-adjust to a “functional way of thinking” which I think proves the biggest challenge.

In terms of tooling, we used the simple REPL and whatever environment we chose (the exercises don’t really need that much) although I learned about ParEdit that seemed to be quite useful.

I also learned about a new datastructure – Bit Partitioned Hash Trees (more here and here that I need to do some more reading around.

The course accelerated quickly, covering basic functional programming on the first day, the different ideas between state and time in clojure and then syntatic programming. Also we covered topics such as Interoperability with Java libraries and the problems that protocols address and defrecords (prefer defrecords over deftypes as the latter is now considered deprecated).

Just like any good training course, it left me realising how much more I need to learn and get my head around. This only really comes with more time and practice.

Come along to XP2009

April 7, 2009 / Patrick / 2 Comments

At this year’s XP2009, I’m going to run the workshop, Climbing the Dreyfus ladder of Agile Practices where we’ll look at learning models (focusing on one in particular) and how to use them to help as a model for coaching and transferring skills around agile practices.

It’s going to be great fun, and contains some great material inspired by all the wonderful coaching work that Liz Keogh has been doing (we’re also hoping to get into Agile 2009).

Bring your friends, your work colleagues and anyone you think might get some benefit. I’ll be maintaining this page as we get closer to the conference.

Why Training Fails

June 2, 2008 / Patrick / 3 Comments

I’m a big believer in letting people try things out. Unfortunately, most training programs don’t let people do this enough. In fact, most of the time, training is seen as some way of “fixing problems” or a “all-in-one solution”. I can tell you a simple reason why training fails… people don’t have support to actually use the things they are trained on. They don’t get the essential feedback loop in their real environment and they quickly forget what they learned.

It’s all fantastic when you have an opportunity in class to try what you learned out. What really matters if whether or not you have long term lasting support in your environment to apply it to what you do. Unfortunately most training programs fail to address that, or the trainers don’t feel like it’s something they can influence.

Training lasts a day. True learning lasts a lifetime. If you send people on training, make sure they have a safe environment to apply it as well. Don’t view training as a silver bullet. Use it as a tactical solution as part of a larger strategic initiative.

Agile Principles Applied to Training: Transparency and Information Radiation

May 14, 2008 / Patrick / 0 Comments

One thing I’ve noticed agile projects tend to do is to push relevant information out to people, and be extremely honest about how things are going. Here are my attempts at doing so:

Posters Around the Workplace – Finding time to showcase progress to my stakeholders is like trying to hold a wriggling eel in water, so I thought of hanging some eye catching posters on the noticeboards. I decided they’d be good for two purposes – the first to help give stakeholders an idea of what I’ve been doing with training since we met about a month ago without the need of scheduling another meeting, and the second, to market towards potential people who’d have an interest in attending. In about an hour, I ended up with a poster (see the photo) that included what topics I have material for (and what I have planned), photos of outputs from the training including snippets of real feedback, and contact information for more information. I purposely left two spaces to update the colour poster with two pieces of information, just the right size for sticky notes. I’m currently filling one indicating the number of people who’ve participated so far, and the other, the number of classes I’ve run.
Mini Card Wall – Keeping track of all the tasks associated with material development, scheduling training, meeting with people is becoming difficult so I’ve put up a mini card wall using the desktop PC I have next to my monitor. People around me can take a look at the things that I need to do, and as new requests pop up, I can quickly add it to the list of items still open using the pen and pad of sticky notes I have nearby. As you can see from the picture, all I really care about is whether or not something is open (needs my attention eventually), in progress (reminds me of what I’m working on) and done (I remove these at the end of the day).

Agile Principles Applied to Training: Building in Quality and Continuous Improvement

May 13, 2008 / Patrick / 0 Comments

In my experience, achieving high quality is a key part to being adaptive and nimble. Continuous improvement and responding to the feedback allows you to achieve high quality. Here’s what I’ve applied to training so far:

Set design and collaborating ideas – One approach I could have taken to developing the material included simply writing the content, trainer’s guide, handouts, etc and run it with a single class before trying to change anything. Instead, I came up with a few options, bouncing ideas off someone else who’d run training before and asked them, “I’m thinking of trying something like like …, I imagine it would work like … and we’d achieve … What do you think? What discussion would this generate? Would people find it engaging?” It stopped me detailing things too early and putting in too much effort that would need rework.
User Centred Design – For some of the worksheets, I applied some principles from Don’t Make Me Think, testing them out with some users to make sure they needed as little instructions as possible. It’s important for students to have a good experience with everything to do with the course. You can see the evolution by looking at the picture above – it’s a worksheet for introducing the concept of velocity for the XP Lego Game.
Finding the right metrics to use – I’ve already changed my feedback forms since running the pilot programs, looking at what information I actually consume and how people use it. I used to have a two-page feedback form, the first including instructions and a focus on multiple choice answers, with the second page using a more free form format. Since I hand them out in class, I give verbal instructions and removed the detail blurb I had at the top. I also condensed the form into a single page, and focused on three key questions I am more interested in – “What did you like best about the session? What constructive changes would you suggest to make the session more effective? What else do you want to know about?”

Agile Principles Applied to Training: Building in Feedback Cycles

May 12, 2008 / Patrick / 0 Comments

I’ve been leveraging my experience with agile in teams and development and applying it to what I’ve been doing in training. Here’s what it looks like:

Review material before class – Executing the material with an audience is the slowest part of my feedback loop. Instead, I’ve had a few people review different parts of the material during and after I’d developed the material, constantly seeking people who might give a different perspective about the content, delivery techniques, etc. Some of them involved a detailed walk through, others a brief, what do you think response?
Gathering feedback from classes – I’ve had a chance to run some pilot classes, gathering effective feedback to consider changes. I also try to set some time aside after class, capturing notes around how effective I thought some of the classes ran, looking at ways of improving them.
Eating my own dog food – The trainer’s guide is meant for someone else, and as difficult as I find it is, following a guide you wrote, I try using it to plan out the classes I run to see how well documented it is.