Working with the CEO

Close Enough to Influence, Independent Enough to Be Honest

Carmel, USA – Photo by Kevin Goldsmith – April, 2026

Recently, four people I mentor brought me different versions of the same problem in the span of a few days. One CTO was dealing with a founder-developer who still had strong opinions about how software should be built. Another had an operator CEO who was hands-off on technology until something broke, at which point they overreacted. A third had just discovered that their CEO was making decisions affecting their team without consulting them. And a fourth was trying to figure out how to respond to a CEO who had vibe-coded a prototype and couldn’t understand why the engineering team needed more than a few days to build the production version.

Stepping back, there are some familiar patterns here: each scenario involved a disconnect between the CTO and CEO on expectations, communication, and decision-making. Whether the CEO was too hands-on, too removed, or making unilateral decisions, the shared challenge was finding the right balance of influence, alignment, and honest partnership. These patterns are common for technology leaders, and recognizing them early helps you map your own challenges and approach.

Four people. Four different situations. All with the same core question: how do you build an effective relationship with your CEO?

This led me to reflect on my own experiences. I’ve reported to about half a dozen CEOs across companies of different sizes and stages. Every one of those relationships was different in ways that mattered. Not just because of personality, but because of what the CEO cared about, what they expected from me, and how much room there was for honest disagreement. The lesson that keeps coming back is that this relationship is something you have to build deliberately. It doesn’t just happen because you’re both competent.

Why this relationship is different

To understand why these relationships are challenging, consider how the CTO-to-CEO relationship is asymmetric, setting it apart from other working relationships. The CEO hired you (or chose not to let you go when they joined). They can fire you. They set your compensation. They determine how much room you have to operate. That part isn’t different from any boss-employee dynamic. But they also depend on your judgment in domains they often can’t evaluate themselves. They need to hear things honestly from you. And they have very narrow windows into your part of the organization: a weekly one-on-one, a staff meeting, maybe a few ad hoc conversations. That’s it. What they understand about your world comes almost entirely through what you choose to surface.

You need to be close enough to influence, independent enough to be honest, and aligned enough to execute even when you disagree. If you’re too close, you become a yes-person and stop adding value. If you’re too independent, you look like you’re running your own company inside the company. If you suppress every disagreement in the name of alignment, you let the company make avoidable mistakes.

When this relationship breaks, it rarely stays contained. The exec team senses it. The board senses it. Your directs sense it, and they start hedging. If the CRO sees you disagree with the CEO and still get respected, they’ll feel safer doing the same. If they see you get shut down, they learn to keep quiet. The CTO-CEO dynamic models what honesty and partnership look like for the entire leadership team.

Different CEOs, different problems

Each CEO has distinct attitudes and preferences, which present unique challenges. However, CEOs can be grouped by shared traits, which create distinct dynamics.

The founder-developer CEO still has strong opinions about how things should be built. When your CEO built version one, they have opinions wired differently than those of a CEO who came up through sales or marketing. Some of those opinions are gold. Some of them are artifacts of how they used to build things. Your job is to figure out which is which without being dismissive. I’ve worked for a founder who was a brilliant product mind and an exceptionally fast developer, but whose approach to building code worked well for a solo builder and wasn’t something you’d want to build an engineering organization around. Navigating that meant figuring out which areas they cared deeply about and which areas they’d acknowledge they didn’t know well. You push forward where you have room and tread carefully where you don’t.

I also worked for a founder-developer CEO who was very narrowly technical rather than broadly so. Deeply knowledgeable in specific areas, but without a full picture of the platform. That created a different challenge: they felt qualified to weigh in on technical decisions, and in their areas of depth, they often knew more than I did. In those areas, I deferred completely. In the areas where they didn’t claim expertise, I had more room to work.

The operator CEO, as is most common in my experience, is hands-off when it comes to technology. That seems freeing, but it isn’t. These CEOs lack context to judge severity, timing, or reasons for failures, and swing from ignoring problems to overreacting. A surprised CEO makes poor decisions. With this type, proactively build context: provide regular, concise updates, link technical health to business outcomes, and alert them before problems escalate.

Visionary CEOs, usually founders, bring constant new ideas and a strong drive for innovation. Their entrepreneurial mindset fuels company growth, but following every idea can drain focus from the core business. If you always say yes, you’ll be overwhelmed; saying no all the time may sideline you. Find areas to invest in, leveraging credibility so you can advise the CEO when an idea isn’t feasible right now.

