15 tips for managing the development of a learning solution
Following on from the tips for starting a learning solution, here are my tips for managing the development of a learning solution. Some of them may seem really obvious, although I rarely see all of them put together. Some are based on what I’ve done, others are what I should have done (especially the last one). Here’s the list:
-
Get a good delivery manager
If the project is reasonably large you are going to need some help in coping with the logisitics and the volume of work being generated. A good delivery manager is worth their weight in gold. Whilst you’re dealing with the challenges of politics and stakeholders, they will make sure the work is going on, the right people are doing the right work and they’ll be your support and confidant.
-
Be the behaviour you want your team to be
This might sound obvious but it’s so often overlooked. If you’re enthusiastic, your team will be. If you’re downbeat, that contagion will spread. If you’re willing to go the extra mile, if you’re open to challenge and discussion, open to be wrong and honest about it then your team will be too. They’ll follow you if they see you’re being authentic.
-
Challenge openly
If something is not how you want it, be prepared to challenge it in public. There will be no time to play nice here and the quicker you do it, the more normal it will become. Let me be clear: I’m talking about telling someone in a room full of workers that the work they’re doing isn’t what you want it to be. You must be supportive, it must be safe to fail and the quicker you do this the quicker your team will get used to it. You should tell them at the start that this is what you do so that there are no surprises. There are a few rules to this – if it’s a capability issue that’s something that’s dealt with in private. If it’s just a work thing make sure they know that they’re valued and valuable but that the work they’ve done in this instance isn’t what you want. Separate the work from the person. Challenging in public becomes a valuable tool for you and your team. They all know that they’re being directed into being better, it’s not embarrassing (eventually) and everyone learns from everyone else’s mistakes. This means people are happy to make mistakes – and that means you’ll get more interesting and powerful solutions. Safe places to fail are lovely places to be.
-
Trust your team and treat them as adults
Your team are professionals who you’ve employed to do a good job. Let me do that. Let them manage their time, let them have ideas and run with them. The only rule you should have for your team is “Don’t go too far”. Focus on output, not time in the office. Some people will go too far and will need to be brought back into line but that’s ok – they’ll learn.
-
Review regularly and randomly
I don’t mean review everything but do regular and sometimes spontaneous reviews of the teams work. Don’t make them too long, don’t make them overly complex. All you’re trying to do is keep things on track and be available for your team. Of course, if something isn’t right you’ve now spotted it early.
-
Don’t expect to be popular
Ad hoc reviews, public comments, open challenge – all these things will hardly help you win a popularity contest. Thing is, it’s not your job to be popular. Don’t go out of the way to upset people, but don’t worry that they’ll be gripes and moaning. Make sure you’re watching out for genuine problems and ask your delivery manager to help you with this.
-
Show them a good time
You’re not trying to buy their affection – you’re trying to show the team that you really appreciate the work they’re doing and that they’re putting up with a lot in pursuit of the goal. Get them coffee, doughnuts and take them out for a social once in a while. Don’t be stingy with this. If you go the extra mile for them, they’ll do it for you.
-
Don’t micro manage (unless they want you to)
This one is obvious, but this is important. Some people want to be micro-managed, some don’t. Manage people in the way that gets the best out of them and don’t expect them to adapt to you.
-
Muck in when the going gets tough
Roll your sleaves up, do some writing, coding or graphics. Work the hours and then some. When things are hard you have to be there with them showing them you care. And when you can’t do the work, buy the pizza.
-
Use a cardboard developer
You and your team will bump up against problems and sometimes everyone is too busy (or not there) enough to talk through. So go out and get a cardboard cut-out character from your local cinema and pop them in the corner. Next time there’s a problem, go and explain it to the cardboard cut out. 90% of the time you’ll get an answer. Yes, I know it uses the fact that explaining something sometimes reveals the answer but have a cardboard developer is more fun. I use a blue plastic cow called Colin…
-
Be very specific about formats and treatments
Don’t leave any design, animation, video or visual elements open to interpretation. If you do, you are opening yourself to someone ‘having a great idea’ that just about derails the entire project because they don’t have the full picture. Explain why you do it, give everyone a chance to contribute and have a process for amending later. But don’t let people tweak because they thought of something in the shower.
-
Don’t assume your team understands you
I find this hard because I understand me. But my team are a) not me and b) might not even be from my culture. You need to make sure the communication channels are open enough for you to ask your team to replay their understanding and adjust your style accordingly.
-
Don’t be afraid to hurt feelings and require a complete rework
If it’s not right get it fixed. This one is really obvious but a tough one to get right. You naturally want your team to like working with you but sometimes you need to be really tough. Make sure you’re offering guidance as to the rewrite or redo and change yourself afterwards to ensure you’re giving clear instructions
-
Don’t over-iterate
Perfection is something to be aimed at. But you need to decide when you’re close enough. The temptation is to keep tweaking and keep iterating until it’s brilliant. The problem is that doing that costs time and money and the small tweaks you’re making won’t make much difference. So decide what to fix and leave it until the next version.
-
Decide early on what is good enough
I’ve left the most important one until last. You will kill yourself if you haven’t decided at the start what good enough looks like. Define it, write it down and put it up somewhere. What does it mean for text, visuals, animation, video, simulation, audio, user experience and testing? This gives you and everyone else a public measure to test against.
Add your tips in the comments