This post is part of the "Growing Developers" guidance.
One of the best things you can do for the developers on your team is to stop giving them the solutions to problems they are facing, and instead ask them to find the solution on their own.
I'm talking of course about problems that are under their control, not things which require you to make it happen.
A few examples:
Instead, ask them to come up with 3 different possible designs, and show them to you. Give them a time frame for coming up with the designs. They can use a peer or the whole team to help get the design of the API right, or they can do it alone. It's their choice.
When they come to you with the API you might be pleasantly surprised by what they have. If you don't like what they came up with, you can explain why you don't like their solutions, and ask why they came up with that solution in the first place.
This would be a great place to ask them what values they were thinking of when they designed the API (maybe none!). This might be a good time to gather the team and ask them to come up with guidelines for an API (short? single point of entry? no singletons?) and then ask the person who came up with the initial problem to go back to the drawing board and come up with another three solutions for the API, and choose the one that best fits the design guidelines the team has chosen.
All this process may take a bit of time at first (instead of 10 minutes of you giving them an API, they might spend half a day working on it if they've never had guidelines before). But this is time well spent.
It's important to not only ask for one solution, but to ask for multiple solutions. At the very least, the team is open minded and not dead set on a specific choice from the get go. But there is an added benefit to multiple solutions:
Multiple solutions allow the company to "select' the solution that best fits the current status of the company in the marketplace. For example, one API design could be beautiful, but would take far too long to implement, when you have urgent things to do and get ready for a version.
Another API might be great for the short term but very risky in technical terms as it relies on a third party product that the company maybe disconnecting its ties with next month.
In short, not only are you growing your team and giving them tools to solve their own problems, you are also making the company more adaptable to changes (in the small, but that's something!).
If your team can't come up with a good solution of can't agree on the best one you can help them in several ways:
You can ask them to learn the subject matter before deciding. It might lengthen the decision but you will lower the technical risk of using something you don't understand.
It could also be sign that they are way our of their comfort zone (a team of infrastructure doing UI for the first time for example) - you can ask them to do a small "spike" - a simple proof of concept for a couple of ways to achieve the solution for a problem. should not take more than a day or two.
After the spike they will know more.
Like it or not - learning takes time. Things slow down a bit at first. You need to be confident in yourself and your team that you will all be better for this.
This scares you? good. Means you're our of your comfort zone as well! That's not a bad place to be - this is the place where you actually learn something. treat it as an experiment - see what happens.