The challenge isn’t finding the ‘best’ CEO type. The real test is recognizing who you’re working with and intentionally adapting your approach to make the relationship work.

The four foundations of CEO trust

Every successful CEO relationship I’ve seen shares four key foundations: competence, candor, commitment, and context. These consistently determine whether the partnership is strong or fragile.

Competence seems obvious, and technical leaders often assume it. But to a CEO, it’s not just technical depth. It’s your ability to translate technical details into business reality, deliver results, and spot problems early. CEOs judge competence by outcomes, not by engineers’ standards.

Candor is the hardest foundation to build and the easiest to lose. CEOs are surrounded by people who have incentives to shade the truth. If you become one of those people, you lose the thing that makes you most valuable. But candor without judgment is just complaining. Candor means: here’s the real situation, here’s what I think we should do, and here’s what I need from you. It also means telling the CEO when they’re wrong in your domain, and doing it in a way they can hear. Privately. With data. With a proposed alternative. Not in front of the board. Not in a group setting.

Commitment is what separates senior leaders from everyone else. Disagree and commit is easy to say and genuinely hard to do. It means your team never hears you undermine the decision. It means you run at it with full effort, not with one foot out the door waiting to say, “I told you so.” If your team can tell you disagree with the decision you’re executing, you’ve already failed the commitment test. Your behavior teaches the organization whether decisions are real or negotiable.

Context is the one most people miss. Competence, candor, and commitment can all be undermined if you and the CEO are operating from different mental models of how the business works. Building context means constantly translating between the engineering and business worlds. “We need to replatform” means nothing to most CEOs. “Our current architecture limits how fast we can ship features customers are asking for, and that’s contributing to churn” means everything. Building context goes both ways, though. You need to understand what the CEO is dealing with that you don’t see: board pressure, investor expectations, competitive moves, and how the rest of the exec team is pulling on them. When the CEO makes a decision that seems wrong to you, the first question to ask is: What context do they have that I don’t?

Making the relationship work day to day

Weekly one-on-ones with the CEO are non-negotiable. Protect them. If the CEO cancels frequently, that’s a signal you need to address directly. Use that time to pre-wire. Nothing that comes up in a staff or board meeting should be the first time the CEO hears it from you. Lead with conclusions, not context. Tell them what you think, then offer the supporting detail if they want to dig in.

Handle disagreements deliberately. Raise concerns before decisions are made. Bring data, not just opinions. Frame feedback as “here’s what I see and what I’d advise” instead of “I disagree.” If overruled, commit fully. Execute as if it were your idea. If it fails, you’ll have standing to revisit, having genuinely tried.

I learned about handling disagreement the hard way. At one company, I saw us heading in a direction I disagreed with. I raised my concerns. They were heard. We kept moving in that direction. I continued advocating until another member of the exec team pulled me aside and said, “This one’s over. This is the way we’re going now.” I hadn’t read the room. The decision had been made, and I was still arguing. I had to shift fully into execution mode, and I should have gotten there sooner.

Watch for the strategic vacuum. If you’re the only person on the exec team thinking past the current quarter, writing strategy documents, doing competitive analysis, pushing the team to plan for what’s coming, that’s both valuable and dangerous. Valuable because somebody has to do it. Dangerous because if the CEO isn’t co-owning that work, it can create resentment on both sides. If you’ve come from companies with more structure and you’re now at a place that doesn’t operate that way, the instinct to fill that gap is strong. But your current company exists because whatever they’ve been doing has worked for them so far. If you feel yourself becoming the lone operator, surface it directly: “I notice I’m driving a lot of the longer-term strategic thinking. I’m happy to do it, but I want to make sure we’re aligned on that being part of my role.”

When trust is eroding

By the time most leaders recognize that trust has eroded, it’s often too late. Here are the signals.

Signs the CEO is losing confidence in you: they start asking your directs for information instead of you (and not in the healthy way where you’ve pre-wired those relationships). They bring in outside advisors or consultants for things that should be your responsibility. Your one-on-one gets shorter, less frequent, or more transactional. You find out about decisions affecting your team after they’ve been made.

