Behind the work.

The context

In the mid-1980s I set up Design Soft in Australia and developed SCAMP, an integrated front-office and back-office management system for indoor sports centres. It was my first real experience of taking an idea from a practical business problem through to a product that people could use.

These centres needed front-office functions for fixtures, scheduling and daily operations, alongside back-office accounting and business management. SCAMP brought those activities together and connected to electronic scoreboards and cash registers. I wanted the software to support the venue as a whole, not just keep separate records.

My contribution

I designed and developed the software and took it to beta in around eight months. That was the technical part. The next challenge was money. If I wanted the product to reach its potential, I needed investment and a business around it. So I prepared a business plan and advertised for investors in the Australian Financial Review. It worked: outside investment came in and we were able to take the product forward.

What changed

SCAMP went on to be used by sports centres in Australia and New Zealand. For me, that was the important milestone. It was no longer an idea or a prototype. People were using it to run their businesses.

It was also where I learned something that has stayed with me. Developing useful software is only half the job. You need to understand the customer, explain why the product matters, get the economics right and make sure the business can support what you've built.

The context

When I joined a global telecommunications business in the early 2000s, its industry was changing rapidly. Traditional fixed-line services could not remain the centre of the business forever. The opportunity was in ICT, managed services and solving much broader problems for enterprise customers.

That sounds straightforward when written into a strategy. It is anything but straightforward when you have an established organisation, thousands of people, existing customers, products, processes and commercial targets built around the old business.

My contribution

I was brought in to establish and lead a transformation team. We worked across the commercial organisation, looking at how the business was structured, how it sold, how it managed customers and what it needed from technology and suppliers to support a different proposition.

I worked with senior leadership, account teams, technical specialists and operational colleagues. We had to connect the new direction with the realities of the business: sales structures and incentives, customer relationship management, vendor arrangements, organisational responsibilities and the people affected by those changes.

What changed

The programme led to changes in the sales organisation, customer-management systems, product and procurement arrangements, as well as wider restructuring. These were not isolated technology upgrades. The point was to create a business that could operate differently.

I enjoyed that work because it demanded more than one discipline. You needed to understand the technology, certainly. But you also needed to understand people, commercial pressures and how decisions really get made inside a large organisation. Without that, even a sensible strategy can remain a set of slides.

The context

Before that transformation work, I spent several years with international networking technology businesses. The products were sophisticated, the customers were demanding, and the commercial opportunity was substantial. But having the right product did not mean you automatically had a way to sell and support it.

One of my responsibilities was to build a channel into a major telecommunications group and, through it, into large enterprise customers. That meant getting to know how the carrier actually worked: who made the decisions, how products were selected, what account teams needed and how a supplier could become part of a much larger customer proposition.

My contribution

I developed senior relationships, worked on reseller and distribution agreements and brought technical and commercial teams together around specific opportunities. Financial institutions and other major enterprises needed credible solutions, not simply impressive equipment specifications.

What changed

There were significant customer wins and the channel business grew. What interested me just as much was the change in position. We moved from trying to sell individual products into developing a relationship and commercial structure through which those products could become part of the carrier's offering.

It reinforced a lesson I have seen repeatedly since. Partnerships are not built by signing an agreement and issuing a press release. They work when both sides understand where the value lies, who is responsible for what and how the relationship will function when real customers are involved.

The context

Some assignments take you well beyond the familiar boundaries of your own industry. During my time working with an Asia-Pacific consultancy, I was involved in developing the bid strategy for a major air-traffic management opportunity.

It was an exceptionally complex proposition. No single supplier could sensibly cover every element. The opportunity needed a consortium that could bring together the right capabilities, present a credible approach and deal with the commercial and institutional realities of a major public infrastructure procurement.

My contribution

My role was to help shape that bid. I worked on the strategy, potential partner structure, senior relationships and engagement with government stakeholders. There were technical questions, but also questions about who would lead, who would take responsibility and how different suppliers could operate as one team.

What changed

The assignment was about bringing an international proposal to the point where it could be seriously presented and negotiated. My responsibility was the bid, rather than the subsequent delivery of the air-traffic system. The job was to turn several potential participants into one credible commercial proposition.

It was a useful reminder that the most difficult part of a large project is sometimes not the individual technology. It is bringing the institutions, people and responsibilities together so that the technology has a realistic chance of being delivered.

The context

I have always been struck by how much time people spend looking for information they already have. It is buried in a document, sitting in someone's inbox or known only to the person who attended a meeting. Decisions get made, but the reasons behind them are easily lost.

This becomes a serious problem in a business that needs proper governance, approvals and accountability. Simply putting more files into a shared drive does not solve it. You still have to know which version matters, who owns it, what decision it relates to and what needs to happen next.

My contribution

In one of the businesses I lead, I began developing an approach that connected information with the work and decisions around it. I set the direction and requirements, worked through how the processes should operate and pushed for applications that people could use without having to become specialists in internal administration.

That work has resulted in functioning applications covering document registration, reviews, approvals and audit records. It has involved close collaboration with technical colleagues, with my role focused on the business architecture, the design choices and whether the result genuinely supports the way the organisation operates.

What changed

I am interested in the principle more than the machinery behind it. Knowledge has little value if people cannot find it, understand its context or act on it. Connecting those things changes how an organisation works. It also makes accountability more practical and less dependent on individuals.

For me, the test is whether someone can find the right information, understand why a decision was made and know what happens next. That is much more useful than another folder full of documents.

The context

After many years working at the commercial and strategic end of technology, I found myself wanting to build software again. Part of it was curiosity. Part of it was frustration with tools that had become more complicated, more expensive and more dependent on subscriptions than the job really required.

I revived Design Soft to explore a simple idea: useful software should give people control of their work and their information. I am not trying to create another all-encompassing platform. I am interested in solving specific problems well.

My contribution

The first application, Corroboree, came from the difficulty of capturing meetings and then making proper use of what was said. Recording is only the beginning. You need a reliable transcript, a way to find the conversation again and a way to keep the information under your control. Corroboree is now a working Windows beta, with local recording and transcription, conversation records, summaries and search. I have been using and testing it in real workflows.

Digital Paper grew out of another ordinary frustration. People still need to open PDF documents, complete them, annotate them, sign them and return a finished copy. Doing that should not require sending sensitive documents through a remote service. We have built and tested a Windows application that covers that complete workflow, including creating a finished PDF.

What changed

What I have enjoyed most is getting close to the detail again. There is something satisfying about taking a problem, challenging the accepted way of doing it and then seeing a better approach work on a screen.