Routines and well-worn processes can serve as our own factories and help provide predictability in life and business. A defined set of steps produces a desired outcome, essential for providing structure in a chaotic environment. The world of software can also be chaotic at times so it makes sense to reach for certainty and predictability.

Unfortunately, the predictability of an operating factory doesn’t translate to the design and construction of the factory itself. This process can be fraught with uncertainty, delay, and escalating costs. It requires experience, effort, and creativity to build a factory or create a good routine. When we mix up the factory analogy, we overlook the significantly greater difficulty in designing and constructing the factory compared to its operation. The principle holds true for software as well.

“We realized that the true problem, the true difficulty, and where the greatest potential is – is building the machine that makes the machine. In other words, it’s building the factory. I’m really thinking of the factory like a product.” - Elon Musk

Every time we are working to build a piece of software we are engaging in this difficult task of building the machine that builds the machine. This process must withstand various pressures, react to a shifting environment, and roll with uncertainty. At the outset, we don’t even know what the product is going to look like in the end! We have a conception of what it could look like but it will inevitably change throughout the development process.

Through the experience of designing and building the factory, we learn more about what we are building and how it can be constructed. We understand better what we like about the solution to our problem and what we don’t like as much as we originally thought. These realizations create conflict with the step-by-step assembly line we often associate with software development. Our process should instead embrace new information and the rapidly changing world around us.

These conflicts born out of the factory analogy result in unrealistic expectations. Stakeholders believe they can simply send in requirements, resources, and funding in one side and wait a defined time frame for the finished product to come out the other side. The mindset needs to shift to one of involvement, experimentation, and iteration. By thinking of software development as an evolutionary process we can better understand that each development project is not the execution of an assembly line but a quest to build the machine that builds the machine.

Does this sound like your experience with software development projects? Reach out @EncodedInsight and let me know!

Subscribe now

To deal with the unknown, you ask for references and research the latest industry trends. Your references confirm the risks and provide tips that hardly instill confidence. There are stories of large overruns in both time and budget, coupled with end solutions that simply do not work. Your research consists of sifting through sterile blog posts and technical jargon that do not map to your business.

The current model of engaging with outsourced software teams is missing a key component. The discomfort of investing outside your expertise is not unique to software. Fortunately, the world of construction has encountered this issue and developed a way to help mitigate the risks.

You need an Owner’s Rep.

You need someone who can speak the language of both your business and the engineers writing the code, who has been down this path numerous times, knows the questions to ask, and recognizes the typical warning signs. Your business problem and your vision for the solution must be translated and properly conveyed to the team that is doing the implementation.

You need someone who looks at the world from a technology perspective and has your best interest in mind. The purpose of the investment that you are making is not technology for the sake of using technology, but instead leveraging technology to advance your business. If the implementation is not pushing your business forward, it is not worth the investment.

What is an Owner’s Rep?

• An Owner’s Rep is:

  • Focused on your unique business

  • A translator between your business and technology

  • Incentivized to provide immediate value to your business

  • Equipped with best practices acquired through hands-on experience

• An Owner’s Rep is not:

  • The decision maker; only you as the owner can be the decision maker for your business

  • Dictating the technology used in the implementation

  • Writing the software; proper incentive alignment is extremely difficult

You’re investing in technology and you need someone who works alongside you to manage that investment. Someone who sits on your side of the table and has experience delivering the outcome that you are looking to achieve.

An Owner’s Rep provides value in a variety of ways, from simply acting as a sounding board when you need a different perspective, to standing by your side through every phase of the project, overseeing your investment in detail. An Owner’s Rep is the person who operates to protect the technology investments that will drive your business forward.

If you are leveraging third-party development resources, having an Owner's Rep is not a luxury; it's a necessity. Reach out on X @EncodedInsight or email logan@encodedinsight.com to start experiencing the immediate benefits an Owner’s Rep can provide.

Subscribe now

I have been periodically delving into the concepts surrounding the intersection of software and business but through a different lens. I realized that I was attempting to describe my entire thought process, which led me to operate at a deeply technical level, a tendency I have as an engineer.

