How to get my project ideas funded?
I've identified a few project ideas and even proposed to my managers in a semi-formal context. My managers don't seem to be very interested in those projects. In general, how to get my project ideas funded?
Some of my ideas are big, some of my ideas are small. Big ones can start from a minimal bare-bone product. I guess my best bet is to propose formally and work on the side?
Discussion
(3 comments)- 2
3 months agoStaff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDEDoes a product manager think they are good ideas? If so, partner with them, get them to champion it, and get it on your team’s roadmap. If they don’t think it’s a good idea, and your manager doesn’t think it’s a good idea, either you need better support for it (showing market fit, user demand, etc) and be able to demonstrate it is a better way to spend time than your current roadmap. If it isn’t, it isn’t the right thing to work on.
If it is actually small, if you can keep everything else on track and prototype it, so be it. Showing people something, and showing progress in a short amount of time, can make it easier to allocate a trickle of time. Otherwise, and rightfully so, the assumption is that it will be much bigger than you think and will be a whirlpool for time.
- 03 months agoMid-Level Software Engineer [OP]Taro Community
What about small ideas on improving system infra? Here's a classic design decision: 1) use an old framework that meets all requirements or, 2) there's a new framework but it's missing features, so we can invest 4 weeks to close the feature gap for the new framework and use the new framework.
It seems to me Option 2 has bigger scope. Option 1 saves time and for business perspective, Option 1 is no brainer. How to advocate for Option 2?
- 03 months agoStaff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE
4 weeks is a significant investment, so I have to assume the new framework isn’t just “new”, but better in measurable ways? Or enables some cleaner or clearer paradigm in your code?
Can you create a shadow API for the new framework that matches the existing functionality exactly, then defines the missing functions the way you would implement them if it were to be enhanced, then behind that delegate to the old library? You can then write your new code against the proper specification for the new library, but you spend a day writing the shadow API object/interface. You can do migrations as you touch other files (potentially even method-for-method if you use an instance of the old library directly, or via the shadow API initiated with that same instance), so you get more and more compliant to the new library.
You can then, without blocking, do piecewise improvements to the new framework, but not have to do a big-bang conversion when it’s ready, or block building the new thing. Once the new framework is ready, you can first make it “switchable” via the Shadow API, then just change your imports (or whatever for your language) to swap strictly to the new framework once you’re confident in it.
This provides an upgrade path for other systems as they can also use the shim/shadow to do method-wise transition, then the ultimate swap.
Maybe this is totally impossible, and you’d have to derive dozens of result object shadows and so on, no idea what it does. I am only saying that blocking direct work on a new feature or system on a 4 week “nice to have” dependency upgrade is simply a hard sell, and in no way a small undertaking. If the old library is deprecated and you’re adding it to a new project, that is certainly different, but finding a way to keep working while migrating gradually in parallel is still a sell.
Unless using the old dependency is so inefficient to develop with, adding more than the 4 weeks you’d need to switch to the new one, this is a really hard sell as you present it.
