Tag Archives: line management

I’ve been quiet on here for a few weeks as I’ve been head-down on some pretty major work at Red Gate and publishing what I and the team have been up to on their freshly launched dev.red-gate.com mini-site.

Here’s a roundup of the highlights:

“Slack” – Exploring how we approach “slack time”. Ensuring slack is available to the right people at the right time and trying to keep it guilt-free.

A Manifesto (of sorts) for personal development – what we expect from each other in developing ourselves and our careers. The outcome of 2 months of Genchi Genbutsu (go see at the source) – asking some really direction questions face to face (individually) with every single member of our development teams.

Top Tips for personal development – 12 Tips on personal development from Red Gate’s development team (plus another 12 linked from this one). These are the tips we use as part of our new personal development plans but are equally useful as prompts to simply “get out and do something”.

Skills Maps – An overview of the skills maps we’re developing at Red Gate for our development team roles (it turns out what we’re trying is pretty unique and developed a bit of a buzz.

Fresh off the press yesterday; Organizational Restructuring – An Insider View – Putting Convergence & Divergence into practice. How Red Gate are performing a complete organizational restructuring to their teams without the usual cloak and dagger HR hell.

Finally, Johanna Hunt and I have paired up again on our “Cracking Big Rocks” cards and workshop. After much editing, re-editing and review we published the second edition of the card deck at the end of September and took them out for a first run at Agile Cambridge. The revised deck includes a few new patterns, rewording of many of the old ones, some basic instructions and some lovely artwork on a few of the cards from our good friend Paul Stapleton.

It’s been a month since I last posted about the work I’ve been doing around career development. Things are moving well and trials of the process described in the first 2 posts in this series have been really successful and way more popular than I expected. Everyone I’ve spoken to about it has been really excited and we’re now doing an expanded second round of trials with another 20 staff before adjusting and rolling out as a tool to all our development teams.

This is just a quick post to highlight a few tweaks and important points for anyone wanting to try this themselves…

Participant feedback

So far everyone that’s tried it has found it really useful. My 2 favorite quotes so far…

“I never would have thought of some of the areas to action without this process”

“I’m better able to prioritize actions because of the process”

This will almost certainly work best for people with quite a strong sense of self-awareness and self-improvement already (as does any development plan) and remember you can’t forcethis on someone.

There’s bound to be cases where this process doesn’t work but we’ve not found one yet. If you try this yourself, we’d love to hear how it’s worked for you and remember, after trying it out once or twice, it’s worth tailoring to your own needs further.

Recommended Adjustments

Clarity – In a change to the original recommendation (working blind), we’ve found it’s more useful to share a clear agenda and state where we are in the process and why at each step so people understand what they’re meant to be thinking about and know what’s left to do.

Skill Levels – In addition to the “out of 10” ratings, we’re going to try developees/managers discussing where they feel they stand in terms of SLII (Situational Leadership) development level (e.g. D1-D4). This requires a bit more thought in understanding the differences but keeps our teams aligned with our broader efforts to use SLII when developing each other. We’ve not tried this bit yet (but will be doing so in the next couple of weeks) so it’ll be an experiment within an experiment – we’ll be seeking feedback and thoughts on how this best works.

Action Grid – Rather than defining all the actions in the action grid up-front; partially filling the set of actions at the beginning and then pulling more in after each step seems to work better for people. It’s important however that developees have filled something in each space to work from toward the end of the session before transferring things across to their plan grid. The idea with pushing for all these actions is to stretch our thinking a bit and gently encourage people out of their normal comfort zone.

Supporting the write-up – It’s still really important that the developee writes this up for themselves but format can be a bit challenging. Whilst we have a couple of people using Mural.ly and one other gave this a shot with excel, we’ve found keeping the visual management aspect afterward is important. Here’s a “blank” PowerPoint presentation with heading placeholders and post-it templates to help people along.

Pitfalls / Caution

Skills Categories – The skills category columns (Job/Role, Soft Skills, Domain/Industry) can be a bit tricky. We’re developing a role-based skills map for each role in development that participants can use as a cue (I’m planning to post more about how this is developing over the next month). Our suggestion here is to select a subset of these skills and traits to talk about in more depth rather than using them all.

Flow – As we’re looking at similar things from multiple angles to find patterns, there’s not always a logical progression through activities. This is deliberate but can sometimes feel a bit “bumpy”.

Time – This takes a lot of time and effort (a minimum of 2 hours depending on how “chatty” the participant is) you could consider breaking it up into 3 sub-meetings:

Current activities/direction

Skills session (including one small next step)

Actions brainstorm around common themes (using action grid)

(I’d still aim for running one straight-through session first time around as the energy from doing it all in one shot is fantastic)

Managing the session – Seriously avoid time-boxing each step. It’s better to reserve more time and let each part play out naturally.

Energy – This can be quite an exhausting session for both participants and we know one size won’t fit everyone so it’s worth setting expectations that this is hard work. I’d recommend running this when participants both have a lot of energy (e.g. start at ~10AM)

Follow-through – It’s reallyimportant that you follow up within the first 2 weeks to ensure the write-up is done and first actions are planned, (Momentum tails off really fast for development plans) and then remember to follow up regularly – e.g. on a monthly basis after that.

Longer-term – We expect people to want to return to this session in future but not to need to spend quite the same level of effort again unless they’re radically altering their role and direction. At the moment, my thinking is an in-depth refresh after about a year however you may feel like 6 months is more useful.