Here are some insights I've learned over my career: 1. Your first hire will be your most difficult. Most engineers know other engineers, and will bring them ov

Here are some insights I've learned over my career: 1. Your first hire will be your most difficult. Most engineers know other engineers, and will bring them over if the work (and pay) is good. 2. You get what you pay for. Hiring very senior staff will pay for itself, even if you could get four or five junior devs for the price of one senior. Very rarely, if ever, will "more developers" mean more productivity. 3. Pick a portion of your system you need to improve and start there. Make sure your engineering team is empowered to make decisions, and that there is a "champion" with the authority to make decisions across departments. A lot of orgs can die waiting for non-engineering portions of the company to make decisions. Even worse is when they wax and wane on those decisions. 4. Following point three, if your organization is disorganized, or unable to move quickly so will your engineering team. 5. Hire remote workers. There are a LOT of folks who will never set foot in an office again. It gives you access to an immense talent pool you may not have otherwise. 6. Be flexible. Most engineers I've know have a schedule, but that schedule isn't generally a strict 9-5. 7. Whatever language and platforms you decide to build with-- make sure you can hire for them. Some are great, but difficult to find experienced engineers. I say this as an Elixir developer. Finally, Logistics sounds pretty fun and for the right folks it will be. Don't undersell the problem space or think of it as boring. The engineering work may be the opposite of boring, or your organization may just be a good place to work. Good luck, mate!