Throughout human existence, one thing stays true: we are a species obsessed with birthing complex technologies. What makes the human culture so unique is that we have built a knowledge-based society, where our focus is on encouraging efficiency and convenience throughout all industries. My time as an archaeologist has given me insight into the social processes that drove the success of technology in the Stone Age. Here’s how I’ve used these processes to build digital tools in my current role as a technical product owner.

As an archaeologist, I specialised in understanding the complexity of the Later Stone Age (LSA) tool technology. My research focused on the hypothesis that larger, inter-connected populations would build more complex technologies when compared to smaller, more isolated populations. This hypothesis was based on the concept that human beings form very complex social systems as a result of our advanced cognitive abilities.

My career then morphed over a ten-year period from a digital knowledge manager to a Technical Product Manager. When developing digital tools, I have always tried to implement three social processes which I believe made the LSA technologies successful. These processes are:

• Innovation: These ancient communities developed the most sustainable technology the world has ever seen.
• Collaboration: Large tool-making communities connected and gathered around to participate in trial-and-error development.
• Education: Expert tool-makers dedicated hours of their time to teach and participate in social learning.

We have a tendency to take these social processes for granted, but they can really enhance the development process! In the tech industry, we encourage technical specialisation but real success lies in the cohesion of everyone involved in the process. This is how I implement these basic processes in my work environment to help me build awesome software and still have fun doing it.

Innovate or die

At the core of every successful innovation is the strong drive to solve a need. For our ancestors, the basic need to survive and hunt drove the development of later Stone Age technologies. As population sizes increased, the need to hunt and locate food relied heavily on developing complex tools. Hunting needed to become more efficient, with first-time effectiveness, since there was a high risk to human life and hunters expended large amounts of energy despite little chance of return.

Stone tool production refined processes and sequences which would otherwise have developed over time through trial and error not unlike modern day product development. Technical innovations within the tool production process allowed for the emergence of hierarchically complex development strategies with multiple, differentiated end-products. Therefore, in order to develop innovative products, the development process itself needed to be innovative.

I believe that the Agile methodology can be defined as a modern day example of an innovative process; one that has been adopted by many tech companies as a means to deliver products faster and more efficiently. This being said, the fundamentals of Agile can occasionally get lost or be used for evil purposes like slow playing delivery or micro-managing your engineering team. For this reason, we need to stay true to its fundamental principles in order to innovate. Here are the three principles that I believe should be kept sacred:

Identify the need

I like to use the ‘5 Whys’ model, whereby a team writes down the problem or need they are trying to solve, and then continues to ask “why?” until they have discovered the granular root cause. This iterative, interrogative method is useful for aligning the perfect technical solution with the customer or business need. The basic need to survive and hunt drove our ancestor’s technologies, so they probably didn’t need to stand around and write on the cave wall “ But why?”, but that doesn’t mean that it isn’t useful for us!

Start with a pure MVP (Minimal Viable Product)

Ensure that you have identified the critical requirements needed to produce a working MVP. By doing this, you are able to put your solution in your customers’ hands for feedback, which means that you can reach the market earlier than anticipated. If LSA societies needed a sharp object to cut up meat, their MVP would’ve been a basic stone blade that could probably sustain a couple of uses.

Hack: To instil trust in those who question the MVP process, ensure that you have accounted for continuous iterations of your product or feature. Your product owner should create a placeholder (if you are using Jira then create a placeholder epic) for improvements and enhancements once further UX testing has been completed.

Continuously improve the MVP

Using the above example of the sharp cutting tool, once the MVP ‘had gone to market’, new requirements or enhancements would have been established. This would have led to our ancestors improving the raw material by adding something like a handle for sustainability, ease of comfort and grip. This mirrors the modern process of iteratively enhancing and fixing your MVP to adjust to your customers’ needs.

Two heads are better than one

As mentioned earlier, my research theory proposed that the larger and more successfully inter-connected the LSA population, the more complex the toolkits would be within that society. Joseph Henrich found historical examples where smaller societies possessed a simple tool technology, like single piece spears, rocks and clubs, and populations of mainland societies had far more complex tools like cold weather clothing, fish hooks, and boomerangs.

