Managing technology during a time of radical organizational change

A few years ago while I was CTO of PTKO, I was asked to work as a technical advisor/Fractional CTO for CrossFit, during a time of change/upheaval.  They had explosive growth both in terms of membership & media exposure, such as with TV & merchandise deals. However that boom was coming to an end and their ownership wanted to refocus on their core mission of fitness, health, and funding health research.  They found themselves in a place that many organizations do, where their public brand, and the technical infrastructure they’d built to support their growth and evolution were not in sync with how they saw themselves overall. 

The core systems running their membership & accreditation of CrossFit gyms had been largely ignored while they built out terabyte level media management capabilities, along with live broadcast systems, and scaled out their financial systems using Netsuite as their ERP.  However their core business heavily relied on some aging custom applications, Salesforce as their CRM for gym owners & trainers, and they had a confusing mix of public facing web systems, with a mix of technologies, disjointed development teams and external agencies supporting all this.

They wanted to simplify & streamline their technical footprint, and re-orient it around their membership experience, and their ability to advocate for change.  At the time they wanted to shine a lot of sunlight on the health risks and negative impacts of sugar in your diet.  They would feature & deliver research on this subject to their website and membership and in some cases they were actively litigation against sugar & soda industry funding of “pro sugar” studies.

My initial approach coming into this was to work with (and sometimes define) the different groups and political power centers within the organization, what their goals were, the friction points they had encountered, and assess their understanding of the technical, staffing, and real world business processes that I was documenting & identifying through my own audit.  This allowed me to identify where communication & education would be helpful in building consensus, where there were disagreements on approach, effectiveness, or business process ownership, and where the blind spots were that I might need to investigate and create my own documentation or illustrations.  This initial process helped build trust and investment in the process, as people felt their opinions were valued, listened to, and would inform the future changes.  Experience has taught me that many, if not most, of the technical problems that businesses face are driven by the business strategy & needs as much as they are driven by technology choices or architecture, and improving the technology situation was going to require understanding and a willingness to change how the business owners worked as well.

With this people, process, and goals understanding, I then focused on documenting & illustrating (often for the first time) their technical ecosystem.  Which systems talked to which, where were the real sources of truth, which places had governance & rules for naming things, which did not, what API’s & services existed for integration, and which were actually integrated.  I also worked to understand the satisfaction or friction with each system or tools that the departments and real world users had.  I used these to reflect back what I had learned, building both trust & faith that I understood the real experience of each person, and that they contributed value to the change & planning process by having their insights & experience reflected in these documents.  At this point I was working with the various technical experts & developers they had working on each system. What I discovered was that a technical team that had initially been described as one team, was really several smaller teams, each focused on one area, without any larger vision or architecture tying their work together.  In essence they were pushing different parts of the technical architecture farther away from being streamlined & integrated, rather than closer.  Like many engineers in these situations, they were aware of this, but felt powerless to influence the business owners & leaders who were directing their work.

Finally I mapped out which systems their customers, supporters, and the public had access to or interfaced with, and mapped those back to the internal teams responsible for managing those. This allowed me to identify & illustrate where their brand experience & customer experience had issues, inconsistencies, or could cause frustration or confusion externally.  This was immensely helpful for reducing confusion between departments, and building buy-in for change as it was clear where things could be improved, and where legacy solutions had been outgrown or not connected with new parts of the architecture.

This gave the organization an overall and accurate view of their current architecture.  I used it to start mapping out how and where I thought changes could be made, noting with each one the lift, effort, and activities that would be needed to make the change.  I then talked with each department or technical development team that would be impacted and both ran my change/improvement concept by them for feedback, and then went through the thought exercise with each of them to see if the activities & effort I was estimating were accurate. I worked with each team to help them understand my rough order of magnitude units for effort, and to ensure that activities such as training, backing up, sunsetting systems, and other often overlooked things were included.

After all this I was prepared to develop recommendations and work with the various stakeholders to both prioritize these recommendations, and nurture their buy-in and consensus for supporting change.  As my plans for a path forward came together, I made sure to deliver them each as a package starting off with the strategic goal the business wanted, the high level architecture that supported that (both technical and business) and then a supporting document of detailed tactical nitty-gritty technical and business process architecture recommendations.  This allowed everyone, regardless of technical background, to understand the recommendations, understand the business impact, and then if they so desire & felt comfortable dive into the specifics of how the overall recommendation would be achieved.  After getting support from the leadership team, I moved onto what is really the more difficult problem, of helping the departments and the technical team adopt and implement these recommendations.

While all departments would be affected, the biggest impacts would be felt by the technical development team.  During my interviews & technical audits with each developer and technical team, I had been able to learn what they focused on, how they worked, and most importantly how much insight & information they had about the business’s goals for each system they worked on.  One of the things I quickly realized was that most of the developers would be more effective, and make better decisions for the business if they had more information about the goals & outcomes their tasks were in support of.  When I shared the documentation and visualizations I’d been making, I often heard “This is the first time I’ve ever seen this.”  That was true even for near neighbor systems & developer activities.,  

To help address this I lead a series of team building & process changing sessions for the various developers to build a more unified vision for the company's technical architecture.  This meant helping them adopt for the very first time, an annual roadmap for the technical architecture and a collaboratively managed digram of that architecture.  I also helped them stand up governance models and decision making processes for agreeing on things such as database field names, figuring out how to jointly maintain and support microservices & integration apis needed to weave systems together.  There was also a problem of “just a little too much work” that I helped them overcome by creating templates for things like diagramming box & diamond diagrams of business processes and setting up shared & easy to access data dictionaries.  Most importantly it meant shining a light on who was doing what, and how those changes were being announced and shared, so that cross-team/department impacts could be recognized and considered sooner.  

All of this needed to be done in a time efficient way that didn’t greatly reduce developer productivity or require new technical “process managers” to be hired.  One of my focuses here is never let the perfect be the enemy of the good, and that plays out successfully by finding sustainable processes that everyone can keep up with and do frequently, even if they leave some gaps or don’t cover every contingency. 

A new path forward also meant that some pet projects and over-engineered components needed to be abandoned or simplified to support the organizational mission.  For example the team had been building out the main company website with the CEO’s blog on it to use an atomic-design system synced across all the various other web properties.  However they had only been able to deploy the design system to about ⅓ of their web properties for a variety of reasons.  Yet this design system was greatly slowing their ability to innovate & explore various ideas the CEO had for their outreach.  One of the recommendations the tech team had to come to grips with was balancing the “best technical approach” with the organizational mission and needs.  Working with them around supporting the mission led to a new technical approach, using a Wordpress site they could quickly and radically change to explore things with the CEO while pairing that with a roadmap to fully deploy and manage the design system to their more static web properties that could really benefit from a consistent and managed user experience.

The recommendations I helped them adopt impacted deployed technology, data integrations, data/content governance, departmental "ownership' of processes, changes to standard operating procedures, and organizational & departmental technical budgeting.  Every organization has a difficult time with change and it's hard for anyone to listen to and consider change if they haven't felt heard, understood, and valued beforehand.  This change management process helped ensure that the discussions and debates that followed were healthily focused on how to solve problems, and what was the best way forward, rather than if the problems existed at all, or who was to blame for them.