After seeing early results with AI, Peapack Private Bank & Trust CEO Doug Kennedy asked his Chief Technology Officer to make a major change.
“I'd like 70% of your time to be dedicated to AI,” CTO John Kowal recalls Doug Kennedy telling him.
Kennedy then asked what needed to happen to make that possible.
At Peapack Private Bank & Trust, a private bank with about 700 employees, that was a consequential question. Technology still had to support employees, maintain existing systems, and meet the needs of a business built around personal client relationships.
The request made AI a question of how the bank would allocate leadership attention and organize its people. As its ability to build with AI grew, the technology team's responsibilities had to grow with it.
Kowal describes the changes in Episode 238 of The Artificial Intelligence Show, part of AI Transformations presented by Google Cloud. Peapack's experience illustrates a management decision that follows new technical capability: leaders have to decide who will turn that capability into useful systems and support them after launch.
Kowal says the CEO's request led to a reorganization. Peapack created a dedicated AI engineering team and its AI champions program, connecting employees across the business to the technology work.
That gave the priority an organizational form. Engineers had a defined focus on AI work. Departmental champions had a way to bring business problems into it. Kowal's role expanded around leading that effort.
The 70% figure was Kennedy's request for how Kowal should direct his time. The useful lesson is the question that accompanied it: what would have to change to make that commitment possible?
For another company, the allocation might be different, but the management work often takes the same shape across organizations engaging in AI transformation. A leader needs to decide which responsibilities can move, where more capacity is needed, and who will keep essential work running as priorities change.
That decision becomes more urgent as early experiments produce systems people depend on. The workload grows beyond evaluating a tool or approving a pilot. Someone has to decide which business needs the technology team will take on next and provide the capacity to deliver.
Peapack's earlier technology model depended heavily on implementing and supporting third-party products. Kowal says a bank of its size lacked the development resources to create a customized solution for every need.
AI-assisted development changed what its engineers could take on. The bank began building more of its own capabilities, including software for wealth account reviews and an app bankers can use to compare pricing with prospects during meetings.
That brings the technology team closer to how the business serves clients. Peapack competes with much larger financial institutions, and its private banking approach depends on understanding individual needs. Kowal says the ability to develop tailored solutions is helping the bank serve those needs and make switching to Peapack easier.
The implication for technology leadership is substantial. A team that can build more of the company's capabilities has more business choices to make. Which process deserves a custom application? Which client need warrants development time? Where does an existing product already do the job well?
Peapack still uses third-party products. But the change expands the CTO's options and makes prioritization more consequential. Internal development can now be a practical answer to needs the bank once would have taken to a vendor.
New development capacity creates another leadership problem: deciding what to build.
Peapack's champions remain embedded in its business divisions, where they understand the work and the challenges their colleagues face. They also have a reporting relationship to Kowal for their AI work, connecting their departments to the bank's AI effort.
The relationship matters because neither side holds the entire answer. A department can recognize an inefficient process without knowing how to automate it. Engineers can build a system without having lived through the work that makes it necessary.
At Peapack, champions bring challenges to technology and work with the team on possible solutions. Sometimes a champion can build a simple chatbot. Sometimes the problem needs engineering help. Sometimes conventional automation is the better fit.
For leaders, the transferable decision is how to connect those people. Business knowledge needs a route into development priorities, and employees need access to technical judgment before a promising idea becomes a system their department relies on.
The CTO's work therefore includes creating that connection. Giving engineers a list of projects is only part of the job. The value of those projects depends on whether the people choosing the work understand the problems it is meant to solve.
Building a useful application changes the responsibility of the people who must keep it useful.
Kowal describes AI as an initiative involving the whole technology team.
“The technology support team also has to support the AI solutions we're rolling out,” he says.
A dedicated engineering group can create a capability, but employees still need help when they use it. Leaders must account for that ongoing work when deciding what the team can afford to build.
This also puts business safeguards inside the design conversation. Peapack's rule is that AI can double-check work or identify a concern, but it cannot replace the checks the bank requires. A new application leaves those responsibilities intact.
For a CTO, the practical questions extend past whether a prototype works. Who will support the deployed system? Who can change it when the business process changes? Which checks must remain in place as more of the work becomes automated?
Those decisions belong in the commitment to build. Otherwise, each successful project can add an obligation the organization has not assigned anyone to handle.
Peapack's newer capabilities drew on work that preceded its AI transformation. The bank had spent years building a data warehouse and already employed people with development experience.
Those investments gave its engineers information and skills to work with as the tools improved. They also explain why a list of promising ideas is only one part of getting ready.
“Finding AI use cases isn't the hard part. You'll find them, the hard part is actually being ready to implement them when you find them,” Kowal says.
A leader can use that observation to examine the organization behind an AI plan:
The answers determine how much of the plan the company can carry out.
Kennedy's request made the commitment visible in Kowal's own job. The next step was to change the team around that commitment. When leaders ask for more AI transformation, they should be prepared to make the same kind of decision about people's time and responsibilities.
Did you enjoy this transformation story? Go deeper on how AI is reshaping work and business with The Artificial Intelligence Show. Each week, we break down what matters in AI and what leaders should do about it.