The inference is that, due to their isolation, the population was not large enough to successfully transmit cultural and technological skills. This example still plays out in the modern-day workplace, when silos are created and specialists become little islands that are isolated from other teams or disciplines. This can damage the cohesion of the team as well as the product that you are trying to develop. As Bill Gates has said: “Software innovation, like almost every other kind of innovation, requires the ability to collaborate and share ideas with other people, and to sit down and talk with customers and get their feedback and understand their needs.”

To harness the power of the individual, and strength the team, the following rituals should be at the core of your team’s processes:

Facilitate effective standups: Too often, mandatory standups are still carried out in teams despite the fact that they have lost their effectiveness. These standups start to become monotonous updates on vague actions that, in most cases, are unrelated to the rest of the team. The suggestions below have helped my team focus our standups on our prioritised initiatives by excluding noise that could result in unnecessary context switching.

1. Ensure the standups occur between people who are working on the same project. If everyone is working on different projects then interest will fade because the information is irrelevant to them.
2. Team members should be committing to and communicating task-level work for the day as opposed to larger user stories. The risk with user stories is that we don’t share the important technical details like the service or component you are working on.

Incorporate discovery workshops into the development cycle: To initiate cohesion in a new project team, or when your team kicks off a new initiative, I find that incorporating a discovery workshop is useful. This workshop should be technology-free and hands on because I believe in the power of sticky notes and large, empty wall space to encourage creative thinking. Ensure that your team has clear objectives and goals for this session and that you have a really good facilitator and time-keeper to help everyone stay on track.

Your goals should be written on the walls so that they can be your guiding star.

The goal of this workshop is to:

• Improve efficiency when you kick-off the development phase,
• Stimulate creativity and innovative ideas amongst team members,
• Incentivise collaboration and working through barriers and problems together, and
• Allow the project team to get insight into the need that the product is trying to solve.

Knowledge increases by sharing, not by saving

During my research, Kline and Boyd taught me that a lack of cultural transmission is one of the reasons for the loss of technological complexity. This means that, if societies did not successfully imitate the development of stone tools from the best toolmakers, the ability to continuously make successful products will decrease.

In more detail, the theory of cultural transmission conveys the idea that the larger the population, the greater the potential of that population to have successful practitioners and toolmakers. When there is more of these individuals in a society, there is a greater opportunity to:

• Learn varying complex traits to hone individual tool making techniques, and
• Innovate techniques to pass down to the next generation.

We’ve all heard that ‘knowledge is power’. However, all too often, specialists struggle to share their critical knowledge for fear of becoming redundant or replaceable. These critical knowledge holders can stifle collaboration and innovative thinking if they choose to hold onto that knowledge, which in turn, can stifle the cohesion of the team. Just like past societies, we need to have the opportunity to learn and hone our skills from those who hold the knowledge.

We need to ensure that critical knowledge is shared across our teams. Here are some of the ways that I ensure this is done effectively:

• Document processes, designs, and complex logic: Try not to over-document where you can actually incorporate other methods of sharing. For instance, Wikis tend to be more digestible than long, wordy documents.
• Host knowledge-sharing sessions on specialised services: Motivate individuals to run knowledge-sharing sessions within the team or company and ensure that these sessions are interactive. Consider running these sessions online so that new starters or others can refer to them later.
• Introduce feature and product demos: All team members should be invited to these sessions. It is another great space for junior members to learn and get a wider understanding of products and features they might be working on. It’s also a great time for your business stakeholders to see your work in action.

Today, as the Head of Product in an Ed Tech company, I work closely with all my engineering teams and constantly implement the above learnings to ensure that my entire team works cohesively and every member understands the entire product, and the goal and vision of every product feature. I strive to learn as much as I teach, and collaborate as much as I ensure delivery.

Resources:

Craig Larman Agile and Iterative Development – A Manager’s Guide.

Lauren is currently working as the Head of Product at Mobile Guardian. She has started two IT graduate programmes in SA and the UK, and promotes the Femtech movement globally. She completed a BSci Honours Archaeology at the University of Cape Town.