AI and Machine Learning

Where AI Can Be Useful, and Where It Cannot Compete

May 15, 2025 | Tiller Inc

With the rapid rise of artificial intelligence, especially large language models and generative AI, there is understandable confusion about what these systems can do and where their limits remain. AI is extremely useful in areas that depend on pattern recognition, analysis, summarization, classification, and generation based on existing information. It can review large amounts of text, identify trends, draft content, write code, generate images, and help people complete certain tasks much faster than before.

But AI should not be confused with human imagination. Today’s AI systems are trained on existing data and generate output by learning patterns from that data. This allows them to produce impressive and useful results, but their creativity is different from human creativity. AI does not create from lived experience, ambition, pain, joy, cultural instinct, personal struggle, or a desire to challenge what came before. It can generate new combinations, but it does not truly imagine with purpose or identity.

This is why much AI-generated creative work can feel polished but familiar. It may produce music, images, writing, or video that appears professional, but often the result feels derivative. Human creativity is not just the ability to produce content. It is the ability to see something that does not yet exist, give it meaning, take risks, and introduce a new direction.

Michael Jackson is a useful example. An AI model could study his songs, voice, choreography, fashion, and stage performances. It could imitate parts of his style or generate something that sounds somewhat similar. But AI could not have invented Michael Jackson. It could not have created the unique combination of singing, dancing, rhythm, image, performance, and cultural impact that made him original. AI can imitate the moonwalk after it exists; it cannot become the artist who makes it iconic.

AI will continue to transform many professions, and people who use it well may become far more productive. But the highest-value human work will still depend on judgment, originality, taste, strategy, emotional intelligence, and creative leadership. AI is strongest when working within existing patterns. Human imagination is strongest when breaking those patterns and creating new ones. That is where AI can be useful, and where it still cannot compete.

Leadership and team building

Team Building Is Not One-Size-Fits-All

June 8, 2022 | Tiller Inc

Effective leadership begins with the recognition that teams are not just collections of job titles, skills, and deliverables. They are groups of people with different motivations, cultural assumptions, communication preferences, and ways of interpreting authority. A leader who wants to build a high-performing team must understand not only what each person can do, but also what conditions help that person contribute at their best. This means looking beyond surface-level productivity and paying attention to team dynamics: who needs autonomy, who needs structure, who gains energy from collaboration, who prefers focused individual work, and who is most effective when given a clearly defined role.

One useful lens comes from Iyengar and Lepper’s 1999 study, “Rethinking the Value of Choice: A Cultural Perspective on Intrinsic Motivation.” Their research challenged the assumption that more choice is always motivating. They found that while personal choice can increase motivation in some cultural contexts, people from other backgrounds may respond more positively when choices are made by trusted in-group members or authority figures. For leaders, the implication is important: empowerment does not look the same to everyone. Some employees may interpret many options as freedom and trust, while others may experience them as ambiguity, lack of direction, or weak leadership. Choice is only one example of a broader leadership principle: motivation depends on the person, the context, and the meaning people attach to a leader’s behavior.

Strong team building also requires deploying the right talent for the right job. A technically skilled person may not be the best fit for every high-pressure client situation, just as a charismatic employee may not be the best person for a task requiring deep concentration and precision. Leaders need to observe patterns: who brings calm to conflict, who energizes the group, who notices risks, who builds trust, who executes reliably, and who thinks creatively under uncertainty. Talent is not only a résumé category; it is behavioral, relational, and situational. The best leaders do not simply assign work based on availability. They align tasks with strengths, motivations, temperament, and the specific needs of the moment.

This same principle applies to team-building activities. Many organizations assume that social events, games, humor, retreats, or group discussions automatically strengthen a team. Sometimes they do. But forcing the same activity on everyone can backfire. Some team members value humor and informal conversation because it builds psychological safety and makes work feel human. Others prefer direct, work-related discussion and may find mandatory bonding exercises artificial or distracting. Introverts may need space to reflect before contributing, while extroverts may build ideas through conversation. A team culture that only rewards one style can unintentionally silence valuable contributors.

The role of the leader, then, is not to impose a single model of teamwork, but to design conditions where different people can contribute without being forced to become the same kind of person. Good team building combines clarity, flexibility, and respect for individual differences. It asks what people value, how they behave under pressure, what motivates them, and where their strengths are most useful. Iyengar and Lepper’s research reminds us that even something as seemingly positive as choice can have different meanings across people and contexts. Leadership is most effective when it treats motivation, communication, and collaboration as variables to understand—not assumptions to standardize.

Architecture and modernization

Microservices, Monoliths, and the Cost of Following Trends

October 5, 2021 | Tiller Inc

Several years ago, microservices became one of the dominant architecture trends in enterprise technology. Many organizations moved in that direction for valid reasons: independent deployment, clearer service ownership, better scalability, and the ability for teams to work with more autonomy. But in many cases, microservices were adopted because they were fashionable, not because the business problem truly required them. Architecture decisions should follow business capability, operational maturity, deployment needs, and team structure—not industry momentum.

