Rebalancing the T: Deepening Hands-On Expertise to Become a Better Architect

For the last few years my calendar has been full of strategy reviews, architecture boards, and stakeholder briefings. The work matters, yet each step away from the terminal created small blind spots. I still jump into production fires and performance issues, but I lean harder on developers and platform engineers for routine detail: Helm charts, Terraform modules, pipeline plumbing.

That imbalance is common. Senior architects extend the horizontal bar of the T-shape, spanning domains and aligning roadmaps, while the vertical bar fades from muscle to memory. I have decided to change that.

Why climb down from the whiteboard

• Credibility with builders – teams trust architects who can pair with them, not just review their work.
• Sharper trade‑off intuition – cloud services evolve quickly; only hands‑on time reveals new limits and hidden fees.
• Future‑proofing – my background is heavy Azure, yet clients now expect multi‑cloud options and vendor‑neutral Kubernetes platforms.
• Personal satisfaction – I started by writing code and I miss the flow state that only a terminal prompt and a failing test provide.

What rebalancing looks like

I am not quitting architecture. I am adding disciplined depth work and using a public learning loop to stay accountable.

Phase	Certification	Goal
1	AWS Solutions Architect Associate (in progress)	Expand cross‑cloud design vocabulary
2	Certified Kubernetes Administrator	Ground rules for running clusters, networking, and workloads
3	Terraform Associate	Standardise infrastructure as code across clouds
4	GitOps Certified Associate	Modern, declarative deployment pipelines
5	AWS Solutions Architect Professional	Prove senior‑level depth in AWS
6	FinOps Practitioner	Tie technical choices to cloud economics
7	TOGAF	Embed it all inside an enterprise framework

Hands‑on project

I will build a practical incident‑intelligence platform.

Languages

• .NET for the core API
• Go for a high‑throughput worker
• Python for enrichment tasks
• React for an admin UI

Platform

• Kubernetes, first local, then AKS and EKS
• Terraform for cluster and service provisioning
• GitHub Actions plus Argo CD for GitOps

Observability and cost

• Prometheus and Grafana for metrics
• Kubecost for spend visibility

The goal is a living case study that exercises cluster setup, secure workload design, multi‑language pipelines, and cost analysis.

How I will share the journey

• Dev.to – long‑form posts on challenges, patterns, and failures worth dissecting.
• GitHub – code, diagrams, and run‑books for anyone who wants to reproduce the stack.
• LinkedIn – short reflections on why each step matters for architects and teams.

Readers will see the messy, valuable parts that rarely make conference slides: blind alleys, rewritten YAML, and the forgotten load balancer that bumps an AWS bill.

Invitation

If you feel the same drift or you are curious about the ground‑level view, let’s compare notes. Comment on Dev.to, file an issue on GitHub, or send a message on LinkedIn. The more perspectives we share, the stronger our collective T‑shapes will become.

Time to trade a bit of whiteboard altitude for the grip of a terminal prompt. See you in the trenches.