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:
- If a developer comes to you asking about what a specific API of the application infrastructure might look like - don't follow your initial feeling. Don't give them your idea of what a good API for that part of the app might look like.
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.
What do you get from this?
- The team is honing its skills - they become better at what they do
- The team comes up with shared knowledge about how things might looks in specific scenarios
- The team can now come up with its own solutions to a specific set of problems, using very simple guidelines
- You will be less of a bottleneck next time such a problem occurs
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!).
What if they can't decide?
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:
- Give them a time-box: "in 15 minutes you should choose one of these and that's it"
- Ask them if they want to add another "value" to decide against to make deciding easier
- Give them hints as to what they may have forgotten to discuss
- Make the choice for them (not recommended)
What if they don't know enough to decide?
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.
This whole idea is just adding lots of time to our schedule!
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.