Government technology boring? Not from where I’m standing.
After years working in the fast-paced mobile sector, I was anxious my new government job as a technical architect might be boring. I was worried about bureaucracy, and having to work with out-dated technology.
As it turns out, my worries were in vain – joining GDS has been a bit like joining a great rock and roll band, but without the wrecked hotel rooms. (I spent a number of years in the music industry when it was at the vanguard of digital change; being personally involved in the transition from analog to digital).
Not only do most people wear a t-shirt at GDS; people just get on with their jobs, creating things that are wonderful. GDS talks about ‘showing the thing’ (a line you’ve probably heard by now if you read these blogs often), and my role on the tech side is to help make this happen.
Why I'm here
I’m here to make sure government stories are a success, using my years of experience within the technology sector. As a consulting architect, I’m to bridge the gap between GDS and other departments and agencies, helping communicate best practices.
It’s my job to help define and design government systems and processes to meet user needs, and this involves making sure all stakeholders are on the same page.
Finding my feet
My first couple of weeks were spent being brought up to speed on the way GDS does things. The biggest eye openers for me were the Service Assessments and Spend Control reviews. I’d have thought these were just guidelines services had to meet, but it’s a lot more rigorous than that. As an observer invited to watch a number of assessments and reviews in action, I quickly realised how seriously these quality controls are enforced.
No public service is allowed to go ahead if it doesn’t meet user needs.
Following those first few weeks at Aviation House (the home to GDS), the time came to let me out into the wild (well, it did feel like a bit of an adventure). I wasn’t let out all alone, but with an experienced technical architect, Dafydd Vaughan, to a number of government departments and agencies.
Setting standards
I’m here to help them work within certain government standards such as the Digital by Default Standard. For instance, I will work with service teams to help them pass the alpha, beta, and live assessments, and advise them on discovery and technical options.
Many departments and agencies are already doing an impressive job of transforming their technical architecture to meet government-wide standards but, often, like many big things some can’t move as quickly as they’d like. For example, they have legacy systems that aren’t easily uprooted. It’s important to understand these challenges; developing and maintaining positive relationships with teams is vital when it comes to transformation. You can’t just march in and tell people what to do; we can all learn from each others’ expertise.
Sharing the driving seat
One of my assignments is at the Driver and Vehicle Standards Agency (DVSA), which is located in Bristol across a number of distributed sites; for me the most interesting one has to be the old coach testing station (it looks like a garage inside with meeting rooms around the sides of the building - a great use of government property).
Part of my job there is to look specifically at how driving services can be transformed by the arrival of Government as a Platform. For example, the whole experience of buying and selling a car involves tons of transactions with government, a process that can almost certainly be streamlined.
Working with a user needs researcher, I’ve looked at how this streamlining can be achieved by analysing user experiences. We interviewed the owner of an MOT station, and drivers who had bought and sold vehicles. We learned about their interactions with the government and existing systems, and how these can be improved for better use. For example, a young woman involved in a accident had her car written off. As a result, she had many separate interactions with government, disposing of the car, getting the tax back, acquiring a new car, taxing that, and then dealing with all the relevant changes of ownership. Wouldn’t it be wonderful if she could do one or two combination transactions instead?
It's all about user needs
The focus GDS puts on user needs resonates with my own approach to improving systems. I’ve always taken a user-centric approach to their design and delivery. When it comes to a technical architect’s other must-have traits, I’d say you need:
- a good understanding of technical architectures and how different systems glue together
- flexibility and the ability to understand any programming language
- empathy to understand what different stakeholders are dealing with
- the ability to easily adapt to different projects, eg, you may be talking about electronic licensing one minute, and then to an MOT owner about how a system works the next
- diplomacy and the confidence to challenge deep seated ideas
- a whole lot of diligence and endurance
Above all you need a desire for change. Government technology has had a poor reputation for being slow, inefficient, and full of mammoth IT projects. The Government Digital Service has spent the last few years working with departments to change this, and since joining two months ago, I’ve got a first hand taste of how challenging this shift really is.
Stay tuned for more from us on being a technical architect at GDS.
Follow John on Twitter, and don't forget to sign up for email alerts.
