Managing the Technical Complexity of the HP Split

My first job out of college was with HP as a Technical Business Analyst and Project Manager for the Integrations and Web Services team within HP Support. (Sorry, I know that’s a mouthful.) We built the APIs that surfaced support, product and customer data from the countless databases cobbled together across the years of ever-changing technology, mergers and acquisitions. Our APIs made that valuable data available to the support website (, HP call center tools, enterprise technical support apps, partner tools and dozens of other systems that I'm sure there are acronyms for, but I can't remember as I write this.

My responsibilities quickly shifted to include project management alongside my technical business analysis and scrum master roles. Around the same time HP announced that it was splitting into 2 separate Fortune-50 companies—Hewlett-Packard Enterprise and HP Inc. We called them HPE and HPI internally.

Meg Whitman

How Hewlett-Packard plans to split in two


Stepping Up—Being the Face of Our Team

After the announcement, it took a while for the implementation plan to trickle down to the technical team level, but by the time it did, the split had become an all-consuming priority. We had a due date, November 1, 2015, and there was no way we were not going to miss that date.

Meg (the CEO) set up a central organization to manage the transition across all aspects of the company. From the beginning, it was clear that there were three long polls that had the vast majority of the work, and we were one of them—HR, Finance, and, yes, IT.

To make things more interesting at my first job out of college, our manager left for another division of the company, and instead of back-filling his role, my entire team was rolled up under a Vice President who lived in Europe. He was a good manager, but due to time-zones and time-scarcity, I needed to step up and be the face of our team, so I did.

As the planning reached our level, I became the go-to person for my teams assets, and I worked cross-functionally to develop the implentation plan that we followed to prepare for launch day.  


Organizing the Complexity

Our team by definition built middleware, integrations and web services that sat between software built by other teams across the entire organization. My team owned 24 distinct software assets, most of which had dozens of upstream dependencies and downstream users. These assets averaged nearly a billion monthly requests.

My approach was to keep things simple. I couldn't get fancy if we were going to succeed. So I took a systematic approach, built a spreadsheet to track my progress, and worked with both upstream dependencies and downstream users to prepare for launch day.


  1. I reached out to the head of each team that owned each of our upstream dependencies

  2. We determine if any changes were necessary to accommodate the split

  3. If changes were necessary, I worked with them to determine a technical approach, plan, prioritize and implement development needed to accommodate those changes.

  4. We made sure to test, test, test and retest.


  1. Several of our downstream users reached out to me (much like I'd reached upstream) but not all. So after we'd determined all the changes necessary to our systems, I reached out to the the head each downstream team.

  2. I informed them of the changes we were making that would effect them.

  3. I explained the optimal approach my team recommended accommodating those changes

  4. I provided guidance on testing in preparation for launch day.


Flipping the Switch

The official split of the two companies was November 1, 2015, but the IT split was a few months earlier on August 1. Some systems weren't legally aloud to be changed until that day, but many, including pretty much all of the Support organization could be switched over ahead of time. So we split the launch up into multiple days the weekend of August 1.

Our systems had been tested thoroughly in lower environments both upstream and down, and we were confident that they would work. The clock ticked down to launch time, and the announcement was made, flip the switch. So my team began deploying our systems to production and reporting their progress to me, and I would in turn report to the central project management office. All of our releases were completed on time, upstream system changes were as expected, production tests passed. We did our part, and the company-side IT separation was a success.


Takeaway: Managing technical complexity as part of the HP/Hewlett Packard Enterprise split taught me that often times the best way to approach complexity and scale is through simple organization and clear communication.



More Product Work