Hacker News Reader

Comment by CobrastanJorji | Hacker News Reader

Man, if I'm trying to decide which company to work for, and I see a blog post from its CTO crowing about regularly checking in code on Saturdays and Sundays, I'd start backing slowly away. And when I got to the bit that said "AI has made me three times as productive," I'd turn and run.

Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not working through the weekend. If you're doing it, your reports and their reports will feel the need to do it, too. Don't. And if you do anyway, certainly don't brag about it!

And then listen to this insanity:

> Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.

That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute, but, being above that process, you personally choose to circumvent it, foregoing required legal or engineering reviews, and shipping it immediately to your critically important customer? If one of the engineers who worked under you did that, you'd probably have fired him.

View on HN

> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie.

This bit got me. It's a direct quote from the linked post for those who haven't read it

Hahaha I would have led with this honestly.

I’m the chief legal officer but at the end of the day I’m just like bruh, chill, who gives a shit

Then why are you the CTO!!

Dude just wants to be a staff engineer

Maybe. If he’s a technical founder though what other position would you hold?

Staff engineer. Founders don’t necessarily need to hold CXO titles to work in the startups they founded.

A few examples that spring to mind, Steve Wozniak and Mitchell Hashimoto

I recall James Goodnight of SAS coding while being a CEO. As per https://www.forbes.com/sites/peterhigh/2014/05/12/an-intervi..., he still programs from time to time but doesn't have a specific part in development. In looking at the articles to refresh my memory, it is clear he is one of the good CEO's

I don't think that's the model we should be looking at here. I'd add Stephen Wolfram to the very short list of similar technical CEOs.

Tobi Luetke at Shopify too

Wasn't Mitchell Hashimoto only a non-CxO for a handful of months between stepping down and selling the company?

I'm not that familiar with his employment history; you could be right. Either way, he'd still be an example. If you have longer term ones, I'm sure it would add to the discussion

It's not that uncommon to keep the "CTO" title and not be the primary manager of the engineering organization. There are all kinds of things you can do with the org chart. If I recall correctly, Clickhouse works this way.

The company's cofounders comprise three people [1]:

* Aaron, a sales-oriented CEO from Elastic and Salesforce

* Alexey, the original Clickhouse developer, as CTO

* Yury, an experienced engineering executive from Google/Netflix as "President"

An excerpt from the launch announcement [2]:

> While negotiations were still ongoing, Katz decided they needed a third co-founder. “I kept thinking, if I could get a third co-founder to run product and engineering, and if I could find someone with the same level of experience building distributed systems on open-source that I have on go-to-market, it could be a really compelling combination,” Katz says.

---

[1] https://clickhouse.com/company/our-story

[2] https://www.indexventures.com/perspectives/the-fast-and-the-...

He mentions he has nobody reporting to him. That sounds like he’s really a staff engineer with a vanity CTO title, plus a lot of sway in strategic decision making.

It’s not a guaranteed recipe for disaster, but it depends critically on his relationship with whoever actually manages the engineering org. If they don’t pull in the same direction, things go south very quickly and you end up with a little civil war.

Either way it’s a red flag and I wouldn’t work there. Another red flag is that he wrote this blog post at all. Given how clearly negative the reaction to it was going to be, it’s a strong signal he doesn’t really think things through and has a ego wrapped up in his “coding” prowess and ability to circumvent process. People mention Woz as an example of a technical co-founder in a non-management role, but he is a humble guy and wouldn’t brag like this.

How big is assembled in terms of headcount? That should resolve most of the questions we are raising.

LinkedIn suggests "50-200". 54 work in San Francisco, and 154 people are associated with it. So probably closer to 150, but that includes a lot of Sales and Marketing related roles. Maybe the "engineering" org is ~100 or just under that.

FWIW Carmack did this as CTO of Oculus [0]. Another configuration I've seen is for the CTO to have like 1 direct (VP Eng) who does actual eng managing. You could argue it's a staff engineer role but I've never seen staff engineers actually get much say over org direction/structure or be empowered to break gridlock like this.

[0]: https://www.uploadvr.com/john-carmacks-app-reviews-series/

This can work, imho, IFF the organization has both a CTO and CIO (or someone else tasked with managing the org). I've seen lots of places where the CTO is purely the technical visionary/advisor/final decision maker, and doesn't directly manage the technical organization.

This scenario is far more common outside of the tech industry, where you usually have a CIO running the IT cost center, and a CTO making decisions about technology adoption strategy.

