Staying Technical: The Architect and the Engineer.
It’s Important to Understand the Business, but Above All, Know the Tech.
Do you know how hard it is to get Midjourney to generate this exact image but with brown people? Let’s just imagine that Architects and Engineers can also be brown 😂
Talofa, Reader,
After a hectic period of work travel and exotic stress over the last several weeks, which resulted in a long post about burnout, I was fortunate enough to find the time (evenings, weekends, in airport lounges, and on crowded plane seats) to study for, and last week, pass, my AWS Certified Security - Specialty certification.
Staying technical, even as an Architect, is important — not just to the role, in my opinion, but also to me personally.
And I don't mean "book" technical like "draw me a diagram".
I mean hands-on, build-the-thing-you're-talking-about, technical.
In an article she wrote earlier this year titled "Architects, Anti-Patterns, and Organizational Fuckery", the one & only Charity Majors laid down the gauntlet, stating that she believes "Architect" is a bullshit role.
For the most part, I agree with her.
Funny story, I never much liked Architects when I was coming up in tech.1
They always seemed like they knew everything and could recite how things should work.
However, they could never say for certain how the thing we were looking at actually worked, because they were usually more about theory and diagrams.
We, the lowly systems engineers, were at the coal face, painfully aware of how the thing usually didn't work.
It was okay for those who didn't have to hang around late to fix a broken environment, or get paged in the early hours of the morning to get things back online.
This isn't to pick on Architects. I thought several roles in many organisations were also bullshit.
My point is the significance of the relationship between the technologist and the technology.
When someone is a certain distance away from the hands-on building of the software or the system, their perspective and experience is also that far removed from the details of the system.
You could get into a few theoretical and philosophical discussions about it, but how much do you really know about a solution if you've never built it?2
There's a big difference between following your finger on a map and hiking the trail from that map, in saying you know how to get from A to B.
When you've been through something yourself, it's different.
You've felt it in your bones.
You know how long the machines actually take to start up. You know the pain of software compile times and tests that run for ages and then fail. You know the real pain of a command output saying your script has an error but can't tell you which line it's on, and you find out it was just a f****ng indentation issue.
I fired up an AWS Managed AD instance last night.
The instructions said "this will take 20-40 mins to start", which is a very different expectation from knowing I can fire up most EC2 instances in minutes.
But now I know, because I've been there, done the thing, and bought the t-shirt.
There's a connection to the experience of doing something that lends the doer an understanding you can maybe extrapolate into words. Someone else might intellectually understand what it's like from reading those words, but they won't ever get the full picture, the immersive full-body experience you get when you do the thing yourself.
There's this other thing that happens as well.
When you do a thing and have a lived experience of the thing, just like gaining a new in-game treasure - you gain empathy.
Empathy is that deep "knowing" of the thing, so that when you see others going through it, or know they might go through a thing you've been through, you see it through a lens of understanding, not judgement.
Charity's article was less about trashing Architects and more about pointing out the understanding that exists for those folks who "do the thing", build the software and systems.
This is why I believe as an Architect, you stay hands-on, you stay technical because it builds the empathy that connects you to the people you're trying to convince to use this technology.
The same way learning a language, or living in a different country, builds this empathy and understanding between things.
It builds connection.
So, I stay technical. It's not easy - nothing worth having is, right?
A role like Solution Architect is customer-facing. It deals with not only technical subjects but also understanding business development, sales, marketing, and more human-related dynamics than, say, a software or DevOps engineer.
Studying for certifications and doing hands-on labs wherever I can helps.
It also helps that AWS requires and encourages ongoing study, training, and certifications as a part of my role.
Having a digital garden for documentation and technical write-ups, and a GitHub with a bunch of unfinished projects, also motivates me to work on things. But at the end of the day, you really have to figure out how to sit down and learn stuff.
I set up a whole-ass Twitch stream as a productivity hack for studying for my OSCP.
I believe staying hands-on technical makes for the best Architects. Also, because I'm a geek, I just like learning and being good at computers.
So, go out there, get your hands dirty, feel some pain, learn a few things and connect with your inner computer geek.
Thanks for reading - see you in the next one.
If you genuinely found this post interesting, please give it a ❤️ to let me know 🙏🏽
Learning
Things I’m actively studying or learning this week…
Toss up between Solution Architecture Pro Study, or CKS re-certify study.
Building
Things I’m building or working on this week…
AWS Managed Microsoft AD - hands-on workshop labs.
A small Golang Microservices Demo
Interesting Reads
Articles or other writing that stood out to me this week…
Nothing much read this past week.
Community
Other projects in community I’m working on…
Pasifika Tech Education Charity - Providing Tech Learning Opportunities for the Pasifika Community.
Pasifika Tech Network - A Network for Pasifika Tech Professionals & Learners.
not you lot at AWS, you’s are alright 😉
yes, I know we don’t have unlimited time or resources, an Architect is hardly going to build an entire Production-scale environment to make this point.