❯ Making Sense of Technical Decisions

Business and technical teams seem to be forever at odds.

The tension is always present. I've seen it during my nine to fives, with side hustles, and as a common complaint on (you guessed it) the internet. Deloitte (figure 3) and BCG call for "new expectations [for CTOs]" and "the end of IT". This tension ultimately leads to frustration for both groups.

I've come to understand the friction as a difference in priority: a market-orientation for business teams, an operational-orientation for technical teams.

What I'll cover here is how market-oriented teams can understand and influence the decisions made by operationally-oriented teams - what's worked for me, at least - so that you can have a more effective organization.

D.R.E.A.M.

Flip the first word of Wu-tang's C.R.E.A.M into Data, and you'll have the majority of what preoccupies engineering, insights, and other operational teams. The underlying question asked is almost always, "How do I get this data to properly interact within and with other systems"?

Data is being used perhaps generously here. It moves beyond numbers into bits, bytes, variables, and functions. It is some nugget of information.

A common task I'm asked to lead is translating between market and operational teams. Over time, as I worked with engineers (many of whom later asked to be part of my team) and then begun to lead MarTech for Crossroads, I started to notice effective patterns to deliver work. Patterns that, importantly, didn't resort to artificial pressure like imagined deadlines or counting story points.

With much left to learn still, here is the enduring mental model that's emerged:

INCREMENTAL VERSUS REVOLUTIONARY

The key question is asking yourself, "How big is this change for the engineering team I'm working with?" On the spectrum of changing the color of a button (incremental) to integrating a new financial platform (revolutionary), there is a significant amount of space.

DEFINING REVOLUTIONARY

Your job, if you are on a market-oriented team, is to understand how the technical teams you interact with would define a revolutionary change. It's fluid. Every organization and team will define it differently because each team operates in a different context (scale, technology used, resourcing available, and amount of tech debt to name a few).

SINGLE VERSUS MULTIPLE SYSTEMS

Data within a singular system is easier to manage than data that's used across and between systems. The connection, quality, consistency, extraction, and output between any two systems are a moving target, even more so when multiple teams are involved.

SOLVING FOR EACH QUADRANT

Each quadrant needs a different method to kick it into gear. As you move from lower left to upper right, the quadrants require progressively more work, people, and leadership.

• Incremental, Single System - Change Request
  There isn't much to say here: hopefully, a single system incremental change can be a simple change request in an intake form.
  

• Incremental, Multiple Systems - Influence Priority
  When you start looking at incremental improvements to multiple systems, think ingesting additional features for enriching user records, this is when you'll need to know how to influence priority of the affected team's work.
  

• Revolution, Single System - Swat Team
  This quadrant is often dealing with adding or replacing platforms. I've seen this at Crossroads with our move to Asana. We assembled a temporary, dedicated team (called a swat team) who managed different pieces of system implementation, from selection to adoption, to make sure it was successful. Revolutions are too big for any one person to get done effectively.
  

• Revolution, Multiple Systems - Dedicated Resources
  When it comes to a revolution across multiple systems, like an overhaul of your CRM or building out AI capabilities, having dedicated resources is a necessity. It moves beyond budget into priority and people: FTE allocation, aligned organizational priorities, the right tools, and executive support. Senior leaders need to have agreed on the initiative's effort, operational disruptions, expectations, and resource needs.

SPEAKING THE LANGUAGE

You'll do yourself a favor learning to speak the language of the other team. For business and market-oriented teams, this might look like articulating definite use cases to your technical teams. For engineers and operational-oriented teams, linking technical features to direct business outcomes will go a long way. Directly ask the other team what's helpful—it's a great use of time.

I remember tuning into a Domino's Data Science Conference. At the time, I was leading Insights for Crossroads, and hungry for clues for using data as a catalyst for change. Walmart's Chief Data Officer, in a crisp white shirt and relaxed demeanor, spoke on data science enabling business transformation. Perfect, right? His talk, summed up in one line, stuck with me:

"The hardest thing about technology isn't the technology, it's the people".

Snapshot:

It's in the games we call Clark rocket, jammie boy, diaper baby, monster stories, dada robot, and race. It's in your most requested songs like Dragula, Renegade, and Teenage Dirtbag. It's deciding there should be a family airplane competition, which you're determined to win.

Nearly three years of invented games, inside jokes, and infinite energy. Endless memories you'll forget and I'll covet. You have changed this family for the better.

Striving for better,

Justin Pichichero