CTO, CIO, and the head of engineering (the latter of which can often be split among different groups) are often very distinct things, especially at larger companies. And, yes, while the CTO probably has a seat at the table for technology direction is often primarily a public technology face of the company as opposed to someone involved in a lot of hands-on day to day technology implementation.

“Probably has a seat at the table for technology direction” is a wild take to me. So much so that I can’t even formulate a response other than “what…?!”

I'm not sure what you find confusing. Someone can have an advisory and essentially technology evangelist role without necessarily being the ultimate decision maker. (And, at a larger company, a variety of folks--including the board--will ultimately make final consequential decisions.)

How can the Chief Technical Officer not be the one chiefly responsible for technology decisions?

Because, title notwithstanding, they may not be the person solely responsible for technical decisions especially at the detailed (or macro) level.

There is a big leap between them not being the sole person responsible for technical decisions and them not even necessarily having a seat at the table for technology direction. The former is understandable. Later - quite surprising.

I'm not sure what I wrote that's contrary to any of that? Maybe I shouldn't have used the word "probably"? There are a lot of people responsible for the technical direction of a large company of which the CTO is important but hardly the only one.

I thought it's typically Chief Technology Officer

In most companies I've been a part off, including multiple >$1B tech companies, the CTO's focus is not on the engineering. That's the job of a VP Engineering or some similar position.

CTO (which will sometimes have a "CTO office") is to work besides the engineering on investigating new technologies and ideas that are beyond what the engineering organization would have otherwise done on the day to day. They are also an authority on all technology in the company but are not in the engineering "chain of command".

That said this is not universal, there are organizations where the CTO does lead the engineering organization. I think that's sub-optimal because there is always going to be tension between the day to day and the broader scope and those should be different roles.

In a startup, it is more common for a CTO to lead engineering because there is not yet enough to justify having both a VP Eng and a CTO and perhaps most of the work is around figuring out technologies. But as the company grows it makes sense to separate those functions.

I've seen both. A CTO office that also leads engineering--typically via a direct report to the CTO--and an organization where the CTO is largely an external evangelist (typically with a small staff) while engineering is a separate organization--though hopefully aligned. The view here where CTO is also the head of day-to-day engineering operations and technical vision is more of a small company/startup thing. The two are often separated to at least some degree at larger operations.

This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.

When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.

As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.

The technical capacity of a CTO matters less then the CTOs ability to stay in their lane (for a lack of a better term).

I once worked for a company with a self taught CTO (and not the good kind). They had a number of star players, and this CTO would frequently lash out at them. All because he was getting in the way of them doing their jobs, doing work he wasn't qualified to do, trying forcing them to clean up after him, and then yelling at them for it. It was insanely toxic. I only lasted a few months. It was so bad I back channelled patches and project briefs to people he liked to get them approved.

Had this CTO remained people, project and product focused everything would have been fine.

> this CTO would frequently lash out at them [...] doing work he wasn't qualified to do, trying forcing them to clean up after him [...] and then yelling at them for it

Was that a Fintech in Germany, by any chance? :)

I once witnessed a meeting between a CTO and a Tech Lead. The CTO was attending from his laptop in an open office, and he was yelling in Russian for one hour straight at another Tech Lead because he wanted the tech lead to finish his work. It was a pathetic display, with the whole company watching and wondering what was going on.

Eventually he was "phased out" by having a few people promoted to VP of engineering who would deal directly with the CEO instead of him.

Last I heard he tried to rewrite the financial core in Golang by himself, but he failed since nobody wanted to work together with him and he doesn't really knew the language.

Self taught in the programming sense, or the people management sense? Because I feel like the letter is much more common than not in software. Just curious in case there's an expected background you're thinking of when you say that. I have no point of reference for CTO backgrounds beyond generic MBAs or senior devs that either gave themselves the titles as founders or failed upwards.

You're not describing a CTO, then

"CTO" is defined by whoever confers the title and accepts the role. Titles are often vague and amorphous.

Also: "I currently manage no direct reports and ship a lot of code." So essentially he is just a staff engineer with a fancy title

Also, probably an asshole

Dude is a staff engineer, not a CTO.

(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.

My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.

I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.

In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).

You mention in the article you have no direct reports. Who does engineering report into in that case?