A monolith is often described negatively, but that is too simplistic. A well-structured monolith can be easier to understand, test, deploy, secure, and operate than a distributed system. In many enterprise environments, business functions are tightly coupled because the business process itself is tightly coupled. Breaking those components into separate services can add network calls, duplicate validation logic, distributed transactions, versioning problems, monitoring complexity, and deployment coordination overhead. In that situation, microservices may not reduce complexity; they may simply move it from the codebase into infrastructure, DevOps, observability, and release management.

The key distinction is between a poorly designed monolith and a modular monolith. A poorly designed monolith becomes a tangled codebase where every change risks breaking unrelated functionality. A modular monolith, however, keeps the deployment model simple while enforcing internal boundaries between business domains. Shopify is a strong example: its core Rails application grew to millions of lines of code, but the company focused on decomposing the monolith internally into clearer components rather than blindly splitting everything into services. Shopify’s engineering team described this as work to manage complexity inside the monolith, not necessarily as a rush toward microservices.

There are also real examples of organizations reversing course. Amazon Prime Video’s engineering team reported that one monitoring system became more efficient after moving away from a distributed microservices/serverless design toward a more consolidated architecture, reducing infrastructure cost by over 90% for that workload. The important lesson is not that “monoliths are better,” but that distributed architecture has a cost, and that cost must be justified by the specific workload. Segment had a similar experience: after operating many small services, the company moved part of its system back toward a monolith because the operational burden and reduced productivity outweighed the benefits for that area.

Microservices absolutely have their place when service boundaries align with real business capabilities, teams can own services independently, deployment pipelines are mature, and the organization has strong observability, automation, and operational discipline. But they are not a universal upgrade from the monolith. Martin Fowler has long warned about the “microservice premium”: the additional cost that comes with distributed systems, and the need to avoid microservices until the system is too complex to manage well as a monolith. The better enterprise architecture question is not “monolith or microservices?” but “where is the actual boundary of change, ownership, scale, and risk?” When that question is answered honestly, many systems belong as modular monoliths, some belong as microservices, and very few benefit from architecture chosen mainly because it is trendy.

Data and analytics

Data Migration: Beyond Tools and Techniques

April 12, 2019 | Tiller Inc

Data migration is often described as a technical exercise: extract the data, transform it, load it into the target system, validate the results, and move on. Tools, scripts, pipelines, mapping documents, reconciliation reports, and automation are all important. A poorly designed migration process can create delays, data loss, and operational risk. But the tools are only part of the story. A successful data migration depends just as much on understanding what the data means, how it is used, and what the business expects it to become in the new environment.

The most difficult part of many migration projects is not moving the data from one place to another. It is understanding the data well enough to know what should happen to it. Legacy systems often contain years of exceptions, workarounds, inconsistent values, duplicated records, missing fields, and business rules that are no longer documented anywhere. Some fields may appear simple but carry important operational meaning. Others may be technically populated but no longer trusted by the business. Without a deep understanding of the source data and the business processes behind it, a migration can be technically successful while still producing data that is confusing, inaccurate, or unusable.

This is why transformation decisions matter. Data migration should not automatically mean copying old problems into a new system. In many cases, the migration is an opportunity to standardize values, clean up outdated structures, align records with current business definitions, and prepare the data for better reporting, analytics, automation, or operational use. But transformation must be handled carefully. Changing data without understanding the business meaning can be just as dangerous as moving bad data unchanged. The right approach requires technical skill, business knowledge, and close collaboration with the people who actually understand how the data is used.

Validation is another area where balance is critical. Some projects require very strict validation, especially when the data supports financial reporting, regulatory compliance, customer transactions, healthcare operations, legal records, or other high-risk functions. In those cases, detailed record counts, field-level comparisons, exception reporting, business rule validation, and sometimes hash-based comparisons may be justified. But not every migration needs the same level of validation. For lower-risk data, historical archives, reference content, or systems where speed is more important than perfect reconciliation, an extreme validation strategy may add cost and delay without delivering meaningful business value.

Hashing algorithms and automated data comparison techniques can be useful, but they are not always necessary. They are strongest when the goal is to prove that data moved without change. But many migrations involve transformation, normalization, enrichment, or restructuring, which means a simple hash comparison may not prove much unless it is designed very carefully. In those cases, business-level validation may be more valuable than technical byte-for-byte comparison. The question should not be, “Can we validate everything?” The better question is, “What level of validation gives the business enough confidence for this specific data and this specific use case?”

Ultimately, data migration is a balance between data accuracy, business value, project cost, and delivery timeline. A fast lift-and-shift approach can make sense when the data is low-risk, when the business needs speed, or when deeper cleanup can happen after the migration. A more rigorous approach is appropriate when mistakes would create serious operational, financial, or compliance consequences. The best migration strategy is not always the most technically complex one. It is the one that fits the criticality of the data, the tolerance for risk, and the goals of the business. Successful migration is not just about moving data; it is about moving the business forward with data that is trusted enough for its intended purpose.