A leader's identity determines whether they solve problems hands-on or build systems. The speaker walks through a diagnostic: assess yourself on value source, best day, worst day, and response under pressure. Moving from operator to architect feels awkward and threatening because it lacks the immediate dopamine of individual wins, but a CTO who practiced coaching for months eventually built a team that surpassed her capabilities.
Identity is kind of the anchor that holds all of the behavioral changes in place. So look at this table and figure out which column describes you on most days, not on your best day, but on most days. Value source. Do you derive value from what you personally produce or from what you enable the organization to produce? Best day. Is your best day the one where you solve the problem nobody else could? Or the one where a major problem got solved and you weren't even involved? Worst day. Is your worst day the one where someone on your team failed at something you could have done? Or the one where you spent all day doing work that should have been delegated? Under pressure. Do you step in, take over, and deliver? Or do you clarify the system, reinforce the boundaries, and let the team work? And here's one that's a good idea to sit with for a few minutes. What do you brag about? When you tell a colleague about a win, are you describing the deal you closed or the crisis you resolved? Or are you describing the team you built and the system that runs without you? Here's what the research on identity transition tells us. You don't just magically flip a switch from operator to architect. It's kind of more like trying on a new suit. You practice architect behaviors before they feel like you. There's a period where it feels awkward, maybe even threatening, because the operator identity has been paying off for your entire career. And that, that is normal. You're not going to wake up one morning and just like feel like an architect. You have to act like one long enough that it starts to feel natural. You know, I've seen this play out hundreds of times. I think of one where the CTO came up through engineering, right? Brilliant coder, could debug anything. Her best days were the ones where she could dive into the code base and fix a critical production issue that just, you know, nobody else could crack it. But when she became CEO, she kept doing it. The team would hit a hard bug, she'd take over the keyboard. Engineers loved it in the moment because, you know, the problem got solved, right? It's like watching a magician work. But over time, they stopped trying to solve the hard problems themselves. Why would they, right? Because you got this brilliant CEO— sorry, CTO— who would step in. And it ended up taking almost a year of deliberate practice to stop touching code. And start building the engineering systems and mentoring systems that would make the team capable of solving those problems without her. I remember saying that the first month was like physically painful. You know, she could see the bugs, she knew the fix, and sometimes she would like literally sit on her hands and coach instead of code. I've seen CEOs, for example, do this where they will literally sit through a meeting and do something like this, like where they are literally like pinching their lips closed just to make the other executives start answering the questions. But, you know, in this case, by month 6, the team was solving problems that she might have been not able to solve herself because they built capabilities that, you know, as things were changing, right? Code advances, keeps speeding up, blah, blah, blah. And they actually started to surpass her, but that's the architect payoff. And you don't get there. You have to go through that first kind of painful month where you're sitting on your hands or pinching your lips shut. But after a few months, then they do start to take it on and they build up those capabilities that, yeah, okay, now the team is actually capable of doing things. They've started to make advancements that maybe we wouldn't have been able to make. There's one more reason why this identity shift is hard. The operator identity is safe, right? You've been validated as an operator, let's say, pretty much for your entire career. When you step into the decision chair and you personally solve a problem, like you jump into the midst of it and you get your hands dirty, right, you get a dopamine hit of competence. You get the recognition, you get the certainty that it was actually done correctly, right? The architect identity though is uncertain. You don't know if you're good at building systems yet because the feedback is delayed and the results are pretty diffuse. Also, oftentimes nobody gives you a standing ovation because your team made a decision without you. And then when the stress hits, you know, there is all of that tendencies we've talked about to revert. And that's just how this tends to go. New identities are fragile until they're practiced enough to become default.