Signs you are losing trust in the CEO: you start building a case file of bad decisions, collecting evidence for an argument you haven’t made yet. You explain the CEO’s decisions to your team in ways that distance you from them (“the CEO wants us to” instead of “we need to”). You spend more energy managing around the CEO than working with them. You stop bringing up problems because you don’t think they’ll be heard.

If you catch yourself translating the CEO’s decisions into something your team can stomach, the relationship needs attention. You’re not a translator. You’re supposed to be a partner.

Understanding the human side

Most CEOs at growth-stage companies are under a lot of pressure from the board and investors that the rest of the exec team doesn’t fully see. They’re being evaluated quarterly. When a CEO takes a struggling function under themselves or suddenly elevates the priority of something that seemed peripheral, it’s often because that issue has reached the board level or they are concerned it will if it isn’t handled.

Understanding that pressure doesn’t mean excusing bad behavior. But it does mean adjusting your approach. A CEO isn’t going to blame the board, just like you aren’t going to blame the CEO to your team. If you sometimes see unusual behavior or weird pressure, there may be something going on that you don’t have visibility into. The best CEO relationships I’ve had are those in which the CEO trusted me enough to say, “The board is aware of this, and they’ve raised the priority.” Even when they can’t share that, recognizing the possibility changes how you respond.

When it’s time to go

Sometimes the relationship can’t be fixed. If the CEO consistently overrides you in your domain without engaging your reasoning. If your values don’t align with how to treat people or make decisions. If you’ve surfaced the issues directly multiple times, and nothing changes. If you’re staying because of inertia or compensation rather than belief in the direction. Those are signs of a role fit problem, not a relationship problem.

If you’re not that far gone, repair requires both sides. Be direct: “I think our working relationship isn’t where it needs to be, and I’d like to talk about what we can do about it.” That is a very hard sentence to say, but it is the only honest one. Propose specific changes. “I’d like us to use our one-on-one to pre-wire any staffing or budget decisions before they go to the broader team.” That’s actionable. “We should communicate more” is not. If you agree on specific changes, give it 90 days of real effort before deciding whether it’s working.

If you’ve done the work and the trust still isn’t there, leaving is a reasonable decision. It’s not failure. It’s recognizing a fit problem. The worst outcome is staying in a broken CEO relationship and letting it erode your judgment, energy, and your team’s trust. And if you’re feeling that the trust has broken down, they’re feeling it too. Every CEO I’ve worked with, when that alignment is gone, they’re already thinking about who comes next. By the time you’ve decided it’s not repairable, they’ve probably already made that decision and may already be interviewing.

What I got wrong early on

Earlier in my career, I thought the CEO relationship was mostly about competence. Deliver results, and the relationship takes care of itself. That turned out to be incomplete. Competence is table stakes. The relationship lives or dies on candor, commitment, and shared context.

I also used to think that disagreeing with the CEO was inherently risky, something to be done sparingly and carefully. Over time, I learned that the opposite is true. A CEO who doesn’t hear honest pushback from their CTO is flying blind. The risk isn’t pushing back. It’s not pushing back. You just have to do it the right way.

Working with founder-developer CEOs taught me something specific. Their technical opinions aren’t obstacles to manage. They’re signals about what the CEO values. Learning to distinguish between “I built this, and I’m attached to it” and “I’ve been watching customers, and I see something you don’t” made me a much better partner to founder-CEOs.

The CEO relationship is the highest-leverage relationship in your career as a technology leader. It determines your scope, your influence, your ability to protect your team, and whether you can do the job you were hired to do. If you want a starting point, ask yourself four questions before your next one-on-one: Does the CEO hear the truth from me? When we disagree, do we have a reliable process for working through it? Do I understand what they’re dealing with that I can’t see? And does my team see a partnership when they look at us, or a hierarchy?

If the answer to any of those is uncomfortable, you have work to do. And that work starts with you.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Working with the CEO: Close Enough to Influence, Independent Enough to Be Honest.

Originally published in my newsletter at: https://kevingoldsmith.substack.com/p/working-with-the-ceo

Making Technology Choices That Last

Every few years, a new wave of technology arrives, and people in our industry start to declare that everything is about to change. Right now, that wave is generative AI. A few years ago, it was Web3. Before that, mobile and public cloud. Before those, the web itself. Some of these shifts turned out to be genuinely transformative. Others didn’t.

