[HN Gopher] Ask HN: What are good books/blogs to read for a firs...
___________________________________________________________________
Ask HN: What are good books/blogs to read for a first time CTO?
Planning my first startup as CTO, what resources should I go
through for sure.
Author : kanodiaashu
Score : 431 points
Date : 2023-12-29 09:18 UTC (13 hours ago)
| CityOfThrowaway wrote:
| Peopleware is a classic
|
| https://www.amazon.com/Tom-Demarco/dp/0932633439/?nodl=1&dpl...
| cientifico wrote:
| There was this related post in hn that might help you.
|
| https://news.ycombinator.com/item?id=37971795
| kozak wrote:
| If it's just a "planning my first startup" stage and not an
| existing enterprise of some non-zero size, I'd suggest starting
| from the book "The Lean Startup" by Eric Ries and other general
| "startup mentality" information sources. For a tech-minded CTO,
| it's especially important to have that correct "startup
| mentality" to avoid big mistakes from the start.
| Omroth wrote:
| The Meta Cast (Bob & Josh) is very useful for getting an insight
| into team management.
| sergioisidoro wrote:
| An Elegant Puzzle: Systems of Engineering Management, by Will
| Larson
| emmanueloga_ wrote:
| I'm reading the O'Reilly book on terraform. The end appendix has
| a great list of books to read for a CTO. Also planning to check
| the author other book, "Hello, startup" (see [1]).
|
| 1: https://www.ybrikman.com
| eddyzh wrote:
| It's old but a mythical man month is where dev management books
| realy started.
| wslh wrote:
| Assumming you have worked as software engineer I recommend to
| talk with other CTOs, product people, and/or senior engineers
| (peer groups) and have concrete problems you would like to solve
| in mind.
|
| What kind of startup you want to build and in what field? Knowing
| more details about the challenges you will face help to narrow
| the focus to specific knowledge and skills.
| elmarschraml wrote:
| Depends a lot on your situation:
|
| Does "CTO" mean you are the tech lead of a small (single team)
| engineering organization? Then everything written for staff
| engineers applies. E.g I've heard good things about "Staff
| engineer's path" by Tanya Reilly.
|
| Does "CTO" mean you are leading an org that is too large to be
| hands-on with tech, and need to build an effective structure and
| culture? Then I second the recommendation for "an elegant puzzle"
| by Will Larson.
|
| Or does "CTO" mean that you switched from being an engineer to
| managing a team of engineers? Then everything for new managers
| applies, for starters I'd recommend "Becoming an effective
| software engineering manager" by James Stanier, or "Engineering
| management for the rest of us" by Sarah Drasner.
|
| For some good general material, I'd also recommend the resources
| that Gergely Orosz makes available for subscribers to his
| "pragmatic engineer" newsletter. Those are templates for the kind
| of documents and processes you will most likely need - if you're
| new to the role, you will not go too wrong by using them, and if
| you want to create your own they are excellent starting points.
| skrebbel wrote:
| And maybe CTO means "the founding programmer of a new startup"
| in which case my advice would be to stop reading and start
| coding :-)
| 946789987649 wrote:
| There's always time to read, you can't only code. E.g. I run
| a lot so I get through a hell of a lot of audio books.
| ysavir wrote:
| I don't think the parent comment means only code, never
| learn. I think their intention was to not worry too much
| about the "CTO" title and instead focus on building the
| product at hand.
| skrebbel wrote:
| Yep. When building a startup you'll find a lot of well-
| meaning people (in books or in person) who really do
| nothing but distract you. YC got it right, you should
| make something people want. Everything that's not either
| making something or finding out what people want is just
| going to slow you down.
| leetrout wrote:
| Too reductionist.
|
| You must "sharpen the saw".
|
| This takes many forms including adequate learning /
| training for self improvement as well as investment in
| your tooling that will pay dividends on delivering faster
| or with higher throughput.
|
| These are second and third system effects that require
| intention to monitor or measure but the effect is real.
| skrebbel wrote:
| Of course nothing is black and white, but if you have
| limited time/money then you want to get to ramen
| profitability _fast_ and you simply don't have time for
| business model canvases, the perfect employee option
| scheme, a scalable k8s setup or a perfect CI /CD
| pipeline.
|
| There's _so much stuff_ that feels important and
| valuable, but _so little of it_ really cannot wait until
| after your wheels are off the ground.
|
| When you read postmortems of startups that didn't get
| enough customers, often it's this stuff that actually
| went wrong. Too much time spent on other stuff than
| "build something" and "that people want".
|
| To my experience, it's difficult to resist all that good
| advice that's all over the internet, books, accelerator
| programs and the like, and saving it all for later.
| People will tell you "you should get $PETPEEVE right from
| the start" for every imaginable pet peeve (all the way
| from legal stuff to unit tests to SEO) and they'll be
| very convincing. Trying to resist this is not
| reductionist, it's super hard.
| Quiark wrote:
| I'd say the time for sharpening the saw was before you
| started the company. The next opportunity to invest into
| best practices / long-term is when the company actually
| has some traction.
| skeeter2020 wrote:
| The entire point of sharpening the saw is that it is
| continual though. It doesn't have to be a major
| investment or long-term, in fact it explicitly references
| "Daily Self-Renewal". I believe the original comment
| branch just meant don't worry about "what's applicable to
| the CTO".
| ysavir wrote:
| Sure. But the point was that if you're a team of 1
| engineer, even if your title is CTO, time spent learning
| "how to be a CTO" when you don't have any team whatsoever
| is time not spent building the prototype that needs to
| demonstrate $XX value/growth by YYYY-MM-DD in order to
| survive.
|
| Learning is always encouraged, but you should be learning
| to solve the problems you're about to face. Learning to
| solve problems which aren't going to be obstacles in the
| near or mid future isn't helping you in your immediate
| circumstances. Sometimes the immediate circumstances
| aren't much of a concern, but when they are, you need to
| be sure you're learning with that in mind.
| dasil003 wrote:
| Any advice is going to be reductive when measured against
| the reality of building a startup. While learning and
| continuous improvement are table stakes, I think the GPs
| advice is much better to get first-time founders overall.
| "Sharpening the saw" is likely to feed perfectionist
| tendencies, or send them into dopamine learning loops
| online. There's a reason that "bias for action" is
| treated as a highly valuable trait in founders.
| endymi0n wrote:
| And honestly, pre product-market fit my advice would be not
| even coding, but iterating in an extremely scrappy way (read:
| Google Sheets, Jupyter Notebooks, no-/low code, handwritten
| invoices) until you have people paying for your product and
| not churning after the first month. Everything else comes
| secondary. For every company that didn't manage to scale
| their tech and teams fast enough, there's 100 that die by
| ,,building and they will come" a polished app with great UX
| through 4 ecosystems that get launched to deafening silence.
| fullstackchris wrote:
| this is perfect advice which i can't agree with enough.
| that is unless the founders insist on a flawless UI... then
| you are in for a world of pain
|
| never understood why teams of literally 1 or 2 devs are
| always forced to try attempt to acheive the visual quality
| of apps like instagram, whatsapp, etc
| liquidpele wrote:
| > never understood why teams of literally 1 or 2 devs are
| always forced to try attempt to acheive the visual
| quality of apps like instagram, whatsapp, etc
|
| For the same reason those kinds of places have more
| managers than workers... it's a vanity project.
| skrebbel wrote:
| Tbf I believe this depends a lot on the product category.
| Uber could do this in their first few months but eg Retool
| couldn't.
| macNchz wrote:
| Obviously some ideas can't be tested without writing some
| code, but it's more of a mindset than a strict playbook-
| many programmers (myself included) tend to bias towards
| wanting to write code and avoid sales conversations until
| the thing feels "done". Tech message boards are littered
| with programmers trying to justify why _their_ app has to
| have a full polished build that will take a year before
| they can begin selling it.
|
| When you get in the habit of asking yourself, before
| building, how you can learn the most about what people
| want with the least amount of code, clever ideas often
| come to mind.
| techbiotic wrote:
| :-)
| mooreds wrote:
| Haha, for sure. I wrote about that contrast here a few years
| ago: https://www.mooreds.com/wordpress/archives/2555
| belter wrote:
| His productivity will shoot trough the roof, when it moves
| into deleting code.
| Aurornis wrote:
| > For some good general material, I'd also recommend the
| resources that Gergely Orosz makes available for subscribers to
| his "pragmatic engineer" newsletter. Those are templates for
| the kind of documents and processes you will most likely need -
| if you're new to the role, you will not go too wrong by using
| them
|
| One word of caution: Engineers and EMs read these newsletters
| and even management books, too.
|
| It's not hard to see when your leadership is just parroting
| things they read from a book or newsletter and trying to pass
| it off as if they had deep leadership experience. Engineers are
| good at seeing through cargo cult leadership.
|
| I suggest that if you embrace a practice found in a book or a
| newsletter, be transparent about the source. Encourage people
| to read more about it in the book or newsletter where you found
| it. Don't try to pass it off as a management technique you
| invented or pulled from deep background experience, because it
| feels disappointing to the team when someone realizes their CTO
| is just parroting things from a newsletter or blog and trying
| to hide the source.
|
| Also, don't get into the mindset that having read a lot of
| books or blogs or podcasts or newsletters is a substitute for
| experience. Some of the worst leaders I've had were those who
| would lord their book knowledge over everyone as though it made
| them the confident expert on everything, while we could all
| clearly see that the extents of their knowledge started and
| stopped with what was contained in the books they read. Books
| contribute bits and pieces and give suggestions to add to your
| corpus of knowledge, but if you treat them like definitive,
| all-encompassing sources of wisdom then it's going to be clear
| to people that you don't really know what you're doing. Be
| honest and stay humble.
| onetimeuse92304 wrote:
| That's a very good point. A "CTO" can mean any mix of
| managerial, leadership and technical responsibilities.
|
| It is my assumption that a CTO is usually coming with technical
| background already except when he/she is a cofounder and they
| got technical domain as a result of division of
| responsibilities. But I am suspicious of startups where none of
| the cofounders come from technical background.
|
| That leaves managerial and leadership. IMO, if you are a CTO,
| managerial is something you can hire other people to do for you
| as your technical organisation grows and leadership is
| something you should really be focusing on.
|
| You can have flourishing technical organisations with the CTO
| being a poor manager but a good leader but very unlikely with a
| CTO with good management but poor leadership skills.
| mac-mc wrote:
| Even if you're effectively 'just' a tech lead of a small team,
| like I am, it's still a very different job than being a tech
| lead of a small team in a larger company. You are at the top
| level of the small group, so you end up being involved in a lot
| more non-tech things than you think you would be.
|
| Your peers are not other engineers and engineering managers
| like you would be in most situations, but marketers, product
| people, designers, PMs and so on. Who is the founder and
| ultimate authority (CEO) and if you are a co-founder or not
| also really changes things. A founder CTO is also very
| different from a non-founder CTO. Co-founder conflicts is a
| huge thing to manage, (see https://flocrivello.com/co-founding-
| considered-harmful/ ) because at a small size even as a non
| founder, you're pretty close to it. You should decide upfront
| if you're going to approach the job as another effective
| founder or employee and communicate that to founder at the
| start as part of a conversation.
|
| I made the transition from staff eng to eng manager to CTO at a
| small startup, and each one is still a very different job even
| though the skill sets transfer greatly. I code way more at the
| startup than I did as an eng manager too. Several things I
| would suggest:
|
| 1. You're an exec, even if your company is tiny, and how it
| works is different than being a manager. Concepts like the
| 'first team' https://www.michaelvizdos.com/resources/first-team
| and 'getting on the balcony' matter way more than when you're
| in a purely product & eng organization:
| https://www.bettermanager.co/post/move-away-from-the-dance-f...
|
| 2. Don't be shy about getting exec coaching, and having the
| company pay for it. We did that and it was very helpful.
|
| 3. Read Radical Candor (updated edition!!!), but also read it
| with a bit of a grain of salt, realizing the title and advice
| was chosen because the writer wanted to balance their general
| high agreeableness with a counterweight that goes too far for
| the typical person IMO, which the writer writes about that
| exact dynamic in the second edition.
|
| 2a. Learning to be properly direct is super essential,
| especially at small sizes where its more make or break based on
| how emotionally deluded you are. The people you are working
| with need be able to handle you being real with them too. If
| they cannot, move on, it's that important.
|
| 4. Expand your skill set, do everything technical. If you're a
| backend engineering manager, expand your stack to all parts of
| the business. That means the back end, the front end, data,
| analytics, observability, devops, AI models, performance
| tracing, etc. I started as a mobile eng with previous backend
| experience, and I wish I expanded sooner so the company had
| those things on lock sooner, especially in the data analytics
| side. Engineers hate analytics, embrace it fast to counteract
| that tendency.
|
| 5. Gergely, Will Larson, etc are good resources, but also note
| they come from what I call the "Uber strain", and thus
| structure a lot of their experience and advice based on
| formative years working at Uber. I also worked at Uber when
| they were there and I recognize a bunch of Uber-isms in their
| writing.
|
| A good chunk of what they talk about is how to be successful at
| a place like Uber. Something I've realized later with them is
| that other companies can be pretty different, and what they
| espouse sometimes might not match. But on the other hand,
| Uber's work culture came from previous strains of silicon
| valley tech culture, especially google's due to the top
| engineers being from google and setting up their promo system
| to match googles (vs lets say apple) and the knock on effects
| of that. Something about that place made people get really good
| at understanding what is needed to succeed in tech leadership
| and write about it, I guess it's kind of a paypal mafia effect.
| thiago_fm wrote:
| As a CTO you'll work a lot with people, the best resource you can
| get is related to people.
|
| Get a mentor, read books about dealing with people in the most
| optimal way for you and the business (closing deals, negotiation,
| psychology etc).
|
| Also learn how to develop people. There are a few books on this,
| but nothing beats experience and being reflective about it. Every
| situation is specific and it's up to you to strategize how to
| develop people in your team, finding out what are the right
| buttons to push.
| ratg13 wrote:
| Given that you have provided no information about your industry,
| the size of your company or team, your background, or any
| relevant information that could be used to help, literally any
| book could be a good fit for you.
|
| Your best bet is to see if your company is willing to pay for you
| to take some Dale Carnegie classes (Specifically the ones on
| Effective Communication). It will help you more than anything
| technical.
| EwanToo wrote:
| If this is the first time you'd to be responsible for budgets,
| working with the board, finance teams, HR, etc, then I'd
| recommend a general business management book like "The Personal
| MBA" to give you an introduction to the concepts and language
| that those teams will use.
|
| The Personal MBA: A World-Class Business Education in a Single
| Volume https://amzn.eu/d/dTAp1GF
| degradas wrote:
| Will Larson has a lot of excellent material and an upcoming book
| specifically targeted for engineering executives. Check out
| https://lethain.com/tags/executive/ and
| https://www.oreilly.com/library/view/the-engineering-executi...
| erikstarck wrote:
| The Mythical Man Month and The Phoenix Project.
| Izmaki wrote:
| I've had The Phoenix Project recommended before. Listening to
| the Audio Book now - hoping it's good.
| Izmaki wrote:
| A couple of hours of listening in here, it feels a lot like
| "The Five Dysfunctions of a Team" - a made-up story about a
| made-up company with made-up problems that are simple and
| self-contained enough to have solutions, and where colleagues
| are able to work together, despite turbulence.
|
| It's hard to relate to, honestly. It's likely that the target
| audience is just not "me", but I think somebody with very
| limited experience dealing with operations would enjoy it.
| Questions like "why is IT Change Management important" and
| "how do we prevent people from making mindless changes in
| production on a Friday afternoon". If you know this already,
| so far this book is nothing but a "good story about work" -
| if anybody ever miss this part of life.
| jrflowers wrote:
| The Butter Battle Book
| apples_oranges wrote:
| I would suggest reading 2-3 books from your tech domain, I mean
| the tech stack your startup will be using, and maybe 2-3 more
| about your niche (for example if you are in online advertising,
| read books about advertising in general and online in particular)
| mobiuscog wrote:
| Whichever books you read - some great suggestions in the comments
| so far - please treat them as advice, and not religious texts.
|
| So many managers and higher fail terribly at being effective
| because they believe all they need to do is encourage/enforce the
| practices in the books on the engineering teams, and that is the
| path to failure and the death of morale.
|
| Take the books as guidance, but listen and engage with your
| reports (and their reports) to find the problems that need to be
| solved. Don't dictate or drive people, let them use their
| expertise in the direction you lead.
| ksplicer wrote:
| People are notoriously bad at identifying what actually led to
| their success. Career advice authors even more so.
| liquidpele wrote:
| I'd imagine mostly because, at least with some jobs, a dead
| parrot could be successful because the success was tied to
| other things (luck, founder connections, a few great
| sales/devs, etc).
| jeanloolz wrote:
| Managing Humans: Biting and Humorous Tales of a Software
| Engineering Manager
| krishadi wrote:
| On a side note, when I had my startup and was the CTO, a lot of
| advice I got and also what I ended up realising was that my
| priority and goal was to build an amazing `Tech Team`.
| gorbachev wrote:
| Books can help, but if I was you, I'd try and find a good mentor.
| onion2k wrote:
| Technical founders are not CTOs. At least, not for a long time. A
| CTO role defines the strategic vision for the org. You'll have a
| vague idea of that as a founder but until you nail the product
| and where it fits in a market it won't really matter too much.
| Focus on executing and getting traction instead.
| pknerd wrote:
| So, does a CTO need to know about:
|
| - Dev/ML/X Ops
|
| - System Architecture
|
| - DB design? etc?
| rwmj wrote:
| IMHO they ought to have a developer background. That doesn't
| mean they need to be an expert in DBMS design or whatever, but
| they should know enough to know when one of their reports is
| talking BS.
|
| I once worked for a CTO who threw out all our Linux systems and
| replaced them with Solaris (early 2000s) because "Linux
| couldn't scale", at the behest of our database architect who
| was basically just trying to increase his own empire and
| budget. One of the stupidest and most costly decisions, that
| also demoralised the rest of the team.
| Izmaki wrote:
| My expectation as a lead-role in DevOps is that my CTO
| understands what I am saying, if I were to present a business
| case to him for evaluation or raise a concern with the company
| tool stack. Shortly put I want somebody with decision making
| powers to also have the knowledge to make those decisions. I
| don't need them to be able to implement any of the changes, but
| I need them to be able to know why the change needs to happen
| and what business value it does or does not give.
| oneplane wrote:
| At a startup phase, I'm not sure there is anything that is
| strictly speaking a "CTO" task, except the paperwork. And once
| you get big enough for it to matter, the same rule applies as for
| a CEO: the CxO you need for your first million is a different one
| you need for your 100 million and different yet again for your
| first billion.
|
| There is of course a GitHub list for this:
| https://github.com/kuchin/awesome-cto and perhaps the best way to
| find out what you need is to check things off of that list that
| don't actually have anything to do with what you're actually
| working on. Role names generally have very little meaning on
| their own, it's all about context.
| lnsru wrote:
| You need to book communication and/or good sales course. As CTO
| you're into politics, not into tech. Ability to communicate
| clearly and steer the conversation is your skill number one. Tech
| background is nice to have, but not really useful. You will hire
| people for that.
| budgi4 wrote:
| Accelerate https://www.amazon.com/Accelerate-Software-Performing-
| Techno...
|
| Team Topologies https://www.amazon.com/Team-Topologies-
| Organizing-Business-T...
|
| Making Work Visible https://www.amazon.com/Making-Work-Visible-
| Exposing-Optimize...
| huqedato wrote:
| https://zachgoldberg.com/ctohandbook - that's a good start
| emmelaich wrote:
| Designing Data-Intensive Applications by Martin Kleppmann
| esseti wrote:
| The effective manager - how to manage people
|
| The mom test - how to discover product
|
| The EOS (Traction and Co) - how to manage the company and give
| direction to the vision of the company
| paulcole wrote:
| I think EOS is great and that every startup should use it, but
| have a feeling that most HN readers will _detest_ it because of
| Not Invented Here syndrome. It's too tempting to think "How
| hard can it be to figure out how to run a meeting, set goals,
| etc.?" And then end up spending the time that should've been
| spent having meetings and working towards goals on all the
| minutiae and cruft that somebody else has worked out in the
| past.
| simonebrunozzi wrote:
| I've been a CTO a couple of times (VMware, startup), I don't
| think I'm a good one (I am better as an individual contributor,
| rather than as a manager), but I have one piece of advice for
| you: ignore books, or use them as secondary source of truth.
|
| You should instead TALK to long-time or former CTOs and ask them
| for advice. You won't find that advice in any book. It's
| invaluable.
| rwmj wrote:
| How/where did you find former CTOs to talk to?
| _jal wrote:
| ...you just found one and talked to him.
| nsoldiac wrote:
| not always a him
| fdsalkjvlkjlkj wrote:
| I'm pretty sure you can safely call him a him in this
| case.
| _jal wrote:
| When does Simone become something else?
| Jtsummers wrote:
| Simone as a feminine or masculine name depends on the
| language and country. Simone in French is feminine, and
| in Italian (so a reasonable interpretation here given the
| last name) is masculine. In the US (and, from what I've
| seen, other English speaking countries) the name is
| brought in from French and generally considered feminine
| (barring being in an Italian community, I've met a couple
| Simone <Italian last name> men, but often the name
| becomes Simon after a generation or two in the US for men
| like how Roberto or Juan will become Robert or John for
| Spanish-language immigrant families).
|
| https://en.wikipedia.org/wiki/Simone_(given_name)#Simone
| - Pick any of the Italians off the list and they're
| almost certainly men, most of the non-Italian Simone's
| are women.
|
| Of course, it's still safer to look them up if you don't
| actually know the person in question and want to use he
| or she.
| piuantiderp wrote:
| Nor a she. Hope no offense is taken by such a small
| matter
| belter wrote:
| https://youtu.be/ifV7IkGVqaY
| dangus wrote:
| "They/Them" would be appropriate if we didn't know the
| person's gender or if they were specifically non-binary.
| However, in this case, we do know that this specific
| person is "he/him" thanks to the username and public
| profile, so the comment parent to yours was appropriate
| and your comment less so.
|
| (Your comment is less appropriate because the analogy
| would be if you said: "Nice to meet you, Jim. Not all
| people in your position are men, though.")
| xtracto wrote:
| The slack community in https://randsinrepose.com/welcome-to-
| rands-leadership-slack/ has a pretty good number of CTOs and
| other leaders.
| stavros wrote:
| This looks interesting, thanks!
| mooreds wrote:
| Plus one for this. There's a #startup-cto channel there
| that is full of good folks to chat with.
| mooreds wrote:
| I mentioned this in another comment but ctolunches.com is a
| group of engineering leaders that I have participated in from
| time to time.
|
| 7 CTOs is another one that I have heard of but haven't
| participated in.
| ajb wrote:
| On that subject, Someone I knew used to use the bartech cto
| network. But I'm not sure if it still exists, as I now can't
| find any trace of bartech online. There is this page:
| https://discourse.bartechcto.net/login but it seems to be
| invite only.
| mooreds wrote:
| Yes, so much is contextual and it's really hard to get that
| from books. But conversations, whether with peers or a coach,
| can help you because they have that context.
| pablobaz wrote:
| Scaling People: Tactics for Management and Company Building
|
| This is a great book for larger team sizes.
|
| https://amzn.eu/d/hnEQvsV
| pixelmonkey wrote:
| I was CTO of a startup from pre-seed stage ($0 raised,
| bootstrapping) thru Series A + B stages ($millions raised,
| scaling). I then promoted a senior engineer to the CTO role,
| around the time that we had ~20-30 engineers organized into sub-
| teams with engineering leads. As part of that, I ran an
| engineering management book club internally for the new CTO and
| engineering leads (which was also open to any engineers to join).
| I then published that reading list as a neatly organized blog
| post.
|
| The team wrote web / SaaS / analytics software in Python and
| JavaScript, deployed on Linux + AWS, using lightweight planning
| tools like GitHub and Notion. It was also a fully distributed
| team long before the pandemic. Over time, the company (Parse.ly)
| gained hundreds of enterprise customers and established itself
| via profitable growth in a straightforward SaaS business model.
| In 2021, less than a year after this blog post was published, the
| company was acquired by one of the largest open web internet
| companies (Automattic, creators of WordPress.com).
|
| "Managing software teams: the definitive reading list"
|
| https://amontalenti.com/2020/11/28/definitive-reading-list
|
| The blog post is organized into a few sections, each featuring a
| few relevant books:
|
| - Management as a high-leverage activity
|
| - Product marketing and product management
|
| - Debugging dysfunctional product cultures
|
| - The psychology of deep work
|
| - Fully distributed teams
|
| - Programmer mindset and philosophy
|
| It's easy to skip around to find a good starting point or make
| your own (smaller) reading list. Hope that helps. Good luck!
| dopamean wrote:
| That sounds like a really awesome workplace you built there.
| Nice job.
| Oras wrote:
| For a startup, focus on shipping faster. The only thing that
| matters in a startup is finding the product market fit.
|
| If you don't get to this point, the startup will die. So spending
| time optimizing the performance or arguing which code formatting
| standards to follow is just a waste of time and resources.
| huqedato wrote:
| https://www.amazon.com/INSPIRED-Create-Tech-Products-Custome...
|
| https://www.amazon.com/Escaping-Build-Trap-Effective-Managem...
| OliverJones wrote:
| Read about what to do: _The Fifth Discipline_ by Peter Senge. A
| bit dated by now, it's still good stuff about "systems thinking"
| . And you'll need a lot of deliberate systems thinking in your
| job, and you'll need to teach others to think that way.
|
| Read about what not to do: _The Ultimate Question_ by Fred
| Reichheld. This book is about the notorious Net Promoter Score.
| (Would you recommend HN to a friend? Would you? Would you?)
| Reading it will give you insight into how bonehead MBAs with Cs
| in their marketing classes can convince leadership they've come
| up with a good way to measure customer satisfaction. (Net
| Promoter Score works fine for competitive businesses selling
| commodity products -- rental cars to individuals for example --
| but not for many places where it is now used.)
| stargrazer wrote:
| Coincidentally, this showed up on my Twitter timeline just now:
|
| https://github.com/kuchin/awesome-cto - A curated and opinionated
| list of resources for Chief Technology Officers and VP R&D, with
| the emphasis on startups and hyper-growth companies.
|
| Someone else beat me to the link.
| smk_ wrote:
| Those who can't do, teach. Don't read. Do.
| rjtavares wrote:
| And those who can do are often terrible teachers.
| rnjailamba wrote:
| Mindset and leadership (explore other titles by Gerald M.
| Weinberg as well)
|
| - An Introduction to General Systems Thinking
|
| - Becoming a Technical Leader: An Organic Problem-Solving
| Approach
|
| So that you have a good answer to "when will it be ready"
|
| - Software Estimation: Demystifying the Black Art
|
| - Agile Estimating and Planning
|
| People management
|
| - The Manager's Path: A Guide for Tech Leaders Navigating Growth
| and Change
|
| - High Output Management
|
| Besides Mythical Man Month already mentioned in other comments.
| TDiblik wrote:
| Depends on what you're into:
|
| romance: i would suggest "Looking for Alaska" by John Green or
| "Pierre et Luce" by Romain Rolland
|
| fantasy: The Way Of Kings by Brandon Sanderson or "Blackout" by
| Marc Elseberg
|
| life advice ig?: "The Algebra of Happiness" by Scott Galloway
|
| ... never been a CTO xd
| jdalsgaard wrote:
| Not a book or blog per se, but:
| https://datatracker.ietf.org/doc/html/rfc1925 -- The Twelve
| Networking Truths.
| leandot wrote:
| You've been chosen to be a CTO, this usually means that you
| either did well in the company or were hired because of a good
| track record. So keep doing this + keep things simple, plan
| ahead, learn from colleagues, share knowledge. Stay humble,
| confess mistakes, ask for genuine feedback and advice.
|
| Books and blogs have a limited anecdotal value (sometimes it is
| high but the effort is also high). I've learned more from
| individual HN comments and actual work experience and mistakes
| than any book.
| tailspin2019 wrote:
| I mean this is decent advice, but slightly odd given you could
| easily have plugged your site here AND actually given the OP
| what they asked for :-)
|
| Maybe it's some reverse psychology thing. Ok I'll do it, you
| evil genius...
|
| https://hackernewsbooks.com
|
| PS CTOs aren't always chosen, many are self-appointed as
| founders or co-founders (possibly in this case too).
|
| Chosen implies you've been subject to external assessment,
| self-appointed is a different matter altogether (ie. you may be
| extremely aware of possible knowledge/experience gaps that you
| need to quickly fill).
|
| To add my own suggestion, I think High Output Management by
| Andy Grove is an excellent resource (not just for CTOs)
| leandot wrote:
| That is a very interesting line of thinking, my comment was
| kind of the opposite - I find that after reading a couple of
| good books on a certain topic, the rate of learning goes down
| rapidly compared to the steady amount I get from HN comments
| and experience. About hackernewsbooks - it's not mine since
| many years and I am not affiliated with it, I am just the one
| who built it and sold it. It's still nice though.
| lifeisstillgood wrote:
| Simply put: https://grugbrain.dev/
| elbi wrote:
| https://datatracker.ietf.org/doc/html/rfc1925
| WillAdams wrote:
| Jerry Kaplan's _StartUp_ is a classic which shows the dark
| underbelly of deal-making and press-release creation, and why we
| can't have nice things if they aren't being made so as to ensure
| the profit of a dominant player:
| https://www.goodreads.com/book/show/1171250.Startup
|
| Contrast it with: https://www.folklore.org/MacBasic.html
|
| and the early history of VisualBASIC (and wonder how things might
| have played out had the Mac had a nice development environment
| out the gate)
|
| and for management interactions see:
| https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
| mysterydip wrote:
| Game Thinking, by Amy Jo Kim: https://gamethinking.io/
|
| Coincidentally, a quote from Ycombinator CEO Garry Tan on their
| site: You've got to find your own window of opportunity. Game
| Thinking is your instruction manual.
| FourthProtocol wrote:
| I'm somewhat surprised that strategy is only mentioned once (at
| time of writing). Strategy is vital for any leadership role. Sun
| Tsu is a classic, but can be difficult to assimilate. There are
| many resources on Wikipedia.
|
| Often overlooked is dealing with power and politics
| (https://www.wittenburg.co.uk/Work/Politics.aspx)
|
| Keeping up to date on tech also important, especially at the tech
| lead/architecture level
| (https://www.wittenburg.co.uk/Work/Mentoring.aspx).
| zoenolan wrote:
| As others have said, joining a community has been helpful to me.
| I would recommend CTO Craft. You get to hear what issues others
| are dealing with and how they solve them.
|
| https://ctocraft.com/community/
| diegof79 wrote:
| The best advice is probably to learn as much as you can from
| different sources but also keep a pragmatic point of view that
| helps to select the things that apply to your situation. Very
| often, new leaders follow a recipe without paying attention to
| the organization's problems. (check the book "The First 90 Days"
| by Watkins; it may give you ideas to organize your initial
| approach).
|
| As someone who went from engineering to product design, I observe
| that CTOs without a product vision are challenging to work with.
| For example, at a previous company, a CTO tried to implement the
| hard rule that every UI component should be in the shared UI
| library. But, even when I was leading the design system, that
| rule didn't match how a product design process works. It caused
| delivery slowdowns and a degradation of the UX. I can bring up
| other examples, and the typical pattern is a leader looking at
| only one aspect or two without balance. Try to go beyond
| engineering and learn more about business and product design,
| which will help you prioritize engineering decisions. Some
| product-related books: Inspired by Cagan and Well-Designed by
| Kolko. Beyond engineering and product, as a C-level executive or
| director, people and hiring will be your primary concern. There
| are many management books, and I don't have any particular to
| recommend (all of them will provide tools, but none is perfect:
| The Advantage and The Five Dysfunctions of a Team by Lencioni,
| The Phoenix Project by Gene Kim). I also enjoy taking ideas from
| biographical stories like Creativity Inc. by Ed Camull or
| Creative Selection by Ken Kocienda. Finally, a book I found funny
| and cynical but depicts big corps very well is "Management
| Stripped Bare" by Jo Owen.
| rramadass wrote:
| Doing short courses (executive training) might be better.
| Assuming you have the Technical Domain side covered, my
| suggestion would be to focus on the following;
|
| 1) Behavioural Psychology -
| https://en.wikipedia.org/wiki/Behaviorism
|
| 2) Organizational Behaviour -
| https://en.wikipedia.org/wiki/Organizational_behavior
|
| 3) Evidence-based Management -
| https://en.wikipedia.org/wiki/Evidence-based_management
| jakderrida wrote:
| I imagine whatever agency or branch that's employing you should
| provide the specialized training you need. I doubt they'd publish
| or share the most important practices for security against those
| you're Counter-Terrorist Operations are targeting from staying
| ahead of you with that knowledge.
| rdli wrote:
| I think the #1 thing when you become part of an exec team is that
| you should be optimizing for the _business_, and not your
| function. The working assumption is that you will keep your
| function executing and delivering, but what is really hard is
| helping to figure out what the right decisions are for the
| business. Should we invest more in product or sales? What if
| there's a huge top of funnel problem -- what can we do about it?
| Your job is to bring that technology perspective to the
| discussion.
|
| I've been an exec, founder, CEO, and board member at various
| stages of successful (IPO) /unsuccessful companies (acqui-hire)
| companies. And the common thread at every stage is that the most
| successful companies had management teams that worked well
| together to optimize for the business.
|
| So instead of spending your energy on reading / learning more
| about tech, I'd recommend you spend your energy learning more
| about business (I'd probably start by asking the CEO & the rest
| of the mgmt team for advice on what to learn.)
| mooreds wrote:
| This is phenomenal advice. You might, for example, recommend
| outsourcing non-corrosive functionality rather than building it
| in house, if you feel that is better for the company.
|
| You should do this even if it leads to layoffs for your
| department, because, again, your goal should be a thriving
| business, not a thriving engineering department and a
| lackluster business.
|
| Source: I did recommend and lead this course of action once
| (the outsourcing, not the layoffs). Company is still using an
| outsourced solution.
| mooreds wrote:
| *non-core
| mrtimo wrote:
| I teach an MBA class on a similar subject.
|
| The students like a book called "Adventures of an IT leader".
| It's a fun read that students with work experience can relate to.
| And students without work experience can learn a lot from.
| koliber wrote:
| This might be a bit contrarian, but don't read engineering
| oriented books. Read up on selling, marketing, and product
| design. These are the things that will help you make better
| decisions about what you will build. My bet is that you got the
| technology parts covered, and the management things will start to
| matter once you have a team of 8+.
| ipnon wrote:
| "An Elegant Puzzle" by Will Larson[0] is revelatory when it comes
| to leading a software engineering team. There is a solution to
| every organizational problem I've encountered in companies from
| single digits to thousands. That book alone, along with its
| intentional and organized bibliography is one of the best
| investments you can make in a tech career. Even without context
| on the size of your company, Larson's new "The Engineering
| Executive's Primer"[1] will surely make a valuable introduction
| too.
|
| [0] https://press.stripe.com/an-elegant-puzzle [1]
| https://lethain.com/eng-execs-primer/
| foxbarrington wrote:
| You might find my survival guide for founders who depend on devs
| to get things done useful. It covers topics like how not to lose
| key information if a dev leaves, preventing endless rebuilds and
| framework switching, keeping devs busy vs. keeping them
| productive, and ensuring product builds don't go off the deep
| end.
|
| As an example, here's the chapter on estimates:
| https://superstruct.tech/blog/estimates
| tgtweak wrote:
| Given the diversity of the "CTO" role in terms of
| responsibilities and scale - what you should be reading will vary
| depending on your current size, composition, industry and your
| own personal experience level.
|
| One I find no trouble recommending regardless of these however is
| High Output Management by Andy Grove (of Intel). Not a new book,
| but chalk full of what I consider absolute truths when it comes
| to optimizing middle management (which is predominantly your role
| as a CTO, once the org reaches 50+ people and your direct reports
| all have direct reports). The fact it is still very relevant to
| organizational challenges today when it was written 40 years ago
| is a testament to this. It is a shame there are so few books that
| focus on this very-ignored (and honestly largest) segment of
| management and arguably where you get the most traction as a
| company.
|
| I've yet to meet two CTOs that share the same skillset or
| strengths, or who work in the same org structure.
|
| I would recommend doing some executive courses and trainings
| (with our other execs) to learn some common language and
| techniques/methodologies around team management and execution -
| this has been the thing which helped me most in embracing a CTO
| role (even one with other CTOs from separate business units
| reporting into). It is ironic but the best blend for a high level
| CTO is actually people and organizational skills moreso than pure
| technical aptitude. You need to be able to fact check your people
| and ask the right technical questions and understand the
| fundamentals of technical debt and TCO analysis, but honestly
| you'll be using your people/organizational skills and trying to
| hire people that know the technology better than you for the most
| part.
| mooreds wrote:
| This isn't a book or blog, but I recommend two different
| communities:
|
| CTOlunches.com, which is an in-person group that meets for
| lunches around the world. It also has an active mailing list,
| with hundreds of engineering leaders there.
|
| The rands leadership slack (Google for it) is an invite only
| slack with thousands of engineering leaders across the world.
| Great for asynchronous conversations across a wide variety of
| topics; they even have an anonymous q and a channel.
| svilen_dobrev wrote:
| Camille Fournier: the manager's path
|
| Eye-opener (worst take away / for me - you can't be friends with
| devs-under-you anymore. Or with anyone techie it seems. Probably
| depends on company-founders' culture - if small and new - or
| politics - if older and/or bigger)
|
| some more of hers here: https://skamille.medium.com/an-
| incomplete-list-of-skills-sen...
|
| Also.. you can't be everything. Choose your poison (or if it has
| been pre-chosen, find out what it is sooner than later), hire
| other people for other stuff:
|
| https://www.allthingsdistributed.com/2007/07/the_different_c...
|
| more on the topic:
|
| https://news.ycombinator.com/item?id=20642423
|
| And... think/assess very-very well - all-the-time - How much
| trust you have got.. and for what. YMMV. Sometimes "CTO" is only
| a parrotizing label for investors to flock on. Sometimes it's for
| real.
|
| have fun
| Solvency wrote:
| A CTO can't have friends in their department?
| mooreds wrote:
| I think it is really tough for execs to have friends in the
| same department, not just the CTO. Sometimes the business has
| needs that conflict with people's needs/desires and a good
| exec should choose the business.
| jantypas2 wrote:
| I don't know if I qualify for a CTO though people call me one
| (people have called me names since I was a kid but Mom always
| said to ignore them...) But let's tuck at that first word --
| "Chief". In many cultures Chief meant the one who held the final
| responsibility for whatever went bad. They were also the ones who
| had to negotiate with opposing forces. With that in mind, learn
| your opposing forces and what can go wrong. Ask the dreaded
| Marketing tribe for their books and learn shamanic things like
| how long it takes to get something into the media or a retail
| store. Negotiate with someone in nursing to learn the mystical
| art of dealing with angry people you are actually trying to help.
| You will learn more from a nurse or a clothing buyer than you
| will learn from the best coding book.
| VPenkov wrote:
| Just to add a bit to the excellent list this thread has
| collected:
|
| https://github.com/kuchin/awesome-cto
|
| Some hit-and-miss there but I discovered a lot of great advice.
| CountVonGuetzli wrote:
| After doing the first-time CTO thing three years ago in an
| established company with over 100 engineers, I think these two
| are the minimum required reading:
|
| An Elegant Puzzle: Systems of Eng Management
| (https://lethain.com/elegant-puzzle)
|
| and
|
| The Art of Leadership, small things done well
| (https://www.amazon.com/Art-Leadership-Small-Things-Done/dp/1...)
|
| There are a lot more that were helpful to me, but those two
| encompass most of the important concepts and skills already in a
| usefully synthesized way, at least for me.
| brightball wrote:
| Are you funded and hiring or are you building?
|
| If you're building, I'll echo other commenters...stop reading and
| go code.
|
| For just about any advice I'd say go read Rework, in between
| coding sessions.
| alberth wrote:
| This is hugely dependent upon company size.
|
| CTO skills needed for a 10-person company is radically different
| than a 10,000-person company.
| demon-code-999 wrote:
| everyone is a CTO on linkedin
| AC_8675309 wrote:
| If I were a CEO and my CTO asked that question I would start
| looking for a new CTO.
|
| Sorry, not a helpful answer...
| feoren wrote:
| Learn about your industry. Learn about the problem. Learn as much
| as you can about the problem your company is trying to solve.
| Learn industry jargon. You already know enough about the tech;
| just focus on the subject matter itself.
| max_ wrote:
| Check out Drew Houston's comment on HN from last year. [0]
|
| [0]: https://news.ycombinator.com/item?id=33595470
| tivert wrote:
| Peopleware: Productive Projects and Teams
|
| https://www.amazon.com/Peopleware-Productive-Projects-Teams-...
|
| It's a classic, and also a pretty easy read. If you're in
| technology and haven't read it yet, you should.
| RecycledEle wrote:
| Do not read books or blogs.
|
| Learn to do every technical job in your company.
| mikey_p wrote:
| Must listen: The Idealcast with Gene Kim
|
| I can't stress just how good this podcast is, all of the guests
| are excellent. Here's a brief highlight of my favorites:
|
| - Michael Nygard, SVP of Enterprise Architecture, Sabre -
| brilliant breakdowns of how to approach software problems
| conceptually
|
| - Dr Steven Spear - tons of excellent stuff from years of
| studying Japanese management techniques
|
| - Elisabeth Hendrickson - has been studying testing and QA for
| decades, tons of great insights
|
| - Scott Havens - incredible breakdown of the inventory management
| system of jet.com, acquired by Wal-mart and now powering
| walmart.com
|
| https://itrevolution.com/podcast/
| mattferderer wrote:
| Underrated new book not mentioned here - Think Like a CTO by Alan
| Williamson
| graycat wrote:
| To several of the authors here, "thanks, I needed that".
|
| I have the software written, and it appears to run as intended.
| Now, doing computer _systems management_ , silly stuff; main
| problem, getting past bad documentation, e.g., was just up all
| night working with video adapters, device drivers, display
| resolution, font scaling, HDMI, display port, flickering cursors,
| etc. Since the documentation was so bad, I did take some notes on
| the more important things I learned, e.g., by the TIFO (try it
| and find out) Method. The results are not perfect but are good
| enough for now. I can delay more until the business is growing
| nicely (if it ever does). That is, for now concentrate on giving
| people "something they want" and put video issues way down on the
| TODO list.
|
| But a concern: If such silly technical stuff does go well, then I
| could be going live on the Internet fairly soon. Then some of the
| issues might be:
|
| (1) publicity and getting the first users
|
| (2) getting advertisers
|
| (3) billing and accounting
|
| So, from this thread and a few hours at Google this week, I just
| concluded: For nearly all that stuff, nearly every business has
| to do it. So, there are well polished options for how to do it,
| and I can put it low on the TODO list for now.
|
| For what to do if the business starts to grow, I saw some of that
| at FedEx and elsewhere. Right, as in this thread, focus on
| providing "what people want", the work, and the revenue. E.g., if
| I get a lot of users, then that should help getting some
| advertisers. Then will need billing and accounting, and, uh,
| there is no shortage of people who can provide such _services_
| for me -- getting the revenue is the hard part; given the
| revenue, it stands to be easy to work with an accounting service!
| Or, for a lot "I don't know how to do it, but there are plenty
| of people who do."
|
| In particular, for management and in particular _engineering
| management_ , I've seen, been in, and done some of it and
| conclude now that my business will be nicely successful before I
| will have to look into the _theories_ of it. In particular, I saw
| several cases of guys really eager to work hard, occasionally all
| night, get good stuff done, with no credit from any _management_.
|
| For the core _technical_ stuff, my efforts have some of that, and
| it should be a business advantage, uses some of my experience and
| Ph.D. in applied math, I would say beats AI, and easy for me --
| early on in the effort I wrote up the math in Knuth 's math word
| processing TeX. Then used the write up when I wrote the code
| (Windows, IIS, .NET, ASP.NET, ADO.NET, platform invoke, etc.).
| So, the core technical stuff is done, not even on the TODO list!
| On with the rest with the balances as often in this thread.
___________________________________________________________________
(page generated 2023-12-29 23:01 UTC)