26
26 Comments

12 Lessons Learned As A CTO

  1. 4

    Agree with all of this (team leader here).
    Nice write up.

  2. 3

    After having worked as a founder & CTO in my SaaS startup for 7+ years, I wanted to share some of the most valuable lessons I learned :
    https://www.romainsimon.net/saas-startup-cto/

    Let me know if this is helpful or you have any comment :)

  3. 2

    Thanks for this. The working conditions point is probably the most critical. Optimize for focus time between distractions is pretty much my only obsession. As far as slack, I like to have slack blackouts for major parts of the day because it's now the worst offender as far as distractions, I think due to more work cohorts using the platform.

    Not sure if I agree with 'no spec no code' as a black and white thing. Most things that are innovative start without specification. As with all things, your mileage may vary.

    1. 2

      I did the same thing for Slack, otherwise that's too many interruptions. Before going full-remote, we had an office and having salespeople or support going physically ask questions to the tech team was also a no.

      For the "No spec no code" yes I do agree, it varies depending on at what stage of development you are, the size of the you team and also seniority of developers.

  4. 2

    It is interesting what you say about the QA. I was able to arrange a deal with one my friends. She wants to become a tester, I wanted to have someone to do manual testing. So now she is an QA intern at my project. I find it great to have her, because she does not have too much IT knowledge. Thus she has a quite different approach, that is much more close to a regular user's one.

    1. 1

      Yes ! I noticed developers have a specific way to test things, because we know how the underlying things work. Having a non-tech manual tester is very important, and I noticed this role is often forgotten because we prefer having more developers to go faster, but it's a mistake.

  5. 2

    nice and concise, but on monorepos, the tooling that exists is good for "medium" stuff, overkill for small stuff but for massive stuff, the build tools that need to exist to support co-ordination of teams and general scaling no joke.

    1. 1

      Thanks !
      I don't think it is overkill, I now use the same structure for all my personal projects, but maybe it depends on which language you use.
      For JS, I use Lerna which is great tool and some specific configuration to deploy the subrepositories at the right place, but very often it is not as difficult as it seems to setup.

  6. 1

    Great post! I would add automation for communication/development like standup bots, deploy, etc. It will keep your remote team be on the same side when something happens.

    Also, when you start your own project it is in pre-revenue stage, do you hire any members or do all of the development by yourself?

    1. 1

      I prefer to bootstrap and do everything by myself, and would limit my expenses until I have some revenue. But that's me and my experience: https://www.romainsimon.net/bootstrapping-vs-venture-capital/
      If I really need something specific I can't do myself, I would prefer hiring freelancers for specific jobs.

  7. 1

    Generally agree with most points, however I'm a big believer in doing the right things at the right time so it might be helpful to at the company size / dev team size you'd start doing this 🤔

    1. 1

      I had a team between 1 and 8 developers. I think those are general principles I want to apply as soon as possible starting from day 1, with the exception on writing tests maybe.

      1. 1

        Also if you work alone?

  8. 1

    I recommended mono repo for one of my client projects and they looked at me like I am a fool. For some projects they make huge difference. For some projects they are not suitable.

    If you have monorepos, you can forget about hiring contractors.Monorepos are not for everyone and it's better if this decision taken early.

    Also your hiring strategy is good. When I am interviewing I always navigate deeper into user answer to understand how much they know. We cant ask everything in 1 or 2 hours of interviews, so sometimes we can relate how much they know and how confident they are.

    1. 1

      I did not think about this case, but you are right. I you want to grant access to only a part of the monorepo to someone, it is not possible anymore.

      For interviews, I was inspired by Joel Spolsky and always asked these very simple questions : https://www.romainsimon.net/spolsky-easy-interview-questions/
      I was surprised by difference they take between different developers. It ranges between 5 seconds to 10+ minutes per question!

      1. 1

        I think Joel is wrong.

        Regarding RegEx and Math: Why should everydev needs to know about RegEx? how many times do we require regex? The right question is to know if a developer can learn the Regex when the project requires it. Do we remember all the styles of css? how to apply a shadow? we quickly google and find.
        Regex and math are something which devs go look for when required. They don't need to memorize them.

        I designed Java interview questions for Mindtree during 2011. My main approach was to find if interview candidate know the programming concepts well, for example method overriding in OOP. I will put a question in different twisted forms to know if the candidate really know the fundamental concepts. I ask questions about what is immutability? devs need to know these concepts to write quality code, where as regex kind of stuff can be easily googled.

        Edit: spelling.

  9. 1

    I think monorepos is just your own preference here. Great that it worked for you, but can we stop using Google as an argument? They are at scale where single repos and feature branches simply don't work. On top they made a lot of tooling around it which others have no access to. If you think you do it like Google, you might be lying to yourself.

    1. 2

      Google is just an argument to respond to "It won't scale" but the real arguments for me were :

      1. We don't need to have a "common" package to keep things we use in all repos (no need to keep track of versions, publish the package, etc...). You make a change in the repo, but since it's not published yet, it's not tested with the rest of your code which is very annoying.

      2. No need to make many PRs for a single modification. This happened very often, and it's better at every stage : You will not forget to make the change in the smaller less often used repo, because you have to make your change in only one place. You have only on PR to open, and one to review. It's way easier to see everything works together. Same thing for deploying to production.

      3. It easier to test all you code together and avoids

      The only downside is it complicates a bit your CI/CD but it is definitely worth it for me, because you only have to setup this once. Is there anything else you do not like about monorepos ?

      1. 1

        I do prefer a single repo with a full-stack app in it (developed with a full-stack team). But if the app is split (SPA, mobile clients), then no. There are different projects with different people. Where you say you need only a single PR, it only works if frontend and backend engineers collaborate in branches.

        For me, the development of any client should be independent of the backend.

        To your points:

        We don't need to have a "common" package to keep things we use in all repos

        Our front-end shares nothing with the backend. Most teams won't have anything to share. Maybe you are all on JavaScript and really share something, but that's not an argument for me.

        No need to make many PRs for a single modification

        We have a monorepo on one project and we often end up with both one and multiple PRs. In a case of a single PR, people have to collaborate together in the same branch.

        Trying to make a single PR among 2 or more clients would be a nightmare.

        Same thing for deploying to production.

        I prefer much more if clients can be versioned separately and target a certain API (as if they are public rather then private projects). Otherwise your repository is either not really consistent with all changes at any given revision or people are waiting on each other.

        It easier to test all you code together and avoids

        Again, they should be independent for the most part. Target the same backend API.

        But again, this is personal taste. Or maybe it's really arguably better for your team -- I couldn't know. It's just a lesson that is not generally applicable.

        Btw I do agree with the rest, I simply think that this one is your personal take.

        1. 1

          Thanks for the explanation.
          Yes I guess it depends on what you have.

          It was more practical to me, event without mixing front-end or back-end.
          You can have multiple things in your back-end : API, workers, crons, ...

          And for the front-end it allows you to share components. We had no mobile app, but a SPA and a Chrome addon. We did not have a monorepo, and the two did not share components which is not convenient.

  10. 1

    Thanks for the insight especially on item 10. Testing.
    Item 11. Priorities also aligns with how Amazon does things: operational excellence is the number 1 priority for engineering/product teams.

    1. 1

      I learned that the hard way.

      When your product is not mature and your customers ask for new features, it is very tempting to prioritize to go fast, but that's how you accumulate technical debt.

      And from a user perspective it's better to have less users because you have only one feature, but have awesome retention because this one feature is done perfectly.

Trending on Indie Hackers
What you are currently working on? 117 comments IH invite system is broken 28 comments How this Reddit marketing tool used itself to grow to $5k/MRR 24 comments Roast my 3D landing page! 13 comments I don't know what to do on indie hackers anymore. 2 comments How to write an engaging comment on Twitter 1 comment