Having lived through enough of these cycles, I have learned that the excitement and fear are always the same. The hard part is never knowing in the moment which changes will last. The other hard part is that, as technology leaders, we have to make decisions about them anyway. Should we adopt this new thing? Wait it out? Ignore it? Every one of those choices comes with a cost.

AI is the current case study, but the real question is broader. How do we make technology choices at all? How do we separate what is genuinely important from what is just noise?

Curiosity with Discipline

Being a technical leader involves staying curious. You have to pay attention to what is happening in the industry. That means reading, listening, and talking to peers. You cannot afford to ignore change because sometimes it is not a fad at all. Sometimes it is the thing that allows the next generation of companies to surpass your company.

Hopefully, you don’t see this curiosity as a burden. You chose a career in technology, after all!

But curiosity alone is not enough. There has to be discipline behind it. I have seen teams that refactor constantly, switching frameworks every few months or adopting tools that promise faster builds or cleaner syntax. They expend a great deal of energy and end up standing in the same place. It is easy to confuse motion with progress.

The goal is not to be early. The goal is to be ready when it matters.

Knowing When to Pay Attention

When something new appears, the first question is not “should we use it,” but “should we even pay attention to it?” Most technologies take a while to prove themselves. They start with hobbyists and early adopters. Then you begin to hear about them in conference talks and blog posts. If you start to see teams you respect using it, that is a signal to look more closely.

There are exceptions. Sometimes, a new tool or framework solves a problem that nothing else does. If it unlocks something meaningful for your business or team, consider taking the risk of early adoption. But most of the time, patience pays off. You want to see that a technology has a community around it, good documentation, and some stability. You want to know that if the creator moves on, the thing won’t go away.

I have seen open-source projects from large companies become popular overnight, only to discover that they were designed to address those companies’ unique constraints. They required more effort to maintain than smaller teams could afford. The code was free, but there was a hidden cost in maintenance. Before adopting the new tool, ensure you are familiar with its operation and can use it efficiently.

Use the Curiosity Around You

You don’t have to do all the exploration yourself. The best engineering teams already have people who watch the industry and bring new ideas. You can turn that energy into a system.

Give people permission to explore. Encourage them to read, share, and experiment safely. Create a channel or regular forum where developers can showcase their work, whether it is a side project or a prototype. It shows them that curiosity is valued, not something to hide until after work hours.

You can tell a lot about your team’s culture by how it reacts to experimentation. If people are afraid to try things, they stop learning. If you reward them for exploring ideas responsibly, you build a team that continues to grow even when the company is stable.

Let the eager ones go first, but set boundaries. They should know what kinds of experiments are helpful in the business. Guide their curiosity. The best developers don’t need permission to learn, but they do appreciate direction.

Evaluating What You Find

When something looks promising, that is when leadership really matters. You have to evaluate it in a way that balances technical interest with business sense.

Start with questions:

What problem does this solve for us right now?
Is it mature enough for the scale and reliability we need?
What are the maintenance implications?
Who else is using it successfully, and what can we learn from them?

Build a small proof of concept. Keep it outside production at first. Compare it with what you already have. Measure performance, stability, and effort. Run it in parallel with your current solution so you can see real data before committing (shadow testing).

This part takes patience. It is easy to fall in love with a clean new abstraction or a faster benchmark. But the actual cost of new technology is rarely visible at the start. The hardest lesson I have learned is that the adoption work is always more expensive than it looks. The second-hardest is that we almost always underestimate the maintenance cost.

If possible, discuss with peers at similar companies. Ask them what happened when they tried it. Did it actually deliver value? Did it hold up? You can save months of effort just by learning from other teams’ experiments.

Managing the People Side

Every new technology comes with human change as well. Some team members will be excited. Others will resist it. Both reactions are normal.

The eager developers will show up ready to rebuild everything in the new tool. The skeptics will say there’s no need to change what already works. Both have a point.

Your job is to balance them. Channel the energy of the early adopters toward solving real problems. Give them structure and goals. At the same time, acknowledge the fear of the skeptics. For many engineers, expertise is tied to identity. When you replace a system they know deeply, it can feel like erasing years of experience.

Pair the enthusiasts with the skeptics. Let them learn from each other. Measure the results and share them openly. When the experiment works, celebrate the outcome. When it doesn’t, celebrate the learning. What matters is not whether every experiment succeeds, but whether the organization learns at a faster rate.

