How to communicate technical & cognitive complexity?

"An idea is more cognitively complex if it causes you to hold more concepts in mind and think about how they relate to each other. A simple example of this is the number of moves and countermoves available in Checkers vs. Chess." It's a measure of how hard something is to understand.

Not recognizing complexity up front is one of the biggest frustrations for teams. I've seen teams think a problem is simpler than it is and/or not want to dig into the details which led to large overruns and significant stress on teams. It can make or break a team.

It's not an exact science but there are strategies.

First, how do you recognize? some data points

•  how many concepts are involved? 

• e.g. building a responsive multi form layout for a user profile to be used in multiple different apps each of which wants to highlight slightly different data/functionality has more concepts involved than a single use table view.

• e.g. supporting different billing address rules by 16 locale/region (line 1, line2, city, state, zip, postal, region etc.)

•  how many systems are involved?

• e.g. for a project in 2020 it required changes to 7+ systems (salesforce, finance, FE & BE etc.)

•  how many teams are involved?

• e.g. same onboarding example, there were all the technical teams plus legal, billing, marketing business

•  skill level and experience level of your team

•  a difficult problem for less experienced/new team may be easier for experienced established team

• significance: significant and new, significant unknowns e.g. using "for of" loops may be new (or not ;-)) but it's not significant

• architecture: how critical is it to the architecture

• importance and urgency of the product; critical or high urgency features may not be the best for experimentation, they could be but they may not be

• risk: what's the risk to the initiative if it fails? are you all in and have no plan b

• spikes and POCs are good techniques to learn more about the problem domain and also allocate time to do R&D; 

• ask other engineers for their opinions. You're not alone and there's a lot of experience around OT. Just sharing with others can be a big help to gain clarity and get opinions & ideas 

An irony is following the Agile process can make it feel harder to have the time to dig into a problem. But you can take time to do r&d and better understand the problem domain in Agile, spike tickets are a way to accommodate that.

Represent the complexity and communicate

• you need to have data to backup the explanation; it can't just be gut feel

• spreadsheets (yes spreadsheets!) can be a useful way to capture complexity eg from international billing address example list all the fields and locale by locale rules e.g. zip in US is 5 or 9 numeric but as postal code in UK is alphanumeric

• architecture diagrams, sequence diagrams etc. can help explain the complexity; I like the C4 model

• task breakdown of work to be done (helps people get an idea of what's involved)

When discussing its best to talk in terms of Risk and Priorities. It's important to understand what Product, Design & Mgt priorities are. Maybe something I think is complex & important is not as important and can thus be simplified.

Maybe something simple is more complex because it has the opportunity for reuse or significant advantage if done in a certain way

• explain the value: maybe what you're building is more than the minimum necessary but will save other teams having to rebuild it