AI Roles - Connector

Combining from the toolbox

From: Steve Jobs
To: Steve Jobs
Date: Thursday, September 2, 2010 at 11:08PM

I grow little of the food I eat, and of the little I do grow I did not breed or perfect the seeds.

I do not make any of my own clothing.

I speak a language I did not invent or refine.

I did not discover the mathematics I use.

I am protected by freedoms and laws I did not conceive of or legislate, and do not enforce or adjudicate.

I am moved by music I did not create myself.

When I needed medical attention, I was helpless to help myself survive.

I did not invent the transistor, the microprocessor, object oriented programming, or most of the technology I work with.

I love and admire my species, living and dead, and am totally dependent on them for my life and well being.

Sent from my iPad

In the quote above, Steve Jobs emailed himself a message of insight and gratitude. The message focuses on how most of what we (and Steve) use is made by others, whether in the past or present. Apple created new products and technologies by combining existing technology in novel ways. As AI and machine learning evolve, many new tools, processes, and ideas will be created and many more will be needed. The most successful teams will be those that solve problems by quickly combining existing components in new and innovative ways. That's the role the connector plays on an AI team.

In my previous post on AI Team Roles, I described the connector role as follows:

Connectors: Responsible for figuring out how to combine different systems and components together to get the required outputs. There's a certain element of combination and creativity involved while requiring a system level approach. Even though it may look like a single interface from the outside, AI systems usually require the use of many different components to work effectively. These individuals understand how to choose and glue the right components together to get the desired outcome.

To understand the role of connectors more, we'll look at the various responsibilities of a connector and how to differentiate between a good and bad connector.

The Why

No single tool can do every job. For as powerful as an LLM might be, it is not going to be an efficient data store, let alone wash your clothes. That's where connectors come in. They understand the ins and outs of each tool and technique and how to apply them. The goal of the connector is to determine the best way to combine components, ideas, and processes to solve problems. Solving problems exists in a few states:

• How can a problem be solved?

• Of the possible solutions, which is best?

• What could be changed about a possible solution to make it better?

Connectors live in all three of these states simultaneously. Due to lots of quick experimentation with the latest tools and refreshing on old ones, connectors gain an intuition for how different problems could be solved. This is because they gain an abundance of exposure to different types of problems and are able to group common issues together. They are also very well-informed and up-to-date on the landscape of tools available. For instance, Matt Turck and the team over at FirstMark Capital have put together the ML/AI/Data landscape every year for the past decade or so. This year it got HUGE. Take a look below (this graphic is zoomed out to show everything):

Figure 1. The ML/AI/Data landscape from FirstMark Capital

There's a lot of companies and tooling here. While most individuals might be overwhelmed by the information here, connectors relish in it and create their own hierarchies, groupings, and assessments on top of landscapes like this. The reason for that is, connectors need an understanding of their toolbox - when to apply a tool and when that tool can be combined with another one. A single component does not usually live in isolation and solve a problem alone. Take for instance the image below of everything that is required around ML/AI code to make it accessible to an end user.

Figure 2. Machine Learning code is only a small part of how a system works well.

Machine learning and AI code is only a small piece of how the overall system works. While it may be the engine that drives everything, it is useless without the chassis, seats, steering, etc. Connectors understand the breadth of required encapsulation and functioning that exists outside their purview.

Concerns

On the surface, a connector may appear similar to a system designer, and in a lot of aspects they are. However, there's a certain level of playfulness and alchemy required to continuously experiment with components and find creative ways to combine them. A connector is more likely to pull a tool or set of tools off the shelf in order to solve a problem as opposed to coding up something from scratch. Additionally, connectors need to be aware of project and system constraints because those control what components can be used. Some questions that connectors should be continually asking are:

• What components do we need to bring together to make this project successful?

• How do we need to transform outputs from one component to get the output we desire from a connected component?

• Is this the best design for solving the problem at hand?

• What other components/tools/processes/ideas are out there that might help solve this better?

• What happens if I add these two, three, four, etc components together?

• What emergent behavior might we see?

• What constraints should we be applying?

• How is what's intended different from what's happening?

• What's causing bottlenecks?

During the product life cycle, connectors should be engaged at the proof-of-concept and build-out stages. During the proof-of-concept stage, connectors are engaged to figure out how to create the desired product and what components will be necessary. Connectors provide several solutions for how something could be done along with the various tradeoffs. At the build-out phase, connectors are engaged to test and modify the existing system. They may swap out components as needed to get the system to perform better. At the performance tuning stages, most design decisions have already been made. Therefore, while connectors may be brought in for their knowledge of system design and understanding of the components used, this is not where their skills shine.

Activities

How should a connector effectively spend their time? Their main deliverables are designs, combinations, flows, investigations, and experiments. Connectors create systems and sub-systems by stringing together components that already exist. It is imperative that they not only be aware of new tooling but also train or experiment with it. Some activities connectors perform includes:

• Creating pipelines and modules to be inserted into a system

• Understanding the landscape of tools, processes, and ideas

• Quickly experimenting with tools and modules to see how they work

• Experimenting with combining different tools together

• System design and understanding constraints/bottlenecks

• Learning concepts and mental models from other fields in order to find novel solutions to current problems.

• Sharing knowledge about new tooling and technologies and trends that are on the rise

• Understanding system requirements for success

What does good look like?

The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. It favors composability as opposed to monolithic design. There's a famous story about Ken Thompson, one of the creators of Unix, where he was once challenged to solve a complex problem that had been previously solved with a lengthy and complicated program written by others. Thompson reportedly replaced it all with a single, elegant Unix command line. This one-liner used existing Unix commands as its components. This is the embodiment of a great connector.

Good connectors work continuously to expand their toolbox and understand how various tools can be used together. They've typically already tested and tried many solutions to problems that might arise. This enables them to quickly put together several possible solutions but they'll still need to be tested for efficacy.

Another trademark of good connectors is that they they connect ideas, typically from disparate areas. They collect mental models that enable them to solve problems creatively. For instance, they may look at the differences at both extremes to understand how a components or process works. They are individuals that look to optimize the system and not the components. Good connectors seek to understand and create emergent behavior.

Themes

As connectors practice their craft, there are several themes they should think about to be successful. These themes are operating principles to get one in the right mindset for the role. While every connector will develop their own working themes and principles, the list below is a good starting point.

• What if? What happens if we put these two components together?

• Simultaneous effectual and causal thinking. Effectual thinking is 'where can we go with what we have?' and causal thinking is 'how can we get to where we want to go with what we have?'. Both are needed for connectors to be successful.

• The Pipe. How to best feed the outputs of one component as the input into another component and then repeat until the final output is obtained. This derives its name from pipelining in Unix using the | command.

• Addition/subtraction. How could we solve this by adding a component? How could we solve this by taking away a component?

• Building the toolbox. Connectors live and die by what they can combine together. The fewer tools available, the less that can be accomplished. Connectors should continuously seek to upgrade, improve, and expand their toolbox of components.

The connector is a role that goes broad and is necessary to accelerate the build out of a system. Connectors work to shape and flow information from one form to another to reach a required end state. Connectors are responsible for understanding what components are available in the landscape, building pipelines between those components, and designing systems with those pipelines.