Have you recently received a message from a company seemingly connected to TSG? Are they offering something that sounds almost too good to be true? Maybe the job they’re offering is exactly what you’ve been looking for, or they promise a fast return on an investment with minimal effort.

Unfortunately, beginning in August 2023, some people in the UK have been receiving offers like the above from a company claiming to be affiliated with TSG. Some have been told their information was obtained from a recruitment agency or a national recruitment database, and some have also been directed to register with an online platform (see images below). Targeted people have been promised profits on their “investments” and some claim to have been scammed out of thousands of dollars.

**Please note: This company is not in any way related to TSG and is falsely attempting to impersonate our company.** We do not operate any platforms outside of [thesmythgroup.com](http://thesmythgroup.com) nor do we email anyone from any other domains. We also do not contact potential job candidates from numbers or offices outside of the USA.

We have been working closely with the FBI and FTC in the United States to resolve this issue. If this company reaches out to you, do not respond to them. They are committing fraud.

**Their app and website interface:**

![Screenshot of scammers website](/uploads/tsg-scam-1.jpg)

![Mobile screenshots of scammers website](/uploads/tsg-scam-2.jpg)

## What to do if you’ve been affected

Immediately discontinue engaging with them. If you’ve been affected by these scammers, we encourage you to contact your local authorities and file a report at [](https://l.facebook.com/l.php?u=https%3A%2F%2Freportfraud.ftc.gov%2F%3Ffbclid%3DIwAR3JD5nwmbN_eaFoJw83FIof8tu0y_xu-hZ4Cy_hLYud8p6XsCLqiqxOJyc%23%2F&h=AT0sUeCC2Fm5kuppp90ibGPDympJe6-Yl9H4hgJ9Jj5PqqzehDaip8eBVtAZB2EtpjiPim1IQ8Mr2wb_Z1OzYNQpYfm4joGWJm3WY4nhDd_Pwc_TnCiMT7eAdbRo4w53eqViSGBe)<https://reportfraud.ftc.gov/#/>

Screenshot of scammers website interface with the word "FAKE" stamped over it in big red letters

Scammers claiming to be TSG are trying to mislead people into investing money through fake job offers.

“Is this you?”—Scammers Pose as TSG Subsidiary 

## The Legend of the Gordian Knot

When Alexander the Great traveled through what is now modern day Turkey, he came upon a curious challenge. 

In the town of Gordium in Phrygia was an ancient ox cart tied with a complex mass of knots known as the Gordian Knot. A local legend claimed that whoever could loosen it would be destined to rule all of Asia. Alexander struggled with the convoluted web of cords before determining, “It makes no difference how they are loosed.” 

So in one simple yet bold act, he slashed through the knot with his sword.

## From Alexander to the Modern MVP Philosophy

This simple solution to a complex problem could arguably be called—2000 years before the term came into existence—a minimum viable product, or MVP. 

When Alexander first confronts the Gordian Knot, the assumption is that he will attempt to untie all the pieces, which were described by the ancient historian Quintus Curitus Rufus as “several knots all so tightly entangled that it was impossible to see how they were fastened.” Instead, he tries a minimal, unexpected solution, and it takes care of the problem completely. 

Eric Ries popularized the concept of an MVP in his book The Lean Startup, saying, “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” 

In other words, start simple, test, make adjustments; rinse and repeat.

MVPs are about challenging assumptions and trying solutions that may initially seem “too simple.” This doesn’t mean your final product will be too simple to do the job thoroughly (if that were the case, it wouldn’t be the right product for you), but it is a stage we begin at to better test assumptions. 

![Alexandar the Great cuts the knot and declares a new precedent for software!](/uploads/alexander-cuts-the-gordian-knot-563f2d-edit.jpg)

## Simplicity Through The Lean Startup

One of the great advantages to adopting this Lean Startup Methodology is that you may discover a far simpler-than-expected iteration of your product that satisfies your needs, saving you time and money. 

Of course, Alexander found a solution to his problem rather quickly, but there are many stages to building suitable software for your business. He also didn’t have more to keep cutting after that first successful slash. 

But creating software is an iterative process that requires refinement. In the spirit of experimentation, we build a simple product, test core assumptions, and make adjustments accordingly. We build and adjust in small stages until the correct product has been developed. In this way we avoid wasting time on features you won’t use, we save you money by not building more than you need, and the final product is stable and easy to use because it fits perfectly into its role in your organization.

### The Southwest Airlines Solution

This process takes humility. Cody Thompson, COO of business consulting company The Table Group, tells an intriguing story on his [podcast](https://www.youtube.com/watch?v=HW4iAwzUT9E) about how Southwest Airlines solved a problem they were having with customers accidentally throwing away their paper boarding passes before they reached their gate (Ah, the days before cell phones!). 

He explains that Southwest agents at the ticket counter “would print the boarding pass and the receipt on the same paper…and they had this huge problem where people were just throwing away their boarding pass because it looked like a receipt.” 

Southwest investigated several solutions to the problem, such as installing self-service kiosks or building out different systems, all of which cost millions of dollars. According to Thompson, the solution they ended up adopting was to “tell all their gate agents to write ‘This is a Boarding Pass’ in red pen on \[the] boarding passes, and it solved the problem almost immediately.”

![Boarding pass with a note written in red ink, reading: "This is your boarding pass!"](/uploads/boardingpass-southwest.jpg)

While self-service kiosks were emerging in the industry, Southwest chose not to adopt this new technology immediately. By staying lean, they found a simple solution with a red pen and waited to adopt the kiosk at a point that was right for them.

While red pens are far less sexy than new automated systems, Southwest had the humility to solve their problem in the leanest way. The resources they saved—from the initial cost, to ongoing maintenance, to training and onboarding employees—can’t be overstated.

## The Lean Software Ecosystem   

It is in this same spirit that we build the leanest software you need. 

Complex software ecosystems can be a burden on your team's productivity and morale. With too many tools to manage, employees might find themselves navigating through a maze of features, unable to focus on their core tasks. New hires will have a longer training and on-boarding process. 

On the other hand, a smaller, carefully curated software ecosystem makes your employees’ lives better, reduces potential points of cyber-attack, and simplifies security measures. A concise software stack is a boon for extracting valuable insights. Fewer tools mean better data integration, which provides a clearer picture of your business's performance.

So while the allure of large software solutions can be tempting for managers looking to boost productivity and stay ahead of the competition, we want to challenge the notion that more internal software equals better business outcomes. We encourage a strategic, streamlined approach to software adoption, focusing on essential tools that align with your specific needs. 

By keeping your software lean, you can adapt to new challenges and opportunities more efficiently. This adaptability allows your business to stay competitive and seize emerging trends without being weighed down by unnecessary software. 

## A Minimalist Approach to Cut Through Your Gordian Knot

When a client approaches us with a custom software project, they may carry with them some assumptions. 

For example, they may assume that the software needs to have a lot of features for it to fulfill the business goals. Or that it must be retrofitted to work with other products. Or that an entire system needs to be built, rather than just one piece. 

To make the best possible product for your business, we will need to step outside these assumptions and approach the problem from the perspective of creating the leanest version of your product, testing how it works, and building out from there. This process has been proven result into the best use of everyone’s time and resources.

And frankly, if you don’t need custom software, we won't recommend it.

![A TSG designer sitting with a client reviewing his app features.](/uploads/strategize-xcitedemo3-email.jpg)

We want to help you cut your Gordian Knot—that’s why we are committed to taking a minimalist approach to our projects and avoiding assumptions throughout the software journey. If you’ve got an upcoming custom software project, contact us to explore how our core values can ensure your project’s success.

AI Illustration of two hands untangling an abstract ball of yarn and fibers. 

See what an ancient legend can teach us about a lean approach to software development today.

Alexander the Great’s Approach to Software | TSG Article

Alexander the Great’s Approach to Software Development

In 1940, an $11 million dollar bridge over the Puget River in Tacoma, Washington, buckled and twisted in 40mph winds before snapping and collapsing only 4 months after it was opened for public use. Its construction was supposed to endure strong winds, but it collapsed due to a fundamental engineering oversight.  “Galloping Gertie,” as she is known, became a famous example of the risks involved in pushing forward with a design that may save costs but has not been fully tested. 

Today, making good software is somewhat like constructing a strong bridge or building. If you build along the lines of Galloping Gertie without understanding the implications of untested designs, the building will not last. 

When it comes to software, businesses are often more concerned with meeting deadlines than building a stable, future-proof product. Launching versions of your software into production sooner than your technical team is comfortable with could result in costly retrofits and years of usability being shaved off down the road. 

So what does it take to keep your software secure, maintainable, and flexible over the long term? Let’s consider nine common strategies that you and your technical team should be aligned on to get the best possible value for your investment.

## 1.  Accurately Defining Business Requirements for Software Development

A good way to fail is by making the wrong product for your business. This seems intuitive, but software (even a simple system) is very complicated, and it needs to serve multiple stakeholders at a company. It is all too common for a high-level executive to request software with features that aren’t actually useful to the mid-level managers and end users. So, making software becomes an exercise in communication. 

The first step is to accurately describe the right product for all the business stakeholders. Often this can be done with a few well-timed conversations and emails. 

The next step is to describe the right product to the development team. You wouldn’t expect a construction crew to construct a building from an artist’s sketch. The crew would need highly detailed blueprints. But in the world of software, many businesses provide only a rough sketch to the development team, perhaps a powerpoint and some wireframes. This is a recipe for confusing, frustrating, unnecessary software. Programmers need precise, thoughtfully defined requirements with clear examples of what you are looking for.\[1]

## 2. Enhancing the Developer Experience 

We’ve all heard of user experience and why considering it is important. Developers are a subset of your users—they’re simply working under the hood. They need quality tools and methods that work well in order to yield faster, more stable results. (Help me help you.) 

This includes a robust development mode for testing the software before deployment, a well-thought-out strategy to avoid “squirreling” (more on this later), and positive morale. 

If the developer experience is pleasant, your software will be made faster, and there will be more interest in creating quality versions of that software. Changes to the software can be made more efficiently, and new developers can be onboarded very quickly. 

Giving your developers tools and processes that improve their experience will streamline the entire process from beginning to end. 

## 3. Avoid Task Switching or Context Switching 

Extensive research shows that frequent task switching—at times referred to as squirreling—is detrimental to our productivity, increases the risk of error, and demands a high cognitive load. 

Frequently switching gears midstream will tank the velocity of any team, but this is especially true for programmers. When writing code, they can be working on a train of thought that spans several days. When this is interrupted with a request to make something else, it leaves loose ends in the code base that have to be finished later. A piece of code that was 8 hours away from completion may now be 24 hours away from completion when it is revisited if the original train of thought is lost or interrupted. 

It is a red flag if your requests for changes encounter resistance from your development team. Usually this is a sign of too many tasks in process and too few completed (which means the code has been deployed and in the hands of users). 

Having a clear product vision will prevent the interruption of a current workflow with a new/different/side workflow. \[2]

## 4. Implementing Infrastructure as Code 

Your staging, quality assurance, and production environments should all be identical. The only way to keep your servers truly identical is by writing a script that can be run by your cloud provider to automatically reprovision your server. This is called “infrastructure as code,” and it is manageable, scalable, and predictable. 

The parameters and settings of your system are written and provided to any platform as a complete package, not requiring any set up or manual adjustment. This methodology is like a series of rubber stamps that can be used over and over again, yielding the same results every time. This avoids the dreaded “pet” server that requires special handling and the manual expertise of a specific technician. It avoids the “snowflake” server that is unique and delicate, impossible to replicate later if your business needs to grow. 

Using infrastructure as code turns your servers into cattle rather than pets. They are all treated the same and offer consistency. Instead of manually setting up specific servers (treating them like pets), you can write a script and run it whenever you need to spin cloud services up or down (treating them like cattle). You can scale up in seconds, and if you find that you no longer require all the resources you formerly did, it takes only moments to scale down. 

All the most popular cloud service providers—Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and others—support all the automation tools necessary to provision your infrastructure as code. The flexibility offered by infrastructure as code is key to getting the best ROI out of your system.

## 5. Emphasizing Peer Code Review

Every newly constructed building goes through many inspection processes, not because the workers are unqualified or untrustworthy, but because there is always something to gain from the insight of other experts. 

Having new code reviewed by senior level developers before it’s checked into the master code repository will not only eliminate problems down the line but will create a more consistent code base and contribute to the training and sharing of knowledge with junior level developers. All of your developers will have a better understanding of the code as a whole, avoiding single experts in small areas. 

The reality is that programmers can and do transition in and out of companies. If one was working in a non-peer-reviewed vacuum and transitioned to another job, this could leave a question mark in the code that would require time and resources to figure out and integrate with the whole. 

Knowledge sharing makes for a healthy, productive company culture, and that in turn will produce a better product. 

![Two developers reviewing code side-by-side](/uploads/software15years-peercodereview.jpg)

## 6. Investing in Delivery Automation for Efficient Deployments

Newly launched software, regular updates, and new features all travel along an automated pipeline to the end user. 

We are all familiar with software updates to our smartphones. These updates are downloaded and installed automatically. Imagine, instead, if these updates were emailed to you from an employee at Apple or Google. Or if you had to make an appointment for a technician to come to your house and update your phone. 

This sounds ludicrous, but many companies struggle with the fragile process of delivering software manually rather than having it automatically deployed. Delivery automation allows developers to roll out needed code changes quickly and efficiently. 

It’s also very important that these code releases not be tied to feature releases. This is possible by building Feature Flags into your system, which will allow you to turn certain functionality on or off (or versions of each functionality) without deploying new code. This allows you to test new features in production and immediately rollback or kill any feature without deploying new code. 

Small patches may need to go out immediately, but if they are tied to an unfinished feature, you will have two bad options: delay an important update, or release a feature that may break everything. Automating the delivery can also allow new features to be released gradually, perhaps to a small number of users within the organization, before releasing them to everyone. 

Keeping code releases separate from feature releases and automating both create stability while simultaneously speeding up the responsiveness of your development team.

## 7. Adopting Test Automation for QA

Testing your code before every deployment mitigates risk and increases quality control, so it’s a matter of course that you would want to do so. Rather than hiring people to simply test it manually, smaller pieces of software can be run alongside the main software, testing as it is built and deployed automatically. 

Imagine if the plumber working on your house had little robots following him around, jumping down the pipes and checking for leaks as he worked the whole time. Not only would he be alerted to issues long before they could bother you, but he would also be able to move more quickly through his work with greater confidence. 

Automated tests being run in a pipeline allow quality metrics in the code to be visible to your entire team, and quality control becomes part of your assembly line. Having rock solid testing requires building a strategy with your development team from the beginning. 

Healthy code is easy to test. But if the tests seem fragile, if they break all the time or are often ignored, this is a red flag that the tests are not high value and are not testing the right things. The better the code, the easier it is to test. 

Having test automation keeps the entire team alert and accountable for writing good healthy code—not just the developers.

## 8. Ensuring Regular Maintenance and Upgrades

Software is **always** changing. All programs ride on the shoulders of other programs, making it possible to build incredibly sophisticated systems. Parts within the system are constantly being updated, defended against malware, and improved. 

To keep your software running properly, it has to keep up with the larger ecosystem. It has to be maintained. 

If you made the investment of building a house, you wouldn’t later refuse to clean the gutters or treat for termites simply because the house was finished. In the same way that treating your house for termites is cheaper than having your woodwork replaced, keeping your software current will defray costs down the road. The cost of staying current is lower than the cost of updating infrequently after several generations. 

If you hear that the updates are too costly or take too much time, this is a red flag. This is tech debt that needs to be paid off. 

All code needs to be patched and kept up to date. Operating systems need to be kept up to date. Delivery platforms such as the App Store have guidelines that require consistent updating to the degree that they will remove an app from the store if it is not kept up to date. 

Proactively maintaining your software is safer and more cost efficient for you and your users.

## 9. Incorporating Built-in Security Measures

You build trust with your users. If you violate that trust, you may have legal repercussions, loss of brand trust, and financial implications. Since security is such a high priority, it should be built directly into your software as part of the development process. 

Make sure your developers are familiar with secure coding practices. Have the code evaluated from a security standpoint. Building in security from the ground up will make your software stronger and therefore last longer. 

Imagine you finished constructing your home, only to realize that the electrical wires pose a fire hazard. To be safe, you would need to rip them out and start over, which would obviously be extremely costly. It is always better to design with security in mind from the very beginning.

## Creating Software that Stands the Test of Time

Each of these topics easily merits an entire article of its own, but if you can talk about them with some fluency to your team, your product will end up being relevant and useful. Being on the lookout for traits and habits that could harm or hamper your system as it develops over the years will keep it robust and stable. And finally, giving your developers the tools they need and the time to follow these healthy practices will keep your system fresh and innovative. 

While these approaches require time, commitment, and effort, the result will be software that can easily last for fifteen years and will yield a significant return on your investment.

If you’re committed to building enduring software, we’d love to hear from you. Schedule a consultation to discuss how our strategic approach can ensure that your software doesn’t just launch—it thrives for years to come.

**\[1]**  BDD or Behavior Driven Development is an approach to software development that encourages a strong focus on the behavior of the system as perceived by its users. For more on this, see [Domain Driven Design with BDD](https://www.youtube.com/watch?v=Ju50D11EIoE) by Dave Farley

**\[2]**  For more on developing a strategy for starting less and completing more see "Why Limit WIP? We're Drowning in Work" by Jim Benson [Why Limit WIP: We are Drowning in Work (MemeMachine Series): Benson, Jim: 9780989081238: Amazon.com](https://www.amazon.com/Why-Limit-WIP-Drowning-MemeMachine/dp/0989081230)

The Tacoma Narrows Bridge Collapse in Washington State

How do you create custom software that stands the test of time? Learn about 9 key strategies that work.

How to Make Your Software Last for 15 Years

How to Make Your Software Last 15 Years

Peter Drucker’s famous quote “Culture eats strategy for breakfast”—essentially meaning that a company’s culture impacts its bottom line more than its business strategy does—has been repeatedly borne out in both research and real-world environments. A close cousin of this concept, Conway’s Law, can be applied more specifically to custom software development, and may be the reason why you don’t have the software that you need. So what is Conway’s Law?

In 1967, computer scientist Melvin Conway made this observation: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” \[1] 

He illustrated this point with the example of two teams, each tasked with producing the same compiler. The team of 5 people produced a 5-phase compiler, and the team of 3 people produced a 3-phase compiler. The way the teams were organized directly affected the way the technology was structured.

Conway’s Law gained so much traction that it was later studied by Harvard Business School and renamed the “Mirroring Hypothesis.” The results were published in a paper entitled [“Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis](https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf).” Their finding: “We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product’s components. The magnitude of the differences is substantial—up to a factor of eight, in terms of the potential for a design change in one component to propagate to others.”

Loosely-coupled software architecture comes from a loosely-coupled organization. So different services that the organization depends on can be updated in production independently, on demand, without needing to wait on each other to deploy in a specific order. As the study shows, loosely-coupled architecture produces significantly more modular systems. Modular systems are easier to change and quicker to adapt to new demands than monolithic systems. 

Therefore, the modularity of a system is an excellent metric for describing the quality of a software system. The Harvard study notes that its findings “have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.” So, if you want better, more modular software, it’s time to examine the structure and culture of your organization.

How you manage teams, how you structure them, and how you encourage communication all contribute to an environment that you (consciously or unconsciously) have designed. The software that your organization can produce will mirror this design. Tight, formal hierarchies produce monolithic code bases that are much more difficult to maintain and change as time passes. So how do you make Conway’s Law work for you instead of against you? 

## Think about hierarchy. 

If the hierarchical structure of your organization separates developers from designers and operations and inhibits intimate communication between these disciplines, your software will suffer. 

Ask yourself the following: How do approvals happen? How does communication happen? Are team members collaborating only through change tracking systems and not talking to one another directly? Is there a strictly rigid multiphase review process for rolling out new changes to production? Is there a database person who must apply changes to the database schema separately before you can deploy new production code changes? Are groups separated to a degree that they do not collaborate or communicate well? 

If communication and collaboration are lacking, put people together, either physically or in an online group, and get them talking directly. Then when a new feature is delivered, all the needed code rolls out together. Think about the modes of communication you are structuring and strive for an inclusive playing field. 

## Think about team structure. 

Small (fewer than 20) teams are [better](https://hbr.org/2007/11/eight-ways-to-build-collaborative-teams). Cross-functional teams of 5-10 are ideal. Amazon famously has the “two-pizza rule”\[2]—if you can’t feed the team with two pizzas, it’s too big. 

But it’s not just numbers that matter. Diversity, safety, and independence are just as important. A monolithic organization has isolated teams for quality control, operations, and product development. Splitting these up into 3-4 cross-functional teams with representatives of each skill set and allowing them to work safely and independently will open the floodgates of innovation. 

Consider the example of a team with the following: 1 designer, 2 developers, 1 operations tech, 1 database tech, and 1 marketing specialist. Not only would this team have significantly reduced communication overhead, but studies show that members would be better able to keep project context in mind, respond to change, and make decisions quickly. \[3] 

## Think about communication and coordination. 

How does your team communicate? Is all the “talking” done in Jira tickets without any actual speaking? This will produce terrible software. 

Removing restrictions on communication in the organization allows for greater knowledge sharing and a freer flow of ideas. Use a mono repository so that teams can see and learn from each other’s code. Examine the effort required to coordinate. Do team members work in different time zones? Avoid a strict company hour policy. Give them the flexibility to work during hours when they can maximize their communication with one another. Remove unnecessary bottlenecks such as putting in a ticket to request deployment to production. Trust your people and allow them to act so they will have a greater sense of ownership and engagement with their work. 

![Small teams working together in an open office](/uploads/conwayslaw-teams.jpg)

These principles of communication and coordination are a major component of the DevOps mindset. This cultural movement for high velocity software delivery is based on the experiences of the people shipping the software and is designed to support and encourage the health of an organization.  For example, CI/CD pipelines improve software delivery and are extremely useful for rapidly shipping software and removing and reducing unnecessary coordination. 

DevOps is not one person or team; it is a way of thinking that serves all team members and sets the foundation for a loosely-coupled organization. This communication and coordination will then be mirrored in the software that is produced. 

## Foster a safe and respectful environment.

For any of the concepts we’ve discussed thus far to actually work, there is a crucial environmental factor that must be met. That factor is [psychological safety](https://www.ccl.org/articles/leading-effectively-articles/what-is-psychological-safety-at-work/). When the culture of an organization is characterized by trust and respect, the social structure will encourage free and open communication, resulting in a technical structure that is flexible and adaptable. 

Keep in mind that at a certain point, how we communicate is more important than what we communicate. A team that communicates with empathy doesn’t simply deliver information for information’s sake. Each member purposefully communicates with the goal of helping others make independent decisions. Being free to ask questions, disagree, express concerns, and point out flaws will enable your people to drive innovation more effectively. 

Don’t tolerate a jerk. If someone is undermining the psychological safety of the team via personal criticism, making people feel unsafe to express themselves, acting like they are the final word or smartest person in the room, then team members will not bring their whole selves to that room. You will have missed an opportunity to access the full strength of your team, and innovation will be stymied. 

So be human, show feelings, express yourself, and encourage others to do so as well. If your organization does not have psychological safety, you can’t create the communication patterns to make Conway’s Law work for you, and you can’t create the technical system that works for the organization.

![An angry man yelling at his coworker and gesturing towards the coworkers incompetence. ](/uploads/conwayslaw-jerk.jpg)

## Apply Conway’s Law.

When presented with new information on any topic, we have 3 choices: ignore, accept, or lean in. 

Ignoring Conway’s Law won’t prevent you from developing custom software. It will prevent you from developing good custom software that can adapt to changing environments. 

Accepting the real-world impact of Conway’s Law and ensuring your architecture doesn’t clash with developers’ communication patterns will notably improve the speed and innovation of your team. 

But leaning into Conway’s Law and taking control of your end product by effecting structural changes at the beginning is one of the most effective ways to transform the quality of software you can produce. 

So think about the structure and culture of your organization—it matters. Create small, cross-functional teams that have the power to do their jobs smoothly, without encountering unnecessary roadblocks. Make sure your people are psychologically safe and can bring the full power of their diversity and experience to the table. Embrace the mental shift of making room for more focus on cultural practices, not just technical practices. It’s all part of the same system. 

If your problems are cultural, you will never fix them by focusing on technical issues. Using Conway’s Law artfully requires flexibility and responsiveness to feedback. The benefits, however, will long outlast the initial growing pains, and you will have positioned yourself to continually produce the best possible software for your organization’s purposes. 

\[1]  <https://www.melconway.com/Home/Conways_Law.html> 

\[2] <https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002> 

\[3] <https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities>

Considering hierarchy, team structure, communication, and your environment can lead to better software.

All Posts / #Culture

“Is this you?”—Scammers Pose as TSG Subsidiary

News

Alexander the Great’s Approach to Software Development

Software Strategy

How to Make Your Software Last 15 Years

Software Strategy

Harnessing Conway’s Law to Create Better Custom Software

Team Culture