* I am hesitant to sign up for yet another source of email without more information about the list membership. Do you already have commitment to participate from experienced CTOs with a public presence (such as Camille Fournier who you cite as inspiration)? That would certainly be an incentive to join. If you can't name names, or if you're bootstrapping and don't yet have names to name, then at least some information about the experience level of folks on the list would help: e.g. "15% of our membership has held a technical leadership or management role for at least 2 years".
* You might consider gathering some demographic information along with email address, for example to help address the point above.
* I'd like to know more about the expected participation model. Your description hints at a Q&A model where people submit questions for open discussion by the list membership, but "mailing list" suggests (to me) more of a broadcast model where the list operators submit curated nuggets of wisdom. As founding members of the community, you'll set the tone; as moderators, even more so.
* As you're building a community, I'd want to see a code of conduct - both to know what to expect from the moderators, and to be sure that people from marginalised demographics would be comfortable participating.
* Related to (and probably covered in) a code of conduct, I'd be more inclined to join a community with an explicit ban on advertising ("15% discount on my product for list members"), recruiting ("my team is hiring an iPhone engineer") and market research ("would your company use this product?"). Not that I have a problem with those things, but I wouldn't currently sign up for something that exposed me to more of them.
A few answers/questions below:
* Bootstrapping with only a few names that are likely unrecognizable. I'm not the CTO of some random unicorn or vc-backed start-up. It's all the more reason I could use a peer-to-peer mentor. When I posted, there was only two of us who mutually agreed to it being a good idea. Myself? 4 years XP as a CTO and him 3 years 5 months. We started talking back and forth about small problems that plagued us or our teams. As we started helping each other, we realized there are likely many more like us who would benefit from having a peer to talk with.
* I am working on this now. Right now I am manually moderating the applications with only a name and email address to work from. Luckily, if you're a CTO/VP, you're name is pretty well published and indexed by LinkedIn, Google, etc. Lesson learned, if you build it they may come and you are likely going to be stuck with the repercussions of any decisions you hadn't made yet. I really should have asked for more on the form. At any rate, those that I cannot find easily I am replying back asking them to share more about themselves with me.
* Exactly right. At this time, it's a single email-list with a Q&A model and open discussion environment. You drive home a good point. Where I am a founding member and moderator, I need to clearly document our expectations, rules of the mailing list and a code of conduct as to what is appropriate to discuss and what is not. People do not want to be surprised when they are banned and a simple code of conduct can easily inform people and prevent them from posting something we don't want discussed or shared. Some of these may be legal minimums - for example, an anti-trust policy stating we cannot discuss pricing or fix the prices of our products especially where competitors may be on the same mailing list. I'm working on this now. As the group becomes larger, we likely need bylaws to further govern the organization.
* Great point regarding an explicit ban on advertising on the mailing list. That is definitely my intent.
Thank you again for taking the time to review and comment.
Firstly, most CTOs were surprised I came from a coding background. Even more were surprised to hear I committed code regularly.
Secondly, most of the discussion was about how to deal with tactical issues in a strategic framework that was almost impossible to relate to.
I don't CTO any more (went back to being a humble dev because it made me happier), but 90% of CTO-only lists/networking events/activities are ego exercises first, useful only by accident.
If somebody can fix that, ace. There is nothing here that suggests this will actually be practically useful.
Author here. Thanks! That's a great suggestion. As you can tell, right now the site and the mailing list is the most minimal of an implementation. We want to build a network, connect and mentor one another through the simplest and easiest mechanism possible - email. Once we have a medium-sized community with dozens of experts, we plan to add community managed content. Perhaps through a wiki?
I'll share the books and articles that have positively affected my career. These aren't tried and true and maybe dozens of people would disagree about their value but here they are, for what they are worth:
- High output management (Grove, 1995)
- Leading Up: How to Lead Your Boss So You Both Win (Useem)
- It’s your Ship (Abrashoff)
- The score takes care of itself (Walsh)
- The Hard Thing About Hard Things (Horowitz)
- Where good ideas come from (Johnson)
- Extreme Ownership (Navy Seals) — (Willink)
- Work Rules — (Bock)
- 5 Dysfunctions of a team — (Lencioni)
- Give and Take (Grant)
- This is what impactful Engineering leadership looks like - http://firstround.com/review/this-is-what-impactful-engineering-leadership-looks-like/
- Notes on startup engineering management for young bloods - http://www.elidedbranches.com/2015/10/notes-on-startup-engineering-management.html?m=1
- Continuous Integration: Improving Software Quality and Reducing Risk (Duval, Matyas, Glover, 2007)
- Continuous Delivery: Release Software Releases through Build, Test and Deployment Automation (Humble, Farley, 2010)
- Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) (Beck, Andres)
- SICP: Structure and Interpretation of Computer Programs
- Clean Code: A Handbook of Agile Software Craftsmanship
- Design Patterns: Elements of Reusable Object-Oriented Software
- Refactoring: Improving the Design of Existing Code
- Refactoring Databases - Evolutionary Database Design (Ambler, Sadalage, 2006)
Honestly I'm kinda surprised that didn't come up sooner...but only half-surprised.
- Mythical Man Month
- High output management
* CTOschool in NYC (http://www.meetup.com/ctoschool/). They have over 2k members, monthly meetups and an active, relevant mailing list. I recommend joining for the mailing list alone.
* I live in Philly so I was tired of commuting to NYC for this meetup, so I co-founded CTOSchool in Philly (http://meetup.com/CTO-School-Philadelphia/). We have over 200 members now and growing.
Both groups focus on engineering leadership topics like hiring, onboarding, software delivery process, team structure, dealing with c-level team, etc. It really made a huge difference in my career.
Seems like it might be useful to ask for a website on your sign up form so that you have some idea what people are working on.
I was especially psyched to join as soon as I saw a reference to that fantastic Camille Fournier article. Her blog is one of the few incisive resources I've found on technical management at startups.
- rocket @ $50/mo and;
- voyage @ $375/mo.
Well, it is currently a fully moderated list, and we will do our best to maintain the guidelines so hopefully you won't get any spam at all!
Right now we are checking sign ups before approving, so if someone signs up with an obfuscated email and we can't find their linked in page etc (so that we can check that they are really a CTO/engineering director and not a spammer) they won't even be added to the list unless we follow up directly and get a bit more information.