Lately I’ve been speaking with a bunch of folks about their “careers.” I always feel a bit of imposter syndrome here because while I’m proud of my work and have managed to be largely successful, it certainly wasn’t because of some exceptional aptitude for career management. I’ve basically bopped around chasing problems that felt interesting and meaningful, gotten really lucky and just worked really hard for a long time — it’s hard to package that up into a TED talk.
But I do encourage folks — and note these are usually technical folks — to be part of a ground-up startup at least once in their career. There is nothing in the world like building your own company, and that’s true whether it ultimately succeeds or fails (I’ve done both). I can’t say this enough: big tech is not the real world. There is great engineering to be done there, and I will always be thankful to Microsoft for teaching me to really write code. But the expertise gained from a career at these places is narrow by definition — there are support structures for everything because specialization is the most efficient way to scale.
At a startup, there are support structures for nothing, and you almost certainly don’t have the money or time to buy them. It’s just on you — full stop. It’s scary and challenging and exhilarating. It’s unforgiving. But it is also uniquely satisfying. It may sound odd, but to me starting a company is like learning to grow your own food, build a house, fix a toilet (actually needed this skill at a couple of startups) or even change the oil in your car. It connects you to the real world in a way that just feels human. I’m a fan.
That said, the overly-romanticized get-rich-play-foosball startup mythology is strong. Few things set me off quicker than listening to some self-satisfied Stanford asshat talk about motivating people and changing the world. Silicon Valley is funny because it’s a 100% true-to-life documentary.
Still, there does seem to be a demand for guidance around those early days, which finally brings me to the point of all this. What follows is my unglamorous, nuts-and-bolts, foosball-free, all-on-you checklist for startup CTOs. Because it’s a post and not a book, I’ll just touch on each item; if anything seems worthy of further discussion I’ll do go deeper another time. So here we go:
1. Network and Servers
Just getting LAN connectivity used to be a big deal, but these days network is pretty much like air. And if you’re trolling the Dell site looking for servers or storage in 2021, you’re doing it wrong. Today, your first decision is which cloud provider to work with.
In a lot of ways it doesn’t matter — all of the big folks are fine. The “obvious choice” is AWS and you’re not likely to be disappointed going that way. Azure has some fantastic service offerings, but the developer experience can be ugly if you’re not all-in on Microsoft languages and tools. If you plan to run Windows servers in any significant way (why would you do this) then Azure probably makes sense.
You’ll definitely want a private network at your cloud provider, and a VPN solution for remote folks. Unless you’re a network nerd, this can be a little tricky to set up securely and may be one of the rare places to invest in a little consulting help. Hackers will try to get in, and you’ll build so much infrastructure on this base, that it’s worth some dollars to get it right.
Speaking of money, keeping track of cloud use and optimizing costs is also a specific skill. Plan to just start with on-demand pricing and move to reserved instance models as you grow and see patterns. Eventually it might make sense to take some services local, but you should for sure have a dedicated production IT person on staff before you go there. And for the love of all that is good in the world, don’t get sucked into multicloud mode… the theoretical “reliability” win you get by running across cloud providers is 1000% not worth it.
2. Laptops and IT
Nobody loves this but guess what, you’re the IT person now. Spend a little effort up-front to minimize your personal time on the support desk. Everybody is going to want to buy their favorite laptop — don’t do that. My unpopular opinion is to just buy everybody a basic black Lenovo Thinkpad running Windows and be done with it. Chromebooks are just now becoming a reasonable option. Macs are nothing but IT trouble, even if the bros love them.
Next up is email and other collaboration. I think about this just like laptops — you want them to work with minimum hassle and distraction. Exactly zero startups have succeeded or failed based on their choice of email provider. It might not be the “cool” choice — but do yourself a favor and subscribe your company to Office365. It’s a one-stop shop for communication and productivity tools and you’re done. Smile and nod when people start a Teams channel to talk about how Slack would be better; you get to move on to things that matter.
3. Developer environment and tools
Developer stuff like issue tracking, source control and build management is easy — use Atlassian. Like O365, a solid comprehensive suite of tools that works together is the right move. You can argue this or that feature, but it’s just not material — the crux here is to have tools early and get folks using them before bad habits take over. Code reviews start on day one, nobody checks in without the build working, etc. etc.
Language and runtime environments are much tougher; that’s a religious battle that can go on forever. I only have one absolute: servers should run Linux, full stop. Beyond that, it’s more about managing dependencies and keeping things from fragmenting too much. My personal preferences (not surprisingly matching pretty much what we used at my last gig) are:
- Backend: Java, it just keeps on working.
- Scripting: Python3, yes 3.
- SQL: Postgres, no stored procedures allowed.
- Web server: Apache for HTTPS, proxying cleartext Play Framework. If you have a frontend heavy system with most of your backend just serving JSON or similar, consider skipping the framework altogether as I’ve done here and here.
- Frontend/Browser: Jeez I hate all of them, just pick one and stick to it even when it stops being cool.
- Build: Maven (if you’re using Java)
- Editor: Emacs or die, but let folks choose whatever they want. Don’t pick a “standard” IDE because your standalone builds and debugging infrastructure will decay.
Getting more esoteric, I’m a big fan of using infrastructure from your cloud provider — e.g., serverless functions are pretty fantastic and no good company should get too big without implementing an enterprise-wide pubsub system. If you need the power (you probably don’t), Spark is very good at what it does. But very quickly these decisions get intertwined with your specific products and customers, so enough said on that.
Just make sure that you HAVE a set of approved technologies … developers love to use every new-and-shiny-thing in the world and losing control of that is a quick path to cacophony. Remember, your job is to ship product that works great — nobody in the real world cares what technology you use to build it.
4. Product
Did it really take us this long to get here? Indeed it did, and that was on purpose. Your first job is to create an environment in which developers (including yourself) can build product with minimal distractions and side trips. You can overdo that too, but in my experience that’s rarely the problem.
In any case, what you build is going to be unique to your startup and I can’t comment much on that. What I can say is that, whatever the product is, you as CTO need to own it. I don’t mean this in some political or organizational sense. I mean that you need to feel a personal responsibility — not just that what you build works as specified, but that the spec is the right one for your business.
This is your company. Your founding team nominally has functional titles (CEO, CTO, etc.), but that doesn’t mean much. You all need to be at the table discussing the customer, the price, the brand, the functionality, the technology, funding, all of it. It really is true that startup relationships are second only to marriage — your partners need you to be all in.
Of course expertise exists, and hopefully you chose co-founders to fill gaps in your skill set. At the end of the day, the CMO chooses the brand, not the CTO. But that’s a dispute resolution reality, not an excuse for you to skip out on your responsibility.
You may find people taken aback when you express an opinion about pricing or something else “non-technical.” Just ignore that and push the conversation forward; they’ll either tell you where you’re wrong (fine), hear and engage with your thoughts (fine), or get ego-bruised and quit (not fine but better to figure it out early).
5. Architecture
The fun part! Your first technical responsibility is to establish product architecture to build around. This basically comes down to:
- The object model that describes the important entities in your system. They sure seem obvious now, but back in drugstore.com days, we were breaking ground by defining PRODUCTS, SHOPPERS, a SHOPPING CART, ORDERS and SHIPMENTS. Each of these entities has their own states, properties and usually relationships to other entities.
- The actions that create and modify entities. These may be user-initiated (add a product to the shopping cart) or happen in the background (order delivery status changed). Being explicit about pre- and post-conditions for these actions is one of the best ways to keep spaghetti in check.
- The distinct subsystems that work together to deliver a complete product. Keeping with the ecommerce theme, these might include a website, a warehouse management system, a customer service interface and a marketing tool. Even in a single standalone application, it’s important to break things up into subsystems so dependencies are obvious.
There are of course books and courses and all kinds of people ready to tell you how to do this stuff. I will simply reiterate that it’s extraordinarily important that you set this structure in place before folks start writing code. It should be no more than a few pages (one is best but I never succeed at that); everyone should have a copy next to their monitor; and it should underlie the vocabulary that they use all day. Who on the HealthVault team will ever forget “Things”??? Or the Intelliserv “Vortex” for Cognisofties? Anybody at Adaptive talk about “Order Tests” today?
Honestly, many of the best times in my career were spent lying on the floor late at night, bright white copy paper and sharp pencils at hand, drawing and erasing boxes and arrows and lists until I got it just right. Solid architecture will save your bacon again and again.
6. Hiring
Other than coding, you really have only one more job — build the team. Depending on your funding situation, this may happen quickly or slowly, but either way, as soon as you can, make four hires:
- A fantastic (Microsoft-style) Program Manager. If you don’t know what this is, and there’s a reasonable chance you don’t, stop reading my nonsense right now and click that link — you’ll be glad you did. To those who say you don’t need PMs, you’re wrong sorry. We’ll call this person “Linda.”
- A great production IT person who understands what the cool kids now call “devops.” How to manage servers, networks and environments; how to deploy code; how to monitor systems in real time and get alerts to the right people to fix things. If they’ll deal with the laptops and email too that’s great, but don’t hire for that. This is “Steve.”
- A rock star developer that understands architecture better than you, is confident pointing out your mistakes, and cranks out a ton of beautiful code. Aka “Jeff” or “Umesh”.
- A really excellent systems-level tester. Not an “SDET” that spends all of their time writing automation frameworks that just duplicate tests developers do anyways, but a career tester that knows how to find that weird edge case and enjoys rubbing it in your face: “Rob.”
As you might imagine, Linda, Steve, Jeff, Umesh, and Rob are all very real people, and I’ve had the good fortune to start companies with each of them at various times, including once almost all together. They are brilliant at what they do.
Of course, knowing each other means we have a shared history of wins and losses, and we’re more productive right away. But the real impact comes when it’s time to do the next round of hiring — this core group models the tone and expectations we have for anyone that joins the team. Awesome wants to work with awesome.
One more piece of advice as you expand functions and start to stratify a bit into leads and managers. Be the “as appropriate” for every hire you make, and take it seriously. Interview these people, don’t just give them a pass because they made it through earlier rounds. Often your team will tell you to “sell” because a candidate is fantastic — and yes, do that for sure. But even the best lead under pressure may start lowering the bar. Don’t let that bullsh*t stand. It’s true that not everyone can be a rock star — but everyone on YOUR team had better be.
OK then — that’s week one. Things will really heat up in week two, so strap in and have the time of your life. And you know, make the world a better place through canonical data models to communicate between endpoints.