I'm glad you are comfortable coming forward and for sharing your thoughts. Not to pile on with the others here but you may go fast alone but you go far together when you build the right team. Being an individual contributor CTO is not being a CTO for a business that succeeds at scale. Don't stop doing what you love if you feel that's more important but it's probably best to step back from being a CTO and hire someone to manage that role so you can code if you don't want to do the job.

It sounds like you are CTO in title only

I would say that's the job of a CTO

I worked at company where the VP of engineering regularly stated that he "hated managing people". This is also the same guy who literally deleted the main production database because he was testing something out.

> That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute

This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well

Cowboy development might fly in an early stage startup. But are you even really a CTO or are you just an overpaid mid-level developer?

Just this. CTO title doesn't even make sense until your org is large enough that engineering vision and strategy becomes decoupled from execution.

I think the answer is in the blog:

"I currently manage no direct reports and ship a lot of code."

That’s not a role that I’d normally associate with “Chief” anything (which, by definition, means direct reports). More like Principal Engineer, or Architect.

In smaller companies, this is probably fairly normal, but you can’t maintain this, as the company grows.

I had a similar path, in my career. I originally started as a regular engineer, in a two-person team, and eventually ended up managing a small team of up to ten engineers.

Towards the end, I couldn’t write any code (for the company), at all. I still needed to code, but did so, for volunteer/open-source stuff. I think it made me a better technical leader (I had an employment contract without a clause that interfered with outside coding).

I remember wanting to take an iOS training course, but the company wouldn’t support it, so I took vacation, and went on my own dime. I never regretted it, but it was discouraging.

The happy medium that the CTO did at the company where I worked where I was the architect guiding the technical direction, he would do non production level experimental coding as research - integrations with third party APIs, see if an AWS service was suitable - to take some of the load off of me hand the code over to me and I cleaned it up and made it production ready and championed it to the rest of the teams.

He still helped accelerate efforts, got his coding fix when he had time, wasn’t in the critical path of any work, and he made the entire org better.

Isn't this the fun part?

That’s not a CTO, that’s a dev.

I was about to ask how someone in the C suite has time to code at all, ever, but here we are.

Trouble is, I don't think they'll just get it and then set about to changing the processes. Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.

Unless you're at a very small company, CTOs set technical vision, choose high level tooling strategy and outline engineering culture in broad strokes, but the nitty gritty of process will be from an engineering director or other role below the CTO. The CTO will probably provide feedback if needed, but they're not in the weeds and won't be able to see problems unless they're raised.

You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so.

I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.

Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.

> If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok.

If the CTO has rank then why not work to solve the unresponsiveness or undesirable things?

If someone--even a founder--can act as a loose cannon then there is a risk that they'll introduce problems like instability, security vulnerabilities, or unnecessary conflict or resentment. Compliance programs like SOC and PCI don't look fondly on staff bypassing SDLC processes because of those risks.

Exactly. Why change a process when you can be a superstar by ignoring it?

Fuck the customers, fuck the employees, fuck the investors. My ego is more important than any of this.

Well if they dont and you have to demonstrate that again and again, then you know what to do and hopefully have the power to do it.

> Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.

Not ime

You need to exercise your god given right to mog goons below you.

Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.

Business value? The ego trip is a business value!

God forbid you'd actually have to do any real work when there's so many design, retro, and daily sync meetings to attend and so many jira issues to groom.

Ive worked on both ends of the spectrum and id prefer too much process to too little

With too little process, people release bugs that I then have to scramble to fix. The CEO who pushed to skip QA and unit testing and everything in the name of release never has to deal with the consequences of their impatience

That same CEO would likely also push to have all of the things including no bugs, then complain people aren't productive enough when arbitrary and unrealistic deadlines aren't met.

Source: my personal experience. Very few of the managers who can code that I've worked with were better than any of the ones who couldn't, and those who did actively code while managing were universally worse.

You're conveniently skipping over the fact that he has full control over those things. He is the CHIEF Technology Officer.

Only indirectly (through management) and still having control is exactly my point. Obviously if you need to do that over and over there’re some other actions need to be taken

> This is exactly what someone who can't be easily unseated should be doing at a company

I mean yeah, but hes the fucking CTO. If hes the CTO, _he_ is responsible for that process. Its his job to evolve it to make it fit for purpose.

What he's done is basically created a whole bunch of process debt, which is much harder to correct than tech debt.

(Author here): I hear what you’re saying, though I’ve never “crowed about regularly checking code in on Saturdays and Sundays” and I think that’s a false characterization of my article.

Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.

And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.

I'm guessing you are ~28, maybe married and no kids.

