How I became a Group Digital Architect

📅 Posted 2020-02-15

A colleague at work asked me the other day:

How did you become a solution architect?

So I figured I might as well write about it. Of course, the usual disclaimer is relevant here: this is my story, your situation is probably different, this is not the only way, batteries not included, yadda yadda.

Technically my role is a Group Digital Architect, or at least that’s what I’m told I can use on my signature. So I’m not really a Solution Architect, but I’ll often introduce myself that way because it’s a much more familar job title.

Say what just is a Group Digital Architect, anyway?

More on this later. tl;dr: I’m still working it out.

Early Beginnings: Landscape Architect

It’s no secret in my family that from a very early age I wanted to be a landscape architect. In fact, I’m pretty sure I said I wanted to be one before I even knew a lot about what a landscape architect really does.

I never really had a ‘green thumb’ as such, but I did like to dabble in growing plants when I was a kid.

///// IMAGE

I also enjoyed drawing diagrams of gardens, so hey, why not.

///// IMAGE

With the help of my family I also managed to build a sign, for my non-existent business for my non-existent skills as a landscape architect.

Having proven I could fix random computer problems as a child (although we only got our first compuiter - a 486 - about 92) and once I had completed an IT-related university degree (mainly because most companies only seemed to employ people with the piece of paper, regardless of their skills), I managed to hook a job at Lendlease (then Lend Lease) thanks to a reference from one of my uni friends.

The technical path: Graduate Developer

By now you’ve probably worked out I was head on into the technical path. The job at Lendlease didn’t pay great but it definitely opened my eyes to terrible big “E” Enterprise software and complex problems that needed solving.

I guess I say ‘technical path’ here because the other common pathway into becoming an architect is more from the business analysis angle, which it still pretty technical as far as the world goes but definitely a lot more business-focused than someone churning out code for a living.

Solution Designer

This role is all about designing solutions! Ha! See what I did there? No but really, it is about marrying up potential options to meet certain business requirements and requires you to take into account constraints (technical, budget, legal, operational, etc.) and work out what is the most appropriate solution. This role is really project or initiative focused and yet still has a place in ‘agile’ methods because surely by now most people have realised that agile does not equal “no documentation”.

Estimation is another key aspect to being a solution designer, and it’s not necessarily always used to validate a solution, but more to refine project timelines and plans to make sure all stakeholders understand what’s involved, how much it will cost and when they’ll get something.

Solution Architect

Taking things up one level, an architect is a much more strategic role, less concerned about every little detail, but more concerned with the overall solution and how it fits into the ‘target state’ of where technology should head.

Engineering Manager

I was, shall we say, coerced into this role of looking after a group of technical people. At this point I had never managed anyone before and I would say it was a great experience, in the end, because I learnt many things. But really, although I love leading people in a technical capacity, I don’t enjoy developing teams nearly as much. Sure, I like to support people in improving their careers and getting the most out of people, but it’s not nearly as much fun as analysing complex problems and getting people on my side.

You can read more about this in my companion blog (which was written almost exactly 12 months ago): On being an Engineering Manager.

Group Digital Architect

This is my current role and It was one whichi I had the opportunity to craft myself, partly because the organisation really needed better technical strategy and partly because I was dead set keen on unlocking my time which was increasingly being consumed by people issues and recruitment!

I see this role as a pivotal function of any great digital product organisation.

Work across multiple projects, products, initiatives Analyse, solution options, present, standardise, workshop, build roadmaps Have empathy Spend time taking people through the thought process and workings Get people on board with your ideas Be a technical leader

Where to from here?

Well…

Final Thoughts

What I like about it

• Creative pursuit
• Working with practically everyone, in some capacity, across the division
• Building up deep knowledge about the organisation over time
• Getting paid to draw diagrams!

What I don’t like about it

• Constant context switching as I jump from one team to another, many times throughout the day
• The challenge of needing to know the technology without actively being “hands-on” everyday
• The future prospects are probably a more people-manager-route and less about playing with tech, if I never get bored of drawing diagrams (probably never)

Tagged

#careers #retrospective #technology

Comments (0)