Systems and People

At Purdue in the late 1990s I studied computer science, with a minor in psychology. Nobody suggested it as a combination. It was simply the two subjects I wanted: how machines work, and how people decide.

I would not claim I had a plan. What I can say is that most business problems I have dealt with since sit in one of those two places. Either the system does not do what it should, or the people around it do not do what the system assumes. The difficult ones are both at once.

Even then, I wanted both

Six years after graduating, running my own business, I went back to Purdue to ask about a doctorate. The first email in that search, in September 2005, was to a professor who had pointed me to someone in Organizational Leadership:

You had recommended I talk to a Professor in OLS with regards to the mix with IT & Organizational Leadership

In February 2006 I sent my proposed area of research to the professor who might supervise it. It was about selling technology, not building it:

My personal business interests really do accomplish my interests to learn more about internet marketing and even outsourcing. However, like most organizations, I don’t get a chance to reflect on the sales process - or how to further optimize it with relation to IT services & products.

The courses I listed to go with it were a mix of both halves: project management (“Knowing what goes into a project is important in being able to sell it more effectively”); managerial training and development, which “can relate to training and developing sales teams”; conflict management, for “conflicts in sales cycles”; leading with integrity, for the “importance of integrity in sales.” I also wrote that I wanted the research to be “more qualitative versus quantitative.”

I did not finish a doctorate. The combination stayed.

Where the problems turned out to be

In the system. In 2025 a partner asked whether one important page on topseos could be changed to perform better in AI search results. The answer was that we could not, because it would change the programming for the whole site. The content was fine. The system had assumptions built into it that a content edit could not reach. I wrote that up in Built for Google, Rebuilt for Answers.

In the people. In 2023, when DMA called its former clients, the most common reason for leaving was not that the work had failed technically. It was that the owner could not see what we were doing: “his phones weren’t ringing.” The campaign may have been running exactly as designed. The client’s experience of it was the problem. That is Calling the Ones Who Left.

In both. A proposal is a document produced by a process, read by a person who is deciding. In 2021 I told DMA’s team that every proposal “needs to solve the ‘pain’ for that unique customer” and then listed what to put in it: revenue now and in six months, traffic now and in six months, conversions now and in six months, collected at intake and measured in every report. The numbers are the system. The pain is the person. A proposal with only one of the two does not get signed, or does not stay signed.

What the pairing is good for

The story I tell about my education on this site puts it in one line: understand how people decide, then build the system around it. That is still the order I would put it in.

A system built without a view of the people using it ends up technically correct and commercially useless. A business that understands its customers but has no system ends up depending on whoever happens to be good with people that year.

Which of the two a business is short of is the first thing I look for when advising a leadership team.

Related: Why I Still Go Back to School.