What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.
PrimeLending CIO: How we rethought IT team structure
Tim Elkins shares three takeaway tips from his group's move to cross-functional teams
Every project, whether it was a new application or something salesforce-related, needed to filter through the project management office — the same place that regulatory compliance and investor demands filtered through, as well. As a result, many of the initiatives that could differentiate PrimeLending technologically as a company were trumped by regulatory and compliance priorities. It’s hard to compete with those demands.
Because important projects weren’t receiving the attention they needed, I pitched a plan to our CEO and other senior IT management to focus our attention on revenue-generating and production-generating projects. This plan centered around making a major change to our organizational structure and embracing cross-functional teams.
How we broke down the silos
Our teams operated in well-defined silos: Quality assurance, developers, and systems administrators all considered themselves separate teams that worked on project after project, for example. Our goal was to disassociate teams by job function and build a cross-functional team that would focus on building out and tending to one product.
[ Busting silos isn't easy. Read 6 tips: Ease the pain on cross-functional teams. ]
Under the new structure, we planned to select people from our siloed teams and move them to another floor where they’d form a new team continuously focused on one product. While they’d work solely for this new team on one product, they’d still report to their job-function manager as part of the reporting structure and for reviews, direction, and oversight. To ease with the transition, managers would keep two desks: one with the product team and one with their QA, developer, or systems administrator teams.
When we built this product team, we sat down with individuals to gauge whether they were interested in going deep on a product and dedicating themselves to one mission. Some expressed that they liked the variety of working on different projects and learning about the business by being exposed to different departments. Others weren't interested; it was split about 50/50.
The job-function managers struggled with this new organizational paradigm: In their minds, their teams were being broken apart and they worried that they wouldn’t be able to effectively manage them. It was uncomfortable for the team members at first, too. They weren’t being managed as closely and were working more autonomously. We decided to pilot this new structure and make adjustments as needed. If it didn’t work, we’d say that we tried it and move on.
While it took some time to adjust, in about six months it was working smoothly. When we released the first product from this team we celebrated at a happy hour. I was surprised by the number of people who approached me to marvel about how this concept was working and how fantastic it was.
Making it work: 3 takeaways
Throughout the process of building and managing this new team, we learned a few lessons. First, get buy-in from managers and make them feel that their concerns are heard. To be successful, it was imperative that the management team understood why we were trying this approach and that we heard their reservations and fears. Constant communication with them was key.
Second, select the right team members. I thought there would be a lot of people who wanted to build out one product; I didn’t expect that there would be some people who were happy bouncing from one project to the next.
We learned quickly that people fall into one of those two camps: You either like the variety of projects, or you want to be part of a team that functions almost like a software development company. There really is no middle ground.
Third, manage the change across the larger organization. Something I occasionally heard was that this new team got to work on “the cool, new, fun stuff.” That’s why dialogue with other teams is key: When I give a presentation to my department, I make sure I talk about accomplishments on other teams that maybe aren’t as sexy or fun but are just as important. Only talking about the fun, new stuff doesn’t sit well with everyone.
Since we moved to this new organizational structure, we’ve built out an application and completed projects that otherwise might not have happened. We launched an app that lets people apply for loans using their phone, redesigned our customer-facing websites, and converted those websites to responsive design.
Today, nearly half of our online loan applications come in via a mobile device – something that wouldn’t have been possible without responsive design. It also would not have been possible without a cross-functional, dedicated team working on it, which is why we needed to shift our focus to the production and revenue-generating side of the house. I’m really proud of the way the team has performed and how smoothly it’s worked. It certainly has not been perfect, but we’ve been able to accomplish exactly what we set out to do.
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.