I work on a team that produces sensors, sensor analysis routines, and web infrastructure to distribute the sensor analysis to clients. We manufacture in house,

I work on a team that produces sensors, sensor analysis routines, and web infrastructure to distribute the sensor analysis to clients. We manufacture in house, and our in-house software team is roughly 5 people depending on how you include roles. I do the actual analysis routines, math-heavy native-compiled stuff. The others do web frontend dev, mobile dev, and backend server stuff. Our current strategy has worked so brilliantly that after 20 years of ancient codebases and constant fires, we've had a year of relative quiet as everything "just works". We now have the most advanced analysis package in our industry. Here are the main points, with a small dev team in mind: 1) Silo responsibility and keep the structure flat. Minimize how much people are stepping on each other's toes by giving them one whole "piece" of the puzzle and letting them take ownership of that piece. 2) Give them freedom to approach the problem with the best methods and tools they know how. Tasks should be long-term goals that allow the engineers to flex their creative and problem-solving muscles. Competent engineers will find ways to communicate and coordinate with who they need to, when they need to. I must emphasize tools. If a problem could benefit from a new language, let engineers explore that path. In replacing some maliciously obfuscated 20-year-old C and PHP code, I entertained several languages before settling on Nim for our analysis routines. It slots easily in to our servers and is invoked via scripts, makes fast C executables, and the maintenance, refactoring, and readability jump has almost made my job too easy. You will need to balance against "bus factor", but keep your competitive advantage in mind. Take a strong look at web technologies like Clojure and HTMX that can attract talent, keep head count low, and increase product quality and maintainability. 3) Use team interviews. Your team will work together to suss out fakes and find good fits far better than any single interviewer, especially a single interviewer without the requisite expertise. Don't just ask technical questions, ask open-ended critical and creative thinking questions. 4) Do entertain the possibility that young and fresh engineers can integrate well, learn quickly, and explore possibilities you never thought of. Our hardware team has a couple of much older (60s) engineers with very old-school practices who are dragging them through a quagmire. Keep an eye on your competitive advantage. 5) A note on our company's old issues: Eons ago, they hired a VERY expert (PhD qualified) engineer as a contractor years ago to build all of their systems. He fought them over the intellectual property and deliberately obfuscated code to keep his job. Make sure your team is in-house and salaried, and that you own everything they produce. Also, avoid desktop applications. The current state of desktop is a disaster. It's difficult to make anything truly useful, and you'll probably need a web view anyways to make use of JavaScript libraries that actually do what you want. As much as it sucks to say, your software probably needs to be a web application. KISS, and again, look towards tools like Clojure and HTMX to simplify things. Host as much as you can in-house. The decline of "cloud" has already started. Make sure your IT person is competent and can architect solid infrastructure, because you can't expect the same from Microsoft or Amazon these days.