> I built and shipped a working version in a day.

If I were an engineer working under a CTO doing this, I’d find it extremely demotivating.

Why, as a CTO, are you not setting things up so that I can do it instead?

he's also casually trashing their engineering team... "I built it in a day" is suggesting no one else could have.

I personally don't think there's anything wrong with doing it (i.e. shipping a feature quickly that a customer needs), but writing a blog post about it is questionable.

No, he clearly points that anyone else would have to be taken off their existing work and would have to context-switch to the context he already has. That's not trashing his engineering team.

I code as a founder/CTO on weekends, I don't expect weekend work done by anyone else and most people rarely check in if ever on weekends.

The job profile of founder-CTO has not a lot of overlap with that of an individual contributor to be leading by example, the overlap is quite narrow even for senior engineering leadership.

Until recently[3] leaders with prior coding skills were always discouraged from code contributions and focus on management exclusively, for all the reasons some of them you describe.

I usually say that I am a part-time coder, not a professional one, and caution not to look at what I do as a benchmark or signal.

Vast majority of the code I write are DevEx or QoL for internal teams[4], or refactor tech debt that no one has time to deal with. Even mid-stage startups may not be large enough to invest in dedicated teams for this type of work.

Occasionally I have written such integrations like OP[1]. It is typically a PoC for a demo, never a production one to actual customers. It would be unfair (and failure prone) to expect anyone else to start supporting a production integration without the full tooling or documentation.

I agree it is a fine-line and you can err on the wrong side of it. It is easy and tempting to start focusing on production code and lose focus of the core job, but so many decisions as a founder are like that. I am hardly the best or optimal founder-CTO. However the value of being close to the metal is important and worth some risk in early to mid stage startups.

Perhaps there is also value in a CTO who understands what individual contributors are doing and is able to be more realistic about outcomes instead of being purely few layers above and not clued in.

[1] Not skipping legal that seems ridiculous, even if I wanted to, I can't imagine any partner would agree to it.

[3] Now I do encourage to try the new tools, it is not they contribute to production or be an IC, it is to get a sense of what is possible and what is not today. A lot of pipe-dreams are being sold in the industry, without hands on experience using the new tools ( which are rapidly evolving) managers can tend to overestimate or misunderstand what is doable.

[4]This is the core of the CTO job, writing code is rarely the bottleneck for productivity that was true even before generative coding tools, it is everything around that which creates friction. If you can reduce it, even writing some code to do so, it shouldn't be a problem or a flag.

- Edited for brevity(some).

If you want to work on the weekend - and occasionally I find myself doing so as a staff level IC consultant who does need to spend an inordinate amount of time mentoring, project management, suppprting sales, interviewing candidates, babysitting clients, etc… - don’t send messages on Slack or email outside of business hours. I schedule messages to go out Monday morning and I never mention I worked on the weekend.

I don’t want to set the expectation that people should work outside of business hours or that I’m willing to.

I kill slack app on weekends , that is largely to save battery on the laptop working out of coffee shops, but serves the same purpose :)

That’s the point — I and others would have the opposite reaction, it’s self selecting, so it’s doing its job. I didn’t even read the article because I thought “boring, nothing special about a CTO who codes, we all do.”

> regularly checking in code on Saturdays and Sundays

If you’re working on insurance SaaS, I agree.

If you’re building hard tech, I’d disagree entirely.

Don’t just back away slowly. Run for your life!

Prediction: this is the part of the AI boom that goes bust.

Calling this guy a CTO is a stretch. He's a senior developer at a company with no CTO.

If you wanted to work yourself into a CTO position, his shop might not be a terrible choice, although I would imagine it would be a bit rough at first.

The "C" stands for "Cowboy"

It seems like you're confusing technical founder CTO at a startup with professional CTO at a large org.

For the later, what you said makes some sense, and it definitely seems like you're more familiar with this archetype.

For the former, the article appears correct. If you've not worked at an early stage startup before, the culture is _very_ different.

As a side note: This article is doing it's job. People that are a good fit for the company will agree, and want to work with them. People that are not a good fit for the company will not agree, and naturally run the other way. Makes filtering out candidates easier.

Working at a startup can be rewarding, but it often means putting in founder-level effort while the founders capture most of the upside.

At an early stage startup, shipping a feature should not require "many meetings across product, legal, and engineering". Especially not one that can be mostly built in a day.

