Above is great.. but your role as a fiduciary also requires you to NOT allow development and deployment costs to get out of hand. You are personally responsibl

Above is great.. but your role as a fiduciary also requires you to NOT allow development and deployment costs to get out of hand. You are personally responsible for ensuring underlying technical costs don’t undermine the viability of the enterprise. Many CTOs just say, “we’ll cloud everything”, and are “shocked” when they get a $500k monthly bill from AWS because a developer wrote errant auto-scale rules. Development and deployment should always be costed using both on-premise and cloud solutions, weighted with the associated risks of hacking, cost, and time. My strategy: budget cloud, implement on-premise. Nowadays, you can simulate AWS using docker-swarm or kubernetes, and that will give you a reasonably accurate scaling cost for your deployments. My two racks at a datacenter cost me $2k/mo all in with 1gbps bandwidth. The cost of clouding, which I check regularly, is over $18k/mo. I can always scale TO the cloud, but it’s an order of magnitude (or more) harder to de-scale to on-premise as developers take liberties with AWS provided shortcuts that they really should learn to deploy locally. De-scaling will cost time, and developers who prefer cloud may leave as a result, requiring costly re-hires and schedule slips. Ultimately, the CTO’s role should include: inform and educate, minimize technical debt, and maximize the company’s return on investment in technical staff and capital expenditures for computing needs, all while understanding the risks of the associated decisions to the bottom line of the company, financially, legally, and in terms of time-to-market. As a 35 developer with 35 years experience, I can tell you that if you let the development team decide, 95% of the time you will lose control of the costs very quickly. My suggestion to keep development costs low is to buy 10 used or new Dell servers and rack them on-premise, and use that for your development “cloud”. Having physical limits on capabilities will force devs to think “lean”, and gain personal experience building the supporting technologies they need to run whatever they develop. Your development team will be better, and your shareholders will appreciate your thriftiness. You can always scale up. Cheers!