I'm an application architect for a brand new application. The application uses tons of data from multiple external systems. New data tables needed to be created for the application too. The person that designed the application is not technical at all. They only designed the front-end and I designed the data model based off it.<p>I did the best I could with the information I had and we are slowly starting to see a working prototype, but there are still a lot of unanswered questions that I'm trying to figure out. The project is behind. I want to take responsibility for it being behind. But at the same time the project seems understaffed and it appears too much is being asked considering the size of the team.<p>What could I have done differently?
What I will say may seem a bit counterintuitive: Early stage projects tend to not benefit from more people. It is often best to start a project with a very small number of highly experienced engineers (maybe 3 at most) and then add more people to the team as the project scales and you are in need of more functionality. Therefore, I don't believe (based on limited information) that staffing is the issue.<p>Starting new projects is hard. Especially hard if you haven't built from scratch before. It is very different from maintaining existing projects.<p>I believe the best approach would be to consult with an experienced colleague, friend or even a consultant on what you are doing/planning and how to best execute the MVP of your scope so you can get your project running. Once it's off the ground it's much easier to negotiate for more time since you start unblocking other stakeholders.<p>If you send me an email with more details on your project (assuming they should not be posted publicly here) I can try to suggest something more specific. My email is on by HN bio.
Just at a guess, perhaps you looked over the fence when you could have satisficed instead, and then you got tangled in details rather than nailing just the main issues and then driving a bargain for more time?<p>That happens a lot in tech, especially if you frame the problem as one for which the solution must also demonstrate your competence. And more especially if you are generally an externally-referencing person, i.e. "how is this type of thing done" vs. "what can I see needs to be done here and what's the easy fix that comes to mind that I'd bet on" or a contingency planner, i.e. "what general perspectives or anti-patterns am I not aware of that will break this later" vs. "later will come later".<p>Still, not knowing all the details it's just a guess. Perhaps there's also blame to be placed on the organizational psychology and it's a lesson to push back more next time, or a mix of things...