You cannot let your early adopters run wild, but you also cannot let the cautious ones stop progress. Most of the time, the right path sits somewhere between.

How to Adopt Deliberately

When you decide to move forward with something new, make it an experiment, not a crusade. Define a hypothesis about what you expect to gain. You may be looking for better scalability, lower costs, or a faster development cycle. Write that down. Then define how you will measure it.

Expect the transition to follow a change curve. Things will feel worse before they get better. People will struggle with the new approach and question why you made the switch. That is normal. Keep communicating what you are seeing and why you are continuing. When the metrics begin to show improvement, make that visible.

If it doesn’t deliver the results you hoped for, be willing to stop. End the experiment, share what you learned, and move on. That kind of clarity builds trust.

When it does work, document it. Recognize the people who led the effort. Build on that experience the next time. Adoption is not just a technical process. It is a cultural one.

Building a System for Technology Choices

The most successful organizations I have worked in treat technology decisions as part of their system, not a one-time event. They create space for discovery, experimentation, and evaluation before anything reaches production. They involve the team in technical direction, not just management.

If you are a CTO, you own the technology strategy; however, the best strategies often emerge from shared ownership. The people doing the work often see opportunities or risks before you do. Involve them. Encourage them to propose ideas, test them safely, and share what they learn.

After every adoption or rejection, hold a retrospective. Talk about what worked, what didn’t, and what to do differently next time. That habit turns random trial and error into institutional learning.

You can build a culture that views new technology not as a threat or distraction, but as an integral part of how the team evolves. Curiosity and discernment can coexist.

Closing Thought

Technology waves will keep coming. Some will reshape how we work; most will not. The challenge of leadership is recognizing the difference.

Good technology choices rarely come from being first. They stem from being thoughtful, from understanding your context, and from fostering a culture that learns quickly and acts deliberately.

The best technology decisions are not about what is new. They are about what is right for you, right now.

Originally published on my newsletter on November 02, 2025

Becoming a CTO

A former co-worker reached out to me recently. They are a director of engineering at a midsize startup and just got their first headhunter inquiry for a CTO role. Having never been in the role before, they wanted to know what the position was like and how to prepare for the interviews.

I realized that while there are some books on technology leadership careers, there aren’t many resources explaining the most senior levels. My goal is to provide some insight and advice for those interested in someday becoming a CTO.

I’ve been a CTO for five and a half years

I’ve worked at a hundred-thousand-person company, seed-stage startups, and many of the variants in-between. I started as a developer and followed a traditional path of moving up to more senior levels on the development track and then moving to lead, engineering manager, director, VP, and now chief technology officer. I’ve been the CTO at three different companies in two countries and three parts of the technology industry. I’m part of a few networks where I meet and talk with CTOs of all sizes and stages of companies.

I’ve learned that one reason there isn’t a good reference for the role of the CTO is that the size of the company and the expectations of the CEO define the job. Some of my role expectations and responsibilities are like those of many of my peers at similar-size companies. However, there are also significant differences in our expectations from our executive peers and boards.

Because of the variability of the role, I will broadly share my direct experiences, joined with an understanding of the expectations of other CTOs that I know.

The early-stage company CTO is often the developer-in-chief

At earlier stage companies, the CTO is often the technical co-founder. They are likely the developer who built many of the earlier versions of the software and helped hire the original development team. Their responsibilities are primarily technical: driving architecture, doing advanced development tasks, and creating technical vision.

Frequently, the first CTO of the company is hired for their ability to code and not their ability to grow or manage a team. Depending on the person, they may also lead the development team. Still, often the team’s management will eventually move to another person, an experienced manager, who may report to the CTO or be a peer to them.

The early-stage CTO is the leading technical voice for the company externally, especially if they are a co-founder. They talk to investors and potential partners and meet with potential vendors. If they also manage the development team, they will solely represent engineering in the senior leadership team. As a result, they will have responsibility for the decisions made by the engineering team. Nevertheless, if they do not manage the team directly, they might not be involved in the decisions around the day-to-day operations.

A mistake that inexperienced founding CTOs often make is that they don’t understand their role beyond coder-in-chief. They focus solely on the technology and are not active participants in the company’s leadership. As a result, they do not work cross-functionally. CTOs fixated on the how without the why or what will not be in the role very long once the company grows.

