5 ms·

Ask HN: Transitioning from DevOps to co-founder/CTO/lead dev?

22 points by throwaway7508 8y ago

I'm late 30s, spent most of my career as an SRE / DevOps engineer with a few big names on my CV. Currently working at a startup in a team of ambitious 20-somethings : my role has evolved from DevOps to "swiss army knife" doing architecture reviews, performance troubleshooting, technology direction and generally being the adult engineer in the room, pointing out pitfalls and icebergs to the young CTO/cofounder. I feel my next logical career step is to start something myself. The main issue has been that my core skillset (and importantly, current mindset) is more tuned to architecting, scaling and operating a service than actually building it, which is what is expected of a tech co-founder at first. I should have the background to pick up any language quickly (I did x86 assembly in the 90s, taught C, dabbled with Java/Python/Go), but I lack immediate motivation, time and ideas for side projects. Frontend dev seems overwhelming and backend dev pointless without an idea. The result is that I'd probably run scared if a potential business co-founder asked me to be his dev buddy at a hackathon the next weekend, and I'll keep missing these opportunities to less experienced engineers. Should I just fake it until I make it ? Has anyone successfully managed this transition ?

jf22 8y ago
Are you asking if you can never program but become a technical leader that manages a team of developers? Sure, it's happened before. However, your developers will probably not respect you. You'll have enough skills to convince management you know what you are talking about, but developers will see through you and know you don't truly understand the code.
- sidlls 8y ago
  Most of the problems my team faces today are due to poor architecture decisions, often made by people who express a similar opinion as you have. Coding is the relatively easy part.