Snake-style org vs Elephant-style org. Nature accomodates lot of survival strategies. People shouldn't unnecessarily criticize others.

In that story, we don’t know why legal would need to be involved. Maybe it’s for a good and essential reason or maybe it’s for a sand-in-the-gears reason.

Maybe the CTO’s company uses GPLv3 or AGPL software and the customer’s legal department vomits all over AGPL and demands extensive review for GPLv3 for their developers. Or maybe they’re worried about later finger-pointing and support issues. Or ensuring the company is running on unmodified, mainline sources.

Those would all be reasons why the CTO’s company could ship without involving customer legal teams without it being a red flag to me.

I fondly remember times when at one company CTO was doing round the dev section at 4:50pm and saying everyone close their machines. Go home or to pub, it's an order.

Once I sent an email at 5:45pm as I forgot to say something earlier about the project. I didn't get a response and in the morning got told off that I should never send an email outside of working hours, unless it is a personal matter that cannot wait.

Couple of years later the owners exited and new management replaced everyone with workers from consultancy of theirs. Company no longer exists.

> An engineer unfamiliar with that part of the codebase would spend quite a lot of time figuring out those details.

Your job is to delegate, yes, the first delegation is hard, but the engineer either grows, or doesn't (then you need to move or yeet).

Yes I understand that you want to code all the time, then you're not a CTO. A CTO leads from the front, leads with process, and context. Your job is to provide context so that your team can execute.

> foregoing required legal

depending on the legal requirement it may not have been foregoed but instead became legal because an executive did it

I took that a step farther and got written into our SOX compliance processes explicit “deviate from normal processes as much as required when this short list of people declare an emergency”, shamelessly cribbed from aviation law.

Slightly more details here: https://news.ycombinator.com/item?id=39174707

They brag about hiring on visas, so you can read between that post and the visa sponsorship as a 996 organization.

What’s your gripe with the part about the AI productivity boost? For anyone working in fairly standard web dev tech, I’d say it’s more of a red flag if a boss denies the productivity boost of these tools (at least when used by senior devs)

> Your job at the top is, more than anything else, pushing down a healthy culture. The CTOs role leading the tech folk to support business goals, which culture a part of. The healthy part is a subjective thing.

Agree. Let me say much the same through a parallel line of observation: maybe you dont need a this cto or any cto? Maybe you need to move this guy to sales.

Goodness gracious corporate america. Can we PLEASE stop with hustle and bs?

You ever heard buffet or munger say everyday they do some bill keeping in a double entry accounting system and AI makes them better? Never. Why? Because when you and your org are competent you're not constantly on the hussle. My guess if they need to, they do and as they have things on their mind they don't have time to blog about.

People know what management at Berkshire Hathaway stands for. Case closed.

Competent upper management can be a boon for orgs esp on cross functional management which builds the org and keeps ia from infighting and running in 10x different directions. This guy isn't that. Moreover that means other people on the board don't know that either.

Thank you for sharing this. The part about Warren Buffett and the contrast with hustle culture is particularly delightful. It highlights the importance of competence and meaningful leadership over performative busyness.

> During Thanksgiving break, I just decided to build it and knocked out a prototype.

You don’t want a boss that works on Thanksgiving and thus probably expects you to as well ?

I’d actually be ok with this if bro offered half a million total comp. I’ll deal with it for 5 years and then retire.

Flabbergasted to say the least. Dude do your job. Fix the process. Don't set a bad example.

Frankly if you’re a CTO you aren’t incentivized by a salary. It makes sense in this case no different than you’d code on the weekends for your side hustle.

It only doesn’t make sense when this jackass thinks the salaried engineer needs this “grit”.

C-levels aren’t supposed to be “model employees”. The incentive structure is wildly weighted in their favor. Instead you should ask them to understand the difference, which is asking a lot of these sociopaths, but I digress.

So in your view c-level are all sociopaths? Let me guess you are not c-level. Or maybe you are but you’re the exception to the rule.

Hasn't it been repeatedly shown that C-level positions select for sociopaths?

Regarding culture:

Complete nonsense. The free market will tell him if he can do this or not. If he can get valid candidates pushing this culture and it’s legal, why shouldn’t he? You, anyone interviewing there or anyone working at their company presumably doesn’t have to work there. Most countries don’t have slavery for tech jobs!

No doubt he will lose many candidates with this culture (you and I included) but maybe that’s a strategy? Maybe he still gets plenty of candidates that are good and the culture he wants.

Reply on news.ycombinator.com