If they have no experience leading an engineering team or organization, the early-stage CTO will be challenged to grow with the company. If they cannot scale, eventually they will end up in a subordinate role reporting to a more experienced CTO hired to replace them.

The midsize company CTO is responsible for leading the organization, corporate strategy, and making technical decisions

Once a company reaches a size at which it needs new processes and structures, the scrappy leaders who helped get the company off the ground are often replaced with more experienced leaders knowledgeable in taking companies through the next growth stage. If the CTO hasn’t grown into the larger role, they will be part of that replaced group.

The midsize company CTO is a full-fledged executive team member working cross-functionally and meeting with partners, investors, and customers. Frequently, the midsize company CTO will also manage the engineering organization. The CTO is responsible for setting technical direction, making sure good architectural decisions are being made, and establishing best practices and working methods. They are still expected to have good technical depth, but don’t often actively contribute to shipping code. A red flag for me personally is seeing a CTO role description where the expectation is to lead a 50-plus-person organization while also actively coding on the product. It means the executive team does not have appropriate expectations for the role.

A midsize company CTO spends significant time establishing culture and practices for the teams they are responsible for; they are also very directly accountable for the organization’s decisions and its track record of delivery. The CTO meets internally with members of the other functions, such as sales, marketing, HR, and finance, to share direction for the organization and get feedback. The CTO is responsible for the administration of the teams, including the budget.

The CTO is also responsible for hiring, performance management, and team structure and may be very active in their teams’ recruitment and interview processes, especially in a scale-up type of company.

A CTO leading a more extensive development organization must be a generalist, understanding different roles and responsibilities. Their remit may include Corporate IT and Technical Support. In some companies, they may also manage the business analytics, security, product, and UX teams. A CTO who is too focused on the areas closest to their background or does not respect non-coding functions will not succeed.

As a midsize company CTO, you will often spend as much time with your peers and their teams as you spend with your own. As a result, you will need to learn about their functions and how your teams can work together. CTOs who “stay in their lane” will not be seen as an equal member of the senior leadership team and may lose their say in decisions that affect the organization.

It is very unusual for someone to move into a midsize company CTO role without having some experience leading a multilevel-development organization and working with other business functions.

Growing (or moving) into the CTO role

If you are a manager or a manager of managers with the goal of being a CTO, there are a few things you can start to focus on that will help you on your path.

Learn about the business your company is in

Offer to sit in on sales calls, on user research interviews. Try to understand the company’s financials when the CFO presents them. If you can’t, make a friend in the finance team and ask them to explain them to you. Understand the KPIs not only for your team, but also for the teams around you.

Learn about the other functions

Get recommendations of reading or conference talks from your peers in the product, UX, and marketing teams. Think about how their work influences yours, and yours influences theirs.

Respect and learn other technology areas aside from your own

If you lead an area you don’t have personal experience in, approach the people in that function with respect and a genuine desire to understand their work. They want to help you know what they do and how they do it.

Hone your craft

Hopefully, you are already working on deepening your skill as an engineering manager or director, but are you trying to understand the bigger picture? Read other companies’ (public) handbooks, engineering blog posts, and conference presentations about their ways of working. What practices are interesting? Which can you try in your team? How do you think they will scale, or what issues do you think they may have?

Ask your CTO if there are tasks they can delegate to you

The best way to learn the job is to do the job. Even better is having someone who is already doing the job explain to you how they perform it so you can help them.

Start thinking in terms of strategy

The main difference between the expectations of line managers and senior managers is the emphasis on strategic thinking. Executives contribute to the company’s strategic planning and use their understanding of the company’s goals and the current situation to make sure that their teams are setting up the conditions for the company’s success. Strategic thinking is a learnable skill, but it takes practice.

The rewards of being a CTO

Being a CTO was not what I imagined it to be when I first decided it was my career goal. It is a lot of work, carries much stress, has fewer perks than you might think, and can be somewhat lonely. However, it is also the most personally rewarding job I have ever had. With the challenges, there is also incredible responsibility, tons to learn, the ability to influence the company’s direction, and the chance to affect the lives of dozens or hundreds of people on your team. I have yet to regret my choice to pursue this role.

Thanks to Laura Blackwell for editing assistance