But instead, my focus needs to be on what impact my thought process has on the world. Why does this intersection of skills I have accumulated actually matter to anyone? How can I help in a tangible way?

A concept that has always fascinated me is that of an Owner's Rep. I was first introduced to this role by a friend who worked as one in the data center construction industry. It seemed similar to what I had been doing within the software organizations I worked for – an intersection of practical, real-world experience and a business's allocation of investment into technology.

The framing is close but doesn’t quite capture the full essence of what I envision Encoded Insight to be. So, I naturally went to ChatGPT for some inspiration. I had a wild thought and asked it how Jack Sparrow would describe my business. The result was hilariously on point. 

“Ahoy matey! When it comes to custom software development, there be no need to set sail alone. Ye can have a trusted translator by yer side - one who’ll speak the language of business and engineering with equal fluency. With an owner’s rep by yer side, ye can navigate the rough waters of software development with ease, and bring yer business vision to life with the wind in yer sails!”

I’m not planning on talking like a pirate from here on out but I am going to be exploring what it means to have an impact on the world. How does my unique experience tangibly affect those that I work with? Why would someone want me on their voyage with them?

If this has made you think of anyone you know, or someone who has helped you with the process of allocating investment into technology, please reach out. I would love to hear about it! 🙏

You can find me on Twitter or at logan@encodedinsight.com

I’m sure many of you have heard that before from someone in your organization. The role you entrusted them with is being infringed upon by someone else. This may be due to the role not being properly filled, a change in the needs of the role, or someone else taking the initiative to gain more responsibility. This can be used as an opportunity to grow but the solution should take into account the principle of encapsulation.

What is encapsulation?

Encapsulation is a software engineering principle that states all of the actions and information related to a particular area of a system should be self-contained in that area. It is designed to provide simplicity and a clear understanding of what code is responsible for each piece of functionality.

Similarly in an organization, each role is created to handle a specific function. That role alone should handle the related tasks and information of that function. An organization should trust and empower each role to execute its responsibility. This does not mean that you are creating silos that do not communicate effectively but instead roles that are confident in their place and communicate their value clearly to others. Organizations that follow the principle of encapsulation have an unambiguous structure and a well-organized flow of information.

encapsulation

[ en-kap-suh-ley-shuhn ]

noun

1. the placement of all tasks and information related to a function inside of a single role

Encapsulation requires trust and ownership. If a role does not take full ownership over its responsibilities then some of that responsibility falls to others. This failure breaks encapsulation and scatters the previously tidy role across the organization. Instead of distributing responsibility haphazardly, it is best to understand why the breakdown in encapsulation has occurred and address the issue in that context.

Encapsulation may be a software engineering principle but it has value when applied to the business world as well.

Let me know on Twitter how you define encapsulation in a business context. 🙏

Subscribe now

Warning Signs / Code Smells

What are the signs of a potential breakdown in encapsulation?

• You hear people complaining that an area of the organization is telling them how to do their job

  • Why: This could mean one role feels the need to handle part of another role

• You receive versions of the same data from two different parts of the organization

  • Why: This could mean that two or more departments are taking ownership of the same data set

Understanding Insight is the process of uncovering assumptions and increasing awareness about the way your business operates. This is done through curiosity and legitimate interest in the core problem that your business was created to solve.

The goal is for you to learn about your business and the decisions that have led to the processes you are operating with today. The questions that are asked throughout the process will provide value by promoting a discussion of first principles and not instructing “This is how it should be done”.

The idea is not to come in and tell you how to operate. But instead, to ask questions that allow you to see your business through a different lens. This different perspective will allow you to step out of the weeds and see the full landscape of your business. From this perspective, the areas in which you are deviating from your core business, the accepted shortcomings, and the outdated habits become far more evident. You have the insight, you just need to take the time to properly leverage it.

Phases:

• Deep dive, focusing on first principles of your business

  • On-site or remote

• Process diagram build-out and question period

• Initial diagram review

• Diagram revisions

• Final review and hand over

Time frame: 4-6 weeks

