I'm pretty sure that "replace the homeless man with a park bench" image was a reference to some TV show making a gentrification joke, but I can't put my finger on it. Anyone recall?
It depends on what "secure" means. Any lock can be destroyed with tools. Most locks can be broken with a big pair of bolt cutters, a drill, or, failing that, melting.
If secure means "without leaving evidence of tampering," things get a lot more interesting, but that has narrow practical use cases outside of stuff like espionage. Once you're in this space, we can start talking about how difficult something can be without specialized tools. But now we're leaving "I am protecting my stuff" territory and entering "this is just a sport and we're agreeing on a ruleset" territory.
There are a couple of lock designs out there that I don't think anybody's successfully ever picked. The ones that first come to mind are a couple of the "smart" electronic locks. Many of those are junk, but a few are very well thought out.
That was a really well written article. I think even somebody who had never heard of a Turing Machine could probably have gotten a pretty reasonable quick understanding of roughly what BB(5) and BB(6) are and how the Antihydra works and its greater mathematical/historical context. That's hard to do, good job!
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.
> 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
(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).
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.
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.
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.
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.)
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.
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 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.
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.
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.
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.
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
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
> 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
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.
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.
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
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.
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.
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.
(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.
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.
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.
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.”
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.
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.
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.
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.
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.
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.
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)
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.
> 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.
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.
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.
Just as a judge should not be ruling on a case where the defendant is throwing suitcases full of money at him, a judge should also not be ruling on a case where the defendant is his own son. Both are inappropriate uses of a power intended for the application of mercy and the correction of faults in the justice system. Both are the sorts of things that should lead to recusal.
Biden's use is far more forgivable, as it's a given that his son was being prosecuted politically to punish Biden (though certainly he was guilty) and would likely have been prosecuted more under Trump, like Comey is being prosecuted today. And certainly "saving your children" is a far more forgivable sin than naked bribery, but being better than Trump is a low bar, but it's still not okay to excuse criminals from punishment because they have an important family member.
If you ask, the leaders in that area of Google will tell you something like "we're actually HELPING users because we're giving them targeted ads that are for the things they're looking for at the time they're looking for it, which only makes things for the user better." Then you show them a picture of YouTube ads or something and it transitions to "well, look, we gotta pay for this somehow, and at least's it's free, and isn't free information for all really great?"
You can totally create a private version of NOAA so long as you keep the messaging about insurance intelligence and never, ever speculate out loud about the causes of hurricanes. And if that's not enough, just do what Meta did and hire some shmuck like Robby Starbuck to signal that you're on the right team.
What they want is for the government to run the satellites and provide the data on the taxpayers' dime, but only let private companies interpret that data so they can sell their forecasting
Google (with partner companies) launched a climate-monitoring satellite last year. Thanks to SpaceX, it’s cheaper than ever for private organizations to launch satellites.
I think they've gotta maybe define what counts as an "Apocalypse." The active "Fourth Turning" hypothesis expects a crisis on the scale of the Civil War. That degree of crisis has happened lots of times. Certainly the Civil War itself was accurately predicted for decades leading up to it.
Agree. You can always claim prescience by being vague enough. "Something really bad will happen" will eventually come true. I suppose the point of this site is to call out the ones who dare to be more specific.
Seems like it worked fine. They laid off a quarter of their junior principal engineers, the stock went up. They had a massive outage a few months later, the stock went up again. Everything's working out fine for their strategy so far.
I remember comments saying the stock went up because the average joe didn't realize how much of the internet was powered by AWS until all their day to day apps started failing. To most people Amazon is an online shopping site.
You would think this would eventually show up on the balance sheets, right? Presumably a lot of their big customers have SLAs with money penalties, so maybe next quarter earnings? Or quarter after that?
SLA monetary penalties won't make the difference there. Enough giant customers moving substantial workload off of AWS (either to another cloud, or otherwise) would, but the timeline for that is years, not next quarter.
reply