Bridging domains others avoid: mechanical to software, operations to computer vision, telephony to AI. Same systems thinking, different tools!
From rebuilding diesel engines in rural Brazil to architecting AI platforms serving tens of millions—this is a story of systems thinking.
I started working at age 8 in my father's truck mechanic shop in Xanxerê, a small city in southern Brazil. For 19 years, I worked on diesel engines, hydraulic systems, and pneumatic equipment.
This wasn't hobby work. It was full-time mechanical engineering in an environment where diagnostic manuals didn't exist and parts had to be fabricated rather than ordered.
Diagnosing why a diesel engine fails under load requires systematic elimination of variables—fuel delivery, compression, timing, electrical systems. This same mental model later applied to debugging distributed systems at scale.
As automation became more common in heavy machinery, I began working with PLCs, PIC microcontrollers, and early Arduino boards. I built digital controllers interfacing with mechanical, hydraulic, and pneumatic systems for wood processing equipment, tube bending machines, and food manufacturing.
The critical insight: Edge computing and IoT came naturally later because I was already solving hardware-software integration at industrial scale. The jump to cloud infrastructure wasn't abandoning mechanical work—it was taking the same systems thinking from factory floors to distributed platforms.
My mother recognized that physical labor, while honorable, limited long-term opportunity. She insisted I enroll in a three-year software development bootcamp while continuing to work in the shop.
This wasn't a gentle suggestion. It was a forced update—Mom.exe pushing a mandatory patch.
The bootcamp taught Java, SQL, and web development basics. The value wasn't the specific technologies—it was learning that software systems could be decomposed and debugged using the same systematic thinking I'd developed with diesel engines.
I earned a Bachelor of Technology in Information Technology and a Post-Graduate Specialization in Software Development with Java from Universidade do Oeste de Santa Catarina.
My first professional software role at NewFocus involved customizing ERP systems for industrial clients. This was the perfect bridge between my mechanical background and software development—solving the "last mile" problem of connecting physical operations to digital systems.
A wood processing company needed to track trucks leaving their premises and capture load weights automatically. I built custom ERP modules integrating PDA devices, industrial weighing scales, and real-time data pipelines. I wasn't just writing database queries—I was solving how to make factory floor operations visible to business systems.
At Nokia Siemens Networks, I built a personnel safety system for cell tower technicians using cellular triangulation before GPS was ubiquitous in mobile devices.
At Dell Technologies, I pioneered server-side JavaScript rendering in 2013—years before React SSR became standard practice.
At Zenvia Mobile, I dockerized applications when Docker was pre-1.0. I built L1/L2/L3 escalation procedures and a "FireFighter" on-duty rotation system that's still operational at Zenvia today, a decade later.
At AGCO, I built military-grade IoT security for agricultural machinery: sub-millisecond authorization using custom nonce calculation on mutual TLS with Erlang and RabbitMQ. Orchestrated autonomous machine-to-machine coordination for harvesters and grain carts using MQTT-based handshakes with sub-meter GPS accuracy.
In 2017, I moved to Berlin.
At PayU, I consolidated 14 markets' payment reconciliation—normalizing disparate formats from banks, merchants, and acquirers into serverless platform. 60% cost reduction.
At OSRAM, I architected zero-trust IoT security with OAuth 2.0 extensions and HSM-backed cryptography.
Then to Stuttgart at Mercedes-Benz.io. Multiple departments needed different views of vehicle data across the lifecycle. Legacy system required manual view creation and individual integrations per department.
My architectural insight: event sourcing. Unified vehicle state across all lifecycle stages, allowing any department to materialize their own view from the same event stream.
Built platform using AWS Lambda, containers, S3, DynamoDB, EventBridge, ElastiCache. Connected 60+ global systems, 47% cost reduction, deployment velocity from months to days.
The principle: One source of truth, infinite flexible views, no tight coupling.
I joined AWS in May 2020 as Senior Solutions Architect in Stuttgart, focused on Germany's premier manufacturing companies: BMW, Bosch, Siemens, Festo; implementing Industry 4.0 initiatives.
In October 2021, I moved to Austin as Senior Product Architect at AWS Industry Products, working on computer vision platforms. I invented the CVOps framework: extending MLOps principles to cover the entire computer vision lifecycle.
In October 2024, I became Principal Architect focused on telecommunications and generative AI, moving to Seattle.
My current work focuses on real-time AI-powered voice platforms: enabling generative AI interactions over traditional phone systems for major telecommunications carriers.
The technical challenge: Building systems that bridge 1970s telephony protocols (SIP/RTP) with modern AI inference platforms, maintaining carrier-grade reliability and real-time performance.
This is genuinely uncharted territory. When new AI capabilities emerge, I build working prototypes within hours to validate architectural approaches. These prototypes become the foundation for production systems spanning multiple regions, handling sub-100ms latency requirements at massive scale.
From 1994 to today—truck mechanic's shop in rural Brazil to architecting AI systems at global scale—the through-line is consistent:
Systems thinking applied to ambiguous problems with real-world constraints.
The tools changed—wrenches to keyboards, diesel engines to distributed systems, mechanical shops to cloud infrastructure, but the approach remained constant!
"The gap between demo and production is where I live."
Most architects can design for the happy path. The value is in knowing what breaks at 3am under 10x load with a team that's never seen the code.
Every distributed system is just another machine with predictable failure modes you can debug and prevent. The more complex the systems get the harder it is to predict, but never impossible!
I spent 19 years diagnosing mechanical failures without manuals. When a diesel engine fails under load, you don't guess. You systematically eliminate variables: fuel delivery, compression, timing, electrical systems. You decompose the problem until you find the constraint.
Software systems work the same way. The abstractions are different, but the physics are the same: latency is limited by speed of light, compute requires energy, energy generates heat, heat requires cooling. Every system has constraints. Find them.
Every problem has one constraint that matters most. Find it. Everything else is noise until that constraint is addressed.
In manufacturing, it's usually throughput at a specific station. In distributed systems, it's usually the slowest component in the critical path. In organizations, it's usually the decision that's blocked or the person who's overloaded.
Frame decisions so stakeholders can choose. Don't hide complexity. Expose it clearly enough that the right people can make informed tradeoffs.
"We can have consistency or availability, not both during a partition" is useful. "It's complicated" is not.
I love teaching. But not the kind that produces copies of the teacher.
Following Paulo Freire's thinking, I see education as a tool for liberation, not indoctrination. The goal isn't to make people think like me. It's to help them think for themselves.
Individual contribution doesn't scale. What scales is enabling others to solve problems you'll never see. The best architectural decisions are the ones teams can extend without you.
Today's architecture is tomorrow's legacy. Build systems that can be replaced piece by piece, not rewritten wholesale.
Event sourcing at Mercedes-Benz wasn't just about current requirements. It was about enabling views we couldn't predict yet. One source of truth, infinite flexible views.
One-way doors are decisions that are costly or impossible to undo. They deserve caution, analysis, and buy-in. Two-way doors are decisions you can reverse if wrong. They deserve speed and experimentation.
Most decisions are two-way doors mistaken for one-way doors. Teams slow down unnecessarily, seeking consensus for choices that could simply be tried and reverted.
I maintain a full workshop in my garage for building metal pieces. This isn't nostalgia. It's philosophy.
Pure abstraction without physical reality feels incomplete. The best software systems account for real-world constraints that pure software engineers often miss:
One lesson that stuck: never assemble without proof you're going in the right direction. I've mounted an engine back into the chassis only to discover I needed to pull it again for one oil retainer I missed. In software, this translates directly: don't merge without confidence, don't deploy without verification, don't architect yourself into a corner you can't back out of.
I don't design systems in ivory towers. For my current telephony work, I didn't just draw architecture diagrams. I built WebSocket servers, tuned GStreamer pipelines, debugged SIP flows, and solved jitter buffer timing issues.
Plans are hypotheses. Prototypes are evidence.
The pattern:
Technical problems are often organizational problems in disguise. A system that requires three teams to coordinate for every deployment isn't a technical architecture problem. It's a team boundary problem.
I come from environments where system failure had immediate economic consequences. Factory lines stopping. Trucks broken down. I build observability and failure recovery from day one. Not as an afterthought. Not as a "phase 2." From day one.
Process theater. Meetings about meetings. Documentation that no one reads. Ceremonies that don't produce decisions.
Premature abstraction. Three similar lines of code are better than a premature abstraction.
Architecture astronauts. People who design systems they'll never implement or operate.
"Best practices" without context. What works for Google doesn't work for a 5-person startup. Context determines correctness.
Clarity over cleverness. Readable code over clever code. Explicit over implicit. Boring technology over exciting technology.
Operational simplicity. Can someone debug this at 3am? Can a new team member understand it in a week?
Speed on two-way doors. If a decision can be reversed, make it fast.
Learning velocity. How fast can we discover what we don't know? Prototypes beat documents.
Team capability. Am I leaving this team better equipped than I found them?
The tools changed. The thinking didn't.
Principal Engineer | Principal Architect | AI & Cloud Engineering Leader
tiago@tiago.sh · LinkedIn · tiago.sh · Greater Seattle Area
I solve the architectural problems that keep organizations from scaling. Not theoretical problems—the ones where teams are stuck, leadership is worried, and the wrong choice costs millions or 6 months.
My pattern: Understand the constraint that matters most → Frame the tradeoffs clearly → Build proof that changes the conversation → Design for 10x the load → Enable teams to execute without me becoming the bottleneck.
Currently architecting telecom-native GenAI platforms serving tens of millions of concurrent users. Multi-modal systems (text/voice/image) where the real challenge isn't today's scale—it's building systems that evolve daily without platform rewrites.
I spent 19 years rebuilding truck transmissions before writing my first line of code. That's why I understand complex systems from first principles—every distributed system is just another machine with predictable failure modes you can debug and prevent.
Leading telecom-native GenAI platform serving tens of millions of concurrent users
Built AI platform reducing investigation time by 35% for major security companies
Transformed manufacturing with edge-to-cloud AI achieving 99.99% reliability