EDIT - for reasons I choose not to speculate on, the original post has been archived and must be seen via the Wayback machine.
The magic bullet that is outsourcing rears its head every so often. Why worry about organisational capability and capacity when you can commoditize the process? Push some money at the problem and it goes away, right?
Well, no. Not even close. There are many problems fundamental with this way of thinking and for me they boil down to two key things:
1. Code is never finished
2. Effective and sustainable outsourcing is really hard
I'm going to write a separate post about the first point. Probably more than one - every time I sit down to write something it grows by a frightening amount. The short version is that written code is the start of the journey, not the end. It's why we have entire frameworks (such as ITIL) to manage the services created. You may have paid someone to create the software - but then what?
I was going to write a series of thoughts to cover the second point. But then I discovered something fun - I've been writing on the internet long enough to be repeating myself. So here is me, nearly six years ago, writing about the pitfalls of outsourcing on my old work blog. It's worth a click - if only so they see a weird spike in traffic on an older post.
I find the thoughts there interesting for a few reasons. Firstly, the world hasn't really changed. At all. The fact that I'm writing this post is due to this approach still being seen as an easy solution, and still having some very dangerous long-term effects. The only point in there I think has improved is that Agile working with a supplier is a bit easier these days - although that might be a reflection of the difference in agencies operating in London and Bath.
Secondly, I find it interesting that I felt strongly enough back then to write a post about it. I was a developer, writing code and helping shape a university department. I saw problems with outsourcing, raised them, and when things happened anyway (and, despite the glib phrasing, I should make it clear that my concerns were addressed in the context of the department's priorities) I was one of the people who was saddled with the fixing and learning to make everything work.
These days I'm the Head of Software Engineering for GDS (for the moment at least) and I get to inflict that fun on other people. Or, more accurately, I get significant input into the operating model for the department - which means I need to make sure we're taking into account the points past-me made and ensure we're effectively taking them into account when considering how we build things. Because otherwise, I'm inflicting that fun on other people.
The magic bullet that is outsourcing rears its head every so often. Why worry about organisational capability and capacity when you can commoditize the process? Push some money at the problem and it goes away, right?
Well, no. Not even close. There are many problems fundamental with this way of thinking and for me they boil down to two key things:
1. Code is never finished
2. Effective and sustainable outsourcing is really hard
I'm going to write a separate post about the first point. Probably more than one - every time I sit down to write something it grows by a frightening amount. The short version is that written code is the start of the journey, not the end. It's why we have entire frameworks (such as ITIL) to manage the services created. You may have paid someone to create the software - but then what?
I was going to write a series of thoughts to cover the second point. But then I discovered something fun - I've been writing on the internet long enough to be repeating myself. So here is me, nearly six years ago, writing about the pitfalls of outsourcing on my old work blog. It's worth a click - if only so they see a weird spike in traffic on an older post.
I find the thoughts there interesting for a few reasons. Firstly, the world hasn't really changed. At all. The fact that I'm writing this post is due to this approach still being seen as an easy solution, and still having some very dangerous long-term effects. The only point in there I think has improved is that Agile working with a supplier is a bit easier these days - although that might be a reflection of the difference in agencies operating in London and Bath.
Secondly, I find it interesting that I felt strongly enough back then to write a post about it. I was a developer, writing code and helping shape a university department. I saw problems with outsourcing, raised them, and when things happened anyway (and, despite the glib phrasing, I should make it clear that my concerns were addressed in the context of the department's priorities) I was one of the people who was saddled with the fixing and learning to make everything work.
These days I'm the Head of Software Engineering for GDS (for the moment at least) and I get to inflict that fun on other people. Or, more accurately, I get significant input into the operating model for the department - which means I need to make sure we're taking into account the points past-me made and ensure we're effectively taking them into account when considering how we build things. Because otherwise, I'm inflicting that fun on other people.
