Most universities are in that group of organisations that live long before the internet era began. Many were at the forefront of the technology behind the internet.
Did that mean they got their web-presence spot on and ran with it?
No, it was the opposite.
They started with no strategy, no governance and little regard for the ongoing management involved.
That means for me, right now, delivering front end solutions fast and at scale is not happening. We drown in technical debt across so much of our infrastructure.
Did you say technical debt? *COUGH* Sorry I was just sick in my mouth
“Technical debt” is the sort of thing I hate saying and get laughed at when I do (among a worrying number of other phrases…). I’m now trying to refer to any tech debt work as “maintenance”.
Recently I’ve been working on a project to align all our public facing website to be within a Design System. This has meant a lot of re-coding and tinkering with the design to… well, make everything look exactly the same as it does now.
This is not sexy. It’s boring and gets shrugs when I tell people about it. But, trust me, it is valuable.
Putting down the Content Design handbook
I feel for the team who are migrating content from old to new. It’s not improving the content. Also, it’s a semi-automated process, so some of the things we switch over to the new world needs a bit of manual intervention.
When it comes to poorly created content (which is frustratingly widespread with our devolved publishing community) we sometimes have to grit our teeth, look the other way and just recreate it.
We’re trying to balance that with making content improvements, but when that requires sign off and stakeholder management, it’s not always straightforward.
We’re in the business of getting all content to a future maintainable state fast so the future development gains are realised as soon as possible (can’t believe I just wrote that). It’s not about fixing every bit of content as we go. And that’s a big, nasty, bitter pill to swallow. I know that time will come, but it can’t come now.
R.O.why?
I think the return on investment here is huge. Working on our technical de… *ahem*… maintenance work schedule will enable us to make changes quicker in the future by:
- Not worrying about applying the same design change in several templates
- Stopping running multiple training variations across each permutation of legacy content types
- Not having to think about how to design that same old drop-down box or module
- Having a focus on one code base to fix accessibility and performance issues
The less I say “we need to work on our technical debt” and just say “our maintenance work is needed, as it will enable us to…” then the easier this will be to grasp.
I can measure success by reducing number of eye-rolls I get by 50%.
John Bourne 