I found the article interesting, even given a large range of possible definitions of CTO.
I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.
For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?
I really appreciated this blog post, John, to know that you're doing what I've been doing without a guilty conscience.
I'm a VP eng/research at a startup and also feel like one of the few people apart from the founders who can push major technical initiatives by just doing it themselves, due to: business context, technical chops, architectural judgment, grit, and seniority to pull in cross-functional stakeholders to help out.
However, I have often questioned if it is correct that so few people in the org can do this and if I shouldn't be enabling others to do it themselves instead.
How have you been able to navigate not having any direct reports? Who does your engineering org report to and how are you able to manage conflict between org builders and your technical vision?
“ how are you able to manage conflict between org builders and your technical vision?”
That for me, is the core of the issue. I have been in a few places where senior management (up to c level) still code and are critical parts of the project team.
The problem is who keeps them to schedules and co-ordination with the other people on the project. Hard to complain about team level issues if the failing person is also the boss of the technical staff.
Build a demo perhaps to illustrate the idea/vision but don’t code, focus on the high level management and direct the ICs to build out the production version.
Both roles (management and coding) are difficult, demanding positions to do well, deserving of respect and commitment.
I'm curious about the simple, lightweight change management process listed in the article. Anyone have any tips on doing this well? I kind of hate the part of having to convince everyone of something "obviously better" :)
- Jira Epics (describe the why from the business standpoint)
- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status
- Two week sprints where engineering leads along go through epics
- New sub-tickets created by engineering (including design) and assigned to specific people.
- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.
- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.
That's pretty much it on the high level, unless I'm forgetting something.
One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.
That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.
Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.
I enjoyed this piece, including references to the Stoics and Spinoza. It preaches serenity, goodwill, composure, etc.
As someone in their 30s with children, work and a generally busy life, I wonder if anyone can recommend some pieces with more direct application - that is, in this vein, but perhaps an operational / how-to guide. Sometimes, it's hard to translate principles to action.
As someone in their 50s with a kid, work and a busy life, I’ve found the unlovable fact of it is these things resist a How To guide. It’s sort of like the thing about anyone who wants to be a politician shouldn’t be allowed to. If someone is distilling these things into a How To, at best, they grasp the ideas but lack the perspective that their lived experience isn’t anyone else’s, so the context is all lost. The bits and pieces that I’ve come to think which map up with the author’s tend to be found in books that lack a goal or a point.
As an aside, the Internet-driven grindset that everything, even a hobby, should have a point is one to resist with all your might. Think of the times you laughed loudest playing with your kids; I doubt you all were trying to achieve a goal beyond being together having fun.
There's some fairly strange and dated advice in here, like entering a door before a woman being impolite (unless it's a revolving door; those require strength, which women do not have?) or being emasculated by shaking hands while sitting down?
Consider outbound AI calls as a weapon against inefficiency. What is the game-theoretic equilibrium when faced with adversaries like call centers & other businesses with labrynthian customer service?
I bet it leads to more efficiency for everyone. When inbound robocalls deluge a business, the business pushes to cost-optimize its own service.
Business replaces humans with similar AI solutions to handle the phone modality, but hopefully then reverts to great service via email/API to reduce costs further.
Then, humans using AI voice services can "de-escalate" and revert to email/API AI, e.g. going from:
1. Business: AI (Voice) or Human | Customer: Human
2. Business: AI (Voice) or Human | Customer: AI (Voice)
Can you share more about your experience regarding how management at a small company lead to management at a big company? Was the switch voluntary, and how did you do it?
The short version is I got lucky. The slightly longer version is that at the small company I was doing tech lead things because I learned I could get more done to help people by helping organize the other engineers. Then when my boss quit to go sail around the world I was offered his job. I was now a "manager" but initially I still acted like a tech lead, writing a little code, taking care of the database, that sort of thing. The nice thing about the small company was they gave me space to learn and lots of mentorship. I got to see all the numbers on the business side and changed from being the "Let's write something new in Rust!" kind of developer to being the "But what's the simplest thing we can do to help our customers now" kind of manager.
Then I got a call from a friend I had worked with many years agi who was staffing up a new org. He needed people and had a very big budget. This is where the "career" part came in. I had a job with people I really liked, making okay money and could probably work there until normal retirement age. The new job offer was much more risky for much more money and I was always bad about taking risks. So I took a lot of long walks with my wife and we talked about the upsides and the downsides (upside: _so_ much money. Downside: What if I'm no good at the job?) and in the end I took the job. The job was in another state and my son only had two more years at one of the best high schools around so I got a small apartment and flew home every three weeks.
It was an incredibly learning experience. My new manager jokingly explained to me that my new job was people and if I was looking at code I wasn't doing my job. I took that to heart. I met some amazing people. I went to an insane number of meetings. I also got paged awake at 2:00am to be low-key yelled at by a group of Irish people because a computer in India wasn't getting enough network traffic and had run out of entropy. I think I helped some junior engineers with stories like "Ha! You think that was a screw up, let me tell you about my friend who turned off amazon.com for 6 minutes many years ago." And I learned the trick of going toe to toe with a senior architect in a design review meeting by asking "Okay, but what if these two things I'm picking at random happen at the same time?"
In the end it worked out for me. I saw other people go from SDE to SDM and then go back to SDE after a year because it wasn't a good fit for them. They were better engineers for having spent a year in management, but they didn't like it at all. Also I'm typing all this with the benefit of hindsight and probably making it sound easier than it was. I made lots of mistakes in my career, but going into management turned out okay for me.
And now I'm trying to write a Smalltalk VM in Rust and no one in Ireland is waking me up at 2:00am. I got lucky.
why a vm for smalltalk vs. one for some other existing language, or designing and then implementing one of your own?
just interested, because i am also working (very early stage) on a language interpreter. only in the idea and thinking of features stage so far. also, i am new to this area. but i find it fun.
"Absolutely ruined"? We still get value from flight, just now trade wait time and privacy for security. It's clearly still worth it for the vast majority of the world, see global flight stats.
I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.
For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?