
Ask HN: Transitioning from DevOps to co-founder/CTO/lead dev? - throwaway7508
I&#x27;m late 30s, spent most of my career as an SRE &#x2F; DevOps engineer with a few big names on my CV.<p>Currently working at a startup in a team of ambitious 20-somethings : my role has evolved from DevOps to &quot;swiss army knife&quot; 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&#x2F;cofounder.<p>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.<p>I should have the background to pick up any language quickly (I did x86 assembly in the 90s, taught C, dabbled with Java&#x2F;Python&#x2F;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&#x27;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&#x27;ll keep missing these opportunities to less experienced engineers.<p>Should I just fake it until I make it ? Has anyone successfully managed this transition ?
======
karmakaze
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.

~~~
throwaway7508
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
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.

------
laurentl
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)

------
themmes
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
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.

------
toyg
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?”

------
jf22
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.

~~~
throwaway7508
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 :) )

------
matt_the_bass
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
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
Cool. Then if this is something that interests you, just give it a shot! Good
luck.

