I'm no SWE, so it might not be 100% applicable here.
As a manager, one of the your tasks are to make sure that your team knows why they are doing what they do. That way, when there is no time for lengthy discussions, they don't feel demoralized when you give them an order they disagree with.
Another task is, to make sure to get the best out of your team. That means to use the experience and knowledge of people as much as possible. Not doing that only drives down motivation.
What happened to me in the past, in a different domain, was somewhat similar to OP. I was explicietly hired because of my FANG background to imporve operations of a new business unit for a German unicorn. So that's what I started to do. Map processes, talk to the team, shadow them, identify issues and problems, work out KPIs and SOPs... the drill. Ony to be shit down by my manager at every turn "because we have 1,000s of proplems right now and nne are addressed by what you are doing". That sucked, it really did. My impression was, that they wanted FANG level withut putting the effort in. Just having someone with the right experience doesn't magicaly solve your problems.
In the above example, when time is critical, implement it. But hen have an pen discussion with your team about best practices, and maybe use whatever solution your "bi-corp" people have in mind.
people usually can't articulate what they want and they always want to skip the hard bits. look to what they do rather than what they say and find a way to slowly pull them towards what they ought to want. it takes a long time but you can make things better under conditions like that.
If you have a team of 5, and one wants to implement terraform or some other package like that, what is the current cost to the rest of the team that is unfamiliar with the new software? Will that one person be hobbled for the next few months trying to get their work done and support the other engineers who get blocked by tech they haven’t learned as well? Was the system viable using shell scripts or however it was originally set up? Is it going to tick off another developer who put effort into the current orchestration?
Would you even have cross-cutting concerns in a team of 5? Given previous experience, it's quite common that if you have a team of 5, it will be reasonable to assume everyone is sharing a bus factor of 1~1.5 and one person will be the infrastructure master. Letting them use whatever tools to leverage until you can have more runway is good.
I agree, unless the introduction of a tool for everyone could slow down 4/5 of the team. Startups usually have inexperienced people but the successful ones have talented people. Sometimes hiring an inexperienced big company employee causes these issues because they “know how it should be done” instead of having the experience to exercise judgement. It’s not a management failure to say, “let’s think about that in 5 months after we have a working product.”
The tradeoffs are not obvious. It could be that terraform is as important to this startup as version control would be, they just don’t know it. But if it ain’t broke....
Btw, I’ve worked at a startup (25 years ago) that had no version control and I was the one who identified the problem and introduced it. I also was unaware we needed it or what it could do for us before we had our first pucker-up moment with the source code. After version control we moved faster and slept better. Or we would have if we weren’t pulling all nighters.
Once you're experienced writing Infrastructure as Code, you always use it, no matter how small the project is. Right now I run a single micro instance for a personal project and I've got the whole thing Terraformed, which took me less than a workday - VPC, subnet, security groups, S3 buckets, and a basic provisioning script to setup the instance's software and cron jobs.
It is (eventually, once you learn it) faster and more intuitive than bothering with the AWS console, and I often reference Terraform's own AWS resource documentation over the AWS docs since it usually has better information density.
Anyway, the issue is all beside the point, I think we realize that Terraform was used as a placeholder example. Another example might be setting up single sign on, Active Directory, and other things that are truly not necessary for a company of that scale.
The other part of this that if you've got a startup with 5 month runway and 10 employees, hiring an Infrastructure as Code SME is probably not the best use of your dollars. Sure, I was able to put this side project in Terraform in under a day, but I also can't write a front-end application to get myself out of a wet paper bag.
> Once you're experienced writing Infrastructure as Code, you always use it, no matter how small the project is.
It's a good idea to start early with IaC but one of the marks of a good engineer is knowing what tooling to use for each circumstance.
Your app might be a perfect fit for Terraform or it might not, I couldn't possibly comment. Given the info you've provided it seems excessive but it's hard to say for sure
I can't think of a project of any size that terraform would be excessive for.
Agree, if you're introducing it to a new team and don't have time to teach the tooling that could be problematic.
But being somewhat familiar with Terraform I would use it to launch a single EC2 instance. Because it's about as fast to do that as it would be for me to use the AWS Console.
It's not that I think Terraform is needed for that small of a project, it's that it adds no cost even for tiny projects.
Not sure about the run-way thing. I'm also partially a six sigma / lean guy, and doing things right in the first place is a key lesson I learned, sometimes the hard way (aerospace definitely drove this home as well).
I would make the case that, even with 5 months of runway, you should invest in a solid foundation. Because if the company goes down, it does. Only a little bit earlier. if it doesn't, which is I assume the reasoning behind the company in the first place, getting the basics right now has a huge impact on runway and scalability later on.
The problem is that sometimes, the overhead isn't the right decision from a cognitive load perspective and a fiscal perspective (cost of infrastructure + developer time).
> Two micro instances don't seem to warrant using Terraform
That doesn't really make sense, it's not like there's some huge fixed cost of using Terraform, the whole point of infrastructure as code is that all the infrastructure is code, i.e. it's all variable cost.
Small infrastructure as small code.
And then it's all there when you expand. Change `num_micro_instances = 2` to `4`. `10`.
As a manager, one of the your tasks are to make sure that your team knows why they are doing what they do. That way, when there is no time for lengthy discussions, they don't feel demoralized when you give them an order they disagree with.
Another task is, to make sure to get the best out of your team. That means to use the experience and knowledge of people as much as possible. Not doing that only drives down motivation.
What happened to me in the past, in a different domain, was somewhat similar to OP. I was explicietly hired because of my FANG background to imporve operations of a new business unit for a German unicorn. So that's what I started to do. Map processes, talk to the team, shadow them, identify issues and problems, work out KPIs and SOPs... the drill. Ony to be shit down by my manager at every turn "because we have 1,000s of proplems right now and nne are addressed by what you are doing". That sucked, it really did. My impression was, that they wanted FANG level withut putting the effort in. Just having someone with the right experience doesn't magicaly solve your problems.
In the above example, when time is critical, implement it. But hen have an pen discussion with your team about best practices, and maybe use whatever solution your "bi-corp" people have in mind.