All of the source files and formatted notes will be handed over to you at the end of the process. This allows you complete optionality. Take the diagrams and knowledge gained and improve your business however you see best.

Request a Quote

What do you get?

• A detailed diagram of your backend business operations

  • Processes

  • Tasks

  • Data flows

    • Inputs / Outputs of each process

    • Connections between processes

  • Assessment of process debt

  • Opportunities

• Source files

What Understanding Insight is not:

• A solution to all of your problems

• Outsiders telling you how to run your business

If Understanding Insight sounds like something that could help you leverage the insights you have developed, request a quote.

As a result of these challenges, you develop a unique set of insights about your business. This accumulation of insight does not come from the outside. It is instead a layered composition of learning and adaptation driven by what you believe to be best for your business.

But, do we fully leverage these valuable insights?

The incremental evolution of a business means that our processes are composed of small, typically in the moment, decisions. This continual focus on the immediate moment does not provide time to reflect on the impact a decision has on the rest of the business. Which often results in a collection of competing processes that pinball in our desired direction.

The best companies seem to work in concert to achieve their mission. But many times, in our own business, we run into areas that just get in the way. When a process is not aligned with the rest of the business friction develops between that process and the rest of the operation. This is when a decision has to be made. Do you push through the friction or remove the process entirely because it is not in line with the core focus of the business?

Over time the core focus of a business stays the same, but the way short-term goals are achieved can change dramatically. When experiencing growth you may find out that processes that worked for you yesterday do not meet your needs today. Attaching yourself to early insights and not updating them as your business scales can leave your business constantly responding “This is the way we have always done it”.

You fight hard to build up your insight but it can get lost in the messiness of operating a company. Many times you need another perspective to allow you to take a breath and look at your broader vision and reset where you currently stand on your path. It is not about handing down an outside model that instructs you on how to run your business, but instead, it is about helping you make the most out of the insights you have developed. This is what Encoded Insight aims to do. We call it Understanding Insight.

This opportunity has led me to understand the interconnectedness of a business. A business is a system, but it is typically not designed with software engineering principles in mind. Because of this mismatch, companies that attempt to implement software to address issues or scale their business often run into significant problems. Many of the problems can be attributed to the fact that the implementation of software is undertaken prematurely.

A business needs to be viewed through software engineering principles before its systems can be translated into software. Companies are composed of complex data flows and interdependent processes that all need to work in concert to achieve a desired outcome. When companies are viewed through this lens, inconsistencies, breakdowns, and opportunities are revealed.

Encoded Insight is about applying software engineering principles to a business's operations and then using that perspective to design and implement software that addresses the needs of the business. Every step along the way the business is learning. And at each step the business owners have the ability to take what they have learned and use it to improve their operations.

There is a place for this fundamental perspective. However, this approach alone is overlooking a rich repository of insight.

The insights you have developed about your business.

These insights have been incrementally built up over time and are unique to you and your business. No one else has developed the exact same insights. No one else has faced the exact same decisions. The ability to make proper decisions for your business comes from not just facts and figures, but a strong intuition.

Only after these insights are understood can the conversation be had about encoding your business through software. For a business to reach its full potential the insights of the business have to be translated into processes that can be owned and executed independently. These processes are a blend of standard procedures, timely data, and software.

Attempting to design software without an understanding of the core business can be frustrating and costly for everyone involved. A deep understanding of both the business and software are required for an effective translation from one to the other. The value is in the bridge, the combination of the two. The goal is not to replace your insight but to encode it.

This is not an easy bridge to build and many people shy away from it. There are many questions that arise as we dig deeper into what it means to translate your business insights into software.

• What does it mean to build a bridge from software to business?

• Is there a common language that can transition concepts from business to software?

• What language should be used to translate software engineering concepts to business?

• Are we effective at encoding the insights people have accumulated about their business into defined processes?

The only way that these questions will be answered is for you to help me iterate on my own insights. These posts, along with short thoughts on Twitter, will be how I communicate my evolving understanding of what it means to encode insight.

I’m @EncodedInsight on Twitter, feel free to reach out with feedback or insights of your own.