What works better in your opinion: offering in-depth training on GenAI for your software staff, or taking a more hands-off approach and letting them experiment?

My view is basic training and then experimentation is what is needed in this space.
The technology has so many potential use cases in the business and each requires trial and error to find what works and what doesn’t.
I also feel experimentation with a specific objective in mind is what is needed to ensure the team understands the boundaries they are experimenting in both from a data and business function perspective.

The thing that would work best in my opinion is to ask your staff what they want.  Tell them what your goals are, why you are asking, and where you think GenAI can apply to your business needs. Then offer resources and/or time for them to learn and experiment.  You should outline the business problems you are having where you think GenAI can help, or even ask them if they see any business problems where they think GenAI can help.  You can then let them loose on one or two of the problems to see what they can come up with.  

Be prepared with resources for training, a site or two where they can get a good grounding in how to Google for the resources they need, or with a commitment of time to actually dive into resources they can find on their own. I guess the overall approach I usually like is: point your staff at a problem and see what they can do to solve it.  Communicate that this is an exercise towards getting them familiar with GenAI so they can be better informed on what that technology can do when you do run into issues it can solve/assist with.  Transparency and engagement will make a person way more likely to take you up on an offer of resources and will make that person more likely to produce or learn something useful to the business at the end.

Your role in staff development should be to clearly communicate the business's goals and have the resources your staff want to use to achieve those goals.  You may not be able to give them everything they want, but what you can give them will be far better spent on what they want to have versus what you think they should have.

In my experience, a combination of both approaches works best. I usually set expectations for my team to learn about a subject and bring that knowledge back to the team, similar to a book club scenario. We read a few chapters on a topic together and reconvene every week. I'm a big believer in feedback cycles and the OODA loop concept.

However, I also encourage experimentation. I don't put too many restrictions on what they can explore, but I do insist that experimental work should not sneak into production workflows. I also try to coordinate sessions where we focus on a particular topic as a group, which helps to reduce duplication of work and learning. If I have 100 people all looking at 100 different things, it's challenging to incorporate all that knowledge back into the organization quickly.

I would lean more towards the latter approach - more experimentation and learning. I see this as an evolution over the next three to six months. For instance, we recently learned about the advanced security functions that GitHub offers on top of Copilot, which is very helpful from a security perspective.

We're looking to learn more about these advanced security features and how we can shift vulnerabilities and exception management processes to the left. Copilot can help developers in real-time, pointing out missing web standards before even getting into deployment mode.

From my organization's perspective, the next few months will be about experimentation and trying out these features. Eventually, as we have a similar governance model and compliance requirements, we will likely introduce more formal training. We've recently started a partnership with LinkedIn Learning, so I see more formal training as a phase two, but for now, it's about experimental learning and proof of concepts.