141–150 of 243 posts
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.
It does sound like burnout, and also like not being in the right environment (which contributes to burn out). I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was…
> I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was talking about. This is the sad truth at way too many orgs, even YC funded ones. Several times I have come in…
Earlier quoted context omitted.
Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions. Type 1 decisions are one-way door decisions that needs to be deliberated deeply and consulted on with higher-ups. Type 2 decisions are two-way door decisions that small teams can be empowered to make. There is a balance between empowerment and the higher-ups taking responsibility. I've been in an organization where-in the higher-ups just abdicated…
> Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions There's a cautionary tale buried here. Many seemingly Type 2 decisions are actually Type 1 decisions in disguise. Case in point, Amazon's decision to not allow warehouse workers to have their phones when working in the warehouse has resulted in the 6+ deaths and many more injuries that we saw in the tornado last Friday. Now there's no going back,…
It does sound like burnout, and also like not being in the right environment (which contributes to burn out). I had one job where there was a lot of technical debt, but my manager did not respect me and my colleagues had what was basically a "learned helplessness" attitude. So I'd go around trying really hard to make things better, but everyone responded to me like I was just crazy or naive or didn't know what I was…
I kinda figured I might be going through some burnout. I have thought about taking a sabbatical to try and recoup from it a bit. The company itself is great. All of the feedback I receive is very respectful and understanding, it still just eats at me though. We're even working on a plan to address some of the tech debt/complexity in 2022. I think my self-doubt is just being on a podium at work teamed up with being bu…
Although my management and business skills were continuing to improve (and, I think, got to be quite strong), the loss of my technical competence did bother me. I ended up leaving and now I'm working as a CTO but with no team - more of an individual contributor, at a senior level in the company. I write code every day and over the past year my technical skills have mostly returned, and I've gotten to learn all sorts of exciting new stuff.
With that said, one of the biggest things I've learned is that, once you know how to write software, it's not that hard to get back into it. Learning Typescript has been straightforward. VS Code is a joy to use, but hey, Xcode was pretty great too. If having strong technical skills is important to you, then you have to change your focus and get back into it. But know that you can do this any time you want. On the other hand, if you value the skills of people management, reporting to a board, managing investments, etc., those are things that are hard AND valuable.
At the end of the day it's just about choices, you can't be great at everything. Good luck!
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.
Earlier quoted context omitted.
Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions. Type 1 decisions are one-way door decisions that needs to be deliberated deeply and consulted on with higher-ups. Type 2 decisions are two-way door decisions that small teams can be empowered to make. There is a balance between empowerment and the higher-ups taking responsibility. I've been in an organization where-in the higher-ups just abdicated…
> Reminds me of what Jeff Bezos said about Type 1 and Type 2 decisions There's a cautionary tale buried here. Many seemingly Type 2 decisions are actually Type 1 decisions in disguise. Case in point, Amazon's decision to not allow warehouse workers to have their phones when working in the warehouse has resulted in the 6+ deaths and many more injuries that we saw in the tornado last Friday. Now there's no going back,…
If they are breaking the law lets prosecute them. If there is a law you want changed vote for a legislator to back it. If you don’t like them, don’t buy from them. This isn’t complicated.
Earlier quoted context omitted.
A single-core single-tasking (or co-operative multitasking) OS kernel is fairly easy. You just need a memory allocator, syscalls, maybe some virtual memory or process isolation (as a treat), and a basic display driver. Writing the USB stack would probably take longer than the whole rest of the OS combined. (Though you'd be hard-pressed to write a USB stack in less than four months.)
That might be true (I don't know, I've never done it), but my point is that I would have thought that I could implement something as large as Linux or macOS in a few months, when in reality that's certainly not true even with my ~decade of experience, let alone when I first dropped out of college in 2012.
Is it possible that you're not making the "right" moves because you're the CTO? 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 th…
I think a CTO should have several mental models for making decisions. Minimizing wrongness is just one.
Some examples:
- Is this decision reversible?
- Does this choice allow my team to grow technically?
- Will this matter a year from now?
- Is this something I can buy instead of build?
- Is this a core competency that we should invest heavily in?
- Does this decision go against the company or your personal values?
- Is quick and dirty good enough for this?
There are several ways to orient the problem to help make a decision. But the OP is totally correct, this decisions will usually be made without all the data and with a lot of people looking at your decision.
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.