- throwaway7508 8y ago
  That's not really what I'm asking, no. I've been programming since I was a child in the 80s basically, but virtually all of my career has been focused on sysadmin/DevOps/infrastructure and I don't have coding side projects at the moment. I'm looking for advice from engineers like me who were still very hands-on on the DevOps side of things + had good technical vision owing to a long experience, and ended up part of a co-founding team. Did they have to purposefully decide to hone their full-stack dev skills first in order to become more attractive to potential business co-founders ? Or were they able to make use of their existing infra/backend-oriented skillset, maybe by teaming up with another tech co-founder with complimentary skills on the product/front-end dev side ? I suspect one of the mental hurdles is that you have to transition from a "run" mindset where you spend most of your day taking other people's code live and operating it (what you build is "just" the infra and systems around it), to a "build" mindset where you actually code the business logic (but don't necessary understand how to run it reliably :) )
  - deleted 8y ago
    [deleted]
toyg 8y ago
If you lack motivation for a side-project, how would you not lack motivation to build anything on your own? To me, it sounds like you lack the fire that a founder needs. I’m not sure I see the point of this question, tbh. If you want to swim, you have to get in the water; there is no point sitting on the beach thinking “I’d be an awesome swimmer, but how do I get in the sea?”
themmes 8y ago
Interesting question, wish I had the experience you have! What exactly will you be faking in order to make it? Its hard to fake starting a company. On subject: If your mind is set on architecture, scaling and operating then thats probably a strong domain to start your startup. Consider it your domain, not an incomplete puzzle. After finding motivation and possible problems to tackle you can find a team to complete the puzzle. On motivation: I wonder why you feel this urge? What makes you think there are logical steps in careers? Sure, there are paths many people take, but you probably only should when you feel you're missing something, not simply because everyone else does. Try listing problems to solve (see below) and see if there is one you would want to make time for. On ideas: I do not think you should think in ideas for side projects, think problems instead. I've seen many people never start anything because they were only looking for the unicorn idea. Metaphorically; - What tool on your Swiss army knife is most worn out? Why is that? - Probably you take a scalpel for some problems instead of a Swiss army knife, why is your scalpel better? - I personally always have the problem of not being able to get the knife out without nails, how did you solve this over the years?
- throwaway7508 8y ago
  Insightful answer, thanks ! What will I be faking until I make it ? Quite simply the ability to answer "yes" to the question "Hey, I'm product guy and here's designer guy. Do you want to be our dev at the local hackathon next week-end ?" There's no way I could do that before going through a couple of language + framework tutorials. Probably JS + React + ExpressJS, or Bootstrap, Vue, and Django / Flask or even Phoenix/Elixir if I want to be hip. And I'm not sure how long it might take to be ready. Probably days not months tbh. I suppose I should just do it, but so far I've lacked a really good opportunity to motivate me to take the plunge. I don't want to lie about this, and I'm introducing myself as an "engineer but not a dev" at startup meetups : because of that I know I've lost a few co-founding opportunities already. Why the urge now ? I guess because working with younger founders has suddenly reminded me that you don't need to know everything and do it all right to get to be a startup CTO. And the best way to be a startup CTO is definitely to be a co-founder : you rarely find those positions on LinkedIn.
laurentl 8y ago
I’m in a somewhat similar situation. Started my career 15 years ago as a dev, quickly moved to technical project management. Then I moved to infrastructure in a variety of roles, essentially around management (of project managers, architects, HW engineers, etc). After 10 years of that, I completely switched tracks 2 years ago and became the CTO of a startup in the insurance sector. I joined as the first employee and the first IT person. Like you, I was worried about my lack of recent experience in development. I had to cram for the technical interview but it boiled down to architecture/dev best practices and talking about a small side project I’d done (to reassure them that I would be comfortable coding myself). After I got the job I spent a few weeks coding in earnest: nothing like the perspective of a new job to focus the mind! When I started the job, I quickly found out that although there was some coding involved, a surprisingly big part of it was very similar to my previous jobs: security audit, contract management, hiring... My first hire was a lead dev to help me with the back-end and to do the front-end. So, I managed a similar transition (although the circumstances are a bit different), it was easier than I expected, and I haven’t regretted it for a second. Hi for it! (If you want to chat, send me an email)
matt_the_bass 8y ago
CTO should be a leader with big vision how the technology will fulfill problem. A CTO should be fluent in understanding big picture pitfalls and hurdles. But in a larger team/well funded startup, their role is not to do the everyday coding. That being said, the CTO should be able to jump in on code reviews of major components and be part of the discussion on how to architect the solution.
- throwaway7508 8y ago
  Well, everything you say here sounds like me to be honest. But as I've mentioned in another comment, you rarely get to a startup CTO/co-founder position without recent everyday product coding experience, even if you have the big picture experience + current hands-on abilities in another field (infrastructure as code for me). That's the conundrum I'm trying to solve.
  - matt_the_bass 8y ago
    Cool. Then if this is something that interests you, just give it a shot! Good luck.
karmakaze 8y ago
As reluctant as I am to say it, you may get by fine as I have worked with CTOs with less broad technical background. I will point out a number of things I'm picking up on that may cause problems: - shouldn't belittle co-workers based on age or any other non-merit: "being the adult". Late 30s is not that much experience. You admittedly lack some experience in other areas. - your experience in "architecting" seems to be ops-related. There are bigger architecture issues that precede it, namely back-end and front-end program architecture. Without this experience, you may make some bad calls and not even be aware of it for a long time as critique of one may just sound like opinion without a deeper understanding. - seems that in the 90s, you did have 'motivation' to stay on the leading edge or at least keep up. It's fairly common for a CTO to have lost some of their edge, and practice but they should have at one time been deep in the full stack. - "Frontend dev seems overwhelming" -- it's not, just do a React tutorial, Vue is easier for picking up the way things are connected but React is more prevalent. - "backend dev pointless without an idea". This is the most alarming. Any upper management needs to have drive to get whatever needs doing done. You've identified these are blockers and at the same time labelled it pointless. Getting stuff done means not only working on the goal but also working on resolving all the blockers impeding progress to that goal. Perhaps, I'm misreading this and your perception is that this is not a blocker, hence this 'Ask' posting to determine just that. Some things don't add up like "missing these opportunities to less experienced engineers". If they're 'less experienced' than how come they can take the opportunities you're missing? All that said, you may be able to carry on, but do find some way to make an unbiased assessment of where you're currently at. The worst type of any manager is one who operates with a level of insecurity or fear.
- deleted 8y ago
  [deleted]
- throwaway7508 8y ago
  Thanks for your reply. Let me clear up some misunderstandings : I didn't mean to convey I have a "less broad technical background" or haven't kept up with the bleeding edge, quite the opposite : my edge is a better-than-average understanding of the full picture from the kernel/networking layers up, and having seen the systems and development landscape evolve since the 90s. That's how I got the "big name" SRE jobs I suppose. In dev terms that means I know why and when you'd use Go, NodeJS, Rust or C, or why CQRS and 12Factor matter. What I lack is recent day to day "in the trenches" product development experience on a large software codebase using framework-of-the-day. I am still very much hands on, but in the DevOps space only (Kubernetes ecosystem tools basically), which isn't as immediately useful if someone asks me to prototype a product next week-end. "Being the adult" was a half-joke and I didn't mean to belittle my younger colleagues, who are awesome at what they do ! But more than a few times, I've seen them going head first into a well-known trap, not knowing what they don't know and undervaluing experience and words of warning, doing hacks their future self will hate them for, or poorly reimplementing something the industry has long had a solution for, thinking they're above that. These are all hallmarks of inexperience and young guy hubris, and it's been frustratingly hard sometimes to articulate to them why they were wrong. That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end. I'm aware of that and would like to remedy it, and this "Ask" is for getting tips from people who may have been in my shoes. Another way to phrase my question : "I have arguably valuable experience and tech vision, plus current hands-on skills in DevOps, but none of that is as immediately useful in a tech cofounder situation as being able to quickly whip together a front-end + back-end prototype with possibly dirty but working code. Any tips for getting there ?"

karmakaze 8y ago
That clears things up. I'm glad that my concerns were a misinterpretation. I myself have been in your shoes in terms of not being able to communicate hard-earned lessons to those less experienced. I don't have a remedy for that other than time. The problem is that if devs follow your advice at face value, they may not run into issues but they can't internalize what they never ran into. Only after they've learned enough can you communicate by analogy in a way that's meaningful. Another trap is that being an expert in one subject area is often dismissed in others which seems reasonable for those with singular depth of knowledge. I've encountered this with mobile dev where I had highly transferable desktop GUI experience to make mobile dev straight forward but until I demonstrated it others would have no clue. Also, the differences in languages tend to be mostly syntactic but some consider that you either know or don't know a language. Another thing that has helped greatly in my situation is pair programming in a small startup. I had already done some mobile & web dev tutorials but pairing on production code fills in the details. It shows how much of what you already know is relevant. Eventually they also pick up better ways of doing things when you either build it a different way but best when you're fixing an issue that was done a poor way. This pattern has repeated enough that I've come to terms with it--any time I'm at a new startup, I give it 6mo-1yr for the team and management to fully figure it out. > That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end. This is a key point, worth seeing from another perspective. Consider that delivering end-user visible features quickly is actually more valuable 'in the present' and long term architecture is for later. We've gone through 4 products/pivots in two years, having spent good architecture/engineering on any product but the last would have been a waste (and we did spend it on the second one). Thing is, we never know which product is the last one. The cadence that's been working out is that others develop new features on products and I pair with other devs sometimes building features but more often improving existing ones by extending them, refactoring them, or simply fixing bugs and making them more reliable/performant. Retros and the occasional Lunch & Learn to share with the extended team to round it out. The most important thing is that it's all done without pointing fingers (or right/wrong labels). Under the same circumstances I would likely behave similarly, so it's best to think of everyone being on a similar path, just at different points. Having written this I think the biggest change was in myself having more patience and seeing more experience/knowledge as just that to be shared and not any kind of superiority. [Less than perfect: I have been known to 'go rogue' on specific issues (not recently) though it's mostly worked out.] Edit: Do play with a newer framework or two. I chose Vue.js and Flutter/Dart. And you can sidestep much back-end coding with GraphQL.