Many times a tech lead isn't about being the smartest or most knowledgable person in the room - it's about getting your team, your boss, other departments on board with a plan and executing. In some environments it may be that you have to be the sharpest depending on the team you're given, but often times it's best to be the most judicious and compassionate. Think of it more like being a mini-manager - perhaps 30% management (where you're like an extension of your supervisor) and 70% software. Also be prepared to bring your boss into issues you may have with external teams/organizations, but try to shield your team itself from that activity. Be prepared to handle considerably more email, process work, signing of documents, etc.
I'm going to share a personal story - it might not have much directly actionable advice, but it may give you some thought on how to approach this strategically.
I spent about 15 years as well on windows software for enterprise health care systems (starting back in VS6 C++ days back in the late 90s) before jumping ship to do Rails development a few years ago.
Right around the 10 year mark in my career I was a run of the mill sr. dev... the only 'lead' experience was on a couple projects, rarely with more than another dev and most of the time solo. I just never really had much confidence in my skill set as a whole, esp. when it came to telling other devs what to do. In 2009 as a 33 year old I felt pretty deflated and was considering a career change. One thing I caught wind of was this book called "The Passionate Programmer" by Chad Fowler (not related to Martin). It was ~200 pages, and it was separated out into 50 or so little chapters of tidbits of mostly, well, soft skills, but also general career advice. I absolutely loved it and finished it in an evening.
In short order a whole bunch of things about my working style changed, not only my demeanor working with other engineers, but key key people in other departments in the projects I worked on(ie. QA, System Engineer, Documentation, Product, Project Management). Ultimately I realized at that particular organization the biggest problem was that departments were silo'ed a bit too much, and as a result schedules slipped because coordinating resources was always a challenge.
Six months after reading the book I was given a lead role on a medium sized project at that company (had 6 engineers on the team and about 20 people working on it for 9 months, ~$15M per annum, 300k LOC over the prior 10 years). One of the engineers who reported to me during on that project was one of the 2 Fellow Engineers at the company (3 titles above mine!). It went well, and my next review had a recommendation from my supervisor to go into management. I politely declined and a few months later was promoted to a principal dev.
One of the reasons why I believe this worked so well was 1) I did underestimate my skills as a whole - I was not the best, but I was certainly good enough that my suggestions held weight and I felt ok with admitting to things I didn't know and delegating 2) I had, as you say, seen other people in this position and already knew what success and failure looked like. I wasn't just given a position as a lead, I had assumed it to some degree on another project I was on at the time (not entirely and not to usurp the authority of the actual lead, but I just became helpful on things that needed to be done but were getting brushed aside, esp. things that were important to other departments). And as such, people started to pay attention to what I was saying.
It sounds like you think it's slated toward being an architect. It can be, but many times it really isn't - you may want to delegate that overall to the stronger members of your team and help them work through the process - be the person who asks questions and helps poke holes. Give the most challenging work to your brightest people. Isolate the more 'dangerous' members from mission critical stuff, and if they have the passion and smarts but they're just a bit misguided give them a nudge of encouragement in the right direction and challenge them accordingly. Pay attention to your devs' key strengths and delegate accordingly, but also remember to provide a degree of work that is challenging and exciting.
So that's my advice - check out that book. It's a quick read. It is about 6 years old now but the advice is mostly generic. Try to put some of it to effect in your current job... assume the role where you can. Even if it's just a week or so, I think the best practice is actually trying it out in real life.