Four phases to transform your organization from IT Project to Product

An IT Quagmire

The client had a problem: every software project they tried to run took forever to complete. Even after switching to an agile methodology, teams were extremely active but nothing ever seemed to get done. Deadlines passed, commitments were unmet, quality was poor, and requirements were missed. Frustration ran high, and the business began building shadow IT teams and buying solutions from outside vendors.

When we were engaged to diagnose the problem, we looked at the organizational aspects and saw some telltale problems: project teams were composed of contributors from a dozen different organizations. Some of the team members contributed less than ten percent of their time to a project; frequently they weren’t available when needed. Only a handful of people on the team understood the problem they were trying to solve, and they had to explain it again and again to the others who came and went like the wind. Decision making was diffuse, shared between architecture, front-end engineers, back-end engineers, middleware, data management, and information security. Still others got involved when it was time to deploy the application, imposing a variety of requirements and bureaucratic hoops for the team to jump through with little or no support.

We recommended a solution and modeled how it would work, where teams would be organized around a particular product, with complete accountability for its success or failure. The organization structure would mirror this, so that rather than composing teams from across the organization (but still working for disparate leaders), they would work for a single engineering leader who would be ultimately accountable for building and maintaining a system that the customer would want. This team was responsible for all aspects of the product, from functionality to quality and operations in production, relying heavily on automation to improve their performance.

Phase one: Definition

In phase one we facilitated deep discussions about how the transformation would work. Underlying this model was a shift in decision-making authority, where engineers would be able to take a much more active role in choosing the technical direction for a project. This was a complete inversion of the “command and control” model that existed previously, and the client needed to work through the consequences of that model and how it would affect managers and leaders, whose roles would transform to a much more servant-leadership kind of work.

Eventually, opinions coalesced around a set of experiments that they would perform, with a small number of teams structured around building products, reporting the roadblocks they ran into with the greater IT organization (who was unprepared for the new approach) to leaders. The leaders, in turn, would negotiate with the greater IT organizations (who were outside their authority) to try to change they way they engaged with the new product teams. It was a daunting task.

Phase two: Experiment and Transform

We formed the teams and assigned them products, let them scale out to the size they wanted to be, and got started. Immediately, as predicted, they ran into roadblocks with the larger IT organization. Problems getting hardware, configuring a CI/CD environment, databases, all piled up. We formed a team of VPs to take on the work of negotiating with the various departments of the greater IT apparatus, learning which techniques were more effective and which weren’t. We supplied the teams with an experienced coach to help them learn how to do things they were unaccustomed to, like fully automated testing, and for leaders new and old, we coached a leadership model that gave them a framework for effectively pushing decision-making down into the organization.

Transforming the greater IT apparatus was a long slow process. Since we didn’t have top-down authority to force them to change, we had to negotiate on our product teams’ behalf the things they needed to be successful, and hold each department to commitments they made to serve us. We framed the product teams as a new kind of customer, which was a bit of a lie since they didn’t currently treat any teams like customers at all. Still, bit by bit, we found the right combination of messaging and framing to make progress.

Phase three: Expand

After about a year, the experiment had proven itself successful and leaders chose to form a series of new product teams in this model. Greater IT still hadn’t completed its own transformation, but the thought was that enough had changed that while the new teams wouldn’t have a trouble-free journey, the benefits of the newer smaller teams outweighed the performance impediments they might face with a halfway-transformed IT department. This had the effect of increasing the urgency of transforming the teams in Greater IT, focusing on the needs of the increasingly large force of the new product teams.

In order to achieve the best results, more and more teams began gathering information from their customers about their needs, and establishing a process that transparently shared their feature backlog and made it easy to prioritize them.

Phase four: Sustain

• Focus on customer satisfaction

• Empower product teams to solve their own problems

• Give a clear vision

  • Who’s the customer(s)?

  • How do you know what they want?

  • What are the organizational values?

  • What are the constraints?