You are a VP of Engineering. The board met on Tuesday. By Thursday the CEO has forwarded you an article and asked, with a short note, what your AI strategy is. Your team is in the third week of a release that is a month late. Two of your senior engineers are talking about leaving. You have six concurrent priorities, including, possibly, “AI strategy.”
This is a pattern. We see it once a month. The mandate from above is real. The exhaustion below is real. Both are pointing at the same fact, which is that your team has a fixed amount of capacity, and you are about to ask them to take on a new initiative on top of the one that is already late.
The wrong move, which we have watched several times, is to pick the most senior engineer on the team and tell them to “lead AI.” That engineer is, definitionally, the person who is most overloaded. You have just added a third project to their plate. They will start by spending two weeks reading. They will come back to you with a sixteen-slide deck. The deck will be sensible and unactionable. By month two the slate has nothing on it that a customer can use. By month four the engineer is gone.
The wrong move that comes second is to hire. You will not hire fast enough. The hiring market for engineers who are credible on AI is bad. It will be bad for the next two years. By the time the new person is productive, the strategy you needed has changed.
The right move, almost always, is the same move.
Pick one feature. One. The criteria are: it has to be something a customer or an internal user already complains about. It has to be small enough that a pair of engineers could ship a bad version of it in three weeks. It has to be visible. By visible I mean visible to the board, the team, and the user.
Then take that pair of engineers off everything else. Not “in addition to.” Off. Their managers will not love it. The other projects will slip by another two weeks. That is the price.
The reason this works has nothing to do with the feature itself. The feature is a wedge. Three weeks in, you have a thing in production. You can show the board a thing. You can tell the team that you have, in fact, started. You can give the rest of the team a credible story about how the work will scale: by repeating this, with two engineers and three weeks, until everyone has done one. The pair you took off becomes the second pair’s pair-programmer. By month four, half the team has shipped something. By month six, the question of “what is our AI strategy” stops being a question, because it has been answered by the work.
The board does not want a deck. The board wants to be able to tell the next board it talks to that this company is doing AI. Almost any thing in production is enough. A bad thing in production is enough. The team does not want a strategy meeting. The team wants a peer who has already done it, and three weeks of focus, and someone in their reporting line saying out loud that it is OK to ship the bad version first.
The pattern is the same in companies of fifteen and companies of fifteen thousand. The cost is the same. The cost is two engineers for three weeks, and the slipped work that comes with it. The mistake, in our experience, is not picking too small a wedge. The mistake is going wide too early because going wide feels like leadership. It is not. Going wide too early is how you end up at month six with three half-finished initiatives and an exhausted team and a board that is about to ask you the same question, with less patience.
Pick one. Three weeks. A pair. Take them off the rest. Ship a bad version. Then do it again.