Leadership is hard and it's hard because you're making bayesian calculations on suboptimal choices. Almost by definition.
Say a Jr. dev has a problem that they can't solve. They kick it to an intermediate.
The intermediate can't solve it so they kick it up to a senior.
The senior can see a couple of solutions, but want's to run it past the architect.
The architect takes these options, weighs them against n number of considerations + the dev roadmap and sees strengths and weaknesses to all of them.
They package those pros and cons and brings them to you, the CTO to make a decision between these sub-optimal choices.
In this kind of environment EVERY move you make is going to be a little bit wrong. You just kind of have to minimize the wrongness
It has this gem of a quote:
> It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you will be wrong), you can always undo the damage later by backtracking. Suddenly, you get to be doubly managerial for making two inconsequential decisions - the wrong one and the right one.
It goes on to mention that most technical decisions fall inline as small changes and why.
I left. My new job has lots of tech debt, lots of processes that are broken, but when I propose changes people listen. When I put in the work I can see progress. It's hard work and frustrating, but I know that it's because the problems I'm tackling are hard, not because I'm a failure or lacking. That's a very different environment.
I can only give a very broad bit of advice here -- having a positive, open environment is very important. Gaslighting will bring down even the most secure, confident person over time. If you can't change the environment, leaving to find a better one is the right thing to do. What that looks like will differ on one's situation -- might be a long break from coding, might be changing teams, might be changing companies. But we absolutely need people around us who believe in us to work sustainably.
If the company is big enough where people have the time to call you out on shitty code and think they can do better - awesome! Let them code it, and you can focus on technical direction. Tell them what to do. Delegate. Let them write the code - it's what you're paying them for.
You can put your developer hat on at home and write code that automates the garage door at your new mansion.
I've seen two successful models of CTO that are "good developers:"
1. Knows the core tech of the company really well. There's some small bit of tech at your company that's legit an enabler of your growth. You should probably know it better than anybody. Maybe it's moved or changed or grown in the last 8 years, and you've lost touch a bit? It seems reasonable to carve out time to build something on your own, in the same space, using the new stuff. You probably have a better sense of what's important to get right than anybody else, so building a personal project with that tech on company time _is_ actually a great use of time.
2. Knows the system dependencies better than anybody else. This particularly applies if you have reliability woes or other systematic issues. You have a great position to ask other teams to educate you. Get a couple good devs from each team in a room, drop your ego, and have them teach you what they know in their domain. Do this across a bunch of teams. Some folks might find this irritating, but most folks will like the time to show off their work and share their worries.
Everybody is constrained by where they spend their time. If you want to go back to being a great IC ... you need a different job. Which it might be time for! But you can be technically great as a CTO, and I'm sure I've missed some other ways you can do it in the context of you "day job."
If you asked me to reinvent the Linux kernel now, I would probably first say "I don't know anything about that, I'm not your guy", and if you were really insistent I'd give a huge number, like 10-15 years, with several disclaimers of "seriously, I don't know what I'm doing here, I'm pulling these numbers out of my ass".
Did I become a worse engineer in the last decade? No, I was just inexperienced ten years ago, and as a result I wasn't really able to differentiate "easy" and "hard" problems, and since I was a goofball (with too big of an ego at the time) I just assumed most projects were easy. Nowadays I have a much better handle on what I know and what I don't know, and as a result I find myself in doubt about things all the time. It's easy to get into a spiral of "I don't know to do this and omg I'm going to fuck it all up."
How big is this company?
Is it a small company with few developers where you hold the CTO title because you're a founding developer or the most senior developer? If so, you might be missing the reassurance that came from your previous life where you had a manager to check your work, peers to review it, and feedback from people who didn't report to you:
> When I look at a new feature I just think that I will make it shitty or get called out on not doing things the "right" way.
At a startup, the "right" way isn't necessarily the most textbook-perfect code. The right way is getting features shipped as soon as possible with the code being good enough to be understandable, stable, and maintainable. You need to be careful about spiraling into decision paralysis or drawn out refactor iterations and instead focus more on shipping features to users, focusing effort where it matters for the business, and avoiding unnecessary complication in search of perfection. Perfectionism will kill startups slowly.
If you're the CTO of a big company with many developers reporting to you, then it's time to start letting go of the developer responsibilities. Trying to manage the code too closely or trying to insert yourself into the development teams that you're supposed to be managing doesn't work at scale. Focus on the bigger picture: Driving objectives, mentoring developers, hiring, monitoring output, and other leadership roles. Don't let a desire to control the code interfere with your management duties.
I was a manager for 25 years, and one thing that I learned, was to never put myself into the critical path. I could do tech projects, but they needed to be "nice to have on the side" projects.
Management requires that we work on interrupt. We can't have that sweet "fugue," that makes us productive developers.
What I did, was work on a lot of open-source stuff, on the side. I didn't have deadlines, and it allowed me to keep my "tech chops" up.
Since leaving that job, I tossed the management stuff into the skip, and have concentrated 100% on tech work. I love it.
I'm a damn good engineer. I get a hell of a lot done, at awesome quality levels, in very little time, but I also don't particularly care whether or not anyone co-signs my work.
Also, I'm not a jargonaut. Lots of folks like to sneer at people like me, because we suck at Buzzword Bingo.
As others have noted I agree that building something (even not software related) helps get me out of these kinds of funks. The reality of your position is that you likely are at a point where you have hired people to make the important technical decisions in terms or architecture, design, and "engineering" and you hired them because they are specialists at that. In todays dev world there is too much to know about to many things to keep full grasp on it all. Your job as a technical leader is to drive the trajectory of the project in the right direction and that often means trusting the leaders of various teams to make decisions about individual technical topics so long as it meets your higher level goals as an organization. Remember Wernher von Braun was not designing every piece of the Saturn V he was driving the project to success.
It seems that you already have the answer.
You know that there are times that you are right and that other people are wrong, and perhaps this occurs often enough that you are being inadvertently gaslit.
If you're CTO and you are being called out to this extent, then you might want to consider finding another company or stepping down to a senior engineering role. I've never been a CTO or have worked closely with one, but my impression is that a CTO gets some sort of respect and final say around things technical. There's a mismatch somewhere here. Other people aren't always right, no matter how reasonable they may seem. There has been plenty of times in my career where I've pointed out objectively counterproductive development practices and have been told that I was wrong because reasons, and sometimes I've totally noped out of those clients/companies for that reason. Unless you really need the next paycheck that badly, life's too short for the mental agony of doing things that are nonsensical.
Although I hope you also can consider whether your ideas are actually the right ones. Sometimes I didn't learn until years later how right someone was when they criticized or disagreed with my engineering decisions.
I think you need to find some good mentors; and/or find some good people in your organization that you can talk about these issues with.
> or get called out on not doing things the "right" way
Assuming you're working in a team setting, you need to direct the people who will call you out into planning to make sure that things are done the "right" way. And, then ask yourself, why aren't these people writing the coding guide, picking the patterns, writing the design, or reviewing such work? Why aren't you delegating to them?
One big mistake that I see is a general lack of mentorship when someone is "leading" without at least decade under their belt. You might be the smartest person in the room, but without experience, you're going to make mistakes that are "obvious" to anyone who's been in this field for 10+ years.
Your best bet is to do a project entirely different from anything you've done in a while. You can vary: (1) the domain of the project (what it's about) and (2) the technology behind the project.
When I was really sick and tired of programming I enjoyed playing with Scratch with kids. Many coders, including myself, have a blast with Arduino and other embedded boards.
Trust your gut. You've been busy with other things, and you have fallen behind as a developer. That doesn't mean you are worthless or unable to improve again. It just means you need to be humble and have a plan to improve as a coder.
The only way to improve consistently I have seen is to seek feedback from peers. Seek out a trusted colleague and ask to pair program for a while. Submit PRs early and often, and get early feedback.
I know a lot of people who would never admit they are struggling, and just say everyone else is the problem.
There are tons of remote options like BetterHelp where you can get an appointment quick without much hassle or commitment, so it's a pretty low threshold to give it a shot---that might be a good place to start. Good luck!
As others have pointed out, you can't really be CTO and a software developer unless you're at a tiny company (like 3 people tiny) and you claim that you're "growing like crazy" which implies that you couldn't have been CTO at a small company for long.
This then means that you've been a software developer for 12 - 8 = 4 years. You're not and never have been a very senior IC, and there's nothing wrong with that if you're in a CTO role. You're probably not a bad developer, but you don't have the experience and skills of a really great senior IC. The skills required of a good CTO have almost nothing in common with those of a strong, senior IC. The only reason it's useful for CTOs to have developer experience is to help communication, but nobody looks up to their CTO for advice on solving day-to-day software problems.
My guess is that if you're worried about your developer skills you might be lagging in some of your CTO duties (totally possible I'm wrong here). I would first make sure you're providing the high level leadership and support of that role. It's also possible that you don't really want to be CTO, if you want to be developer you can easily find a place where you can transition into an IC role.
Overall it sounds like you should reflect a bit on what you want, where you currently are, and how to get to where you want to be. Do you want to be a great CTO? do you want to be a great developer? or is there something else you're looking for?
Its OK to not know something, CTO's and principal engineers are not gods of their trade but people who use the synergies presented to them. That is not an archive of man pages that you have produced for your minions, but the combined effort of everyone (technical) involved.
Realizing that you may lack a certain set of information is a perfect point to reach out to someone in your team, who does. You will see that the exact opposite of what you are expecting will happen: people will you value more because you can be reasoned with. See it this way: even if you could theoretically barely program, I wold wager that you have more tech skills than some CTOs the past has brought up. Really successfull ones too.
Even if noone other in your team has the answers to your problem, the solution is still communication. Either hire talent or use freelancers and consultants. That is what we do. But the result its still the same, it's your team that is facing the problem, not the problem facing the team.
On the risk of sounding a bit funny, but maybe you should consider taking a management course?
None of the comments here will give you the faith in yourself that you seek (that is not to say they are not good, or not beneficial). You are the only person who can give you that.
In a way the biggest fear for a CTO is getting called out 3 or 4 years down the road for problems in the core direction you set. It happens, and will happen, and we all work to make those events as rare as possible.
I found that I had lost my developer experience over the years and I didn't feel like a good CTO. I figured I was burnt out and started to not care about the work but couldn't bring myself to give myself a rest or sort it out. I quit last week.
This has a lot of benefits: you can serve as their rubber duck and help solve their problems which feels great.
You can sanity check your thought process and conclusions. This will help assuage the doubt.
And it's a social connection which helps with anxiety.
Also, go easy on yourself. No one knows the 'right' answer. It's great to look for the best move but it's ok to make a bunch of merely really good moves, too. Allow yourself to accept the context under which your decisions are made.
Don't forget to give yourself space. You're CTO. Delegate the shit out of everything you can, even the stuff you're best at. Call it a growth opportunity for your team. But if you don't give yourself the space to make great decisions, everyone suffers. Avoid the 'busy-ness' trap at all costs. That's not your job.
"Should top managers focus on their peers or on those who they lead?"
https://demodexio.substack.com/p/should-top-managers-focus-o...
Many newly promoted managers stay focused on the work they used to do, but fail to give enough attention to the other parts of the business, with which they need to learn about and integrate with.
And remember: this is art, not science. We all make artistic decisions about how to do things in programming all day (we pretend it's science or engineering... it's not) and you will, too. Give yourself permission to do things how you want to, it's all just a learning opportunity.
I did this when I turned 40 after years of being an architect... it refreshed my love for coding.
If you have a mentor or someone close that you really trust, I would really sit down with them and talk through this. Slumps are expected, and everyone has different ways to get out of them!
Also, this doesn't sound like burn out, but I could definitely be wrong.
The time I took off was restful, for sure, but the insecurity I felt was extreme. It took me another 3 months to get my groove back and just feel like, "no, you know what? I'm a decent programmer and I have earned the right to be here with the other devs. I'll catch up in my knowledge gap."
I always wondered how female programmers who go on mat leave cope with stepping away from it all for like a year.
Me too. I don't know. Force yourself into situations where it's sink or swim and that nobody is willing to step up to?
I don't since I have a family to support. If you're a CTO, that sounds like you've already made it.
Make something purely for yourself, just because you want it for yourself (whether an app or a website or a desktop program, a game, etc).
Design and code it how you want, focusing on making it work without obsessing about doing it the right way.
I think that will help you recapture the pure joy of coding.
Once you have recaptured that, then I think a lot of other stuff will kind of get back into the right perspective.
This self-doubt isn't happening in a vacuum. You haven't gone into depth here (and that's fine) but it sounds like a lack of psychological safety. And even if you are the CTO you cannot create a supportive environment by yourself.
Who around you is calling out what you do, or making you feel (even subtly) that what you're doing is shitty?
(and yes, if that's the environment, it absolutely contributes to burnout)
Imagine you have opinionated or senior developers, maybe with a tiny chip on their shoulder - they know better than their idiot boss! And you're not the sort of person who wants to ride roughshod over them. Their opinion matters to you.
There are absolutely ways they could advocate for their own views and express disagreement without making you feel stupid.
If anything like this sounds right (just spitballing after all), I don't know what to do without more details. Gonna be hard to say "be nice" without sounding like "don't tell me I'm wrong." But not impossible.
Wishing you the best.
If the CTO title is more ceremonial (or your organization is very small) and you are actual performing the role of the most senior developer, know that there is no “right” solution to any software development task. Any working solution outweighs any theoretical optimal solution. The only real metric that matters is that each time you make a decision that it is better than the last one; where better is an amalgamation of (personnel * knowledge * skills * metrics ) / time available.
By definition, if what you're doing is working, it's the right way. There's nobody higher up the chain to tell you otherwise.
If it's not hitting the goals you're setting for yourself, you'll need to determine if the goals are unrealistic or if the approach you're taking to reach them is unrealistic (as CTO, that's often more of the job than writing the actual code).
It's hard to be at the top; it often feels like "working without a net." I changed companies to avoid that feeling when I was younger, and it's possible that's the right move. But if you stick it out, I just want to share that "working without a net" feeling only diminishes if you build a net for yourself (in the form of process you can use to determine if anything is working).
Beyond the feeling of unease that comes from the above realization, who is the voice the back of your mind who is critical of your code or your technical decisions? Is it an old voice from childhood, a parent or a teacher, or is it current, your peers for example? These voices are sometimes triggered by events going on in your life, work related or not.
Is it really your code or is it that you don't work in a supportive environment? Perhaps someone is gunning for your job and being subtly critical in ways that are getting to you.
You might want to look at "egoless programming" and work on getting your ego out of your code and into the competitive workplace where it is more relevant.
- possibly your thoughts and feelings might be hormone-related. If male, consider getting T checked?
- optimistically, maybe you have built such a strong team that you doubt yourself in their context and it's time to move on :)
I'd suggest looking up a local independent coach. Maybe ask around for references. If you can get the company to pay for it, great (should be worth it to them). Otherwise pay for it yourself.
You have thought about this a lot, and come to a big realization. You need an outside sounding board to help you think through the implications and figure out next steps. A coach seems like a great fit because they are aimed at personal development, whereas a therapist is for fixibg things. It doesn't sound like you need fixing.
(Saying this because of personal experience with coaches)
Meet-ups, hackathons etc are good ways to stay up to date on diverse topics & letting your brain work on new stuff instead.
If you haven't actively adapted over the last 8 years, this may just be the result of being in a job you don't like. Whereas regular-exec work might be a lot of management, architecture decisions, etc., high-level-exec work is more pure politics, storytelling, and resource allocation.
There's a reason a lot of startups replace their sr execs every 10x-100x growth period or so.
Also appreciate that most thoughtful engineers are their own worst enemy. Its a sign that you're good that you even care. Find a way to taper back your own self-criticisms because after a certain point they are inaccurate and not helpful.
Jokes aside, did something happen before? Did a software not perform or caused problems? You say growth is fast. Sounds good and that means to make compromises here and there in software that might not fit your aspirations of quality.
Is this a new position? Or did you see a topic that was just beyond you in any conceivable way? I guess making wrong decisions comes with the job, but as long as business is good...
I think being a CTO brings it's own unique challenges, perspectives and context. You were a developer. Your not exactly one now and that has to be considered. For one you have context that developers don't and they may not understand that. It also depends on the specific situation. Good code, 'right way', it often just translates to "my definition of right or good". Lots of subjectivity to software development, as weird as that sometimes feels. Lots of ego and ego is a problem.
In my experience a group of developers can believe something is right very strongly and be completely wrong about it and that really sucks because we're social animals and, for better or worst, concensus is often at play in decision making.
No idea how to fix your specific issue but I think it requires openness and sharing and accepting that different people have different opinions on what's correct and everyone has to accept that it differs from person to person. Did you want to share anything specific? Not sure if it'll help but it might give you more insights to get a set of different opinions from outside your usual circle.
In some ways, it can look bad for someone in leadership, like a CTO, to get called out for not doing things the right way. At the same time though, if you and the leadership in your company have hired the right engineers working with you, even if you are the CTO hopefully people working with you know more about specific areas than you do, and as CTO you can help make sure that things fit together. So what if you get feedback on how to do things better? You as CTO have a chance to set an example to others on the team for how to receive feedback constructively.
First off, DO NOT RESIGN from your post of CTO. Your Experience, Knowledge and Seniority is what got you that role, so no need to give up something which you have earned and which can be made more manageable by changing perspectives, work habits and learning.
The basic problem is that as you went up the career ladder you took up more load without shedding any. A CTO does not have to be a Super-Duper Developer (there is simply not enough time) but needs to know enough to understand the product/service. The CTO is a "Technology Strategist" i.e one who can understand Technology deeply, see how it can affect Domains/Markets and how to marry the two. You need to be somebody who can connect the dots and push towards a goal. The view is overarching and not local i.e. you "see the forest and not just the trees".
So dial down your desire to be a "nitty-gritty Developer", understand broadly what every role (IC, Tech. Lead, Architect etc.) entails, interact with them all and only take responsibility for the "Global Company Strategy".
I think you're getting so much terrible advice in this thread, from everyone attacking you for writing code. You should be writing more code if that's what you like to do. I spend about two thirds of my time writing and reviewing code, take the lead new features (core and experimental), fix bugs, and generally work on whatever I find the most fun and think will be the most useful for customers. You can do the same and still lead a very large and fast growing company. This idea that as a leader you should abstain from doing real work is nonsense and results in bad leaders.
If you find yourself stressed about the code you write adhering to everyone else's standards, I'd suggest 1) not worrying about everyone else (easy to say / hard to do), or 2) finding a commercially valid excuse to make a new repo and try some fun ideas out there. If the ideas are good, incorporate them into the main codebase and get back to what you do best.
Here is another secret, no one has the right way to develop. There are many development styles and some produce better short term or long term results.
Unelegant code that works might be just the thing until more robust, better architected, unit tested code takes its place it all comes down to the purpose. A small one off hacked together solution for on boarding might be better than spending three months to "get it right " it all depends on risk appetite, project standards, and the scenario.
Don't act like you know better if you don't. Listen to other developers ideas, they might have input you haven't thought of.
Always Be Learning, not as catchy as always be closing, but the path of a developer is a path not a destination. You can always make progress.
Fear of failure or being called out as a fraud shouldn't stop you. Remember everyone makes mistakes, no one is perfect, lots developers think they write the best code in their shop, and would critique your code even if you objectively were the best developer of all time.
Learn the industry standards as you can and shore up your weaknesses with good underlings that will help you learn.
In any case, it sounds like you might need to try to find a community of folks to help mentor you, and act as sanity checks? At least, that's my thought.
Though with everything that's happened in the last two years, it may just be burnout, in which case rest is probably the best approach.
Some places try to create solutions for things that don’t have a problem. Being caught in the middle of such a requirement chain will make you doubt yourself. Especially after you realize it is a bullshit idea to begin with, yet still have to keep a smile on, both in front of your subordinates and your investors.
Unfortunately, when you step into a CTO role, skills-wise, you have to become a generalist to do your job better.
If you're losing faith in yourself because you feel your technical capabilities is diminishing and so is your perceived value to the organization, I fully understand. You need to reevaluate what your value in your role. Is it important that you're the best developer? To me, no. As others have pointed out, your job is to make the better decision in a sea of decisions; I say better and not best because sometimes the best decision is not the right decision for the business.
Good luck!
First was that when you are higher up the chain, you should not be making decisions on small stuff. You should be delegating to the smartest people that report to you.
Second, in the executive level, you should be focused on strategy and identifying industry trends, not on doing day to day grunt work.
If this seems to be the case, the solution is to care less of that chaos and care more of your developer’s craft, which you seem to still have more affinity to. It is your role. Push the anxiety back to where it belongs by doing/planning things the right-most possible way and negotiating it to the forces which drive it ahead “like crazy”.
There is a balance between growing like crazy and turning all limbs into cancerous tumors. You may find peace of mind in finding it and messaging it back to where imbalances originate from.
I would ask myself in this positon what do I want as a pro (hard one), whose responsibilities I take on me without profiting from it (not only money-wise), make it clear what will happen to me, to the company and to the next guy if I just leave, what are both good and bad sides of how things work now, think which points of that list should be fixed, which should be added, in the circumstances, and evaluate possible outcomes. I mean not which I can “live with” today, but which should [not] be there strategically. And finally, I’d detect the source(s) of trouble and message them publicly-directly about the structured issues from that board. It’s a huge reflective/collective work, which would serve good both me and the company.
When I was CTO I built the MVP and coded at first. Then after adding engineers we started shifting the architecture to their designs (because it's important to allow people to be creative and own things, right?) and I started feeling like a sub-par engineer, not creating sophisticated code as they did.
Well, turns out they overcomplicated things, focused on complex problems rather than end-to-end feature delivery, and waisted a lot of time rebuilding things that wete better (albite simpler) in my MVP.
For me, the takeaway is - trust yourself. You know best.
It's not the same lesson for everyone, some people are too controlling, but it seems you and I are closer to the other end of the spectrum.
This is in addition to the other advice here, not instead of.
Edit: I probably should have said to kill all projects/features/goals that you are not absolutely certain of. Ideas for achieving the same objective in a different way, are probably good risks.
1. Stop developing. Then you don't have to feel judged for dev work.
2. Stop CTOing. Then you're "just a developer" and you can go back to doing work as a team, where your own personal opinions or decisions should not override those of the team. Being "wrong" is fine, because whatever decision the team comes to is "right", and you all cooperate together to accomplish the shared goal, right or wrong.
3. Continue to be a CTO, continue to write code, but go to therapy and find out the source of your fear, then figure out how to cope with it.
If I'm worried about the performance of my software, but I don't know which things to optimize, I need to use a profiler.
If I'm worried that my code changes introduce bugs, I need tests.
If I'm worried that a design isn't the best set of trade-offs, I need to share it with people whose judgement I trust and get their feedback.
I'm not a manager, so I don't know exactly what feedback looks like at your level, but I'd suggest involving more of your team and collaborating on decisions more.
Why are you implementing features as a CTO? Isn't that what your team is for?
All of us have to combat that Syndrome at some time or other. For many of us, it strikes more than once.
In my case, I've had it strike in several of my 'professions': Pharmacist, Programmer, Pilot.
I'm beginning to suspect that 'Imposter Syndrome' is a normal 'Rite of Passage' - on moving from mid-level to a higher-than-normal level of expertise in that particular field. You get the 'Am I good enough to match those others who are already in the upper echelons of the field?' doubts.
You will likely get called out whichever way you make the decision by people tunnel visioning on one side of the coin. Getting called out doesn't mean the decision was wrong. Your goal should not be that no one calls you out. Rather it should be to be able to say: Yeah I took that drawback into account.
> CTO of a company that is growing like crazy.
Well if the company is growing like crazy then you must be doing a lot of things right?
What you'll get:
- Brand new ideas (new learning)
- Confirmation of ideas you already hold, but weren't 100% on
- Knowledge of some ideas you held that were wrong (without anyone else knowing!)
Also set aside a little time to do some 'fun coding'. Maybe Go or Erlang or C#. Something that's a little close to the metal, but not mind-numbingly difficult to get going with.
Good Luck. Given a little time spent right, I'm sure you'll be bursting with confidence in no time.
Regarding large software systems there almost never one right answer. At times we need to make decisions without perfect knowledge. Some portion of those decisions will be suboptimal of course. Whereby we make more decisions to hopefully improve the outcome. It's the nature of the problem.
Perhaps you have "decision fatigue?" Sounds like a nice vacation is in order.
Maybe search on some colleagues where you can discuss technical things at eye level. You beeing CTO doesn't mean you have to know everything better (imo, dependent on the company culture it may backfire).
Maybe it's something unrelated and you are just a bit depressive. I can easily imagine that happens to a lot of people with all the reduced social contacts due to covid....
However, you're the CTO and your role realistically shouldn't be developing, but it should be weighing up the decisions your team is making as THEY develop, building connections and looking at the forward strategy.
It sounds to me that you made the move into the CTO role, without fully making the break with what you used to do in your previous role as a developer.
But from my own experience: it might have to do with lack of energy.
It sounds like you are responsible for the decisions you make. If you don't have a lot of energy you don't have energy to deal with possible bad outcomes. That's when you start to overthink your decisions to protect you from energy loss in case you made the wrong choice.
So check your energy levels.
And if the responsibility is too much for you be honest about it. Involve others to make the decision.
At least your company is growing and you know that you are a decent developer.
Maybe you can take a sabbatical. Talk to your partner if you are on good terms. Make sure to explore your options.
Hope you find a way to move forward and regain your confidence.
This is 100% normal: you are comparing yourself to the world nowadays and, since you read HN, to many real brave people (I am scared myself too ahahahah).
My advice is to cool down and tell to yourself: "developing is not rocket science"... but practice, a lot of practice (as in any art) is needed: no practice, no speed.. no result, which is as in any field. :)
do not be too hard on youself
Fix your expectations. Perfect things don't exists. Don't get trap into the idea of perfectionism. In retrospective, everything will look like "not doing the right thing", don't take that personally, that's how retrospective works.
If not, don't worry. If you do, don't worry. Perfection is the enemy of good enough.
You want to hire developers who will take your vision and turn it into good code even if that means rewriting your code. And every developer will rewrite your code to make it their own. They will also always complain about your code.
The first group is afforded the "ask for forgiveness not permission" mantra, while the latter is left with "fall on the sword".
This leads to generally higher pressure and less feedback since you are kinda sorta pioneering and not just following hand-me-down instructions.
How do you escape the funk? Realize the funk is useful and normal, and it always was!
few months ago i went through a similar self-trust downturn. i had a nice salary, complete decision making freedom, great team, booming market.. i was getting the job done, but i felt like shit and couldn't trust myself with anything..
now i'm in a process of figuring things out. i'm not there yet, but it turned out the problem we were solving stopped being interesting to me. that made me rely on "best practices" and i stopped being creative. couldn't come up with brilliant/scary shit to do, everything was so predictable..
if you have shitty problems to solve, or not interesting to you personally, you won't be able to engage.
if developing makes you happy, then find problems worth solving in the first place. some time off helps, find some scary things to do. satisfaction is on the other side.
As others have mentioned- hire the best and empower them. If being a developer is your passion then perhaps you should consider giving up the CTO role.
As a Disney princess once said: "Let it go".
Forgetting is just as critical a skill as remembering.
Except, if you're not listening at all to suggestions from colleagues, then you may be doing things the wrong way. Or when the code is just failing at doing its task.
Are you taking care of your body?
Are you sleeping well?
Are you eating well?
Also, consider checking your hormones. Age and stress will move your thoughts in this direction. There are ways to counteract though.
Mind and body are inseparable, one influences the other.
Dealing with infinite unknowns is just part of the package, the reason most can't cope, the reason we're paid relatively insane amounts for what we do.
So say my 35 years in the trenches at least...
Seek contact to those using your software.
Read about „imposter syndrome“ and „decision fatigue“.
Keep abreast of stuff and the winds of technological change, but hire people to code and get them to make the outcome you want.
stop being hard on yourself
Save your design and coding for your home projects for fun.
If you're not for a prolonged period of time, it's likely burnout.
I've been faking imposter syndrome for the past thirty years.
Who do you fear it´s going to do this?
I'm only saying this because I worked on a video game for 11 years. Finally got it released, at the cost of a falling out with my best friend and business partner, and we never recovered our friendship in the same way. This stuff can be brutal.
If you're a CTO in name only, then you're probably also sensing that investment in different people or tools like #nocode could have bigger returns than more code. But maybe that doesn't sound good to investors, so you keep doubling down on the current approach.
I went through a massive burnout in 2018 and lost my job in 2019. The stress combined with too much alcohol and gym time finally just burned me out. Humans aren't meant to live under continuous stress for years on end. It was like having a stroke. I lost all decision-making and problem-solving ability and could barely get out of bed for 6 months. Then the rona hit.
There's hope though, because I made a full recovery. Here's what I did, YMMV:
* https://www.depression-chat-rooms.org
* Split and subdivided my tasks to their most granular level in todo lists
* Executed the tasks at a different time or day to exercise executive function
* Tackled the low-hanging fruit instead of the hardest thing first
* Prioritized my physical needs over a job after I found the smoking gun, that gut health affects serotonin and can be sent out of whack by common foods like dairy, tree nuts like almonds, legumes and nightshades (B vitamins, digestive enzymes, kefir, psyllium husk capsules, spinach, iodine, etc, talk to a nutritionist or eastern medicine/Ayurvedic specialist)
* Dedicated myself to service (donated plasma, jumped to help others in need, vocalized that I was there for people)
* Found ADHD TikTok
* Set boundaries (most important of all?)
* Tried something completely different for awhile (handyman for another friend during the summer of 2020) - AND/OR - Worked on my communication skills
That last one might be hard to do, so if you can't take a break from your job, I'd recommend opening a dialog with the people around you. Being more transparent with my supervisor/boss at my current job has done wonders. It turns out that many of the people who antagonized me over the years were actually terrified that I was going to run away and leave them hanging. We're working through a tremendous amount of projection and anxiety as a society. So it might help to flip the situation from "what's wrong with me?" to "how can I help?" because the change in perspective might reveal the issues that your subconscious mind is warning you about.
In the end, it was all worth it, and I'm so much happier and more resilient now for the experience. But I can't lie, I still struggle some days with the continuous nature of it. All I think about pretty much all of the time now is how much I just want a break. But, a bigger percentage of my time now goes to my personal development goals (bought an electric car that I'm going to take full solarpunk to drive for free) so I use mantras and meditation and envisioning a better future to push through the tough mornings.
Hope something in this helps!
I'm not a CTO and never have been, so feel free to completely disregard my advise, but from what I've observed being a good CTO is far more about communicating effectively with the rest of the org, understanding business requirements and ensuring the development team is equipped to solve problems than being a good dev. To some extent you also need to be available to unblock devs when there are key decisions that need to made at a higher level.
In a smaller company you might need to wear multiple hats from time to time, but when you're acting as a CTO your job isn't to be a good dev and to do things the right way, but to ensure you have the right devs and architects in your team so they can tell you the right way to solve problems. The most you should be doing is approving and guiding their decisions. If you feel you have something to offer as a dev then by all means, share your opinion with the team, but your not there to be a dev, you're there to be a CTO.
It sounds like you're taking too much on honestly. You can't be expected to know everything or be an expert on everything technical problem that comes your way -- that's not what a CTO does. A CTO just needs to have a solid high-level understanding about how things come together and delegate everything else.
I think first you need to decide if you want to be a full-time CTO or a CTO who is also a developer. If you're going to continue to be a developer while being CTO then you'll probably just need to accept you're statistically unlikely to be the best developer on the team to solve every problem and therefore from time to time you're going to do things wrong and you're going to need to seek help and feedback from other devs.
For what it's worth a small-medium sized company I used to work for had a CTO who was also a dev (he was the first dev), but by the time I joined the team he was also the weakest dev there. Thing is, he acknowledged that and that's why we were there. He picked up a few dev tasks from time to time where he could and when he had time, but otherwise he would trust us to tell him the right way to solve problems and let us get on with it. He was a great CTO in my opinion, not because of his dev skills, but because he trusted us and gave us the resources we needed to get our jobs done. There were many occasions I needed help from other devs on the team or even external resources and he would always make sure that help was available to me so I could do my job well. That's your primary role as CTO in my opinion. You're not suppose to be a good dev, you're just suppose to ensure you have a team of great devs who have everything they need to be great devs.
I think this specifically might be part of what's causing a challenge for you...
If you were a software developer for 4 years and then a CTO for 8, I'm guessing that you're quite a generalist. And a pretty talented one. You're likely able to think (and communicate) very effectively about higher level strategy/architecture as well as work down in the detail. This is a valuable and rare skill, and it's this ability to work at different levels of abstraction which makes you valuable to the company and not necessarily just your "raw" software development skills at this point.
Being a CTO you're probably also a little rusty (unless you're a very active hybrid coder/CTO). The best developer in the world would get a bit rusty after doing what is often NOT really a software development job for a while. So if this is the case, you can cut yourself some slack there.
At the same time, you probably work with people, perhaps on your team, who are talented specialists. Not generalists. Ie. on the surface, perhaps you think they are better developers than you? (Or perhaps you think that they think that?). Perhaps you see them using newer technologies or design patterns that you're not as familiar with and that leads you to doubt yourself.
I've definitely been there. (So I may be projecting a little here). As an engineering manager (sort of a pseudo-CTO in our small business) my first hire was an incredibly smart guy. The smartest developer I've ever worked with, even to this day. And there were certainly times when I'd doubt myself in his presence. I felt like he was often several steps ahead of me. Fortunately he was also the nicest guy I've ever worked with, so while he would certainly tell me if he thought I was doing something wrong, I would encourage him to do so, and always knew that it was coming from a place of good intentions. Even if I had to occasionally swallow my pride! I saw it as an opportunity to grow and as an exercise in humility too! He was often right too, but not always.
Anyway, I became a _much_ stronger developer and technologist as a result of having the good fortune to work with him for several years. And you will too if you have the good fortune to be working with a very smart team. Even if you doubt yourself at times. Working with people who are obstensibly smarter than you is about the best thing you can do in any career. And if they're not smarter than you, then cool. They're not smarter than you. Either way it's a win! :-)
However. The MOST important thing I would say, is don't judge yourself as a developer, judge yourself as a CTO. That's the role you're in. Some CTOs can't code at all. So you're already ahead of the pack. And try to remind yourself that even if you don't use the latest fancy design patterns or technologies - this actually has very little bearing on how productive/useful you are in your position. Sometimes those things are complete distractions and actually in reality add zero actual value to the business. (Sometimes).
With our developer hats on, we can sometimes get a little narrow-minded and work to produce the "perfect" piece of code that conforms to all the SOLID principles, fully tested, extensible, using the latest shiny language etc. etc. when a competitor of the business may have just thrown something together in PHP (sorry PHP people) and are still delivering the exact same outward-facing value to their customers. And their management team / shareholders literally don't know the difference. As long as that PHP solution is fit for purpose, nor should they. It's irrelevant. There can sometimes be a divide between what an engineering team "thinks" is best vs what is actually best given all the context that you as a CTO may know about the business and its priorities vs the view of the world that they may have.
So if your MO is throwing together some crappy looking code that works. Own it. You're the damn CTO and that's fine. Learn from others by all means, but don't doubt your approach either, it may be way more valid than you think. You also don't need to be the strongest coder. You can be the best CTO in the world and be the worst coder in the company.
Finally, my last piece of advice is to jump on something like www.pluralsight.com and speed-watch courses in areas that you think you might be weak on. I did this during my years as pseudo-CTO to quickly get up to speed with technologies that I wasn't necessarily working with every day, either to be able to talk intelligently about it with my team, or (at the best times) be a able to dip into coding and actually bring the team up to speed with that new technology/pattern.
By absorbing online courses like that, and blogs, and HN, as well as having quite a lot of engaging side projects, I was able to stay pretty sharp and still teach my team a thing of two - even the smartest of them - even when my "default" state was to often feel like a bit of an imposter and have similar worries to you.
TLDR; You probably deserve to give yourself more credit than you are.
Good luck!
Long form:
The one (or last?) time I felt this way was when I had just stepped down as CTO of a well funded company I co-founded.
I can say today that the reasons for stepping down had little to do with my competence, though I didn't feel that way at the time. In truth, it was 2007, and my co-founder and I realized that we were in for a very long stretch of no income, and a short runway, and that the best thing to do was to essentially go on standby.
Still, my confidence took a hit.
I took about a month off, which didn't really help change that feeling. I enjoyed the time off, and it was good for me in general, but it didn't change how I felt about my abilities.
Eventually I decided to do whatever I could to reduce any doubts I had about my competence. I started teaching people how to write code, which meant I really had to make sure that I knew what I was talking about. Teaching helped fill in a lot of gaps I didn't know I had, but also helped me see that I knew what I was doing, at least enough to teach others.
I didn't stop at teaching how to write code though. I started consulting, and managed to find gigs that let me help engineering teams communicate better, and taught those same teams how to have more robust practices around code changes, releases, failures, debugging, code reviews, etc. All the other non-coding stuff every coder needs to be good at.
It took years, but eventually it got really difficult to feel like I didn't know what I was doing. It was clear I knew enough to be effective.
I learned another pretty important thing during that time:
I'm not an expert. No one is. The people who say they are don't yet realize what they don't know.
Admitting I'm not an expert does a few things: it allows me to fail and learn, and to be grateful for what I gain when I do. I don't pretend like I'm a beginner that can't function without stackoverflow. I just leave room for the possibility that there are often better ways to do something. I've learned that shutting the doors to those possibilities is a sure fire way of feel incompetent.
Being humble and ok failing makes all the difference. If someone doesn't like my approach, that's fine. Rather than defend my approach at all costs, I explain the goal, define constraints, and reduce any friction towards hearing how to improve the idea. If after talking it out my idea was still the right way to go I make sure to express gratitude for the feedback.
While trying to "get back", a friend of mine who recently lost his fight with cancer, who's leadership abilities and incredible software development skills were something I still hold up as my "end goal", often said: "It's always good to be humble, and almost always better to be humbled."
I try to optimize what I do around that idea. Having a baseline of "there's always more to learn" just makes things better and easier.
It also helps me get stuff done. It helps me have good relationships with people I work with. If someone doubts a decision I've made, my default mode is to assume they're correct. They often are correct, and I grow. Sometimes they're wrong, and it gives me an opportunity to be humble and help them grow with me. Either way, no energy is spent defending an idea because my ego says I need to. Energy is only ever spent on improving my skills and the skills of teams I lead or work with.