Over the last 2.5 years, I have worked with a number of charities, and had a fabulous time doing it. I've met some great people, with real passion for what they do, who are making a difference in the lives of the people they're helping. I was a part of that. I never delivered direct services. Instead, I helped them do better, more effective work, often through technology. It was my great pleasure.
And now it's time to move on.
I have done what I can, and found, looking back, that things were not working for me. The issues had nothing to do with our clients, or our mission. I leave behind some people who will continue to pursue working with charities with passion and drive. They will carry the torch, and continue to change the not-for-profit sector for the better.
I am moving to new opportunities, which I was too captivated by to pass up. While a lot of the work I've been doing over the last few years has been with small charities, I now have a chance to apply what I've learned to large organisations throughout London, the UK, and the world.
Many organisations have been caught out by the rate of change in technology, over the last 10 years. Traditional job roles, hierarchies, and silos, don't work when technology makes it easy to put something in front of a customer in a few minutes. The imperative to make sure everything is 100% perfect before releasing is being eroded by the idea that rapid change, and rapid recovery, is more valuable to customers. Monolithic projects taking 24 months are being replaced by very small iterations that take 12 hours. Releases which used to keep teams up late at night on a Friday, and over the weekend, are being replaced by releases which take 3 minutes and happen constantly throughout the day.
This is the future, and companies want it. They want to be able to be more responsive to their customers. They want to be able to make rapid changes. They want to be able to make changes in one system without affecting an unknown number of other systems. We will help deliver it. We help make that possible, with agile development practices, microservices, continuous integration, and configuration management, largely in cloud environments. That, alone, is pretty fascinating. And it requires changes in how companies work.
Change creates chaos. Poorly managed chaos results in failed projects, unhappy customers, and poor morale. Every change has ripples. The bigger the change, the bigger the ripples and the more likely to cause unforeseen problems. Unmanaged change has a tendency to fail, over the long term. While you can change individual processes, how the company thinks about those changes can stay the same. When the change agent leaves (a consultant, a local champion, or senior stakeholders), the old ways reassert themselves, slowly blunting (and often reversing) the changes. That's where I come in.
My new role will be to help organisations figure out what change they want to make, figure out who needs to be involved, and figure out how to achieve it. This will overlap with the technical changes that are being implemented. Working in tandem will make things more effective than either of us working alone. Together, we can change culture. Together we can change technology. Together, we can change everything.
Tuesday 2 June 2015
Thursday 21 May 2015
Working at the technical level
My preferred method of engagement with a client is with the senior team. I'm hoping to bring a new viewpoint and ways of thinking to them which, in turn, will allow/facilitate changing their organisation to be more data-driven, experimental, agile, and reflective.
Sometimes it's unclear where help is required. When this happens, we get called in at the easiest level - technology - because it has discrete problems which can be captured, quantified, and solved. And truthfully, a lot of what we have to offer is about addressing technical problems. We have lots of experience solving these sorts of problems, and they can often be done with little disruption to the rest of the organisation.
Working to address things at a purely technical level requires no change. The new solution, which works better than the old one, will be fit into the organisation in the same way and same place as the old solution; if it doesn't work in the same way, it will fail, and thus we will fail. While this clearly suits some problems, it doesn't resolve the challenges that brought us in in the first place. It solves what is essentially a symptom of problems created elsewhere in the organisation (or system). Solving problems this way, without understanding the entire system, and being able to test changes made on it, is tinkering. It ultimately leads to decreased performance; the old way of doing things had known problems, while the new way has unknown problems.
Given that sometimes everybody is brought in to work at a level that's different than where they can be the most use, how do you move from where you are, to where you want to be? The key, I think, lies in framing - asking questions that allow you to expose the areas that haven't been thought of. Talk to the team you're working with, and work to address their challenges, while at the same time helping them become more aware of what's happening around them, and how those things are impacting them. The more aware they become, the more likely that they'll talk to management, and ask them to speak with you about what's going on. Lather, rinse, repeat as necessary until you're operating within your preferred sphere of influence.
This is not a quick fix. It requires deep knowledge of the team you're working with, and an understanding of why things are the way they are (what's keeping them there, and what's stopping them from trying to change), and why they want to change things (what's pushing them away from where they are, and what's tempting them to change). This knowledge gives you a thorough understanding of the current and future environments, and you can start talking about change.
The goal here is not to push change, but to be the catalyst, the agent, of change. What you bring to the table is knowledge of a better, different way to do things, and what they bring to the table is themselves, and their domain knowledge. If things go well, what you leave with is a sense of satisfaction, and what they leave with is a burning knowledge that things can improve, and an idea of how it can happen. Once that fire is lit, it's nigh on impossible for someone else to put out. With that fire lit, you become an adviser, a mentor, a guide. Instead of trying to drag people to progress, you can point it out, and let people figure out for themselves how to get there.
Sometimes it's unclear where help is required. When this happens, we get called in at the easiest level - technology - because it has discrete problems which can be captured, quantified, and solved. And truthfully, a lot of what we have to offer is about addressing technical problems. We have lots of experience solving these sorts of problems, and they can often be done with little disruption to the rest of the organisation.
Working to address things at a purely technical level requires no change. The new solution, which works better than the old one, will be fit into the organisation in the same way and same place as the old solution; if it doesn't work in the same way, it will fail, and thus we will fail. While this clearly suits some problems, it doesn't resolve the challenges that brought us in in the first place. It solves what is essentially a symptom of problems created elsewhere in the organisation (or system). Solving problems this way, without understanding the entire system, and being able to test changes made on it, is tinkering. It ultimately leads to decreased performance; the old way of doing things had known problems, while the new way has unknown problems.
Given that sometimes everybody is brought in to work at a level that's different than where they can be the most use, how do you move from where you are, to where you want to be? The key, I think, lies in framing - asking questions that allow you to expose the areas that haven't been thought of. Talk to the team you're working with, and work to address their challenges, while at the same time helping them become more aware of what's happening around them, and how those things are impacting them. The more aware they become, the more likely that they'll talk to management, and ask them to speak with you about what's going on. Lather, rinse, repeat as necessary until you're operating within your preferred sphere of influence.
This is not a quick fix. It requires deep knowledge of the team you're working with, and an understanding of why things are the way they are (what's keeping them there, and what's stopping them from trying to change), and why they want to change things (what's pushing them away from where they are, and what's tempting them to change). This knowledge gives you a thorough understanding of the current and future environments, and you can start talking about change.
The goal here is not to push change, but to be the catalyst, the agent, of change. What you bring to the table is knowledge of a better, different way to do things, and what they bring to the table is themselves, and their domain knowledge. If things go well, what you leave with is a sense of satisfaction, and what they leave with is a burning knowledge that things can improve, and an idea of how it can happen. Once that fire is lit, it's nigh on impossible for someone else to put out. With that fire lit, you become an adviser, a mentor, a guide. Instead of trying to drag people to progress, you can point it out, and let people figure out for themselves how to get there.
Tuesday 21 April 2015
Learning to change
We have been working with a charity, over the last couple of years, going through clarification of their strategy, applying an IT strategy, and a few IT projects. During this time, we have also been working to help them make systematic use of data, and the organisational change that goes with making that shift. This is, as far as I'm concerned, the cornerstone of good organisational practices, and the most valuable part of approaching IT from a strategic perspective.
This charity works with volunteers who come from the UK and spend several months overseas, as part of the International Citizen Service (ICS). Volunteers apply, interview, learn what country they're going to, get any vaccinations, work on the program, and continue involvement upon their return.
Satisfaction rates were lower than expected, due to a high volume of complaints around expenses. Expenses for the program are all paid, including travel and vaccinations, which can reach £500-1000. Volunteers frequently don’t have that kind of money, so timely expense repayment is crucial.
They originally thought the an automated expenses system would fix everything, at a cost of thousand of pounds per year. They couldn't figure out why people were unhappy - they told volunteers that expenses would be repaid within 4 weeks, and they were sure everything was being repaid in 4 weeks or less (2 weeks for the repayment team to verify expenses, and a payment run every 2 weeks).
When we dug into the data, we learned there wasn't any. Nobody kept track of when expenses came in, when they were signed off, or when they were paid, so nobody knew whether the process worked. They had defined a process, and assumed it worked.
Our first step was to create a spreadsheet to keep track of when expenses came in, and when they were paid. From this data, we learned that it took anywhere between 5 and 115 days to repay expenses. Normal repayment time was anything up to 51 days.
Armed with this data, we gathered everybody responsible for any aspect of expenses repayments in a room and mapped out what the process was supposed to look like, as well as what the process actually looked like. They identified 6 things that could be changed to improve the process, some of which could be undertaken by those in the room, and some of which would require external help.
Armed with the new ideas, we talked to the senior team about the changes that needed to be made, then implemented them and measured their impact by seeing whether the expense repayment time was reduced. Once those ideas were bedded in, new ideas came up, and more after that. From 5-50 days, the team reduced the repayment time 16-22 days, from start to finish. Reliably. And continues to work on it.
Once they understood how to capture the problem, and measure it, they were able to make the process reliable, and fast. Feedback started improving. Reported experiences were better.
The cost of this project was £0, plus time spent learning, which they can now share with the rest of the organisation.
This happens frequently when digging into 'IT' problems. Things which look like IT problems turn out to be something else entirely. This isn't unusual.
So, if approaching IT strategically isn't about software or hardware, what is it about? I define IT strategy as
At the end of the day, your organisation is only as effective as its ability to serve its users, whoever they are. Helping everybody focus on external user needs moves people from 'mine' to 'ours,' and helps them think about how their work contributes to the organisations purpose. Giving them the tools necessary to measure their effectiveness allows them to figure out whether what they're doing works, and provides an environment in which they can try to do things differently, and learn whether changes make things better. It becomes a short jump from this to working to constantly improve things, and when you've reached that point, you're set - it does't matter where an organisation starts; if it learns to constantly improve, it'll eventually be the best organisation of its type.
This charity works with volunteers who come from the UK and spend several months overseas, as part of the International Citizen Service (ICS). Volunteers apply, interview, learn what country they're going to, get any vaccinations, work on the program, and continue involvement upon their return.
Satisfaction rates were lower than expected, due to a high volume of complaints around expenses. Expenses for the program are all paid, including travel and vaccinations, which can reach £500-1000. Volunteers frequently don’t have that kind of money, so timely expense repayment is crucial.
They originally thought the an automated expenses system would fix everything, at a cost of thousand of pounds per year. They couldn't figure out why people were unhappy - they told volunteers that expenses would be repaid within 4 weeks, and they were sure everything was being repaid in 4 weeks or less (2 weeks for the repayment team to verify expenses, and a payment run every 2 weeks).
When we dug into the data, we learned there wasn't any. Nobody kept track of when expenses came in, when they were signed off, or when they were paid, so nobody knew whether the process worked. They had defined a process, and assumed it worked.
Our first step was to create a spreadsheet to keep track of when expenses came in, and when they were paid. From this data, we learned that it took anywhere between 5 and 115 days to repay expenses. Normal repayment time was anything up to 51 days.
Armed with this data, we gathered everybody responsible for any aspect of expenses repayments in a room and mapped out what the process was supposed to look like, as well as what the process actually looked like. They identified 6 things that could be changed to improve the process, some of which could be undertaken by those in the room, and some of which would require external help.
Armed with the new ideas, we talked to the senior team about the changes that needed to be made, then implemented them and measured their impact by seeing whether the expense repayment time was reduced. Once those ideas were bedded in, new ideas came up, and more after that. From 5-50 days, the team reduced the repayment time 16-22 days, from start to finish. Reliably. And continues to work on it.
Once they understood how to capture the problem, and measure it, they were able to make the process reliable, and fast. Feedback started improving. Reported experiences were better.
The cost of this project was £0, plus time spent learning, which they can now share with the rest of the organisation.
This happens frequently when digging into 'IT' problems. Things which look like IT problems turn out to be something else entirely. This isn't unusual.
So, if approaching IT strategically isn't about software or hardware, what is it about? I define IT strategy as
the application of knowledge to organisational and stakeholder needs*, with the possibility of IT contributing to the fix, when the time is rightNo matter what needs you look at addressing it, ultimately, none of it matters if you aren't addressing end-users' needs. Focusing on stakeholder needs allows people to step outside their daily roles, seeing things across departments, and helping people understand that they're all working toward the same goals. It moves the conversation from 'accountability' to 'collaboration,' from 'What do I want?' to 'What do our stakeholders need?' With increased collaboration and understanding comes better prioritisation, and increased focus on the things that really matter.
At the end of the day, your organisation is only as effective as its ability to serve its users, whoever they are. Helping everybody focus on external user needs moves people from 'mine' to 'ours,' and helps them think about how their work contributes to the organisations purpose. Giving them the tools necessary to measure their effectiveness allows them to figure out whether what they're doing works, and provides an environment in which they can try to do things differently, and learn whether changes make things better. It becomes a short jump from this to working to constantly improve things, and when you've reached that point, you're set - it does't matter where an organisation starts; if it learns to constantly improve, it'll eventually be the best organisation of its type.
Thursday 26 March 2015
Working with Apprentices (Part II)
Having recently published Working with Apprentices (Part I), I am now saddened to be taking a new tack - What happens when apprentices leave? This post will, as ever, try to be brutally honest about where I am.
I talk a lot about how to address things so they go well. What happens when they don't? Sometimes, despite doing everything you know how to do (and learning new things, to try to help more); despite building an environment where people are comfortable; where there's no fear of failure; where saying "I don't know" is seen as an opportunity for learning, not ridicule; where coaching is a given; and where advice can be sought for any problem, things don't work out.
We recently went through this with an apprentice. Things didn't work out. Clients were happy with his work, he was curious, resourceful, and imaginative. He helped address problems in new ways, and was very popular. We worked with him for 18 months, and spent many days coaching, mentoring, teaching, and listening. We learned about his life, his problems, his challenges, and his plans to resolve them. We approached problems as learning opportunities, and to the full extent possible, worked with him to help him figure out how to resolve the issues that impacted him and us. We acted as a sounding board and raised red flags if something was a problem.
Given all of that, how did things end up where they did?
The truth is, I'm not sure.
The details of the case don't particularly matter, other than to say that by several measures, in spite of all the good stuff, parting ways was a reasonable choice, and nobody would have been surprised if it had happened 12 months before.
But it sucks. I work for a charity that intentionally hires people who may have had difficult backgrounds. People who may not have worked before, who may have difficult home lives, who may need help, and who have not inconsiderable challenges. Not everybody who comes to us faces those challenges, but they're not uncommon in the demographics from which we recruit. Part of what we do is to hire people as apprentices, and teach them how to become people-focused IT consultants.
At what point do you say, 'In this case, we have failed. We are not the right people to provide the help that's required?' The truth is, perhaps we could help him, if we did something differently, or were persistent. Perhaps if we'd spent a bit longer, approached work a bit differently, framed things slightly differently, given him more/less autonomy/responsibility/freedom/training, we wouldn't be sitting where we are now. But there's a conflicting truth that we must face, as well. It's the same one every charity faces - time we spend working with one person is time we can't spend working with someone else. Charities that we could be working with aren't being helped, because we can't schedule meetings reliably, can't count on having someone there who we need, and can't give them the focus and attention they need.
Assuming the goal is to meet the needs of our staff and our clients, maximise our impact, minimise our harm, and help as many organisations as possible get a better understanding of IT, then we have to recognise that sometimes things don't work. We choose to draw a line, which says, 'At this point, we are no longer working toward the same goals, and we are no longer a good fit for each other.'
I can no longer help this person, but perhaps this will serve as a wakeup call, and perhaps he will finally help himself. At this point, that is my sincerest hope, and I'd love to see him again, someday, when that has come to pass. Hope, in the face of adversity, is why we do what we do. So we don't say goodbye. Instead, we say, 'Until next time,' and we hope that our paths cross again.
I talk a lot about how to address things so they go well. What happens when they don't? Sometimes, despite doing everything you know how to do (and learning new things, to try to help more); despite building an environment where people are comfortable; where there's no fear of failure; where saying "I don't know" is seen as an opportunity for learning, not ridicule; where coaching is a given; and where advice can be sought for any problem, things don't work out.
We recently went through this with an apprentice. Things didn't work out. Clients were happy with his work, he was curious, resourceful, and imaginative. He helped address problems in new ways, and was very popular. We worked with him for 18 months, and spent many days coaching, mentoring, teaching, and listening. We learned about his life, his problems, his challenges, and his plans to resolve them. We approached problems as learning opportunities, and to the full extent possible, worked with him to help him figure out how to resolve the issues that impacted him and us. We acted as a sounding board and raised red flags if something was a problem.
Given all of that, how did things end up where they did?
The truth is, I'm not sure.
The details of the case don't particularly matter, other than to say that by several measures, in spite of all the good stuff, parting ways was a reasonable choice, and nobody would have been surprised if it had happened 12 months before.
But it sucks. I work for a charity that intentionally hires people who may have had difficult backgrounds. People who may not have worked before, who may have difficult home lives, who may need help, and who have not inconsiderable challenges. Not everybody who comes to us faces those challenges, but they're not uncommon in the demographics from which we recruit. Part of what we do is to hire people as apprentices, and teach them how to become people-focused IT consultants.
At what point do you say, 'In this case, we have failed. We are not the right people to provide the help that's required?' The truth is, perhaps we could help him, if we did something differently, or were persistent. Perhaps if we'd spent a bit longer, approached work a bit differently, framed things slightly differently, given him more/less autonomy/responsibility/freedom/training, we wouldn't be sitting where we are now. But there's a conflicting truth that we must face, as well. It's the same one every charity faces - time we spend working with one person is time we can't spend working with someone else. Charities that we could be working with aren't being helped, because we can't schedule meetings reliably, can't count on having someone there who we need, and can't give them the focus and attention they need.
Assuming the goal is to meet the needs of our staff and our clients, maximise our impact, minimise our harm, and help as many organisations as possible get a better understanding of IT, then we have to recognise that sometimes things don't work. We choose to draw a line, which says, 'At this point, we are no longer working toward the same goals, and we are no longer a good fit for each other.'
I can no longer help this person, but perhaps this will serve as a wakeup call, and perhaps he will finally help himself. At this point, that is my sincerest hope, and I'd love to see him again, someday, when that has come to pass. Hope, in the face of adversity, is why we do what we do. So we don't say goodbye. Instead, we say, 'Until next time,' and we hope that our paths cross again.
Tuesday 17 February 2015
Working with Apprentices (Part I)
When I tell people about that we recruit people with no IT experience and teach them to be IT consultants, they frequently ask what it's like working with people without experience. After doing it for a couple of years, I can honestly say, it's no different than working with anybody else. This is frequently a surprise to people who think people without experience won't know how to behave or how to do anything. They think we'll have to be firm, or 'cruel to be kind,' to get results and to keep them from dropping off the apprenticeship.
We understand this view, but don't subscribe to it. We don't want to be the same as other companies, so we don't treat them the same as other companies. Ours is a company where we value autonomy, mastery, and purpose. We use a cardwall to ensure everything that needs to be done is visible to the whole company; break things into pieces to give us a chance to iterate and constantly improve; don't judge other's behaviour; and ensure we always focus on the area that needs our attention the most.*
This changes things. In an organisation that keeps information hidden, people can't learn how to behave, or what to do, without making mistakes, or being told (which frequently takes the form of 'behaviour management'). By opening up the needs of the organisation so everybody can see them and can choose what to work on, we ensure that even people with no experience can find something to do that needs to get done, and which they're willing to take on. This appeals to their desire to achieve mastery, and their autonomy, and we do it for everybody.
Our process comes with risks. Sometimes people get lost. They don't know what to do, or they don't know how to structure their work so it's achievable. Our job (regardless of experience level) is to help people figure out what needs to be done, and how to make it possible. Sometimes that's me asking apprentices questions, and sometimes it's them asking me questions. It's a give and take based on equality and respect, where experience and length of service mean less than empathy and learning, and the more you know, the more likely you are to spend your time helping people who know less.
Sometimes people make mistakes. Mistakes are inevitable, if you're learning, and pushing boundaries. For us, the important thing is to learn from those mistakes - to reflect on the process that lead to the mistake, rather than who is responsible for making it - so we can do things differently in the future. We approach every project, every task, every need as the current step in an iteration. Learning is an ongoing process which never ends. Our apprentices start out shadowing more experienced consultants and working on a service desk. Over time (6-9 months), they pick up enough experience to run their own small, supervised projects. In the next 9 months, they start running projects on their own and mentoring new apprentices. Within 18 months, they go from knowing nothing about IT to running their own projects and taking responsibility for the results, challenges, and learning.
It is my sincere privilege to watch them grow and change, learn and improve, and to embrace and unleash their own potential. They learn to look within themselves for their self-worth, and I couldn't be prouder of them for it.
*How we do these will (probably) be explored in later posts. As with everything else, this is an ongoing work in progress.
You can read my follow-up post here.
We understand this view, but don't subscribe to it. We don't want to be the same as other companies, so we don't treat them the same as other companies. Ours is a company where we value autonomy, mastery, and purpose. We use a cardwall to ensure everything that needs to be done is visible to the whole company; break things into pieces to give us a chance to iterate and constantly improve; don't judge other's behaviour; and ensure we always focus on the area that needs our attention the most.*
This changes things. In an organisation that keeps information hidden, people can't learn how to behave, or what to do, without making mistakes, or being told (which frequently takes the form of 'behaviour management'). By opening up the needs of the organisation so everybody can see them and can choose what to work on, we ensure that even people with no experience can find something to do that needs to get done, and which they're willing to take on. This appeals to their desire to achieve mastery, and their autonomy, and we do it for everybody.
Our process comes with risks. Sometimes people get lost. They don't know what to do, or they don't know how to structure their work so it's achievable. Our job (regardless of experience level) is to help people figure out what needs to be done, and how to make it possible. Sometimes that's me asking apprentices questions, and sometimes it's them asking me questions. It's a give and take based on equality and respect, where experience and length of service mean less than empathy and learning, and the more you know, the more likely you are to spend your time helping people who know less.
Sometimes people make mistakes. Mistakes are inevitable, if you're learning, and pushing boundaries. For us, the important thing is to learn from those mistakes - to reflect on the process that lead to the mistake, rather than who is responsible for making it - so we can do things differently in the future. We approach every project, every task, every need as the current step in an iteration. Learning is an ongoing process which never ends. Our apprentices start out shadowing more experienced consultants and working on a service desk. Over time (6-9 months), they pick up enough experience to run their own small, supervised projects. In the next 9 months, they start running projects on their own and mentoring new apprentices. Within 18 months, they go from knowing nothing about IT to running their own projects and taking responsibility for the results, challenges, and learning.
It is my sincere privilege to watch them grow and change, learn and improve, and to embrace and unleash their own potential. They learn to look within themselves for their self-worth, and I couldn't be prouder of them for it.
*How we do these will (probably) be explored in later posts. As with everything else, this is an ongoing work in progress.
You can read my follow-up post here.
Thursday 12 February 2015
Strategic Learning
I saw a really good talk this week, at a London Funders meeting, about strategic learning. It was defined thus:
Learning isn't reserved for the SMT; it's something that is at everybody's fingertips. If you look around your organisation and ask yourself who knows the beneficiary's needs best, it's more likely to be the front line than it is to be the SMT. The SMT has a number of responsibilities, but day-to-day operations with program beneficiaries isn't usually one of them. This makes them well placed to identify overall trends in their sector, upcoming organisational challenges, and opportunities. It doesn't make the SMT particularly well suited to make decisions about how to best serve program beneficiaries. Therefore, anything which helps the front line to learn, share that learning, and propagate those things throughout the organisation is to be embraced, while things which do the opposite are to be avoided.
Doesn't moving learning to the front line risk moving strategy out of the hands of the SMT and result in chaos? Realistically, no. Embracing learning as an organisation means changing the role of the SMT from that of decision-maker and policy-setter to that of enabler; from enforcement of a strategy to facilitation of thinking, learning, and experimentation. Learning and improvement become the strategy, and as beneficiary progress is the only true measure of progress, beneficiaries become the real heart of the organisation - not just in words and thoughts, but also in measurement (and what gets measured is what gets done).
In a system where learning is embraced, the SMT's primary responsibility is to help people figure out how to learn, how to interpret what they've learned, and how to continually find new ways to learn, grow, and challenge themselves, in service to program beneficiaries. When I ask myself which I'd rather have - one person responsible for strategy who is removed from day-to-day operations, or 50 people who know what impact the organisation's decisions are having on beneficiaries, the decision seems clear to me.
(This post is loosely linked to The Outsider's Experience)
Strategic learning is the use of data and insights from a variety of information-gathering approaches—including evaluation—to inform decision making about strategy.
This is a fabulous definition. It encapsulates what's needed, what's done with it, and how you can tell you're doing it. I think the biggest risk is with the words being defined. Use of the word "strategic" risks making learning loftier and more exclusive than it needs to be.It occurs when organizations or groups integrate data and evaluative thinking into their work, and then adapt their strategies in response to what they learn.
Learning isn't reserved for the SMT; it's something that is at everybody's fingertips. If you look around your organisation and ask yourself who knows the beneficiary's needs best, it's more likely to be the front line than it is to be the SMT. The SMT has a number of responsibilities, but day-to-day operations with program beneficiaries isn't usually one of them. This makes them well placed to identify overall trends in their sector, upcoming organisational challenges, and opportunities. It doesn't make the SMT particularly well suited to make decisions about how to best serve program beneficiaries. Therefore, anything which helps the front line to learn, share that learning, and propagate those things throughout the organisation is to be embraced, while things which do the opposite are to be avoided.
Doesn't moving learning to the front line risk moving strategy out of the hands of the SMT and result in chaos? Realistically, no. Embracing learning as an organisation means changing the role of the SMT from that of decision-maker and policy-setter to that of enabler; from enforcement of a strategy to facilitation of thinking, learning, and experimentation. Learning and improvement become the strategy, and as beneficiary progress is the only true measure of progress, beneficiaries become the real heart of the organisation - not just in words and thoughts, but also in measurement (and what gets measured is what gets done).
In a system where learning is embraced, the SMT's primary responsibility is to help people figure out how to learn, how to interpret what they've learned, and how to continually find new ways to learn, grow, and challenge themselves, in service to program beneficiaries. When I ask myself which I'd rather have - one person responsible for strategy who is removed from day-to-day operations, or 50 people who know what impact the organisation's decisions are having on beneficiaries, the decision seems clear to me.
(This post is loosely linked to The Outsider's Experience)
Wednesday 11 February 2015
Why do charities need IT help?
I'm sitting on a train, traveling to Manchester, reflecting on what I do. I spend my time split between two roles at the same company. I work with young people, teaching them IT, and ensuring they have the knowledge necessary to be outstanding IT consultants. My other role is why I'm traveling today. I'm on my way to visit a company that's expanding. They're based in Manchester and have just opened an office in Liverpool, with plans to open a few more around the country. There are a few challenges inherent in expansion, and the one I'm concerned with is IT.
I work with charities. Charities work with the vulnerable and the needy. They're started by people with passion, and a burning drive to do something good. They're rarely started by people who understand IT, let alone how IT can facilitate or inhibit organisational growth, change, and improvement. That's where I come in. My role is to help charities understand what IT means. Not necessarily in the day-to-day infrastructure sense of the word (servers, support, etc), but in the sense of IT being a fundamental part of how the organisation works. Like fundraising, management, or finance, organisations can run without IT for only so long before they become unwieldy. This is what I thought when I first started working with charities - that if I could help them understand IT, things would all work out.
It turns out, I was wrong. My role as originally envisaged doesn't work. If the focus remains on IT, then there is rarely any openness to the idea that what needs to change is how the organisation thinks (about IT, about systems, about itself). What does seem to work is going through a process, which is the same between charities but which plays out in very different ways, of mutual learning and growth. Through my understanding of IT, systems, and management, and their understanding of how their organisations work, we learn how to make changes, and test them, in ways that ensure the continual improvement of the charity, long after I'm gone.
The end result of successful consulting, is not a delivered project, or a report, but a changed system, where it seems obvious that the new way is an improvement, and nobody is interested, or capable, of going back to the way things were before. IT plays a part in this story, but it's not the hero. The hero is the charity. And like any hero, each charity goes through its own hero's quest, first encountering challenges, and then slowly learning how to overcome them, until at some point, it looks back and is astounded by how far it's come, and how much better things are now than they were.
I work with charities. Charities work with the vulnerable and the needy. They're started by people with passion, and a burning drive to do something good. They're rarely started by people who understand IT, let alone how IT can facilitate or inhibit organisational growth, change, and improvement. That's where I come in. My role is to help charities understand what IT means. Not necessarily in the day-to-day infrastructure sense of the word (servers, support, etc), but in the sense of IT being a fundamental part of how the organisation works. Like fundraising, management, or finance, organisations can run without IT for only so long before they become unwieldy. This is what I thought when I first started working with charities - that if I could help them understand IT, things would all work out.
It turns out, I was wrong. My role as originally envisaged doesn't work. If the focus remains on IT, then there is rarely any openness to the idea that what needs to change is how the organisation thinks (about IT, about systems, about itself). What does seem to work is going through a process, which is the same between charities but which plays out in very different ways, of mutual learning and growth. Through my understanding of IT, systems, and management, and their understanding of how their organisations work, we learn how to make changes, and test them, in ways that ensure the continual improvement of the charity, long after I'm gone.
The end result of successful consulting, is not a delivered project, or a report, but a changed system, where it seems obvious that the new way is an improvement, and nobody is interested, or capable, of going back to the way things were before. IT plays a part in this story, but it's not the hero. The hero is the charity. And like any hero, each charity goes through its own hero's quest, first encountering challenges, and then slowly learning how to overcome them, until at some point, it looks back and is astounded by how far it's come, and how much better things are now than they were.
Friday 6 February 2015
Teaching and Corporate Responsibilities
I've heard a lot, over the last few years, that students are leaving school unprepared for the world of work, and the solution is to teach work-specific skills to students before they graduate. On the surface this makes sense, particularly if we only look at the last 20 years of employment. However, if we go a bit further back, we'll find that this argument doesn't make any sense.
60 years ago, even 40 years ago, work-ready meant something else. When my parents were starting work, their companies took them on, fresh from university, expecting to have to train them. That was how businesses got employees that knew what to do - they taught them. This was true whether someone was hired for management or the mailroom. The new person was always taught by someone with more experience. What they were taught, and how intense the training was depended on the company and the position, but the basic fact of training was a part of the job.
Sometime between about 1975 and 1990 we seemed to lose sight of the fact that employee training is an employer's responsibility. This was fairly predictable, as a new generation of management graduates had been taught that shareholder value was the most important thing to consider, and training seemed like an undesirable expense. This is the same school of thought that brought about the end of pensions, and the end of employee/employer loyalty.
Employers are really good at convincing governments of their perspectives (Adam Smith warned against allowing them to do this as far back as 1776). It's even easier when they own the newspapers and are allowed to sway public opinion in their favour. It didn't take long for government to start talking about how schools are failing our children, by not getting them ready for the world of work. It's rhetoric that took 20 years to stick, but has a growing base of support among government, people, and business, despite there being no evidence that educational quality has declined since employers stopped taking responsibility for training.
Like the banking crisis, making people 'work-ready' is another way of making costs and losses the responsibility of the taxpayer, while diverting ever-increasing profits to a smaller and smaller number of people. Allowing businesses to frame the conversation will always result in the public losing out, and will over time, result in the public not knowing there was anything to ever lose.
Our education system isn't failing our children, we are. We allowed it to start, we have allowed it to continue, and at the end of the day, we are the only ones who can stop it, thereby leaving a better world to our children.
60 years ago, even 40 years ago, work-ready meant something else. When my parents were starting work, their companies took them on, fresh from university, expecting to have to train them. That was how businesses got employees that knew what to do - they taught them. This was true whether someone was hired for management or the mailroom. The new person was always taught by someone with more experience. What they were taught, and how intense the training was depended on the company and the position, but the basic fact of training was a part of the job.
Sometime between about 1975 and 1990 we seemed to lose sight of the fact that employee training is an employer's responsibility. This was fairly predictable, as a new generation of management graduates had been taught that shareholder value was the most important thing to consider, and training seemed like an undesirable expense. This is the same school of thought that brought about the end of pensions, and the end of employee/employer loyalty.
Employers are really good at convincing governments of their perspectives (Adam Smith warned against allowing them to do this as far back as 1776). It's even easier when they own the newspapers and are allowed to sway public opinion in their favour. It didn't take long for government to start talking about how schools are failing our children, by not getting them ready for the world of work. It's rhetoric that took 20 years to stick, but has a growing base of support among government, people, and business, despite there being no evidence that educational quality has declined since employers stopped taking responsibility for training.
Like the banking crisis, making people 'work-ready' is another way of making costs and losses the responsibility of the taxpayer, while diverting ever-increasing profits to a smaller and smaller number of people. Allowing businesses to frame the conversation will always result in the public losing out, and will over time, result in the public not knowing there was anything to ever lose.
Our education system isn't failing our children, we are. We allowed it to start, we have allowed it to continue, and at the end of the day, we are the only ones who can stop it, thereby leaving a better world to our children.
Subscribe to:
Posts (Atom)