# Kablamo — full content corpus for AI tools This is the long-form companion to llms.txt. It contains the full text of Kablamo's top case studies, recent news, and key blog posts in a single file so AI tools can ingest the site without crawling every URL individually. Site: https://www.kablamo.com.au Generated: 2026-08-25 Convention: llms.txt (index) + llms-full.txt (this file) For brand basics, partnerships, and contact info, see https://www.kablamo.com.au/llms.txt. ## Case Studies ### ABC URL: https://www.kablamo.com.au/case-study/abc Date: 2019-10-12 ## The Challenge The ABC's archive spanned 91 years of Australian broadcasting history, with over 11 million hours of video and audio files spread across multiple siloed systems. Finding specific content meant navigating five disconnected on-premise storage locations, physical warehouses, and manual processes that could take up to three weeks to complete a single search. Thousands of content creators, journalists, and internal users relied on the archive daily, but the process was, as the ABC's content management team described it, "slow, manual, inefficient and unacceptable." The organisation needed to overhaul its content library, moving away from scattered warehouses, disconnected metadata systems, and storage locations that had never been fully digitised. The goal was to consolidate metadata from all five systems, migrate petabytes of media into a single cloud platform, and deliver a search experience that could locate archives in seconds instead of weeks. The platform needed to serve the entire breadth of the ABC's operations, from historical research to live news and radio production, supporting the thousands of users who depended on the archive every day. --- ## The Approach The migration came in two parts. First, multiple metadata sources were merged into a single golden record following a new format designed collaboratively with the ABC. This metadata consolidation involved reconciling records from five separate legacy systems into a unified schema. Over three months, the process iterated with constant updates and user feedback, moving several gigabytes of metadata into AWS S3. The collaborative design process ensured the new format addressed the needs of archivists, journalists, and content producers across the organisation, resolving inconsistencies between the legacy systems and establishing a single source of truth for every record. Second, video, audio, and photo media was migrated and aligned with the newly standardised metadata. Media was organised in S3 buckets with unique prefixes and filenames matching IDs, creating a consistent and predictable storage structure that could be accessed programmatically. The migration handled content spanning the full history of Australian broadcasting, from early radio recordings through to modern high-definition video. Each media file was linked to its corresponding metadata record, ensuring that search results could immediately surface the associated audio, video, or image alongside its descriptive information. Using AWS Machine Learning services, Kablamo implemented Amazon Transcribe to ingest and process archival content for transcription, reducing reliance on manual tagging. ABC audio and video archives achieved transcription accuracy exceeding 90%, making decades of previously unsearchable audio and video content discoverable through text queries for the first time. These synchronised processes moved 3 million records into the CoDA (Content Digital Archive) system, totalling 6 petabytes of audio, video and photo content. The strategy was extended to support ingestion and export for other systems, including live news video desk editing and live radio editing, making CoDA the central hub for content flowing across the organisation. --- ## The Results A successful cloud archive search prototype was ready within six weeks, demonstrating that the approach was viable and that the new search experience represented a step change over the existing process. CoDA hit production within three months. The five legacy storage systems became obsolete, with all content housed in the AWS cloud platform for scalable, remote access and ongoing cost savings. Storage costs decreased as the organisation moved from maintaining physical infrastructure and on-premise servers to a pay-as-you-go cloud model. In CoDA's first six months, nearly two million archives had been uploaded while content had been processed or downloaded more than two billion times. The platform eliminated the need for physical retrieval from warehouses, and staff across the country could access the same archive simultaneously from any location. Journalists working on breaking news stories could locate and pull archival footage in seconds, a process that had previously required days of coordination with archive staff. The machine learning transcription pipeline continued to improve the discoverability of the archive over time. As more content was processed, the searchable corpus grew, making the platform increasingly valuable to producers and researchers who needed to find specific moments in the ABC's 91-year history. --- ## Looking Forward Today, the ABC supports lightning-fast search, access and editing of content, with archive search time reduced from weeks to milliseconds. The CoDA platform continues to serve as the backbone of ABC's content management operations, handling the daily demands of news production, radio editing, and historical research. The platform's integration with live news and radio workflows means it is not just an archive but an active part of the content creation process, with new material flowing into CoDA as it is produced. The CoDA transformation was presented at the NFSA Digital Directions conference in 2019, sharing how the project changed the way Australia's national broadcaster manages its content heritage. The serverless cloud architecture ensures the platform can scale with the ABC's growing archive without requiring additional infrastructure investment. This project is also published as a case study on aws.amazon.com. --- ### ABSEC URL: https://www.kablamo.com.au/case-study/absec-case-management-platform Date: 2024-11-12 ## The Challenge As of 2023, more than 6,000 Aboriginal children were in out-of-home care in New South Wales. Of those, only approximately 1,400 were managed by an Aboriginal Community Controlled Organisation (ACCO). The rest were managed by non-Aboriginal NGOs, organisations that, however well-intentioned, lack the cultural knowledge and community connections that Aboriginal families and children need. The national Closing the Gap agreement set a target to reduce Aboriginal children's overrepresentation in out-of-home care by 45 percent by 2031. Reaching that target requires a fundamental shift: transferring hundreds of cases annually from NGOs to ACCOs, and ensuring ACCOs have the tools, data, and capacity to manage them. AbSec, the NSW Child, Family and Community Peak Aboriginal Corporation, sought a technology partner to design and build two future-facing and interconnected solutions. The first was a Case Management Tool (CMT) for ACCOs to manage casework related to Closing the Gap Target 12 (children not overrepresented in the child protection system) and Target 13 (families and households are safe). The second was an Aboriginal Data Platform (ADP) to replace manual spreadsheets with a structured digital system that could centralise data from multiple priorities, generate quantitative reporting, and support data-driven advocacy. The challenge was not purely technical. AbSec works with approximately 35 associated organisations, each with different data types, formats, and levels of digital maturity. And everything, every insight, every data point, every piece of workshop material, had to be owned by the Aboriginal communities it represents. Data sovereignty was not a feature request; it was the foundation. --- ## The Approach Kablamo structured an initial Discovery and Co-Design phase with collaborative input and interaction with key Aboriginal communities and stakeholders, driving cultural intelligence, embedded in every decision. Using Double Diamond and DVF frameworks, Kablamo facilitated deep discovery across AbSec's network. The process included stakeholder mapping, empathy mapping, persona development, user journey mapping, and benchmarking against existing systems. Kablamo participated in sector forums and ran interviews and workshops with ACCO executives, caseworkers, CFOs, IT personnel, and community leaders to surface the real operational picture: operational capacity, geographical coverage, accreditation status, and tool readiness. This data was critical. To scale from a handful of annual case transfers to the target of hundreds, AbSec needed to understand not just the policy aspiration but the actual capacity of each ACCO to absorb additional families. Forums and workshops captured program innovations and unique approaches that individual organisations had developed. The capabilities required spanned human-centred design, data strategy, cloud data platforms, analytics and reporting, machine learning, and data visualisation. --- ## The Results By bringing together a diverse set of stakeholders and listening to the community voices that matter most, Kablamo co-designed and delivered a vision and product roadmap for a transformational Case Management Tool and a centralised sovereign data platform. The new platforms would be capable of providing a unified digital environment to manage casework and data analysis for Closing the Gap Targets 12 and 13, replacing fragmented manual processes with structured, reportable workflows and self-managed datastores. Critically, the platform designs incorporated key principles of indigenous data sovereignty, strong governance and scalability to support future growth. Absec is now well positioned to plan and implement future phases of this critical project, bringing to life the vision of truly closing the gap and enabling Aboriginal communities to manage better outcomes for children and families. --- ## Looking Forward The AbSec platform represents a model for how technology can serve Aboriginal community self-determination. As the Case Management Tool matures and the Aboriginal Data Platform incorporates additional Closing the Gap priorities, the system can grow into a comprehensive intelligence capability for Aboriginal community organisations across New South Wales and beyond. Kablamo continues to support AbSec, with the shared goal of ensuring Aboriginal communities have the data, tools, and digital sovereignty to close the gap on their own terms. --- ### UNO HOME LOANS URL: https://www.kablamo.com.au/case-study/accelerating-innovation-in-home-loans Date: 2020-05-15 ## The Challenge In the competitive Australian home loan market, customer experience and continuous innovation are critical to uno Home Loans' success. uno is an online mortgage broker focused on helping customers find and stay on the best value home loan, disrupting the industry by putting the customer first and using data to discover savings opportunities. Technology moves fast, and in a small team it is hard to maintain expertise across every area. While hosting exclusively in AWS, uno did not have all the skills needed to take full advantage of the cloud's capabilities. They also faced a specific technical challenge in their codebase: the team had adopted a functional programming library that neither uno's in-house developers nor external engineers were fluent in, creating a bottleneck in development velocity and making it harder to onboard new contributors. uno needed a partner who could plug the skills gaps, increase delivery speed, and help the team make pragmatic technical decisions about their architecture, all without disrupting the pace of product delivery that their competitive position demanded. --- ## The Approach The first engagement focused on team augmentation. Kablamo engineers embedded within uno's team to evaluate and continue implementation of a core API layer. The team assessed the existing codebase and identified a key technical decision: deprecating the functional programming library that had been creating a bottleneck. Kotlin was retained for the main routing layer due to its lower learning curve, while core logic in services and repositories was migrated to Java to match the team's existing strengths. This gave uno a codebase that any competent Java developer could contribute to, rather than requiring niche functional programming expertise. The team implemented user management endpoints, built out unit and integration tests as part of the continuous integration pipeline, and wrote acceptance tests that validated the API against real service behaviour. The goal was not just to ship features but to establish patterns that uno's internal team could follow after the augmentation ended. Kablamo delivered a set of recommendations covering areas where manual processes could be replaced with automated pipeline steps, ensuring the team could maintain velocity independently. The second engagement was a data proof of concept. uno had a large volume of customer phone call recordings but no way to extract structured insights from them. Kablamo used AWS Transcribe to convert call audio to text and AWS Comprehend to analyse the transcripts for sentiment, syntax, and key phrases. The hypothesis was that ML could identify where customers were in their home loan journey based on call content, enabling more personalised and timely follow-up. The approach followed a structured methodology: investigate and set hypotheses, set up the transcription and analysis pipeline, run hypothesis tests against real call data, and validate results. The proof of concept demonstrated that sentiment analysis and key phrase extraction could meaningfully identify customer journey stages from call recordings. --- ## The Results The augmentation engagement delivered measurable improvements: increased sprint velocity, fewer bugs reaching production, higher team morale, and reduced risk to the customer experience. The partnership moved beyond a transactional staffing arrangement into a co-invested relationship where uno gained access to a team of engineers they could draw on as needs evolved. The deprecation of the functional programming library was the most impactful technical decision. It removed a barrier that had been slowing every developer on the team, not just Kablamo's engineers. New contributors could now be productive within days rather than spending weeks learning an unfamiliar paradigm. The automated testing patterns and pipeline improvements established during the engagement continued to deliver value after Kablamo's involvement ended. The data proof of concept validated that ML-based analysis of customer calls was feasible and useful. AWS Transcribe produced usable transcripts from real call recordings, and Comprehend's sentiment analysis was accurate enough to support the hypothesis that customer journey stage could be inferred from call content. This opened a path for uno to build more personalised customer experiences based on structured call data. --- ## Looking Forward uno is now better positioned to continue its disruption of Australia's home loan market. The pragmatic codebase decisions, moving from niche functional programming to mainstream Kotlin and Java, mean the team can hire and onboard engineers faster. The automated testing and deployment improvements give the team confidence to ship more frequently without increasing risk to the customer experience. The data proof of concept laid groundwork for using ML to personalise the home loan journey. With structured call insights, uno can identify customers who may benefit from refinancing, flag accounts where sentiment suggests a service issue, and tailor follow-up communications based on where each customer sits in their loan lifecycle. In a market where the difference between winning and losing a customer often comes down to timing and relevance, the ability to extract structured signals from every customer interaction is a competitive advantage that compounds over time. --- ### INFRASTRUCTURE GROUP URL: https://www.kablamo.com.au/case-study/bricks-to-bytes-building-a-digital-future Date: 2020-07-22 ## The Challenge After almost 70 years developing, financing and managing residential and commercial infrastructure across Australia, Asia, Europe and the Americas, the client had accumulated an enormous volume of operational data but lacked the means to extract value from it. The data challenge was significant: - Petabytes of data stored across various locations: designs, costings, security cameras, elevators, air conditioners, plus external data sources including air pollution, traffic, and weather - 70+ years of documentation locked in print or PDF format - Critical security, governance, and compliance requirements across the portfolio - Very limited internal capabilities in rapid digital product development The organisation's IT business unit wanted to demonstrate that printed and PDF documentation could be recovered into machine-readable format using ML. If the approach worked, it would open the door to more efficient use of current property assets and new digital products built on data that had been invisible for decades. --- ## The Approach Kablamo structured the engagement into two parallel streams: a Data Stream covering data lake design, build, and AI/ML model development, and a Business Development Stream covering digital product development and growth analysis. The first phase focused on establishing the cloud foundations. The team set up AWS account structures, VPCs, landing zones, and IAM policies, then assessed and validated data sources for ingestion. An AWS Data Lake framework was established with an initial dataset covering construction sources, alongside CI/CD and data pipelines. Data governance and security postures were defined from the outset, with the target of delivering a searchable data lake within the first weeks. The second phase extended the platform with completed Data Lake APIs, expanded data ingestion pipelines with cleaning and transformation, established data relationships across sources, extracted the first actionable insights, and built an initial digital product on top of the platform. The data architecture followed event-driven, serverless workloads designed for automated scalability. Data flowed in one direction: raw to queryable to enriched. Multiple ingestion methods were supported including secure cross-account ingestion, bespoke APIs via API Gateway and Lambda, and Kinesis streams for real-time data. All queryable data was stored in Parquet format for efficient Athena queries. The platform was built entirely on AWS serverless services. Glue handled data categorisation and ETL across real-time sources. Athena provided interactive queries on datasets of any size without provisioning infrastructure. Kinesis ingested real-time data streams from IoT sensors and operational systems, while Lambda and API Gateway served bespoke APIs. S3 and Glacier provided the storage tiers, from hot data lake to long-term archive. AWS Textract was selected for the PDF extraction workstream, converting decades of printed and scanned documentation into machine-readable data. The team designed a processing pipeline that could handle the variety of document formats in the archive, from construction drawings and specifications to financial tables, and tuned extraction parameters iteratively to improve accuracy across different document types and layouts. --- ## The Results The intelligent data platform allows creation of a new data lake in minutes, compared to weeks with the previous approach. The platform supports multi-tenancy, enabling different business units and data science teams to work independently within isolated environments while sharing common infrastructure. Textract results were strong for converting 70+ years of PDF documentation into machine-readable data. The team established a scalable extraction pattern applicable to over 100,000 files across the organisation, turning decades of locked information into queryable datasets. Complex documents containing tables, forms, and mixed layouts were handled through iterative refinement, producing structured output that could feed directly into the data lake's enrichment pipeline. A custom user interface and data catalogue gave users a practical way to explore, search, and query the ingested data without needing direct access to the underlying AWS services. Throughout the engagement, Kablamo worked alongside the company's internal digital teams to build the capabilities they would need to operate and extend the platform independently. This was not a handover at the end: engineers from both sides paired on architecture decisions, pipeline development, and Textract tuning from the first week. --- ## Looking Forward The infrastructure group can now build new revenue streams from data assets that were previously inaccessible. The serverless, event-driven architecture means the platform scales automatically as new data sources are connected and query volumes increase, without requiring additional infrastructure management. Data science teams can access the queryable data layer to uncover insights and drive future product development. The Parquet-based storage and Athena query layer mean that analysts can run complex queries across petabytes of data without provisioning any compute infrastructure. The multi-tenant architecture provides flexibility for integrations across the organisation and its global operations, supporting the long-term vision of building data-driven digital products on top of decades of accumulated operational knowledge. What was once paper in filing cabinets is now a queryable asset. The same platform that serves operational analytics today can support predictive maintenance, tenant insights, and new data products as the organisation's digital ambitions grow. --- ### VICTORIAN GOVERNMENT URL: https://www.kablamo.com.au/case-study/data-clouds-to-prevent-pyro-clouds Date: 2020-04-22 ## The Challenge The Department of Environment, Land, Water and Planning (DELWP) in Victoria, now DEECA, manages bushfire risk through the "Residual Risk" metric, using modelling to calculate the likelihood and severity of bushfires based on fuel levels on public land. After four years, the metric needed cloud technology to improve accuracy. DELWP sought AWS cloud-based infrastructure and an ML framework for a next-generation risk modelling platform. The context was devastating. During the 2019/2020 bushfire season, fires burnt more than 18 million hectares, more than 30 lives were lost, billions of animals were killed, and damage bill estimates exceeded $200 million. PHOENIX RapidFire, the fire behaviour simulator that puts Australia at the forefront of bushfire analysis, needed to be modernised. The existing system suffered from outdated data layers and models, post-processing bottlenecks preventing scalability, manual processes requiring human intervention, a PostgreSQL bottleneck in post-processing, and limited spatial resolution at 5km squared detail when 1km squared was needed. The platform needed to handle six times more ignition points and double the simulation resolution. It had to be accessible by both scientists and fire chiefs. --- ## The Approach The project ran from December 2020 to March 2021. The team built a robust, scalable AWS cloud data platform to deliver bushfire prediction models via an intuitive and interactive user interface. The architecture centred on replacing bottlenecks with scalable AWS services. Amazon Glue replaced the PostgreSQL post-processing bottleneck with PySpark, running post-processing steps concurrently instead of serially. While individual jobs were not dramatically faster (15 minutes versus 20 minutes), the ability to execute concurrently with independent scaling was transformative. The SQL changes required to work in Spark SQL were minimal. Amazon Glue Crawlers and Athena enabled queries on transformed data in S3 directly without loading into a database. Amazon SageMaker Batch Transform integrated university-led research models from the R ecosystem using custom containers for existing model code. Batch inference ran on Phoenix outputs without significant development effort, scaling compute as required without ongoing server costs. Amazon Lambda performed automatic scaling of the Phoenix cluster, compiled data inputs, populated job queues, monitored batch job status, converted output, and initiated Glue Crawlers. Amazon AppSync provided a fully managed GraphQL API backing the user interface, with Amazon Aurora as the database. Step Functions connected Glue Jobs and SageMaker Batch Transform in a state machine pipeline. The architecture followed core principles: scalability through auto-scaling to accommodate increased data size and variety; automation to remove human intervention and reduce time; cloud-native design with AWS professionally certified DevOps engineers and data scientists; removal of post-processing bottlenecks through big data pipeline best practices; cost effectiveness through spinning down unused resources, serverless compute, and optimised storage; and performance visibility through a web interface for job management and status. Designers composed an accessible user interface that displayed prediction knowledge and management advice with accurate maps, enabling fast communication between teams during times of high pressure. --- ## The Results The platform delivers a fully scalable, cost-effective AWS cloud platform for bushfire risk assessments. The rich user interface enables users to quickly create scenarios, upload data, and repeat previous runs with modifications. The fully automated cloud-native solution removes scaling constraints with automated data pipelines and serverless processes. Amazon Glue enables concurrent post-processing and SageMaker enables automated inference with ML capabilities. The platform handles six times the ignition points and double the simulation resolution compared to the previous system, with an estimated 2.75 million executions per model run. It maintains interoperability with existing mapping systems (ArcGIS), prediction models, and decision workflows. Processing time for post-processing tasks dropped significantly. While individual Glue jobs ran in approximately 15 minutes (compared to 20 minutes in the legacy system), the ability to run dozens of jobs concurrently rather than serially compressed total batch processing from hours to minutes. Scientists and fire chiefs can now access the same interface, running scenario comparisons that previously required manual coordination between technical teams and operational staff. The combination of automated data pipelines, serverless compute, and scalable storage means the platform can accommodate future increases in data volume and model complexity without architectural changes. --- ## Looking Forward The new data platform assists State and Territory firefighting services to be more prepared for longer, more intense fire seasons. The integration of university-led research models through SageMaker means that advances in fire behaviour science can be incorporated into the platform without significant re-engineering. The scalable platform enables more sophisticated data analysis, machine-learning-based fire prediction models, and automated fire response mechanisms including robotics and drones. The architecture's interoperability with ArcGIS and existing prediction models ensures it fits within established emergency management workflows rather than requiring agencies to change how they operate. As climate conditions drive longer and more unpredictable fire seasons, the platform's capacity to ingest new data sources (including higher-resolution satellite imagery and additional IoT sensor networks) positions it as a foundation for the next generation of bushfire preparedness. The serverless architecture means that operational costs remain proportional to usage, making the platform viable for agencies of varying size and budget. The work established a replicable pattern for applying cloud data platforms and machine learning to natural disaster prediction, applicable beyond bushfires to flood, storm, and drought modelling. --- ### DEECA URL: https://www.kablamo.com.au/case-study/deeca Date: 2021-06-16 ## The Challenge While the 2019-20 Australian bushfire disaster unfolded, DEECA (Department of Energy, Environment and Climate Action) was managing statewide bushfire risk using its 'Residual Risk' metric, calculated by the Phoenix RapidFire modelling framework. After four years in operation, the system needed a significant injection of cloud technology and machine learning capabilities to continue reducing bushfire risk across Victoria. The Phoenix RapidFire model, originally designed for desktop use, was struggling to scale. Manual post-processing workflows created bottlenecks that prevented the system from running at the resolution required for accurate prediction. Outdated data layers limited modelling accuracy, and the existing infrastructure could not integrate new data sources such as modern weather scenarios or varied ignition patterns. High operational costs came with limited capacity. The platform needed to be accessible to a range of operators, from scientists to fire chiefs, who applied the resulting metrics in different and important ways. DEECA needed cloud-based data storage and processing at many orders of magnitude greater than had previously existed. The volume of data required for high-resolution bushfire modelling across all of Victoria far exceeded what any on-premise system could handle. An upgrade of this scale would not be likely for several years, so the project needed to be as advanced and fit-for-purpose as possible, delivering near-limitless scale while maintaining cost-effectiveness and enabling advanced machine learning integration. --- ## The Approach Kablamo was engaged to design and deploy CloudFARM, a cloud-native, fully scalable AWS platform to underpin the next generation of DEECA's risk modelling. The solution was architected around four key principles: - Cloud-Native: migrated Phoenix RapidFire to a high-performance AWS cloud environment, replacing the desktop-bound processing model with a serverless architecture - ML Integration: Amazon SageMaker for sophisticated analysis and enhanced predictions, enabling more accurate risk assessments through machine learning - Automation: serverless pipelines using Lambda and Athena for massive scale, eliminating the manual post-processing workflows that had previously created bottlenecks - Cost Control: auto-scaling resources with rich operator visibility, ensuring the platform only consumed resources when running simulations The bushfire modelling uses Phoenix RapidFire, a fire behaviour simulator that puts Australia at the forefront of bushfire tools and analysis innovation. To improve accuracy, Phoenix RapidFire was supported with cleaner data from geospatial, temporal, and historical sources. The platform allows scientists and fire chiefs to swiftly create, simulate, and repeat complex scenarios with high-resolution data. A rich user interface was introduced that allowed users to quickly create scenarios for simulation using predefined or newly uploaded data, and to repeat previous runs with slight modifications. Advanced machine learning capabilities using Amazon SageMaker enable more sophisticated analysis and enhanced predictive accuracy. The architecture uses Amazon Athena and S3 for data pipelines, and combines Phoenix RapidFire with Bayesian Network models for prediction. Python-based processing pipelines handle data transformation and model orchestration. The entire solution prioritises scalability, automation, cloud-native design, and cost-effectiveness, ensuring that DEECA can run thousands of simulations across Victoria without manual intervention or infrastructure constraints. --- ## The Results The CloudFARM solution increased modelling ignition resolution by a factor of approximately 6x and simulation resolution by 2x, with the combined effect on weather scenarios delivering an approximately 70x improvement compared to the previous implementation. The fully automated, AWS cloud-native architecture has eliminated previous scaling constraints, offering near-limitless capacity in a cost-effective manner. All data pipelines are now 100% automated, removing the manual processing steps that had previously limited the system's throughput. Before CloudFARM, running a statewide risk assessment required days of manual coordination and processing. The new platform reduces that timeline to hours, with operators able to trigger simulation runs on demand and monitor progress through the rich user interface. Scientists can compare multiple scenario outputs side by side, adjusting parameters such as ignition patterns, weather conditions, and fuel load data to understand how different variables affect predicted fire behaviour. The auto-scaling architecture means DEECA only pays for compute when simulations are running, keeping costs predictable despite the massive increase in processing capacity. --- ## Looking Forward This redevelopment of an important resource, the ability to predict risk and subsequently manage bushfires, is a milestone in Australia's role as a leader in bushfire management. With a suite of AWS cloud infrastructure, near-limitless data processing, and machine learning advantages, Victoria now has a powerful tool with which to save lives, property, and bushland. The CloudFARM solution ensures that DEECA's critical risk metrics can now be produced using the most accurate and powerful digital technologies available. The platform's architecture is designed to accommodate new data sources and modelling techniques as they become available, ensuring the system remains at the leading edge of bushfire science. As new geospatial datasets, satellite imagery, and climate projections become available, they can be integrated into the modelling framework without re-engineering the underlying infrastructure. Kablamo continues to provide operational support and ongoing product development through Product Care services. --- ### ASX-100 MINING COMPANY URL: https://www.kablamo.com.au/case-study/earth-moving-migration Date: 2019-11-10 ## The Challenge An ASX-100 mining company had chosen to end an existing hosting contract and was facing an urgent deadline to migrate business-critical applications out of its data centre. The company needed a cloud hosting platform that offered resiliency, scalability, and a lower cost base, while avoiding business downtime or risking the loss of any data. The project carried strict requirements around data sovereignty. All data had to remain within Australia, and the company required strong isolation guarantees and formal security controls throughout the migration. There was no room for extended timelines or phased rollouts that might leave the business exposed between environments. The migration had to be planned and executed as a single coordinated effort. To ensure the first workload migration to AWS went smoothly within the short timeframe, Kablamo came onboard to set up an operational environment on AWS and guide the migration. The project also needed to deliver training and documentation that would allow the company's operations team to manage and grow the new cloud environment independently after handover. --- ## The Approach The engagement was structured in two phases. The first phase focused on discovery and establishing the AWS landing zone: defining and setting up the account structure, proving out security postures and governance practices, analysing servers and applications, and prioritising migration candidates. The team started with a technical workshop to establish prerequisites and map the current state. From there, Kablamo designed and implemented the networking layer, configured and rolled out the AWS account structure, built an automation framework for repeatable deployments, and provisioned security controls. The phase concluded with a demonstration application deployed to production, proving the environment was ready for live workloads. After analysis of the company's computing infrastructure and business needs, Kablamo recommended AWS Server Migration as the appropriate tool to transfer virtual machines into the cloud. The migration approach included: - **Detailed migration timeline** using native AWS tools - **CloudFormation, CodeCommit, and CodeBuild** for infrastructure automation - **Fast, reliable network link** from the existing data centres into AWS - **Agile framework** with Kablamo and the company's teams working side by side - **Upskilling** of internal staff to operate and extend the new environment In parallel with the Phase 1 build, the team ran application discovery sessions to identify, categorise, and rank migration candidates for the second phase. This produced a prioritised application list that would guide the physical migration of servers in the follow-on engagement. Security was a first-class concern throughout the engagement. The team designed the AWS account structure with strong isolation between environments, implemented least-privilege IAM policies, and configured network security groups to mirror the controls the company had maintained in its physical data centre. All data remained within Australian AWS regions, meeting the company's sovereignty requirements without compromising on performance or availability. The second phase covered the physical migration of servers and followed directly from the landing zone work, building on the proven automation framework and network connectivity established in Phase 1. --- ## The Results The migration was completed in nine weeks, on time, within budget, and exactly to scope with zero business downtime. Business-critical applications were moved from the data centre to AWS without any interruption to operations, meeting the strict data sovereignty and security requirements throughout. The company now has a well-governed, best-practice AWS environment with strong network design and connectivity. The automation framework built during the engagement means that new environments can be provisioned consistently and quickly, removing the manual overhead that had characterised previous infrastructure changes. The prioritised application list and repeatable migration frameworks developed during the first phase provided a clear, structured path for subsequent migrations across the company's global operations. Rather than treating each migration as a standalone project, the frameworks ensured that future moves could follow a consistent, low-risk process with predictable timelines and costs. Internal teams gained hands-on experience with AWS through the upskilling program, building the confidence and capability to manage the cloud environment without ongoing external support. Documentation covered operational procedures, monitoring, incident response, and the automation tooling, giving the operations team everything they needed from day one. --- ## Looking Forward Through the upskilling program and documented automation tooling, Kablamo ensured both the project's success and a strong foundation for the company's cloud-centric future. The repeatable frameworks and automation tooling mean that future data centre exits can follow the same proven approach, reducing risk and compressing timelines. The second-phase engagement for physical server migration followed directly, building on the production-ready AWS landing zone, network design, environment automation, and security provisioning established in Phase 1. The company is now equipped to progressively move additional global data centres into AWS using the same methodology, with internal teams capable of leading the process. What began as a nine-week migration under tight deadline pressure has become the foundation for a long-term cloud strategy across the company's global operations. --- ### EMERGENCY SERVICES URL: https://www.kablamo.com.au/case-study/enterprise-ai-accelerator Date: 2025-05-01 ## The Challenge Emergency services organisations across Australia and North America generate enormous volumes of operational data: incident records spanning decades, sensor networks feeding real-time conditions, satellite and aerial imagery, weather station outputs, social media intelligence, and GPS tracking from thousands of personnel and vehicles. The potential for AI and machine learning to extract actionable intelligence from this data is significant: predictive incident modelling, automated resource allocation, early warning systems, and natural language search across operational archives. But most agencies have not progressed beyond exploration. Isolated AI pilots run by individual teams. Vendor demonstrations that show impressive capabilities but don't connect to real operational data or workflows. Innovation labs that produce proof-of-concepts which never reach production because the governance, training, and infrastructure required to operate AI responsibly in high-stakes environments was never established. Kablamo identified this pattern through years of delivering the bushfire intelligence platform for bushfire intelligence, working directly with the NSW Rural Fire Service (where the Athena platform tracks 15,000+ fire incidents and predicts fire spread within minutes) and DEECA Victoria (where the cloud-based fire analysis and risk modelling platform increased modelling capacity significantly). The gap was consistent across every agency: organisations understood AI's potential but needed a structured, repeatable path from exploration to production, one that addressed not just the technology, but the people, processes, and governance required to sustain AI operations in environments where decisions affect public safety. --- ## The Approach Kablamo developed the Enterprise AI Accelerator as a productised 12-week programme that takes organisations from problem identification through to working prototypes backed by governance frameworks and trained staff. The programme is structured around three phases. **Phase 1 - Discovery and Alignment:** Kablamo works with agency leadership, operational commanders, data custodians, and frontline staff to identify the highest-value AI use cases. This involves mapping existing data sources and assessing quality, accessibility, and integration points. Potential use cases are aligned with operational priorities and strategic goals, then ranked by impact, feasibility, and data readiness. The output is a prioritised backlog of AI opportunities, not a theoretical roadmap, but a practical sequence of prototypes that can demonstrate value within the programme timeframe. **Phase 2 - Rapid Prototyping:** Kablamo engineers build working prototypes against real agency data. These are not vendor demos or simulations running on sample datasets; they are functional systems that process the agency's actual operational data and demonstrate measurable value against the identified use cases. Common prototypes include predictive incident modelling (using historical incident data to forecast risk patterns), automated resource allocation (optimising crew deployment based on predicted conditions), geospatial intelligence overlays (combining satellite, sensor, and social media data on operational maps), and natural language search across decades of operational records. **Phase 3 - Governance, Training, and Roadmap:** The final phase focuses on making AI sustainable within the organisation. Kablamo delivers responsible AI governance frameworks covering data handling protocols, model monitoring and performance tracking, bias detection and mitigation, human-in-the-loop decision-making gates, and escalation paths for low-confidence outputs. Hands-on training equips operational staff to use the prototypes effectively. A phased roadmap charts the path from prototype to production deployment, with clear milestones, infrastructure requirements, and resource estimates. The programme builds on Kablamo's bushfire intelligence platform architecture, a proven foundation for geospatial AI in emergency services that has been deployed at scale across Australian fire agencies. Components, architectural patterns, and infrastructure from bushfire intelligence are adapted for each agency's specific context, dramatically reducing the time and risk of building from scratch. The accelerator uses the same AWS serverless infrastructure, machine learning pipelines, and geospatial data processing capabilities that power operational bushfire intelligence for thousands of firefighters. --- ## The Programme Offering _Note: This case study describes a productised programme offering, not a single delivered engagement. The programme draws on Kablamo's operational experience with Australian fire agencies._ The Enterprise AI Accelerator provides emergency services organisations with a structured, repeatable path to operational AI capability. In 12 weeks, agencies move from exploratory discussions to working prototypes validated against real operational data, backed by governance frameworks that address the responsible deployment requirements of public safety environments. The productised model means Kablamo can deploy the programme consistently across multiple agencies while tailoring the specific use cases, data sources, and governance requirements to each organisation's context. Agencies receive not just technology prototypes but the governance documentation, training materials, and implementation roadmap needed to move from prototype into production, the critical transition where most AI initiatives stall. The bushfire intelligence platform foundation provides a significant head start. Rather than building geospatial AI, data processing pipelines, and operational intelligence capabilities from scratch, the accelerator inherits battle-tested components that have proven their reliability at scale in active emergency operations. This reduces the programme's technical risk and allows the team to focus engineering effort on agency-specific use cases rather than foundational infrastructure. --- ## Looking Forward The Enterprise AI Accelerator represents Kablamo's evolution from bespoke project delivery to productised capability, packaging years of bushfire intelligence experience into a repeatable programme that any emergency services organisation can adopt. The accelerator has been positioned for deployment across Australian state agencies and North American emergency services organisations, extending Kablamo's fire and geospatial expertise into the broader emergency management AI market. As AI becomes essential infrastructure for public safety operations, the accelerator ensures agencies can move quickly, responsibly, and with confidence that the technical and governance foundations are built to scale. --- ### ENTERPRISE CLIENT URL: https://www.kablamo.com.au/case-study/frankly-my-dear-weve-got-a-better-dam Date: 2020-03-18 ## The Challenge Kablamo observed ongoing customer frustration with existing Digital Asset Management software offerings: large up-front license costs, overselling of basic features, inflexible storage solutions and "feature-waste." So Kablamo committed to developing something better: a 100% AWS-native digital asset management solution designed as a centralised platform for enterprises to store, enrich, search, and distribute digital assets. Traditional DAM platforms suffer from common frustrations: they try to do everything, become bloated with unused features, and lock customers into expensive licensing models. Implementation takes months or years, requires domain-specific languages, and creates vendor lock-in. Organisations that outgrow their initial DAM setup often face a painful migration to a new vendor, losing metadata and workflow configurations in the process. Kablamo identified three target markets. First, streaming and broadcast: consolidating multiple DAM/MAM systems, digitising physical assets, enriching with metadata, and distributing through many channels with licensing compliance. Second, corporate enterprises: centralising data types from many years of cataloguing including paper, video, streaming, and digital marketing assets. Third, law enforcement: aggregating digital and physical media from streaming video, body cameras, drones, tapes, and paper, with digitisation, normalisation, role-based security, and AI metadata enrichment. Each of these markets shares a common pain point: assets trapped in silos, searched manually, and distributed through brittle, hand-wired integrations that break whenever a downstream system changes. --- ## The Approach DAME was built as a 100% transparent (white box) solution using AWS best practices, lean and extensible across AWS cloud applications. The React front end was paired with serverless technology for performance and low costs. The UI is white-label and customisable to enterprise branding. The platform is PII and GDPR compliant with CI/CD and test automation. Core capabilities include a central repository for all digital files (videos, images, documents); RESTful serverless APIs to aggregate from existing repositories; normalisation via AWS MediaConvert to transcode to consistent formats while maintaining originals; automated metadata creation and tagging for structure and enrichment; distribution to push assets to CMS, VMS, OTT, OVP, or any platform via APIs; bulk storage with S3 and Glacier (currently storing petabytes across customers); and context-specific workflows customisable for media request and fulfillment, approval, video editing, transcription editing, language conversion, and facial detection. The platform can also run in headless mode, completely without a UI, with all workflows via RESTful APIs. The architecture separates compute from storage so that ingestion, transcoding, and ML enrichment run independently and scale on demand. When a new asset is uploaded, an event pipeline triggers the relevant processing steps: MediaConvert generates preview renditions, Rekognition scans for faces and objects, Transcribe produces a text track for audio and video files, and Comprehend extracts key phrases and sentiment. All generated metadata lands in a search index within seconds, making the asset discoverable before the operator has closed the upload dialog. Because each ML step is an independent Lambda function behind a feature flag, customers can enable only the enrichments they need and add others later without re-deploying the platform. The AWS services include S3 for centralised storage with 11 nines durability, Glacier for long-term archival, MediaConvert for transcoding, Rekognition for facial and object detection, Transcribe for speech-to-text, Comprehend for text analysis and object detection, Textract for document transcription, AppSync for API distribution, and Cognito with Auth0 as authentication options. Key differentiators over competitors: implementation measured in days or weeks instead of months or years; very low cost to start with enterprise-capable DAM; no vendor lock-in thanks to common market skills (React, AWS) and no domain-specific languages; built-in expansion and integration as a primary feature; designed to scale from small teams to enterprise organisations without re-architecting; and full CI/CD with no manual chokepoints. Because every component communicates through well-documented REST endpoints, customer engineering teams can integrate DAME into their existing toolchain without learning a proprietary SDK. --- ## The Results The pre-built software platform enables Kablamo to accelerate time to market and reduce costs for customers' digital product development journeys. DAME supports files up to 5TB, with modular ML-powered tagging and analysis and enterprise-grade security and governance. The platform is currently storing petabytes of data across customers and scales from small teams to millions of users without architectural changes. For broadcast customers, DAME replaced multiple legacy MAM systems with a single searchable catalogue, cutting the time needed to locate and clear an archive clip from hours to seconds. Corporate enterprise customers consolidated decades of marketing collateral, legal documents, and training videos into one governed repository with consistent access controls. In the law enforcement space, DAME's role-based security model ensures that sensitive evidentiary material is accessible only to authorised personnel, with a full audit trail of every view, download, and share event. Across all three sectors, customers reported that onboarding new teams onto the platform took days rather than the weeks or months typical of competing products. --- ## Looking Forward DAME continues to evolve with ML features tracked and developed across customers in streaming, broadcast, corporate enterprise, and law enforcement sectors. The roadmap includes expanded ML capabilities such as automatic content moderation, deeper video scene segmentation, and multi-language transcription support. As AWS releases new AI services, DAME's modular plugin architecture means they can be wired in behind the same feature-flag system without touching the core platform. The goal remains straightforward: give organisations a DAM that grows with them instead of one they will need to replace in three years. --- ### ICMEC AUSTRALIA URL: https://www.kablamo.com.au/case-study/icmec-website-redesign Date: 2024-10-01 ## The Challenge Every year, billions of dollars in financial transactions flow through Australian banks, and hidden within that volume are payments linked to the possession, distribution, and production of child sexual abuse material. Banks and financial institutions sit at a unique vantage point to detect these patterns, but until Lighthouse, no platform existed in Australia to centralise global intelligence about child sexual exploitation and abuse (CSEA) and make it actionable for compliance teams. The International Centre for Missing & Exploited Children (ICMEC) Australia had been working to fill this gap. The project needed a new delivery approach, and AWS referred Kablamo based on prior work, recognising the combination of engineering speed, security rigour, and the kind of team that would treat a child safety mission with the gravity it demanded. ICMEC needed a partner who could stabilise the engagement and deliver fast. The platform needed to ingest complex, multi-source global datasets about CSEA activity and transform them into localised, contextual intelligence for the Australian financial sector. Compliance analysts needed to see behavioural trends across digital platforms, time periods, and geographies, presented clearly enough to act on immediately, not buried in raw data exports. --- ## The Approach Kablamo joined the project and immediately established a one-team model with ICMEC's product owner and in-house DevOps team. There was no handoff culture, no separate streams reporting into different governance structures. ICMEC's product owner made decisions quickly, communication was transparent, and every sprint was focused on a single goal: getting Lighthouse into the hands of the financial institutions that needed it. The engineering team built the platform from the ground up across both frontend and backend. The user interface was developed in React with Next.js, using Aria Kit to ensure the platform met accessibility standards, critical for a tool that compliance analysts would use daily across different devices and screen configurations. The data processing layer used Python and Streamlit, chosen for their strength in handling the analytical workflows that would transform raw intelligence feeds into actionable insights. On the infrastructure side, Kablamo chose Amazon RDS for persistent storage, ECS Fargate for elastic serverless compute that could scale without manual intervention, and managed authentication for secure user access. NextGIS provided the geospatial visualisation layer, enabling analysts to map exploitation patterns across locations and correlate them with financial transaction data. CloudFront ensured reliable content delivery regardless of user location. The active build took just ten weeks. Within four months of Kablamo's onboarding, including ramp-up, architecture decisions, and knowledge transfer from the prior vendor's work, Lighthouse version 1.0 was live. The platform centralised access to sensitive international datasets, integrated built-in analytics, and removed the burden on individual banks to independently source and interpret global CSEA intelligence. Following launch, ICMEC engaged Kablamo through a Product Care agreement, an ongoing support arrangement providing full-stack development, security patching, diagnostics, and rapid incident response. An experienced Kablamo engineer was aligned as the dedicated Technical Lead, ensuring continuity of platform knowledge across every update. Kablamo also established a twelve-month knowledge transfer program, working alongside ICMEC's internal DevOps team to progressively transfer architectural knowledge, operational procedures, and the institutional context behind every technical decision. As ICMEC's Product Owner described the partnership: "Kablamo is not just a vendor. They've become part of our mission to protect children. Their engineers understand the context and share in our pride." --- ## The Results Lighthouse went live on schedule and became the first intelligence platform of its kind in Australia. For the first time, Australian banks and financial institutions had a single, secure platform to access international CSEA intelligence, tailored to the local regulatory and operational context. The platform replaced a fragmented landscape where individual institutions had to independently source, interpret, and act on raw data from multiple international bodies. Lighthouse consolidated these feeds into a unified interface with built-in analytics, geospatial visualisation, and trend detection. Compliance teams that had previously relied on spreadsheets and ad hoc data requests could now access contextualised intelligence through a modern web application designed for their daily workflow. Kablamo's twelve-month knowledge transfer program ensured ICMEC's internal team could sustain and extend the platform independently. Over the course of the year, Kablamo engineers worked alongside ICMEC's DevOps team, progressively transferring architectural knowledge, operational procedures, and the institutional context behind every technical decision. The Product Care agreement has been renewed annually since launch, a reflection of the ongoing trust and the critical nature of the platform's mission. The user experience improvements alone drove a significant increase in adoption. Lighthouse was designed to feel like a modern web application, not a government tool, because higher adoption among compliance teams directly translates to more exploitation detected and more children protected. --- ## Looking Forward Lighthouse is not a completed project; it is a living capability that evolves alongside the threat landscape. As exploitation methods shift across digital platforms, Lighthouse's intelligence feeds and analytical tools are updated to match. Kablamo remains embedded as a trusted technology partner, supporting feature development, security hardening, and the onboarding of additional financial institutions onto the platform. The partnership between ICMEC and Kablamo demonstrates what happens when engineering capability is applied to mission-critical social impact. The same speed, security rigour, and collaborative delivery that Kablamo brings to enterprise clients, built here for a cause that matters. As ICMEC expands its intelligence offerings and onboards additional financial institutions, the architecture is designed to scale: new data sources, new institutions, and deeper analytical capability, all flowing through the platform Kablamo built in ten weeks. --- ### ASSEMBLY PAYMENTS URL: https://www.kablamo.com.au/case-study/keeping-vendors-vending Date: 2019-08-25 ## The Challenge After Assembly Payments, an Australian fintech, secured funding from a major bank, a new cloud-based payments solution was needed to integrate with the bank's internal network. This platform would consume data from well over 50,000 POS terminals and online merchant stores. The solution had to comply with the bank's stringent governance, security, and regulatory requirements, and be ready in less than 12 months. Assembly Payments had been unable to find the right talent internally before the deadline, so they engaged Kablamo. The platform comprised two critical components: - **Client-facing Merchant Payment Platform** - Enable customers to take payments more flexibly, provide greater visibility into transactions, and give instant access to cash flow - **POS Real-Time Monitoring Tool** - Built to handle 50,000 POS device feeds, enabling proactive troubleshooting to predict and fix POS issues before they impact the client, and allowing proactive management of customer terminals The cloud environment had to connect into the major bank's internal systems via a network managed by one of Australia's largest telcos, while managing multiple stakeholders and third-party integrations. Both platforms had to be PCI compliant. PCI compliance in particular added significant constraints: every component that touched cardholder data needed to sit inside a hardened network segment with encrypted storage, restricted access, and continuous audit logging. These requirements shaped every architectural decision from day one. --- ## The Approach Kablamo augmented Assembly's Agile squads, setting up an iterative and immersive framework. The team worked closely with Assembly Payments' customer support agents in mutual discovery. This meant they could respond rapidly to feedback from each iteration, designing products with the user's needs front-and-centre. Support agents brought real-world insight into the most common merchant pain points: slow settlement visibility, difficulty diagnosing why a terminal had gone offline, and a lack of self-service tools for everyday account changes. AWS was chosen for ease of integration, connectivity and rapid scalability. The maturity of AWS' platform provided robust VPN interconnectivity and encryption services to meet compliance and governance requirements. The architecture was built for high scalability to handle real-time ingestion of 50,000 POS terminal feeds. The Merchant Payment Platform gave merchants a single dashboard to view transactions across all their terminals and online channels, track settlement status, and export reconciliation data. It replaced a patchwork of spreadsheets and email-based reporting that merchants had relied on previously. The interface was designed to surface the information that mattered most: outstanding settlements, failed transactions, and terminal health, all visible within seconds of logging in. The POS Real-Time Monitoring Tool ingested telemetry from every terminal in the network. Each device reported heartbeat signals, transaction throughput, and error codes into a streaming pipeline. Automated rules flagged anomalies such as a terminal that had not sent a heartbeat in a configurable window, or a sudden spike in declined transactions at a single location. When the system detected an issue, it raised an alert for the support team before the merchant noticed a problem. This shifted the support model from reactive (waiting for a merchant to call) to proactive (reaching out with a fix already in hand). The network topology required careful coordination. Traffic from Assembly's AWS environment traversed a dedicated VPN link into the bank's data centre, with the telco managing the underlying connectivity. Kablamo worked with both parties to define firewall rules, IP address allocations, and failover paths, ensuring that a link interruption would not leave merchants unable to process payments. --- ## The Results Both platforms were delivered in nine months, three months ahead of the original 12-month deadline. The partner was confident enough in the delivery to bring the go-live date forward. In the past, adding endpoints would take days. Now, thanks to the new AWS cloud environment, adding them only takes minutes and with no downtime. The platforms adhere to all security, governance, and regulatory requirements. The proactive monitoring approach proved its value quickly. Terminal outages that previously went undetected for hours were now surfaced within minutes, and in many cases the support team resolved the issue before the merchant was aware of it. Merchants also gained self-service access to transaction history and settlement tracking for the first time, reducing the volume of inbound support calls and giving them direct visibility into their cash flow. --- ## Looking Forward The client-facing portal enables merchants to take payments more flexibly, with greater visibility, and provides instant access to cash flow. The POS Real-Time Monitoring Tool enables Assembly Payments to predict and troubleshoot issues before they impact merchants. The highly scalable architecture ensures the platform can grow with Assembly Payments as they onboard new merchants and expand their POS terminal network beyond the initial 50,000 devices. The same streaming pipeline that monitors terminal health can absorb new device types and data sources as Assembly's product line expands, without requiring a re-architecture of the ingestion layer. --- ### MAJOR AUSTRALIAN BANK URL: https://www.kablamo.com.au/case-study/launching-a-big-four-bank-into-fintech Date: 2019-06-20 ## The Challenge A major Australian bank identified Small to Medium Business (SMB) as one of the least supported groups in its customer base. Despite representing a significant portion of the economy, SMB customers were being served with products and experiences originally designed for retail or corporate segments, neither of which matched the way small businesses actually operate. The bank recognised the need for a powerful digital product specifically for SMB needs. They had innovation arms and access to vast internal and external data, but they didn't just want to improve the SMB experience. They wanted to re-imagine it entirely, and needed a partner to drive world-first innovation. The goal was to completely re-imagine the SMB banking experience using data, machine learning, and cloud infrastructure. The bank needed a next-generation, cloud-native platform with strong focus on secure infrastructure, ease of integration with the bank's partners, and intelligent data capabilities with machine learning. Small business owners typically lack the time and resources to manage complex financial processes, so the platform had to reduce friction and deliver insights proactively rather than requiring users to search for them. This would be one of the bank's first production workloads with customer data securely deployed in AWS, making it a pathfinder for the bank's broader cloud adoption strategy. --- ## The Approach Kablamo launched a program of deep consultation to comprehensively map the needs of SMBs. Over the course of the two-year engagement, the team conducted over 200 hours of user testing. The research combined quantitative and qualitative methods to build a comprehensive picture of what small business owners actually needed from their bank. Interviews focused on understanding the daily financial workflows of SMB owners: how they tracked invoices, managed cash flow, reconciled accounts, and made decisions about financing and growth. Unlike traditional design agencies, Kablamo did not let user research slow down build of reusable and flexible solution components. The product principles were established early: Integrate, Simplify, Automate. Within two weeks of kickoff, the team had a working customer landing page in AWS, animation, and mock branding. One discovery during the design process was that if a planned AI component functioned too well, it would confuse the end user, leading to careful calibration of the ML capabilities. The team learned that recommendations had to be transparent, showing the user why a particular action was suggested rather than presenting conclusions without context. In parallel with user testing, Kablamo worked with the bank to design and build a cloud-native SMB digital platform. The platform ingested large amounts of SMB data for insights and recommendations. The secure AWS infrastructure was designed from the ground up to meet the bank's compliance requirements, with encryption of all data in transit and at rest, identity-based access controls, and continuous monitoring. The approach included: - **200+ hours of user interviews** balanced with rapid product development over a two-year engagement - **Intelligent data platform** with machine learning capabilities for data-driven insights - **Secure cloud infrastructure** deployed in AWS, one of the first production workloads for the bank - **UX testing** to hone algorithm outputs and recommendations - **Accounting integration** connecting the platform to existing financial tools used by small businesses --- ## The Results The platform launched into a closed pilot within 12 months of kickoff. The three-month pilot ran with 10 real customers using their actual banking data. Features built included an accounting solution, financing options, ASP integration, and invoice reminders and alerts. Over 500 user interviews were conducted and 200 hours of user testing completed throughout the engagement. This was one of the bank's first production workloads, including customer data, securely deployed in AWS. It marked a major step for the bank to become cloud-based, agile, and future-ready. The pilot validated that SMB customers responded positively to proactive, data-driven insights integrated directly into their banking experience, rather than having to seek out information through separate reporting tools. The machine learning components provided meaningful recommendations while remaining transparent enough for users to trust and act on. The secure AWS deployment established patterns and governance that the bank could apply to subsequent cloud workloads across its broader technology portfolio. --- ## Looking Forward The platform delivered new customer value via an intelligent data platform using machine learning and a strong customer experience. The engagement demonstrated that deep user research and rapid product development can run in parallel without one slowing the other. The approach of running deep user research in parallel with rapid product development proved that a bank could build and test new digital products at startup speed while maintaining the rigorous security and compliance requirements expected of a major financial institution. The engagement established a model for how large banks can approach digital product innovation: combining deep domain understanding (through hundreds of hours of direct customer research) with rapid technical execution (through cloud-native architecture and reusable components). The patterns established during this engagement, particularly around secure AWS deployment and ML-driven customer insights, became reference architectures for the bank's subsequent digital initiatives. For Kablamo, the project demonstrated the value of treating user research not as a phase that precedes engineering, but as a continuous input that shapes the product throughout its development lifecycle. --- ### MIHOYO URL: https://www.kablamo.com.au/case-study/levelling-up-on-user-experience Date: 2021-12-12 ## The Challenge Genshin Impact is an action role-playing game developed and published by miHoYo (HoYoverse). The Paimon character in the game enhances the player's experience by educating and sharing information with the player. Kablamo had built the original Paimon Extension for Twitch in 2020/2021, which included a code distribution system and basic information modal. In 2022, Twitch and HoYoverse engaged Kablamo to update and expand the Paimon Extension with new interactive game modes, timed to coincide with the Genshin Impact v3.2 launch on 2 November 2022. The updated extension was an overlay with in-stream games involving Paimon and Slimes characters from Genshin Impact. The solution needed to faithfully reflect the Genshin Impact visual experience using brand themes, UI and characters. It had to support thousands of concurrent players while integrating seamlessly with Twitch's extension platform. The extension had to work across desktop, tablet, and mobile with full localisation for text and images across multiple regions, and handle bursts of heavy concurrent usage during popular streams. HoYoverse provided in-game reward codes (primogems and items) to distribute through the extension, with daily limits and RNG distribution to control the total number of codes given out. The code distribution system needed to work across both Paimon Defender and the new Battle of the Slimes game mode, with daily caps and randomised distribution to control the total volume of codes given out across all regions. --- ## The Approach The discovery and design phase ran from July 2022, starting with an ideation workshop to define the game direction. This was a co-design effort between Kablamo, the Twitch Brand Partnership Studio team, and HoYoverse stakeholders. Kablamo's design lead worked in Figma to ensure every visual element faithfully represented the Genshin Impact brand, matching the game's colour palette, typography, and character art standards exactly. Within the first sprint, rapid user journey wireframing was completed along with first-round high-fidelity prototyping for both desktop and mobile. Regular QA testing and tweaking sessions were run with a team of Kablamo gamers who could evaluate the experience as players, providing feedback grounded in actual gameplay behaviour rather than abstract usability testing. The team built two interactive game modes. **Paimon Defender** was the existing mini-game where viewers interacted with the stream. **Battle of the Slimes (BOTS)** was a new team-based game mode: viewers joined via the extension (not chat), selected a slime type, and entered a passive mode for powering up. Team A battled Team B with a kill feed logging the action. A battle summary appeared at the end, and winners and participants received in-game redemption codes. The front end used React, TypeScript, Canvas, and PixiJS, a high-performance game and animation library. The back end was built in Go with AWS Lambda and DynamoDB for a scalable serverless architecture that could handle bursts of thousands of concurrent players. AWS Cognito managed user access lists and admin controls. Distributed load testing validated the APIs at scale. Analytics captured daily streamer counts, daily user participation in BOTS, daily codes distributed via both Paimon Defender and BOTS, unique users who clicked Like, generated codes, or opened the info modal, and users who clicked external links. Localisation for text and images was baked into every component. --- ## The Results The extension delivered 10.9 million minutes watched, equivalent to 21 years of continuous viewing, with 436,000 in-game code redemptions across the Paimon Defender and Battle of the Slimes game modes. A custom emote was used over 600 million times in chat by viewers across multiple regions. Streams ran across the US, Korea, Spain, Germany, and Brazil. The serverless architecture handled the burst traffic patterns that characterise Twitch streams without any performance degradation. When popular streamers activated the extension and thousands of viewers joined simultaneously, the Lambda and DynamoDB backend scaled to meet demand and scaled back down when streams ended, keeping operational costs proportional to actual usage. At the final showcase, the Twitch team said the extension "exceeded what we initially thought possible." The HoYoverse campaign received a Twitch Brand Partnership Award in recognition of the campaign's success. --- ## Looking Forward By using popular development languages and serverless cloud technology, ongoing operational costs for Twitch were reduced. A new AWS instance was spun up for production and development environments, keeping the infrastructure clean and dedicated to the extension. The deliverables included information modals, reward modals, menu hub, live configuration panel, and the mini-game, all with localisation, responsive design across desktop, tablet, and mobile, and full analytics. Kablamo also delivered a portfolio of reusable design assets and full documentation of environments and extensions. The proven technical architecture and reusable component library provide a foundation for future campaigns on the Twitch platform. The PixiJS rendering layer, the serverless API pattern, and the code distribution system are all designed to be adapted for other game titles and brand partnerships without rebuilding from scratch. --- ### EVENTS MANAGEMENT COMPANY URL: https://www.kablamo.com.au/case-study/lights-camera-live-stream Date: 2020-06-08 ## The Challenge The client is a family-owned Australian production and live streaming company. Their team of producers and event managers provides end-to-end livestream production services to thousands of viewers worldwide, serving enterprise customers across technology, education, event activation, consulting, and government sectors. The company had relied on WordPress to build custom branded pages for each livestream event. A producer would manually create each page, configure the branding, embed the stream, and publish it before the event went live. As the business grew, this manual process became a bottleneck. Each event required hands-on work from the production team, limiting how many events could run concurrently and creating risk when last-minute changes were needed close to go-live. The company approached Kablamo to develop a customer-facing platform that would allow their enterprise customers to log in, create their own event pages, and customise their livestream feeds directly. The platform needed to be fast, scalable to handle concurrent events with large audiences, and integrated with live streaming services. Most importantly, it needed to give customers complete autonomy over their event page branding, removing the dependency on the production team for every page change. --- ## The Approach The engagement started with a discovery phase where the team ran customer journey workshops, feature prioritisation sessions, and lean service blueprint workshops with the client's team and end users. These sessions clarified what customers actually needed from a self-service tool versus what the production team had been doing manually on their behalf. A key technical decision early in the project was to integrate Vimeo's live stream API rather than building a custom video player from scratch with AWS MediaLive. This decision significantly reduced development time and provided features out of the box including RTMP stream keys and embedded chat, freeing the team to focus engineering effort on the custom event page builder, which was the core differentiator for the product. The event page builder allowed customers to upload media including images, text, videos, and livestream links, then configure pages to reflect their own branding. Reusable content blocks gave users complete control over placement and layout. Material UI provided base components, allowing the team to concentrate on UX and custom interactions rather than rebuilding standard UI elements. The architecture was a single-page application hosted on CloudFront and S3, with a CRUDL API using API Gateway and Lambda, backed by DynamoDB. The front end used React, TypeScript, Storybook, and Material UI with Jest for unit testing. The back end used Go with AWS Lambda and DynamoDB, with AWS Cognito handling authentication and access control. CloudFormation templates automated infrastructure provisioning, and fully automated deployments to the development environment ensured the team could ship changes quickly and safely. Separate development and production environments were established from the start. The entire solution was built on AWS with no external dependencies beyond the Vimeo streaming integration. This kept the operational footprint small and predictable, with costs scaling proportionally to actual event traffic rather than requiring fixed infrastructure. --- ## The Results The MVP was delivered in just over two months, on time and on budget. Enterprise customers can now configure their own event pages through the self-service platform, a process that previously required the production team to build each page manually in WordPress. The time from event booking to page-ready dropped from hours of manual work to minutes of customer self-service. The serverless AWS architecture ensures the platform scales with demand. When a large enterprise event draws thousands of concurrent viewers, the Lambda and DynamoDB backend handles the load without pre-provisioning. When traffic drops after the event, costs return to baseline. This elastic model is a natural fit for the event business, where traffic is inherently spiky and unpredictable. The team also completed a four-stage roadmap for future feature development, giving the client a clear path for extending the platform beyond the initial MVP. Features like advanced analytics, multi-stream support, and enhanced audience interaction tools were scoped and prioritised for subsequent releases. The automated deployment pipeline and separate environments mean new features can be tested safely before reaching production. --- ## Looking Forward The platform provides the company's enterprise customers with more engagement and customisation options than they have ever had. The workflow is more efficient for both the production team and their customers, with the production team freed from repetitive page-building work to focus on the creative and technical aspects of live event production. Development and production environments are set up for safe future feature testing, and the serverless architecture means the platform can absorb growth without infrastructure changes. The CloudFormation templates that automate infrastructure provisioning mean the client's team can deploy updates with confidence, following the same automated process Kablamo established during the build. Kablamo continues to provide ongoing operational and development support through Product Care services, helping the client extend the platform as their customer base and event volume grow. --- ### CEREBRAL PALSY ALLIANCE URL: https://www.kablamo.com.au/case-study/my-voice-library Date: 2023-05-20 ## The Challenge Communication is a key pillar of any childhood experience. Much of a child's day involves making themselves heard. But for over 50% of children with cerebral palsy who have difficulties with their speech, it is not that simple. This condition, known as dysarthria, means that while assistive technology exists, these solutions often take 15 to 20 times longer to convey a message compared to normal speech. People with cerebral palsy and dysarthria face communication barriers that current assistive technology has not adequately addressed. The lack of quality data on the voices of children with CP is a major barrier in the development of assistive technology solutions. There are no large public datasets of human voices with speech impairments available to researchers. Engineers and researchers need large datasets of dysarthric speech to train and test new technology, but collecting this data is difficult and time-consuming. Traditional voice data collection methods fail children with CP because they require sustained attention and repetitive tasks in clinical, sterile environments. High dropout rates and limited dataset growth have hampered previous efforts. CPA needed a platform that could make data collection accessible, engaging, and scalable while respecting the needs and limitations of children with CP. A new approach was needed that made data collection feel like play, not work. --- ## The Approach Cerebral Palsy Alliance enlisted Kablamo to help explore how to give children with CP the same rights, access, and opportunities as anyone else. Kablamo designed My Voice Library, a world-first platform for collecting voice and orofacial data from children with cerebral palsy. By gamifying the collection process, the platform makes it easier and quicker to assemble a significant, open-source library that biomedical engineers, speech pathologists, and researchers can use to develop the next generation of assistive technology. The solution was celebrated for its user-friendly and engaging experience. Children create their avatar and enter colourful, themed worlds designed to feel familiar and welcoming. Voice recording is disguised as mini-games, with prompts delivered through engaging characters and scenarios. The application includes multiple difficulty levels with a point-based reward system, custom characters for personalisation, age- and gender-neutral content, and fun facts and trivia integrated into each level. Each recording earns rewards, unlocks new worlds, and contributes to a growing library visible to participants. The system captures both voice and facial-movement data during interactive gameplay where participants repeat sentences on camera. The platform required a cost-effective, scalable architecture that could handle unpredictable usage patterns while maintaining strict data security for sensitive voice recordings from children. Scalability, accessibility, and cost optimisation drove the architectural decisions. Kablamo implemented a cloud-native approach using Amazon S3 and CloudFront for the static frontend, with a lightweight Lambda and API Gateway backend connected to DynamoDB. Amazon EC2 provides scalable, secure compute capacity for application processing, and Amazon EBS delivers high-performance block storage for database and analytics requirements. Restrictive S3 bucket policies ensure that once uploaded, recordings cannot be re-downloaded by the application. Encryption at rest, managed authentication, and comprehensive audit logging ensure data security and compliance for research involving minors. This architecture keeps ongoing hosting costs extremely low while scaling automatically. --- ## The Results My Voice Library is the first time voice samples have been collected from children who have a dysarthric speech condition. The gamified modules make it easier for children to go through the tasks, enabling engineers and researchers to develop and test new technology with the repetitions of sounds and words they need. The platform is designed to scale as the participant base grows. My Voice Library was recognised at the 2023 Good Design Awards for its innovative approach to accessible technology and human-centred design. The platform enables direct connections between parents and researchers, giving families access to individualised speech solutions that would previously have been out of reach. The open-source nature of the library means researchers globally can access the dataset, accelerating the pace of assistive technology development. --- ## Looking Forward My Voice Library represents a new approach to assistive technology development, one that puts the people who will benefit from the technology at the centre of the research process. As the library grows, it will enable engineers and researchers to develop and test new communication solutions that could improve quality of life for people with dysarthria. Future plans include integration of AWS machine learning capabilities to develop bespoke communication technologies tailored to individual speech patterns. The cloud-native architecture means the platform can scale to support thousands of participants without additional infrastructure investment, and the gamified collection approach has proven that inclusive research design can produce better data than traditional clinical methods. The platform demonstrates how thoughtful design, combined with modern cloud architecture, can create meaningful impact for underserved communities while building valuable research infrastructure for the future. This project is featured as an [AWS case study](https://aws.amazon.com/solutions/case-studies/cerebral-palsy-alliance-data-collection-case-study/). --- ### RURAL FIRE SERVICE NSW URL: https://www.kablamo.com.au/case-study/nsw-rural-fire-service Date: 2022-11-15 ## The Challenge The 2019-20 Australian 'Black Summer' bushfire season burnt more than 18 million hectares of land. In the wake of the NSW Bushfire Enquiry, it became clear that the NSW Rural Fire Service needed a fundamental shift in how incident information is gathered, validated, and turned into operational decisions. The enquiry specifically recommended that RFS investigate new technologies and embrace AI to bolster its capabilities during future fire seasons. Before Athena, critical context was scattered across systems, tools, and communication channels. Incident teams lost valuable time validating information during fast-changing events. Physical servers were unable to cope with incoming data volume during peak fire activity, and manual analysis was creating dangerous delays. Disconnected systems across agencies hindered coordination. Maintaining a shared operational picture at scale was nearly impossible. The goal was not just to digitise existing processes. It was to create a new kind of capability: intelligence, not just information. RFS needed a platform that could ingest almost limitless data sources including satellite imagery, wind forecasts, and social media, and turn that data into actionable intelligence in minutes rather than hours. --- ## The Approach RFS collaborated with Kablamo to build and deploy Athena, a custom bushfire intelligence platform. Named after the Greek goddess of wisdom and strategy, Athena was developed over two years with a dedicated Kablamo team working alongside RFS operational and technical leadership. Athena provides a common operating picture, bringing incident context, activity, and risk into a single interface so incident teams can coordinate and act on the best available signal. The platform displays predicted fire spread within minutes using Phoenix and Spark models, then supports analyst review and endorsement. It shows growth over the next 12 hours and highlights assets that may be threatened within the next two hours. The system displays comprehensive state maps integrating data from government, public, and private sources, including deployed firefighting vehicle and personnel locations, weather data and forecasts, wildfire history, RFS station locations, critical assets such as schools, hospitals, helipads, and aerial imagery. Athena can also ingest geotagged social content as an additional intelligence source, flag items for human analysis, and learn over time from validation. The Social Intelligence module monitors social media platforms including Twitter to identify unreported fires through keyword tracking and geo-referenced image analysis. AWS Rekognition performs real-time image recognition from social media. The more the system is used operationally, the more it refines its predictions. The platform covers the full incident lifecycle: preparation through short- and long-term hazard insights, detection with confidence metrics and risk ratings, response with predictions in minutes as impacts change, and recovery with operational records of decisions, assessments, and learnings. Built with a serverless architecture using AWS Lambda, RDS Aurora, S3, Fargate, Step Functions, and Event Bridge, with fire prediction engines from CSIRO (Spark) and Fire Prediction Services (Phoenix RapidFire). Development followed an agile sprint methodology with continuous iteration based on operational feedback. A second phase introduced additional modules including an Aviation Safety Module that assesses minimum aircraft types required for specific fires, evaluates weather conditions and aircraft classifications, generates risk assessments with red/amber/green operating environment ratings, and integrates with the national aviation tasking system. A Risk Response Engine identifies coverage gaps and recommends proportional response based on fire conditions and available resources. --- ## The Results The platform launched in November 2022 with approximately 200 trial users during the 2022-23 fire season. Athena was used operationally from its first deployment, with incident controllers relying on its predictions and common operating picture during live fire events. Since going live, the platform has tracked over 15,000 fire incidents with 100% uptime despite continuous zero-downtime deployments to the production environment. Output predictions have been validated operationally across multiple fire seasons. The Social Intelligence module received a Best-in-Class Australian Good Design Award. The system was expanded to approximately 700 operational RFS personnel for the 2023-24 season, with plans to extend access to other firefighting and partner agencies. Mobile Data Terminals are being rolled out to firefighting trucks, and Computer-Aided Dispatch integration with push-notification capabilities enables volunteer coordination in the field. The integration means that volunteer crews arriving at an incident can receive the latest predictions and threat assessments directly on their in-vehicle screens, rather than relying on radio updates alone. Discussions are underway with other firefighting agencies for system adaptation and integration, with potential for deployment beyond Australia. --- ## Looking Forward The collaboration between NSW RFS and Kablamo produced Athena, a platform that has changed how NSW approaches bushfire operations. By consolidating intelligence, prediction, and coordination into a single system, Athena replaced the fragmented tools that had limited decision-making speed during previous fire seasons. The platform continues to evolve with each fire season. This project is featured on [aws.amazon.com](https://aws.amazon.com/partners/success/nsw-rfs-kablamo/) as a partner case study, and it has been recognised with a Best-in-Class Australian Good Design Award for the Social Intelligence module. --- ### POLEMOS URL: https://www.kablamo.com.au/case-study/polemos Date: 2022-08-18 ## The Challenge Polemos is a Singapore-based Decentralised Autonomous Organisation (DAO) that operates as an education provider, game asset lender, and community platform for blockchain games and Web3 gaming (GameFi). They welcome people into this new online realm with open arms, from novice to veteran. The blockchain gaming space was fragmented. Players struggled to understand how to get started, which games to play, and how to manage digital assets across multiple chains. Existing platforms were either too technical for newcomers or lacked the depth that experienced players needed. Polemos needed a platform that could serve as the **single destination** for GameFi. The scope covered market analysis and strategy, user acquisition strategy, technology and infrastructure, monetisation and sustainability, user experience and solution design, and capability building. The platform had to bridge the gap between crypto-native users and mainstream gamers who had never used a blockchain wallet. --- ## The Approach Kablamo partnered with Polemos to design and build **The Forge**, a platform structured around three core pillars: University (education for GameFi), Armory (NFT asset lending), and community/DAO integration. The journey began with discovery sessions, user-centred research, interviews, and immersive workshops. The team mapped user journeys through design-thinking methodologies and cross-functional collaboration to align user needs with product strategy and business objectives. This end-to-end design process led to **The Forge**, a platform intertwined directly with the Polemos DAO. The engagement followed a phased release schedule. The initial release covered the migration and Scholar App: the Polemos homepage, University overview and courses, scholarship overview and courses, dashboard, admin tables, the Honor Engine, and Discord bots. Subsequent releases added the Scholar dashboard, staking overview and rewards, governance overview, Snapshot voting, and a bespoke forum. A further release coincided with a major partner game launch and delivered the Armory. The final phase focused on platform iteration and updates. The University pillar provided a flexible framework to build, upload, and promote courses aimed at non-technical users who could author content without engineering support. Content was migration-ready and reusable, supporting images, video, and custom typography. Course completion was validated through exams with randomised questions or multiple quizzes, ensuring genuine knowledge transfer rather than passive consumption. The Armory pillar enabled short-term rentals of in-game NFTs for performance boosts. Players could stake their unused assets into the Armory and earn returns, while other players could rent those NFTs for a short-term performance boost in supported games. This created a lending marketplace within the ecosystem that aligned incentives across the community. The platform was built on AWS best practices with a serverless-first event-driven architecture. The front end used React and TypeScript integrated with Web3.0 libraries including Web3Modal and Wagmi. The technical implementation included: - **Smart contract integration** for secure, transparent transactions on the blockchain - **API connectivity** to aggregate data from diverse game ecosystems - **Discord bot integration** for community engagement and notifications - **Polemos University** for player education and onboarding with flexible content authoring The platform supports multiple wallet providers, enabling seamless asset management across supported chains. --- ## The Results The Forge launched and is now live at [forge.polemos.io](https://forge.polemos.io), serving as the central hub for the Polemos community. The platform delivers multi-chain cross-blockchain support for major networks with DAO-integrated community governance and participation. The engagement evolved through multiple phases over the following months as the platform grew with new games, features, and educational content. The University pillar proved particularly effective at lowering the barrier to entry. Courses could be authored by community contributors without engineering involvement, and the exam and quiz system verified that players genuinely understood wallet setup, gas fees, and smart contract interactions before they risked real assets. This reduced the support burden on the Polemos team and gave new players confidence to participate in the wider ecosystem. The Armory created a self-sustaining lending marketplace. Asset owners who were inactive in a particular game could stake their NFTs and earn passive returns, while active players gained access to high-value items they could not otherwise afford. Because staking and rental terms were governed by smart contracts, the process required no manual intervention and settled transparently on-chain. On the technical side, the serverless architecture kept operating costs proportional to actual usage. During tournament periods, traffic spiked significantly, and the platform scaled automatically without manual capacity planning. Between events, costs dropped back in line with baseline traffic. The event-driven design also allowed the team to add support for new game integrations by deploying a new set of API adapters without modifying the core platform. --- ## Looking Forward The collaboration between Kablamo and Polemos shows how considered design and solid engineering can make emerging technologies accessible to a broad audience. The engagement evolved through multiple phases reflecting the evolving needs of the Web3 gaming space and the platform's growing feature set. As blockchain gaming continues to grow, The Forge is positioned to welcome the next generation of players into the GameFi ecosystem. The serverless-first event-driven architecture enables rapid iteration and expansion, allowing Polemos to respond to the fast-moving Web3 gaming landscape while maintaining a consistent, high-quality user experience across all three pillars of the platform. Future priorities include expanding the Armory to support additional game titles and chain networks, deepening the University course library with advanced strategy and tokenomics content, and introducing community-driven governance features that let DAO members vote on which games and courses the platform should prioritise next. The underlying architecture was designed with exactly this kind of growth in mind: each new game integration is a plugin, each new course is a content entry, and each new chain is a wallet adapter, none of which require changes to the platform core. --- ### GOVERNMENT AGENCY URL: https://www.kablamo.com.au/case-study/question-time-securing-interview-data Date: 2021-01-15 ## The Challenge Government interviews are valuable digital assets requiring careful management, transcription, storage, and retrieval. The existing system required administrative personnel or officers to transcribe interviews manually. With a high degree of variation in audio quality and an average interview length of one hour, the process was time consuming, expensive, and emotionally difficult for staff given the sensitive nature of the content. A one-hour interview could take five to ten hours to transcribe, depending on the quality of the recording. A backlog of transcriptions was building up across the agency. Interviews were stored on physical media in a centralised warehouse, and search and retrieval times were lengthening as the archive grew. Legacy systems made it difficult to cross-reference or search across cases. The solution needed to address four priorities with equal weight: speech-to-text optimisation, transcription editing, storage and retrieval, and encryption and security. Given the sensitivity of the data, security was not an afterthought but a first-class requirement from day one. --- ## The Approach Kablamo built a secure digital asset management platform with equal priorities across the four areas. Initial prototypes of the system and editor were delivered in under two weeks and given to agency teams to trial. User feedback from those trials informed the optimisation of the final implementation. The speech-to-text research phase tested Amazon Transcribe with real interview data of varying quality, including different accents, slang usage, diction, recording equipment, and file types. Success rates were monitored across multiple configurations to inform the ML solution development. A significant finding came from the audio preprocessing experiments. The team tested various methods to improve transcription of low-quality recordings, including volume normalisation, noise reduction, and speed adjustment. Counter-intuitively, audio preprocessing actually reduced accuracy in most cases. The ML pipeline had been trained to compensate for imperfections in raw audio, and altering the recordings introduced artefacts that caused more errors than they prevented. The decision to use raw audio as the primary input improved results across the board. For speaker identification, the team tested channel-based diarisation approaches. Multi-channel separation with clear channel assignment achieved near-perfect accuracy when each channel contained a single speaker. Accuracy dropped when speakers talked simultaneously or alternated quickly, which informed the design of the transcription editor's manual correction interface. Custom vocabulary training achieved strong results for domain-specific terms and phrases that appeared frequently in interviews. The system handled specialised legal and procedural language well after training. Proper nouns, including local place names, produced mixed results: the system sometimes replaced common words with similarly-sounding place names, a trade-off that was managed through the editing interface rather than attempting to eliminate it programmatically. The platform included a transcription editor with audio waveform visualisation, speaker diarisation display, and stereo audio channel separation. The editor was designed for efficiency, allowing staff to review and correct transcriptions while listening to the original audio, with the interface highlighting areas of lower confidence for prioritised review. --- ## The Results The speech-to-text automation reduced administrative staff workload by 50% or more for most audio recordings. This delivered both efficiency gains and mental health benefits for staff who previously had to repeatedly listen to sensitive interview content to produce manual transcriptions. The editing platform proved intuitive to use through its UX-focused design. Staff could review ML-generated transcriptions, correct errors, and annotate content without specialised training. The custom vocabulary training meant that domain-specific language was handled accurately from the first pass, reducing the volume of corrections needed. The platform provided a secure cloud-based system for storing, searching, and editing interview data, replacing the legacy physical media warehouse with a digital asset repository. Encryption at rest and in transit, combined with comprehensive audit logging, met the agency's security requirements for handling sensitive material. Every access, edit, and export is logged with full attribution, providing the compliance trail that the agency's governance framework requires. Search and retrieval times improved dramatically compared to the physical archive system. Staff can now locate specific interviews, search within transcriptions for keywords or phrases, and retrieve historical records in seconds rather than waiting for physical media to be located and delivered from the warehouse. --- ## Looking Forward This solution goes well beyond transcription efficiency. It opens up a powerful ML-based future for the agency. With interview data now stored digitally in a searchable, structured format, the platform supports capabilities that were impossible with the physical archive: meta-tagging interviews, cross-referencing data across cases, and identifying patterns across large volumes of interview material. Future capabilities under consideration include hardware integration for editing efficiency, expanded cross-referencing tools, and additional ML models trained on the growing corpus of transcribed interview data. As the platform continues to evolve, each new interview that enters the system improves the ML model's accuracy for the agency's specific vocabulary and audio conditions. What started as a transcription efficiency project has become the foundation for a searchable, secure, ML-enhanced intelligence capability. --- ### CAPE YORK PARTNERSHIP URL: https://www.kablamo.com.au/case-study/rethinking-digital-access Date: 2020-11-05 ## The Challenge Cape York Partnership (CYP) is an Indigenous organisation established to enable Cape York's Indigenous people. In 2005, CYP developed the Cape York Agenda, a framework for enabling Indigenous community members to have control and responsibility of their own lives without welfare reliance. All CYP initiatives are co-designed with the people of Cape York so they can lead the changes that will make a difference to them. Many financial and community services are migrating to online platforms, so it's vital that people with lower digital literacy are not excluded. CYP approached Kablamo in late 2020 to build Pama, an Australian-first digital platform spanning five domains: money management, education, health, home ownership, and employment. "Pama", which translates to "my people", aims to transform the lives of Indigenous Australians. The platform needed to resolve four core problems. First, effective community communication: CYP needed a comprehensive and accurate user database for mass and individual contact across remote communities. Second, access to education tools: the organisation's existing MPower money management resources needed to be digitalised and made available online. Third, financial management: users needed an online portal to access and manage their trust and opportunity accounts, with budgeting guardrails built in. Fourth, document consolidation: community members frequently lost certificates and proof of identity when applying for jobs, creating repeated barriers to employment. The design challenges were equally complex. Many users had low tech proficiency, and some had limited literacy. Devices ranged from basic supermarket phones to the latest iPhones, and bandwidth in remote Cape York was severely constrained. On top of this, the Kablamo team was based in Sydney while stakeholders were in Cape York, and Coronavirus border closures made in-person workshops impossible throughout the project. --- ## The Approach The team tackled the low-literacy challenge by leveraging familiar social media patterns, drawing on Instagram-like interactions that users already understood. Extra attention was given to the language used throughout the platform. Default text sizes were boosted, and a vibrant high-contrast colour palette was applied that met AA accessibility compliance. The goal was to reduce cognitive load and reward intuition. To handle device diversity, the design language relied on negative space and chunky field padding to deliver a consistent experience regardless of screen size or device capability. For bandwidth constraints in remote Cape York, step flows replaced long single-page forms, minimising content per page load and creating a sense of progress for users on slow connections. With the Sydney team unable to travel to Cape York, weekly online design catch-ups and co-creation sessions ran over Zoom. Figma prototyping enabled remote user testing, with CYP staff in Cape York facilitating sessions with community members. Kablamo invested time creating a comprehensive toolkit and style guide at the start of the project. Core atoms and molecules were designed and developed in Figma and Storybook, forming the backbone for all interface design and development. This Flat 2.0 Design approach, favouring simple, flat interfaces, enabled the team to produce 14 comprehensive features across 250+ UI screens in six months. The toolkit was built to bootstrap into a full design system for future phases. The platform was built on a serverless event-driven architecture using a managed relational database with schema versioning for easy updates, AWS Lambda and SQS queues for serverless processing, AWS CodeBuild and CodePipeline for fully automated builds and deployment, and AWS S3, EC2, CloudWatch and QuickSight for storage, compute, monitoring and analytics. Secure third-party banking integration was handled via SQS and Lambda. --- ## The Results The team delivered an MVP from scratch in under four months, followed by additional refinement informed by ongoing co-creation sessions with the community. The iterative approach meant each release incorporated direct feedback from the people who would use the platform daily. Pama now serves over 250 Indigenous Australians daily across both mobile and desktop. Feedback from community members during the co-creation sessions directly shaped the final design of each feature, ensuring the platform reflected how people actually use their devices in remote settings. The 14 features built include a digital calendar, community noticeboard, services providers address book, in-context education about payday loans, unnecessary insurance and humbugging, a step-flow budgeting tool based on MPower resources, a resume builder with auto-attached certifications and achievements, and trust and opportunity account management. --- ## Looking Forward Pama has become an extension of the community itself, delivering alerts about medical services, food delivery, and community events alongside its financial tools. The platform provides guardrails that enable spending in a thoughtful way while enabling users to take control of their financial futures. It pioneered a way to educate and enable users in financial management with safeguards built in. Based on the platform's success, CYP is developing plans to expand Pama nationally, extending access to Indigenous communities beyond Cape York. The platform architecture is designed for this kind of expansion. Kablamo continues to provide ongoing Product Care for the platform. --- ### UNIVERSITY RESEARCH URL: https://www.kablamo.com.au/case-study/smart-solutions-for-clever-minds Date: 2021-08-12 ## The Challenge Kablamo was engaged by one of Australia's leading universities, home to some of the most advanced research and development projects in the country. The computing requirements across the University's various R&D departments were exceeding their current capacity, creating both bottlenecks during peak periods and wasted resources during quiet periods. Academic workloads are inherently uneven, with high peak loads that stretch resources and then periods of time when infrastructure is largely unused. Universities have traditionally maintained their own computing infrastructure, but this requires large investment in hardware plus high maintenance and development costs. Researchers across 16 departments were constrained by the same fixed pool of on-premise compute, meaning that a genomics team running intensive simulations could block capacity for an engineering group needing to process experimental data. When one department hit a deadline, everyone else waited. The University needed a solution that was cost-effective, easy to use, and fit within their existing practices for running and accessing cloud infrastructure without requiring researchers to be experts in cloud technology. The platform needed to provide on-demand access to compute resources while maintaining the security and access controls required for sensitive research data. Critically, researchers ranged from computational scientists comfortable with command-line tools to social science teams who had never provisioned a virtual machine, so the solution had to work for both groups without separate training tracks. --- ## The Approach Kablamo was engaged to deploy AWS Service Workbench (SWB), allowing the University to assess how it could be used by research departments. SWB enables researchers to securely store and share data without waiting for university computing facilities to become available. From an initial proof of concept that demonstrated the viability of the approach, it was quickly moved into production. The technical approach included a continuous delivery pipeline with custom functionality that allowed the University's own team to deploy updates and new configurations without external support. A complete AMI building pipeline for research environments ensured that each department could have pre-configured machine images tailored to their specific software and tooling requirements. For example, a life sciences group could launch an environment with R, Bioconductor, and the university's licensed genome analysis suite already installed, while an engineering team would get a different image with MATLAB, finite element solvers, and GPU drivers ready to go. Researchers did not need to install or configure any of this themselves. Custom IAM roles and policies provided secure, fine-grained access control so that researchers could only access the resources and data relevant to their projects. Data isolation was particularly important for groups working with health records or commercially sensitive industry partnerships, where accidental cross-department access could breach ethics approval conditions. Kablamo also provided Agile delivery training for University staff, transferring knowledge about iterative development and delivery practices so the internal team could maintain and extend the platform independently. The platform provided clear reporting and cost management visibility that was previously absent. Each department could see its own usage and costs, enabling informed decisions about resource allocation and preventing the surprise bills that often accompany early cloud adoption in research settings. Budget alerts were configured per department so that a runaway batch job would trigger a notification before costs escalated. --- ## The Results Kablamo onboarded 80 researchers across 16 research departments onto the platform, providing highly supportable and scalable solutions for the University's research groups. Researchers gained on-demand access to compute resources that scaled with their workloads, eliminating the bottlenecks that had previously delayed research timelines. The cost management visibility transformed how departments planned and budgeted for computing resources, replacing opaque shared infrastructure costs with transparent, per-department usage reporting. Researchers who previously waited days or weeks for compute capacity could now spin up a pre-configured environment in minutes and release it when the job finished, paying only for what they used. Departments that had been reluctant to try cloud computing adopted the platform once they saw peers running workloads successfully. The self-service model also freed the University's central IT team from a constant queue of provisioning requests, allowing them to focus on platform improvements rather than ticket-by-ticket support. --- ## Looking Forward This approach has resulted in an uplift in the internal DevOps team's capabilities and processes, along with developing the University's knowledge of Agile methodologies. The skills transfer embedded during the project means the University's internal team can now manage day-to-day operations, onboard new departments, and extend the platform's capabilities without starting from scratch. As new research groups come online, the AMI pipeline makes it straightforward to build purpose-specific environments for new disciplines. The University is also exploring tighter integration with its research data management policies, so that data classification and retention rules are applied automatically when a workspace is created. Kablamo continues to provide ongoing Product Care support, ensuring the platform stays current with AWS service updates and evolves alongside the University's research ambitions. --- ### SEVEN WEST MEDIA URL: https://www.kablamo.com.au/case-study/stabilising-the-headlines Date: 2020-02-18 ## The Challenge Pacific Magazines, Australia's number one magazine publisher with brands including New Idea, Marie Claire, and Home Beautiful (16 brands in total), needed a more stable platform to host their online content management system. The publisher later became part of Seven West Media. Growth in the digital channel and spiky website traffic had put significant strain on the existing hosting platform. Engineers were spending their time on platform stabilisation, often after hours, instead of working on innovation and new digital products. The company wanted to advance their websites beyond being digital copies of their published magazines, but the underlying infrastructure was holding them back. The platform was unable to handle traffic surges that accompanied major news events. When a major story broke and audience numbers spiked, the sites would buckle under load, reducing engagement, increasing page abandonment, and decreasing SEO authority. These reliability problems threatened to undermine the company's brands and reputation with both readers and advertisers, directly impacting revenue. The publisher needed a solution that could handle unpredictable traffic spikes without manual intervention. --- ## The Approach A combined team of architects and engineers from Kablamo, AWS, and the publisher worked together to plan and execute the migration from the existing hosting environment to AWS. The team brought together cloud architecture, DevOps, and delivery management expertise from Kablamo alongside the publisher's engineering and digital leadership. The design, build, testing, migration, and optimisation for the first two brands was completed within eight weeks. Home Beautiful and New Idea were cutover to run live on AWS, serving as the proving ground for the migration approach before rolling it out to the remaining 14 brands. The deliverables included: - **Pre-production environments** that mirrored production, enabling safe testing before cutover - **Automated continuous delivery pipelines** replacing manual deployment processes - **Container orchestration** for consistent, scalable application hosting - **Training and documentation** using a "we do, you do" competency model to build internal capability - **Automated toolsets and repeatable migration frameworks** for the remaining 14 platform migrations The "we do, you do" approach was central to the engagement. Rather than simply migrating the platforms and handing over the keys, Kablamo worked alongside the publisher's engineers throughout the process. Each step was performed collaboratively so the internal team built real understanding of the new environment, not just documentation to read later. This meant the publisher's team could handle subsequent migrations independently. The migration approach prioritised the brands experiencing the most acute stability issues, allowing the team to demonstrate value quickly while building confidence in the new platform. Each migration followed the same repeatable process: assess, plan, build pre-production, test, cutover, and validate. This consistency reduced risk and compressed timelines as the team moved through the portfolio. --- ## The Results The migration delivered measurable improvements across every dimension. Page load times improved by 50% on desktop browsers and 20% on mobile. Platform availability reached 99.99%, eliminating the after-hours stabilisation work that had been consuming engineering time. Audience traffic expanded by 24% as faster load times and improved reliability boosted SEO authority and reduced page abandonment. The new AWS platform proved its resilience almost immediately. Just days after cutting over, the platform withstood a major DDoS attack that generated a 500% spike in traffic. Where the previous platform had buckled under far smaller surges, the AWS infrastructure absorbed the load without any impact on user experience. During a subsequent high-traffic news event, the platform handled over 200,000 daily visitors without issues, compared to the previous infrastructure which had crashed at a fraction of that volume. The migration also delivered significant cost savings through reduced staff overtime and lower platform hosting costs, while adding capabilities that the previous environment lacked: CloudWatch logging for real-time monitoring and alerting, automated DDoS mitigation through AWS Shield, and faster content delivery through CloudFront and AWS edge infrastructure. These operational improvements meant the engineering team could respond to issues proactively rather than reactively. --- ## Looking Forward With near-zero downtime and no effect on user experience during the transition, the publisher now avoids the revenue losses and brand damage that had accompanied platform outages. Advertisers can rely on consistent audience delivery, and readers experience fast, stable access to content across all 16 brands. The digital team now has the time and knowledge to research, evaluate, and build new digital products rather than firefighting infrastructure problems. Engineering effort that was previously consumed by after-hours stabilisation and incident response is now directed toward innovation and growing the digital business. The competency model and repeatable frameworks delivered during the project equipped the internal team to handle the remaining 14 platform migrations independently, turning what could have been a multi-year dependency on external support into a self-sufficient capability. The automated toolsets mean each subsequent migration follows the same tested process, with consistent quality and predictable timelines. The project was also published as an AWS case study. --- ### VODAFONE URL: https://www.kablamo.com.au/case-study/vodafone Date: 2021-03-08 ## The Challenge Vodafone needed a modern digital shopfront that could handle peak sales traffic, including the high-demand Christmas season, with zero downtime. The existing platform could not support the release velocity or reliability required for a competitive telecommunications market. Every production release carried the risk of downtime, making the team hesitant to ship changes and slowing the pace of iteration on the customer experience. With multiple vendors and legacy APIs, the project demanded collaboration at scale and the ability to handle traffic spikes during critical sales periods. The Digital First programme brought together over 100 people across multiple vendor organisations, each with their own delivery practices and tooling. Aligning this group around a shared cadence and shared standards was as significant a challenge as the technical architecture itself. Any outage during the Christmas shopping season would directly impact revenue and customer trust at the busiest time of the year. --- ## The Approach Kablamo partnered with Vodafone (now TPG) to lead the delivery of their new online shop as part of the Digital First programme, transforming the customer experience. The programme represented a wholesale rethink of how Vodafone's digital channels operated, replacing the existing online shop with a modern, cloud-native platform built for speed and reliability. Working within the multi-vendor, 100+ person team, Kablamo embedded agile best practices and enabled Vodafone to confidently release multiple times per day for the first time in its history. The engineering team focused on four key areas. First, building a scalable, serverless architecture in AWS that could absorb peak sales traffic without manual intervention. The serverless approach meant the platform would scale automatically in response to demand, removing the need for capacity planning and pre-provisioning that had constrained the previous system. Second, embedding agile ceremonies to drive collaboration across the multiple vendors involved in the programme, establishing shared rituals such as cross-team stand-ups, sprint reviews, and retrospectives that kept the large team aligned on priorities and progress. Third, implementing developer experience improvements that shortened the feedback loop and made delivery faster and more reliable, including automated CI/CD pipelines for continuous deployment that gave engineers confidence in every release. Fourth, creating an integration layer to unify the various APIs that powered the shop, enriching system responses and providing a consistent interface for the Next.js frontend. Using AWS, Next.js, and the serverless architecture, the team delivered a platform designed for resilience under load. The architecture ensured that individual component failures would not cascade into site-wide outages, and auto-scaling handled traffic increases without manual capacity planning. The platform was built to support a "big-bang" launch where the old shop would be replaced entirely, rather than a gradual migration, which raised the stakes for the team to deliver a stable product from day one. Extensive load testing validated that the platform could handle the anticipated Christmas traffic peaks before the cutover. The team simulated peak traffic scenarios to ensure that every component in the stack, from the Next.js frontend through the integration layer to the underlying APIs, could sustain high concurrent load without degradation. --- ## The Results The project culminated in a successful big-bang launch with no downtime and no priority issues identified, a first for Vodafone. The new platform enabled Vodafone to release multiple times daily, ensuring agility and reliability during critical sales spikes. The platform handled the Christmas sales season without incident, validating the architectural decisions made during development. The shift from infrequent, high-risk releases to multiple daily deployments changed how the digital team operated, allowing product changes to reach customers within hours rather than weeks. The integration layer that unified the legacy APIs proved particularly valuable, providing a stable abstraction that allowed backend systems to be updated independently without breaking the customer-facing shop. The CI/CD pipelines established during the programme gave engineers confidence that each release was safe, removing the anxiety that had previously slowed delivery velocity. --- ## Looking Forward Agile practices embedded by Kablamo continue to deliver value across the business today. The shared ceremonies and delivery practices established during the programme became the standard operating model for Vodafone's digital teams, improving cross-vendor collaboration well beyond the initial project scope. Teams that had previously worked in isolation adopted the shared rituals and communication patterns introduced during the programme, creating a more cohesive engineering culture across the organisation. The platform's scalable, serverless architecture ensures Vodafone can continue to grow and adapt to changing customer demands without the downtime risks that previously accompanied every release. The ability to deploy multiple times per day, proven during the critical Christmas launch period, remains a core capability of the digital team. The zero-downtime release capability that was a first for Vodafone has become the expected standard for all subsequent platform work. Vodafone has since merged with TPG Telecom, and the engineering practices established during this programme continue to inform the combined entity's digital operations. --- ## News ### Troy Bebee and Brooke Cushing join Kablamo to lead our Google Cloud practice URL: https://www.kablamo.com.au/news/kablamo-appoints-troy-and-brooke-gcp-team Date: 2026-05-19 Two appointments today, both connected to our growing partnership with Google Cloud Platform. Troy Bebee joins as Kablamo's first Head of Google Cloud. He arrives from NTT DATA Asia Pacific, where he led the Google capability. Before that, his career sits at the intersection of two careful decisions. The first was made in 2018, when he bet that Google Cloud was about to mature into a serious enterprise platform and joined Kasna as CTO. He spent five years building Kasna into Australia's premier Google solutions partner, and continued that practice at Mantel Group as CTO Google Cloud. The second decision was a short detour into GenAI customer engineering at Redactive, which taught him that the most interesting questions in enterprise AI sit beneath the models, in the platforms they run on. ![Troy Bebee, Head of Google Cloud at Kablamo](/images/news/kablamo-appoints-troy-and-brooke-gcp-team-2.jpg) That is the centre of gravity Troy brings to this role. He has the engineering depth to architect at-scale GCP solutions, and the patience to talk a customer through the choices a roadmap requires. People who have worked with him over the years describe a rare ability to translate technical decisions into language a board can act on. That combination is the reason we created this role for him, and the reason we scoped it as a player-coach. He will architect, he will lead the practice, and he will manage the relationship with Google directly. We are not separating those things. Troy's particular focus is the cloud foundation underneath AI and agentic systems. Most of the interesting client questions we field this year sit in that area, and his depth with Gemini Enterprise, Vertex AI, and the wider Google data and AI suite is exactly the experience the market is asking us for. He is also a builder by instinct. A story we like: he ran a home machine-learning project on a Raspberry Pi to stop his cats jumping onto the kitchen counter, prototyped over a weekend. The instinct behind it, that the use case is the entire point and prototyping is non-negotiable, is the right one for the work in front of us. Brooke Cushing joins as our GCP Partner Manager. She brings more than ten years of partnership and programs experience across the technology and digital agency sides of the industry. At Rackspace she built the ANZ digital partner ecosystem from scratch. A former colleague there describes her as one of the most connected people he knows in the segment. At Campaign Monitor she ran APAC Customer Success across two and a half years, including a period as APAC Head of Customer Experience. At Salesforce she sat inside ANZ Sales Programs and Productivity, where she ran strategic pipeline development across cross-functional teams: sales development, partners, marketing, product, solution engineering, and strategy. ![Brooke Cushing, GCP Partner Manager at Kablamo](/images/news/kablamo-appoints-troy-and-brooke-gcp-team-3.jpg) That breadth is the point. Good partner management is operational discipline at its core. It means knowing where your pipeline gaps sit, having a plan to close them, and bringing the right people from the right teams into the same conversation at the right moment. Brooke does that for a living. She returned to work earlier this year after a deliberate career break to support her family, and we are glad she chose us. We are already in the work. Kablamo's Google Cloud practice runs across two of Australia's largest media and publishing groups, the national public broadcaster, and a market-leading ASX-listed property technology business, with a joint sales pipeline that is filling out steadily. We are a confirmed sponsor of the GCP Sydney Summit in 2026. We are continuing to invest in the team in Australia and in Canada. There is a pattern worth naming behind all this. Google Cloud is no longer the third entrant in the Australian enterprise market. The competitive frame has changed. Gemini, the agent infrastructure that surrounds it, and the data platform underneath it are the questions clients are putting to us this year. Our job, and the job we have hired Troy and Brooke to lead, is to give those clients answers that work in production once the deck is closed. Troy is Sydney-based and spends a good amount of his week in Melbourne. He is there with me next week. Brooke is also Sydney-based. They are both already in the work. We are glad to have them on the team. --- ### Leadership in the Agentic AI Era: Cutting Through the Hype. Toronto, April URL: https://www.kablamo.com.au/news/toronto-ai-roundtable-april-2026 Date: 2026-04-03 Author: Allan Waddell ## Leadership in the Agentic AI Era: Cutting Through the Hype **Toronto. April 29, 2026. Cibo Wine Bar, King West.** Kablamo is bringing its AI Round Table series to Canada for the first time. This is the fifth session in a series that has run in Sydney and Melbourne since late 2025, and the first outside Australia. The format is deliberate. A small group of executive technology leaders around a dinner table. No presentations. No vendor pitches. A candid, peer-led conversation about what is actually happening inside their organisations as they navigate the shift to agentic AI. Allan Waddell, Kablamo's Founder and Co-CEO, will join the table. Allan has been testing the limits of AI and agentic solutions for years and brings a practitioner's perspective on what works, what breaks, and what nobody talks about on stage. **Seating is intentionally limited. [Reach out to join the table](/contact).** ![Leadership in the Agentic AI Era](/images/news/toronto-ai-roundtable-april-2026.avif) --- ## What previous sessions have surfaced The Round Table series has now run four times across Australia. The conversations have been off the record, but the patterns that emerge are worth sharing. Here is what technology leaders at some of Australia's largest enterprises are dealing with in early 2026. ### The people best placed to lead adoption are the last to move The observation that kept surfacing across sessions: there is an inverse relationship between someone's depth of expertise and their willingness to use AI in that domain. A senior developer who uses Claude to plan a holiday will hold it to a completely different standard the moment it touches their codebase. "People are not adopting it because it helps the business. They are adopting because it helps them. If you cannot reach them at a personal level, there is a pushback." The organisations making progress have stopped trying to drive adoption from the top. They are designing for individual benefit first. ### AI-assisted commits are the new baseline One organisation shared that AI-assisted commits now account for 40 to 60 per cent of code written. Their QA function went from a full team to two people. Production incident rates held steady. A feature rebuild that would have taken two months was completed in three days. The constraint is no longer writing new code. It is removing old code, because AI cannot yet hold an entire legacy codebase in context well enough to do large-scale refactoring safely. The practical response has been architectural: build new capabilities as small, independent services that the AI can reason about, then gradually retire the legacy. ### Sixteen agents and nobody governing them One participant from a major cloud provider was running sixteen personal AI agents alongside their daily work. Another had a dedicated Slack channel for bots, quarantined from human channels. A third raised the security implications: agents can interact with each other in ways that create data leakage paths nobody anticipated. "How do you govern a tsunami of agents that are exploding internally?" Nobody had a complete answer. The analogy the room kept returning to was shadow IT in the 1990s. Agent proliferation is the same pattern at higher speed and higher stakes. ### The measurement problem nobody has solved Most organisations have committed to AI efficiency targets. Almost none have a baseline to measure against. The board wants 50 per cent improvement. Engineering is deploying tools. But when the review comes around, nobody can demonstrate the gain, because the efficiency that materialises tends to create new demand rather than reduce cost. One transformation specialist put it bluntly: the finance function will be a tenth of its size in ten years. CFOs do not enjoy hearing that. ### Some companies may not need to exist The sharpest moments came when the conversation moved from efficiency to existence. Train companies did not become airlines. Traditional retailers did not build the winning online stores. One retailer at the table confirmed that ChatGPT is now in their top referral sources. The trajectory is clear. The divergence in the room was not optimism versus pessimism. It was between people who think awareness is sufficient and people who think it is not. --- ## Why Toronto The Canadian market presents its own version of these questions. Enterprises are earlier in the adoption curve. The mid-market is underserved. The regulatory landscape differs. But the underlying tension is the same everywhere: between organisations that are rebuilding around intelligence as a core capability and those still bolting it onto the side. The Toronto session follows Google Cloud Next, bringing together leaders who are working through these problems in real time. --- ## Join the table **Leadership in the Agentic AI Era: Cutting Through the Hype** **April 29, 2026** **Cibo Wine Bar, 522 King St W, Toronto, ON** **Milano Room** This is not a conference. It is a dinner for a small group of peers. Seating is limited and the table is intentionally designed to spark candid dialogue. **[Reach out to reserve your seat](/contact)** --- *The Kablamo AI Round Table is a private, off-the-record forum for technology leaders. Previous sessions have been held in Sydney and Melbourne with CTOs, VPs of Engineering, Heads of AI, and transformation executives from major retailers, financial services firms, property platforms, cloud providers, and investors.* --- ### Kablamo becomes a Google Cloud Partner URL: https://www.kablamo.com.au/news/kablamo-gcp-partnership Date: 2026-03-17 Kablamo has formalised a partnership with Google Cloud, becoming an official Google Cloud Partner and extending our capability across the full GCP platform. The partnership reflects where our clients are. Australian enterprises and government agencies are increasingly running workloads across multiple cloud providers, and Google Cloud's strengths in AI, data analytics, and Kubernetes-based infrastructure are directly relevant to the problems we solve. ## Why Google Cloud We've always been platform-honest. We recommend the right tool for the problem, not the one on the preferred vendor list. In practice, that means AWS for the majority of our work, but increasingly Google Cloud for specific workloads where it genuinely leads: - **BigQuery and Vertex AI** for large-scale analytics and ML pipelines where the managed tooling reduces engineering overhead - **Google Kubernetes Engine** for clients already running GKE workloads who need expert support without a migration - **Workspace and Identity** integrations for organisations deep in the Google ecosystem - **Multimodal AI** via Gemini for clients building on top of generative models ## What it means for clients The Google Cloud partnership gives Kablamo clients access to Google's technical resources, architectural support, and co-sell opportunities, the same benefits our clients have leveraged through our AWS Advanced partnership. More practically, it means our engineers can operate across both platforms without the client needing to manage the vendor relationship themselves. ## Multi-cloud is the reality Most of our clients don't live on a single cloud. Data lakes span providers. Legacy workloads sit in different accounts. Acquisitions bring in new infrastructure. The partnership with Google Cloud means we can work across that reality rather than around it. We'll be expanding our GCP capability over the coming months, including Google Cloud certifications across our engineering teams and deeper integration with Google's AI partner programme. For enquiries, contact us at [hello@kablamo.com.au](mailto:hello@kablamo.com.au). --- ### Kablamo appoints Laura Fini as Managing Director, Canada URL: https://www.kablamo.com.au/news/kablamo-appoints-laura-fini-managing-director-canada Date: 2025-07-09 Kablamo has appointed Laura Fini as Managing Director, Canada, a senior leadership hire that strengthens the company's North American operation as it grows its presence in the Waterloo region of Ontario. Fini brings executive leadership experience to a practice that has been building quietly since Kablamo first opened its Canadian office in 2022. The appointment marks a step change in how the company is structured in Canada: from a delivery outpost to a fully led regional practice with its own director. ## Building on a strong foundation Since launching in Canada, Kablamo has assembled a local team with deep capability across technical delivery, DevOps, QA, and program management. Fini's appointment gives that team clear executive leadership and a direct line to Kablamo's co-CEOs in Australia. The Canadian practice serves enterprises in the Waterloo and broader Ontario region, delivering the same cloud-native digital product development and data platform work that has defined Kablamo's reputation in Australia, particularly in fintech, where the company has deep experience. ## A maturing North American practice The Waterloo region continues to grow as one of North America's most significant technology hubs, with strong ties to the University of Waterloo and a dense network of technology companies. Kablamo's presence there positions the company to work with organisations at the forefront of that ecosystem. Fini joins a Canadian leadership team that includes Brian Gilham as Technical Director and Dana Mitchell as Program Consulting Lead, a team built to deliver at the same standard clients expect from Kablamo's Australian practice. --- ### Kablamo launches dedicated AI practice to meet enterprise demand URL: https://www.kablamo.com.au/news/kablamo-launches-ai-practice Date: 2025-04-15 Every system Kablamo has delivered has been, at its core, a data and intelligence project. Not "AI-enhanced." Not "with an AI module." Built around data, machine learning, and intelligent automation from the foundations up. The AI practice we are formalising in 2025 is not new capability. It is a decade of this work given a name and a sharper focus as enterprise demand shifts from experimentation to transformation. It is worth being specific about what "a decade of AI work" actually means, because the claim is easy to make and hard to back up. ## The track record **Bushfire prediction and decision intelligence.** When the 2019/2020 Black Summer fires pushed existing emergency technology to its limits, Kablamo built a cloud-native platform that ingests vast quantities of geospatial and sensor data and turns it into operational decisions. The underlying system uses Amazon SageMaker for compute and ML, Bayesian network models for prediction through Phoenix RapidFire, and automated data pipelines through Athena and S3. It achieved a 70x improvement in modelling resolution for the Victorian Government. The NSW Rural Fire Service subsequently commissioned Athena, a custom implementation built on this platform, to fundamentally shift how incident information is gathered, validated, and turned into decisions. There is nothing else like it in Australia. It won the 2021 AWS Global Public Sector Partners Award for Most Innovative AI and ML Solution. **Petabyte-scale data platforms.** For a major infrastructure group, Kablamo designed and delivered an AWS data lake engineered to ingest petabytes of data from thousands of real-time feeds. The platform used AWS Textract to extract text and data from over seventy years of documentation, event-driven serverless workloads for processing, and a custom UI and data catalogue to make it usable. This was not a dashboard bolted onto a legacy database. It was a ground-up intelligent system designed to create new revenue streams from previously inaccessible data. **Media archive intelligence.** CoDA, built for the ABC, consolidated ninety-one years of broadcast content from five legacy systems into a single searchable platform. It reduced archive retrieval time from weeks to milliseconds, grew to over six terabytes of audio, video, and image content, and has been in continuous production for over seven years. Originally built on Elasticsearch with a Go backend and S3 as the API layer, the system now uses Google Gemini to power next-generation search and content understanding across the archive. CoDA is a living example of a system that was built for intelligence from day one and has continued to evolve as the AI landscape has advanced. **ML-powered transcription for government.** For a government agency, Kablamo built DAME, a machine learning-powered transcription platform for investigative interview data. It reduced administrative workload by 50 per cent or more while maintaining the security and access controls that sensitive investigative material demands. **Voice AI for children with cerebral palsy.** My Voice Library, built with the Cerebral Palsy Alliance, is a world-first platform for collecting dysarthric voice data to develop assistive technology. Fully serverless, cost-effective, and designed to handle sensitive voice recordings from children with strict data security. This is AI in the service of people who need it most. **Intelligent financial platforms.** For a major Australian bank, Kablamo delivered a research-based fintech platform with over 500 user interviews, an intelligent data platform with machine learning capabilities, and the bank's first production AWS workload. From kickoff to closed pilot in twelve months. **Digital asset management.** Kablamo's own DAM platform was built as a modular, cloud-based system for streaming, broadcast, corporate enterprise, and law enforcement. Not a licensed product with features bolted on. A system designed around the data and how it moves. Every one of these projects was, in the language we now use, a business *of* AI rather than a business *with* AI. The intelligence was not a feature added to an existing system. It was the reason the system existed. ## What changed The models changed. Claude Opus 4.6 can sustain autonomous work for over fourteen hours. Gemini 3.1 Pro leads on twelve of eighteen tracked benchmarks at two dollars per million input tokens. The Model Context Protocol has given agents a standard way to discover and use tools across enterprise systems. The cost of intelligence has dropped to commodity economics. This means the kind of work we have been doing for a decade, connecting data to consumers in powerful ways, is now the thing every enterprise needs. The systems we build today use the same architectural instincts as CoDA and Firestory: composable, API-first, designed for change. But they now have access to foundation models that make capabilities possible which would have been science fiction five years ago. ## What the practice focuses on **Agentic systems** that orchestrate across enterprise tools and data sources. We build these for our own operations, with agents spanning CRM, resourcing, project management, content operations, and strategic account planning, all orchestrated through MCP. The same patterns apply to client work. **Production RAG and knowledge systems** that make enterprise data accessible, searchable, and actionable. Not chatbots. Systems with governance, observability, and the engineering rigour that production demands. **AI-augmented engineering workflows** where AI changes not just what gets built but how. QA functions moving upstream into specification-writing that agents test against continuously. Non-engineers gaining AI-mediated access to codebases. Legacy system comprehension as a prerequisite for transformation, not an afterthought. **Model evaluation and monitoring** so AI systems remain accurate as data, requirements, and models change beneath them. ## The partnerships This formalisation comes alongside two significant partnerships. Kablamo's long-standing AWS Advanced partnership, underpinned by the Global Public Sector Award, continues to anchor much of our cloud and AI delivery. Our new Google Cloud partnership, formalised in March 2026, extends our capability across GCP's AI, data, and Kubernetes infrastructure, including Vertex AI, BigQuery, and Gemini. Most of our clients do not live on a single cloud. The ability to operate across both platforms with the engineering depth to make real architectural decisions, rather than vendor-driven ones, is the practical differentiator. ## Why engineering, not consulting There is no shortage of firms offering AI strategy. The gap is in engineering: connecting models to real data, real workflows, and real users inside organisations with legacy systems, regulatory requirements, and the accumulated complexity of having been in business for a long time. That is where Kablamo has always operated. Every programme we have delivered has been built around intelligence, not decorated with it. The AI practice formalises this because the demand now justifies a name, and because the organisations that move in the next eighteen to twenty-four months will build advantages that compound for years. If you are looking to move from experimentation to production, [get in touch](/contact). --- ### Kablamo achieves AWS Advanced Tier Services Partner status URL: https://www.kablamo.com.au/news/kablamo-aws-advanced-partner Date: 2025-03-01 We're proud to announce that Kablamo has achieved AWS Advanced Tier Services Partner status, a recognition of our cloud engineering capability and the outcomes we've delivered for clients across government, media, and financial services. This milestone reflects the work of our entire team and the trust our clients have placed in us to solve genuinely hard problems with cloud technology. The AWS Partner Network recognises organisations that demonstrate technical capability, customer success, and a commitment to building on AWS. The Advanced tier places us in the top tier of AWS consulting partners in Australia. For our clients, this means continued access to AWS technical resources, early access to new services, and the confidence that comes with working with a proven AWS partner. --- ### Kablamo recognised at the Good Design Awards for Firestory URL: https://www.kablamo.com.au/news/kablamo-good-design-award Date: 2024-11-12 Firestory, Kablamo's AI-powered bushfire intelligence platform, has been recognised at the Good Design Awards, Australia's peak design recognition program, operating since 1958. The recognition is for the product's approach to interface and information design under extreme conditions. Firestory is used by incident controllers, fire behaviour analysts, and operations teams during active fire events, environments where cognitive load is high, stakes are real, and there is no room for a confusing UI. ## Design under pressure Most software is designed for users with time. Firestory is designed for users without it. The platform integrates satellite imagery, weather models, predictive fire behaviour engines, and ground-level sensor data into a single coherent interface. Getting that right required thinking carefully about hierarchy, colour, typography, and interaction patterns in a context where the wrong call could cost lives. Kablamo's head of design worked directly with fire agencies to understand how different roles (incident controllers, aviation coordinators, public liaison units) read a screen differently when they're managing a crisis. Each role sees a version of Firestory calibrated to their specific decision-making needs. ## Recognition beyond technology Awards like Good Design matter because they recognise that technology alone isn't enough. The firefighting community doesn't need more data. They need the right data, in the right form, at the right moment. NSW Rural Fire Service Assistant Commissioner Ben Millington captured it well: > "There's nothing like this, certainly in Australia." The Good Design Award recognition joins the 2021 AWS Global Public Sector Partners Award for Most Innovative AI and ML Solution in acknowledging the work Kablamo and its agency partners have done to apply serious technology to one of Australia's most serious problems. --- *Note: Please verify the specific award category, year, and citation details before publishing.* --- ### Kablamo launches Firestory: Australia's first AI-powered bushfire intelligence platform URL: https://www.kablamo.com.au/news/kablamo-firestory-launch Date: 2022-07-01 Today Kablamo formally launches Firestory, a cloud-based data and AI platform built specifically for bushfire management in Australia. Firestory is the product of years of embedded work with fire agencies. It started with a single insight: the people making life-and-death decisions during a fire event had too many systems, too many tabs, and not enough clarity. We set out to fix that. ## What Firestory does Firestory digitises the workflows of fire incident management. It connects data from dozens of sources (weather feeds, satellite imagery, ground sensors, historical records, agency databases) and presents it in a single interface calibrated for the roles that matter: incident controllers, fire behaviour analysts, operations controllers, and public liaison officers. The platform provides: - **Real-time incident tracking** across active fire zones - **Predictive modelling** using CSIRO Spark and Phoenix RapidFire engines - **Workflow digitisation** for processes that were largely paper-based - **Geospatial visualisation** of complex, multi-source data in a human-readable form - **Aviation safety modules** for coordinating aircraft over fire grounds - **Social intelligence** for monitoring community impact and spread of information Previously, after a fire event, producing an incident report required collecting masses of paperwork and individual recollections. With Firestory, it's an export button. ## Built with and for firefighters Kablamo's geospatial lead Andrew McDowell, who has led the engineering of Firestory since its earliest prototype, described the challenge: > "We've had a lot of geospatial challenges around how you integrate different types of data and visualise them so you're presenting complex data in a way that humans, with many different skills, can get insights from quickly. We've got historical data, observational data about what's happening right now, and forecasted data. The challenge is taking all those different types of data and presenting it in a way that just lets people do their jobs." The platform has been developed in close collaboration with Australian fire agencies, with every feature validated against real operational requirements before being shipped. ## What's next Firestory is live and in active deployment. We're continuing to expand its predictive capabilities, integrate hyperspectral satellite imagery, and extend the platform to additional fire agencies across Australia and internationally. For agencies interested in Firestory, contact [firestory@kablamo.com.au](mailto:firestory@kablamo.com.au). --- ### Kablamo expands into Canada URL: https://www.kablamo.com.au/news/kablamo-expands-in-canada Date: 2022-02-03 Kablamo has launched in Canada, establishing operations in the Waterloo region of Ontario and marking the company's first expansion beyond Australia. The move follows growing North American demand for Kablamo's cloud-native digital product development and AI data platform work, capabilities built across a decade of delivering for Australian enterprises and government agencies. ## Why Canada, why now The Waterloo region is home to the University of Waterloo and one of the most concentrated technology talent pools in North America. For Kablamo, it was the right cultural and technical fit. Allan Waddell, co-CEO and founder, said: > "The Waterloo region is widely considered one of the fastest, if not the fastest, growing tech hubs in North America. It's the right fit for our culture and we believe we'll be bringing fresh learnings around digital product development, DevOps and agile while simultaneously being exposed to different approaches that work in this geography." ## What Kablamo brings to Canada Kablamo has launched a bank, expanded an online mortgage broker's AWS capabilities, and modernised a national broadcaster's archives, content that has been processed or downloaded more than two billion times. That track record in fintech, media, and emergency services is directly transferable to Canadian enterprise clients. Tobias Dyhrberg, Kablamo's Canada lead, said: > "Canadian firms are looking for similar responses to their needs and challenges. The decision to launch in Canada is testament to the technology industry in Ontario and the strong demand for the kind of AI, cloud-native software development and data management solutions that the team develops." ## Local talent, global knowledge Kablamo will hire locally in Canada while continuing to draw on its Australian engineering team, building a genuinely cross-Pacific delivery capability rather than simply planting a flag. *Originally covered by iTWire (Kenn Anthony Mendoza).* --- ### Kablamo wins AWS Global Public Sector Award for Most Innovative AI and ML Solution URL: https://www.kablamo.com.au/news/kablamo-aws-most-innovative-ai-ml Date: 2021-06-16 We're proud to announce that Kablamo has won the 2021 AWS Global Public Sector Partners Award for Most Innovative AI and ML Solution. The award recognises our work with the Department of Environment, Land, Water and Planning (DELWP) Victoria, building a fully scalable, future-proof cloud platform for performing bushfire risk assessments at scale. It's the same foundational work that became Firestory. Allan Waddell, Co-CEO and founder of Kablamo, said: > "Waking up to news like this has left me stunned. Global recognition for any Australian company is a big deal to me. This is a special moment and another crazy big step for Kablamo. Proud of the team, proud of all the hard work." Sandy Carter, Vice President of AWS Worldwide Public Sector Partners and Programs, said award winners including Kablamo are "essential in driving innovation, accelerating digital transformation, and delivering results for our AWS customers, and in helping public sector customers achieve their mission." ## What we built The platform integrates disparate data streams (satellite imagery, weather data, historical fire records, ground sensor feeds) into a single decision-making environment for firefighting agencies. Engineers spent over a year embedded with firefighters to understand the actual workflows before writing the first line of production code. As our team said at the time: the goal was integrating a vast amount of disparate data flows into a single, user-friendly platform that could handle near-limitless data, and doing it in a way that let people on the ground do their jobs faster. ## What it means This is the first time an Australian company has won in this category at the AWS Global Public Sector Partner Awards. Being recognised alongside Palantir and Deloitte speaks to the calibre of the work Australian engineers can do when given the right problem to solve. The technology we built for DELWP became the foundation for Firestory, now deployed with the NSW Rural Fire Service, where it has tracked over 15,000 fire incidents with 100% uptime across continuous production deployments. **Media coverage:** [Information Age](https://ia.acs.org.au/article/2021/australian-ai-firefighting-innovation-wins-big.html) · [Silicon Angle](https://siliconangle.com/2021/06/23/aws-event-acknowledges-disruption-caused-covid-19-honors-companies-creating-technology-benefit-humanity-awspublicsectorawards/) · [ARN](https://www.arnnet.com.au/article/689123/kablamo-datacom-rep-nz-aws-global-public-sector-partner-awards-2021/) --- ### Kablamo appoints Andrew McDowell as Geospatial Lead URL: https://www.kablamo.com.au/news/kablamo-taps-mcdowell-geospatial Date: 2021-03-16 Kablamo has appointed Andrew McDowell as its first dedicated Geospatial Technology Lead, a hire that directly supports the company's work building Firestory, Australia's AI-powered bushfire intelligence platform. McDowell joins from Propeller Aero, where he led development of the company's widely used geospatial mapping tool. He previously held engineering roles at Mi9, Pace, Asidua, and NICS Business Services, and holds a Bachelor of Engineering from Queen's University Belfast. ## Filling a critical gap Angus Dorney, co-CEO, explained the strategic thinking behind the hire: > "We believe that many opportunities to apply geo-spatial technology to many pressing problems have fallen into the space between government and the private sector. Andy is a key hire to help us address these opportunities and make a difference. He has pioneered the latest technical advancements in the space, and also understands how important it is to integrate technology into an amazing user experience." ## Maps as a decision-making tool For Firestory, geospatial capability isn't a feature; it's the foundation. Incident controllers and fire behaviour analysts need to read fire events in real time, with every relevant data stream overlaid in a form they can act on. Allan Waddell, co-CEO and founder, described what that demands: > "Technology will only work if it delivers what the people on the frontline actually need. A very clear part of this need is understanding fires as they happen in real time as comprehensively as possible." McDowell is clear on what that means in practice: > "With the firefighting initiative, basically any data that can go on a map should go on a map. What's interesting is marrying the mapping tech with great user experience which will let the data be truly valuable and actionable. We're going to turn up the volume on mapping, 3D experiences, virtual reality and gamification, pushing maps beyond traditional bounds to understand data in new ways." McDowell now leads Kablamo's geospatial practice, bringing spatial intelligence capabilities to both Firestory and the company's broader client work. *Originally covered by ITWire.* --- ### The Human Ethics of Artificial Intelligence URL: https://www.kablamo.com.au/news/kablamo-ethics-of-ai Date: 2018-09-11 Author: Allan Waddell Remember those three laws of robotics penned by Isaac Asimov? As far back as 1942, we were wrestling with the ethical implications of thinking machines. We are rapidly approaching the intersection of silicon and cognition, and it is more important than ever that we update Asimov's laws to ensure that humans are the beneficiaries, not the victims, of artificial intelligence. ## The empathy gap Human intelligence is tempered with human empathy. When a doctor delivers a difficult diagnosis, they consider not just the clinical facts but the person receiving them: their fears, their support network, their capacity to process the information. AI systems optimised purely for accuracy or efficiency have no such constraint. They produce the statistically optimal output without any model of what it means to receive it. In low-stakes contexts, this is fine. In high-stakes ones (healthcare, justice, welfare) it can cause real harm. ## Where the risk is real The most consequential AI deployments are often the least visible. Recidivism prediction tools that inform sentencing. Credit scoring systems that determine access to housing. Content moderation algorithms that shape what billions of people see. These systems embed value judgements (about risk, about fairness, about who deserves what) without the transparency that would allow those judgements to be challenged. The ethics of AI isn't an abstract philosophical problem. It's a practical question about who designs these systems, what objectives they're optimised for, and who bears the consequences when they're wrong. ## What responsible AI practice looks like At Kablamo, we've developed a set of principles that guide how we build AI systems for clients: - **Explainability**: if a system makes a decision that affects someone, they should be able to understand why - **Accountability**: there must always be a human who is responsible for the system's outputs - **Reversibility**: consequential AI decisions should be contestable and reversible - **Diversity in design**: the people building these systems need to represent the people they affect Intelligence without ethics is not just dangerous. It's not intelligence at all. It's optimisation without wisdom. *Originally published on the Kablamo blog.* --- ## Recent Blog Posts ### Where the work goes when the code writes itself URL: https://www.kablamo.com.au/blog/where-the-work-goes-when-the-code-writes-itself Date: 2026-05-18 Author: Allan Waddell Most descriptions of how AI will change software development do not describe software development. They describe coding. The two are not the same, and the distinction is now the most important one a technology leader can hold in their head. Coding is the stage where intent becomes source. The software development lifecycle, the SDLC in the older acronym, is everything around it. It includes the discovery work that turns a vague business problem into a tractable one. It includes the specification work that turns a tractable problem into something engineers can build. It includes the integration, review, and validation work that turns built code into deployable code. And it includes the operation, monitoring, and feedback work that turns deployed code back into the next problem. Coding has always been one stage among many. The reason we came to conflate it with the whole is that, for forty years, it was where the cost lived. That has changed. The interesting question for a leadership team is not whether AI writes code well enough. By now, in the contexts where it works, it plainly does. The question is what the SDLC looks like when the most expensive stage stops being the most expensive. ## The shape of the lifecycle is not the shape of the ceremonies Before getting to the changes, it helps to be precise about what is changing. The phrase "the SDLC" has come to mean several different things at once, and conflating them produces sloppy thinking. In the most literal sense, the SDLC is a sequence of value transformations. A question becomes a brief. A brief becomes a specification. A specification becomes a working system. A working system becomes a deployment. A deployment becomes telemetry, and telemetry becomes the next question. Each arrow is real work. It consumes time, judgement, and often political capital. In a looser sense, "the SDLC" has come to mean the ceremonies that surround those transformations. Standups, refinement sessions, sprint reviews, change advisory boards, post-incident reviews. These are not the lifecycle. They are scaffolding put up to manage the lifecycle, and the scaffolding is often mistaken for the building. The distinction matters because AI is doing very different things to each. It is collapsing several of the transformations to near-zero cost. It is leaving the ceremonies more or less untouched. Many organisations now have ceremonies that consume more elapsed time than the work the ceremonies were invented to coordinate. That is a kind of operational dissonance, and it will resolve itself, one way or another, in the next two to three years. ## What collapses, what survives, what emerges If you map AI's effect onto the transformations rather than the ceremonies, three things become visible. A handful of stages collapse. Translating a clear specification into source code is now closer to a few minutes than a few weeks. Writing a first draft of a test suite. Generating boilerplate for a new service. Producing migration scripts. Drafting API clients from upstream schemas. These are still genuine engineering activities, but their unit cost has fallen by something between one and two orders of magnitude. So has the cost of producing the artefacts adjacent to code. Changelogs, release notes, runbook drafts, infrastructure-as-code scaffolding, documentation that actually reflects the code. None of these were the most important parts of building software. They were simply the most laborious. Some stages are largely unchanged, and the reasons are worth being honest about. Negotiating between two product owners with incompatible mental models of a feature is not a token-prediction problem. Deciding whether a regulator will accept a particular interpretation of a data-residency clause is not a token-prediction problem. Reading a customer's face during a discovery interview is not a token-prediction problem. The parts of the SDLC that involve adversarial intent, irreducible ambiguity, or social judgement are doing more or less what they did before. They will continue to. The most interesting category is the stages that emerge. This is work that did not have a name a few years ago because the cost of doing it was prohibitive. Continuous evaluation of model outputs against ground truth. Maintenance of structured specifications that are themselves executable. Capture of decision context in a form that downstream automation can read. The deliberate cultivation of feedback loops so that telemetry drives specification, not just informs it. These were always good ideas. They are now affordable. ## The constraint moves upstream When you compose those three movements, a clean pattern appears. The bottleneck of the lifecycle has moved upstream, away from the keyboard and back toward the conversation. The expensive stage is no longer turning a specification into code. It is producing a specification good enough that the resulting code is the right code. The useful way to think about what a specification actually contains is as a set of decisions. A working system, viewed from one angle, is a long sequence of decisions that someone, at some point, made on its behalf. What counts as a valid order. Which customer states allow which transitions. What the system should do when an upstream service is degraded but not down. Most of these decisions live in the heads of three or four people. Some live in code as conditional logic, which is to say they live in code as artefacts of the moment they were written and are difficult to recover later. A few live in policy documents that nobody reads. The work that has moved upstream is not, mostly, specifying features. It is surfacing those decisions, naming them, and capturing them in a form precise enough that downstream automation can act on them without re-deriving them every time. Teams that find real traction with AI in the lifecycle usually stop arguing about what to build and start arguing about which decisions the thing they are building is meant to make. This sounds like a return to the waterfall era, but it is not. The specifications that work in this new regime are not two-hundred-page documents written before a line of code is touched. They are smaller, structured artefacts. A few paragraphs. A decision record. A set of worked examples that can be revised in tight loops against working software. The difference is that the specification is now the thing humans spend their time on, and the code is, to a first approximation, a compiled output of it. Anyone who has watched a strong engineering team work with AI tools recognises the pattern. The senior engineer spends almost no time typing. They spend their time interrogating the problem, articulating the constraints, naming the failure modes, and reading the diff. They reach the hard part of the problem faster than they used to, because the baseline functionality is no longer where the time goes. The shift looks small from the outside. It is structurally enormous. ## What this means for where to invest For an executive sponsor, the practical question is what to fund. The honest answer is, not more coding capacity. The places where the marginal dollar now produces disproportionate return are unglamorous, and several of them sit outside the traditional engineering budget line. The first is the capability to specify decisions. The practice of writing down the decisions a system is supposed to make, in a form precise enough that they can be checked. In most organisations this work is currently done verbally, in meetings, and is forgotten within a quarter. The decisions get re-derived every time a new engineer joins the team, with the predictable result that they slowly drift, and the drift goes unnoticed until the system does something embarrassing in production. Treating decisions as artefacts, with owners and lifecycles, is closer to a librarianship problem than an engineering one. It pays back almost immediately. The second is evaluation infrastructure. The boring plumbing that lets a team know, on a continuous basis, whether their system is doing what it is meant to do. Ground-truth datasets. Regression suites that survive contact with production traffic. The operational discipline to run them. Organisations that have invested here are pulling away from the rest of the field in a way that is becoming hard to disguise. The third is the institutional memory behind the decisions. The why behind the what. The first investment captures what the system decides. This one captures why the team decided to build it that way. AI systems are extraordinarily good at executing on context, and pitifully bad at recovering context that was never written down. Companies that capture decisions, constraints, and trade-offs in machine-readable form will compound. Companies that keep those things in the heads of three senior people will discover, on the day those people leave, what they actually lost. None of these are model purchases. None of them are platform licences. They are organisational investments, and they look more like a quiet build-up of capability than a launch. ## What this means for how to build it For a technical leader, the corresponding question is what the implementation looks like. A few principles are emerging from the teams that are getting this right. Treat the lifecycle as state, not procedure. A modern SDLC is best understood as a long-running workflow with persistent state. What stage each piece of work is in. What artefacts exist at that stage. What gates have been passed. State can be inspected, queried, and reasoned about by other software. Procedure cannot. Treat agents as services, not assistants. The useful unit is not a chat window attached to a developer. It is a well-scoped, well-instrumented service that performs a specific transformation in the lifecycle. Drafting a specification from a discovery transcript. Generating a test plan from a specification. Producing a runbook from an incident timeline. Services have inputs, outputs, telemetry, and SLAs. Assistants have moods. Treat evaluation as a first-class artefact, not an afterthought. The hardest discipline to build is the habit of asking, every time a new automation is introduced, how will we know when it stops working? Teams that answer this well end up with infrastructure that resembles a small internal observability platform. Teams that answer it badly end up with confident-sounding outputs and no way to detect drift. ## What this looks like when you actually build it These principles are easier to write down than they are to live with, so it is worth describing what they look like in a real system. We have spent the last year building one. A few of the patterns are non-obvious until you have made the wrong choices once or twice. The first is that stages have to be enums in a database, not headings in a deck. Every piece of work in our platform moves through a defined sequence of stages, from scope and planning through to implementation and operation. Those stages are first-class values in the schema, with constraints on which transitions are legal. The effect is that the question "where is this work up to" is a query, not a meeting. It also means that any agent in the system can reason about the state of any program without asking a human, which sounds like a small thing until you realise it is the difference between automation and theatre. The second is that every agent is a service with a manifest. Each one declares its capabilities, its tools, its dependencies, and the endpoints it exposes. New agents do not get bolted on. They get registered. That is more work upfront than a one-shot integration, but it is the only structure that survives the second year, when you have eight agents instead of three and you still need to know which one is responsible for what. The third is that every model call goes through a single funnel. Not just logged for debugging, but routed through one function that records the prompt, the response, the model, the cost, and the latency, and feeds them into an evaluation pipeline. The reason is unglamorous and important. The only way to know whether an agent is getting better or worse over time is to have a corpus of its past behaviour to compare against. Teams that skip this step typically discover, six months in, that they have a fleet of agents and no way to tell which ones are decaying. None of this is exotic. It is the application of patterns engineering teams have used for decades, applied to a workload that did not exist five years ago. The interesting thing is that the discipline required is mostly old, and the payoff is mostly new. ## A note on overshoot Cycles like this overshoot. There will be a period, and we are arguably in it, during which the value of AI in the SDLC is overstated, the failure modes are understated, and the operational maturity required to deploy these systems safely is treated as a detail. Most organisations will buy too much, integrate too quickly, and discover that the cost of cleaning up an unmaintainable agent estate is comparable to the cost of cleaning up an unmaintainable microservice estate, which is to say, considerable. The deeper failure mode is more interesting than the obvious one. Most organisations are still running the SDLC they had, with AI bolted onto it. The teams that pull ahead will be the ones running an SDLC built around AI. The distinction looks semantic until you have tried both. One is a faster version of what you used to do. The other is a different thing. The teams that come out of the next three years with a structural advantage will not be the ones who adopted fastest. They will be the ones who understood, earlier than their competitors, that the work has moved. The interesting questions are upstream. The work is in the decisions, the evaluation, and the memory. The code, finally, is the easy part. --- ### Building Business of AI, Not Just with AI URL: https://www.kablamo.com.au/blog/building-business-of-ai-not-just-with-ai Date: 2026-04-04 Author: Allan Waddell Every enterprise I talk to has an AI strategy. Most of them are the same strategy. Add a copilot here. Automate a workflow there. Stand up a centre of excellence. Measure cost savings. Report to the board that AI adoption is underway. It is underway. And it is not enough. The companies that will define the next decade are not the ones adding AI to their existing business. They are the ones rebuilding their business around AI as a core operating capability. The difference between those two things is the difference between installing solar panels and redesigning the grid. ## The distinction that matters Most organisations are still asking the wrong question. They ask: "How can we use AI in our business?" The right question is: "How do we become a business *of* AI?" The difference is not semantic. A business *with* AI bolts intelligence onto existing processes. It adds a chatbot to customer service. It automates a report that someone used to write by hand. It treats AI as a feature, owned by the IT department, measured by cost reduction. The gains are real but incremental, and they plateau quickly. A business *of* AI is something else entirely. It rebuilds its operating model around intelligence as a core capability. It does not automate existing workflows. It asks which workflows should exist at all when the cost of intelligence approaches zero. It treats data not as a byproduct of operations but as the fuel for a compounding system where each new use case makes every other use case smarter. The companies that will dominate the next decade are not adding AI to their processes. They are rebuilding around it. ## What changed in the last twelve months To understand why this matters now, you have to understand what changed. And what changed is not one thing but three things happening at once. ### The models crossed a quality threshold that engineers respect Late 2025 was the turning point. When the creators of Redis and Python began publicly using AI coding tools, something shifted in the engineering culture. Before that moment, senior engineers could dismiss AI code generation as a toy. After it, dismissal became harder to defend. At one organisation I am familiar with, AI-assisted commits now account for 40 to 60 per cent of code written. Their QA function went from a full team to two people. Production incident rates held steady. Claude's trajectory tells the story in compressed form. Anthropic released Claude Opus 4 in May 2025, establishing a new frontier in coding and agentic capability. Opus 4.1 followed in August as a precision update for real-world engineering tasks. By November, Opus 4.5 had reclaimed the coding benchmark lead with 80.9 per cent on SWE-bench Verified. With the release of Opus 4.6 in February 2026, the model could sustain autonomous work for over fourteen hours. Long enough that a team of sixteen Opus 4.6 agents wrote a C compiler in Rust from scratch, one capable of compiling the Linux kernel. Google's Gemini followed a parallel arc: Gemini 3 launched with state-of-the-art reasoning, Gemini 3.1 Pro arrived in February 2026 leading on twelve of eighteen tracked benchmarks, and the pricing (two dollars per million input tokens) made frontier intelligence accessible at commodity economics. This is not a hardware refresh. It is a phase change. The models are now good enough, cheap enough and reliable enough that the binding constraint on enterprise AI has moved decisively from capability to organisation. ### The protocol layer matured The Model Context Protocol (MCP) went from Anthropic's internal experiment to what Nvidia's Jensen Huang called a technology that "completely revolutionised the agentic AI landscape." Google announced fully managed MCP servers across BigQuery, Compute Engine, Kubernetes Engine and Maps. Microsoft embedded Claude in Microsoft 365 Copilot. The broader signals confirm it: OpenAI's recent funding round locked AWS as the exclusive distributor of its Frontier agent platform, a structural bet that agentic AI moves from experiment to enterprise infrastructure this year. The significance is not the protocol itself but what it enables: a standard way for AI agents to discover and use tools. Agents can now operate across enterprise systems without bespoke integration for each one. This is the moment the AI ecosystem acquired something like the composability that made the web powerful. A single agent can now query your data warehouse, check your calendar, draft a message in Slack and file a Jira ticket. Not because someone wrote code for each of those integrations, but because the tools expose themselves through a common protocol that the agent can discover at runtime. ### Australia specifically reached an inflection The [Anthropic Economic Index](https://www.anthropic.com/research/how-australia-uses-claude), released this week, shows Australia using Claude at more than four times the rate its population would suggest. New South Wales and Victoria account for nearly 70 per cent of national adoption, driven not by mining wealth or government spend but by the concentration of finance, professional services and technology workers in Sydney and Melbourne. Australian users are spreading their usage across a broader range of tasks than the global average. Less coding, more management, administration and professional communication. The Australian government has now signed a memorandum of understanding with Anthropic on AI safety research and economic data tracking, with Dario Amodei meeting the Prime Minister in Canberra. This is not a technology announcement. It is a structural signal that AI adoption in Australian enterprise has crossed the point where government considers it a matter of economic policy. ## The Headless Enterprise: a pattern for building *of* AI If the technology problem is largely solved, what remains is architecture. Not just software architecture, but the architecture of how a business operates. I want to describe a pattern I have been seeing emerge in organisations that are making the shift well. I am calling it the Headless Enterprise, borrowing the term from the headless CMS concept that reshaped web development a decade ago. ### The original headless insight The headless CMS separated content from presentation. Instead of a monolithic system that managed both what was stored and how it was displayed, the headless approach created an API-first content layer that any frontend could consume. This separation of concerns unlocked an explosion of innovation in digital experience delivery. The Headless Enterprise applies the same principle to CRM, ERP and every other enterprise system that has traditionally been a monolith combining data, logic and interface into a single, tightly coupled package. ### Why ERP and CRM are ripe for decomposition We [wrote about ERP hostageware](/blog/erp-is-dead-long-live-erp) back in 2018. The problems we identified then (cumbersome implementations, glacial update cycles, vendor lock-in so severe we [called it Stockholm Syndrome](/blog/in-erp-no-one-can-hear-you-scream)) have not gone away. They have intensified. The ERP vendor that sued customers for connecting Salesforce to their data is still in business. The average enterprise still runs core processes on systems designed when video rental stores existed. But something fundamental has changed. In 2018, decomposing a monolithic ERP was a multi-year programme that required building custom integrations for every system that needed to talk to every other system. The cost was prohibitive and the risk was enormous. In 2026, with MCP-compatible agents that can discover and orchestrate tools at runtime, the economics of decomposition have shifted radically. ### The pattern The Headless Enterprise pattern has four layers: **The Intelligence Layer** sits at the centre. This is not a single model but a coordination layer: an orchestrator that routes decisions to the appropriate combination of models, tools and human reviewers. It maintains context across interactions and compounds learning over time. Every business decision that flows through the intelligence layer makes the layer smarter, which makes the next decision better. This is the compounding return that distinguishes a business *of* AI from a business *with* AI. **The Data Layer** treats data as a product, not a byproduct. In a traditional ERP, data is locked inside the application. In the Headless Enterprise, data is exposed through APIs that any system (including AI agents) can consume. The data layer includes not just transactional records but the semantic context that makes those records meaningful. What a customer relationship actually looks like. What a project's real status is. What the second-order effects of a decision might be. **The Capability Layer** replaces monolithic applications with composable capabilities. Instead of "our CRM" or "our ERP," the organisation assembles capabilities (customer relationship management, resource planning, financial control, people management) from a mix of best-of-breed services, custom-built components and AI agents. Each capability exposes itself through MCP or equivalent protocols. Each can be replaced, upgraded or augmented independently. **The Experience Layer** is where humans interact with the system, but it is no longer the only layer that matters. In a traditional enterprise, the UI *is* the application. In the Headless Enterprise, the experience layer is one of several consumers of the intelligence and data layers. An AI agent scheduling a meeting, processing an invoice or triaging a support ticket is also a consumer. The experience layer becomes thinner and more adaptive. It asks the intelligence layer what to show, rather than hardcoding business logic into forms and workflows. ### An example in practice Consider what this looks like for a professional services firm, a pattern I have been observing at close range. In the traditional model, the firm runs a CRM for client relationships, a resource management tool for staffing, a project management system for delivery and a finance system for billing. Each is a separate application with its own data model, its own interface and its own update cycle. When a partner wants to know whether they can take on a new engagement, they need to check the CRM for the client history, the resource system for team availability, the project system for current commitments and the finance system for budget constraints. In practice, they call three people and wait two days. In the Headless Enterprise, the partner asks a question in natural language. An orchestrating agent queries the data layer across all four domains through MCP-compatible interfaces, synthesises the result and presents a recommendation. The reasoning is exposed, the confidence levels explicit, and the human override always available. The agent does not replace any of the underlying systems. It replaces the *coupling* between them, which was always the real problem. At Kablamo, we have been building exactly this kind of system for our own operations. Our internal agents, built on Claude and orchestrated through MCP, span CRM, resourcing, project management, content operations, sales intelligence and strategic account planning. They are not separate tools bolted onto existing processes. They are the operational fabric of the business, each one making every other one more effective because they share a common intelligence and data layer. The result is not incremental efficiency. It is a qualitatively different way of operating. A partner preparing for a client meeting gets a briefing that synthesises CRM data, recent project delivery metrics, competitive intelligence and relevant case studies. Assembled in minutes, not days. Improving in quality with every interaction because the system learns what a good briefing looks like. ## The adoption paradox and the governance gap If this architecture is sound, and I believe it is, why is adoption uneven? The answer is captured in an observation from that Melbourne roundtable: there is an inverse relationship between a person's skill in any discipline and their willingness to use AI to help with that discipline. A senior engineer who uses Claude to plan a holiday will hold it to a completely different standard the moment it touches their codebase. The more someone has invested in mastering a domain, the higher the bar they set. This is not irrational. It is a reasonable response to uncertainty about reliability. But it creates a specific problem for organisations running top-down transformation programmes, because the people they need to lead adoption are the people most likely to resist it. The organisations making progress are the ones that focus on individual benefit rather than business benefit. People adopt AI when it helps *them*, not when it helps the organisation. The personal tipping point cannot be manufactured. It has to be experienced. And then there is governance. One participant at the Melbourne gathering was running sixteen personal AI agents alongside their daily work. Another had a dedicated Slack channel for bots, quarantined from human channels. A third raised the security implications: agents can interact with each other in ways that create vulnerabilities nobody anticipated. The analogy the room settled on was shadow IT. Every department building its own Access database in the 1990s, until one critical process broke when the person who built it left. Agent proliferation is the same pattern at higher speed and higher stakes. The Headless Enterprise pattern addresses this directly, because centralising the intelligence and data layers creates natural governance boundaries. Agents operate within a framework that controls what data they can access, what actions they can take and when a human must be in the loop. This is not governance imposed after the fact. It is governance built into the architecture. ## The measurement problem When the conversation at these gatherings turns to ROI, something uncomfortable invariably surfaces. Most organisations have committed to AI efficiency targets. Almost none have a baseline to measure against. The board wants 50 per cent productivity improvement. Engineering is deploying tools. But when the review comes around, nobody can demonstrate the gain, even when the team has genuinely become more productive, because the measurement framework does not exist. The efficiency that does materialise tends to create new demand rather than reduce cost. Build software faster and you generate more customer requests. The gain is real and invisible at the same time. The [Anthropic Economic Index](https://www.anthropic.com/research/economic-index-march-2026-report) provides the first large-scale empirical framework for understanding these dynamics. Its finding that AI usage leans 57 per cent toward augmentation and 43 per cent toward automation suggests the immediate economic impact is more about making existing workers more capable than about replacing them. More experienced users attempt higher-value tasks and are more likely to get successful outcomes, a learning curve that rewards sustained investment in adoption. For Australian enterprises specifically, the Index reveals something instructive: the country's usage pattern skews toward management, administration and professional communication rather than pure coding. This suggests that Australian businesses are further along in discovering AI's value beyond software engineering. Exactly the kind of broad-based adoption that distinguishes a business *of* AI from a business that has merely given its developers a coding assistant. ## The companies that will not survive The sharpest insight from the Melbourne conversation came when someone pointed out that many companies simply do not need to exist anymore. Train companies did not become airlines. Traditional retailers did not build the winning online stores. The people who understood the old model best were often the least able to let go of it. One organisation at the table has a board mandate to reduce headcount by 50 per cent within five years. The first five per cent is straightforward. The next fifteen requires genuine transformation. The last thirty requires rebuilding the business around capabilities that do not exist at scale yet. This is the hard part that the tipping point reveals. The technology works. The protocols are maturing. The economics are favourable. The intelligence is available at commodity pricing. What remains is the organisational will to rebuild. Not to bolt AI onto the side of the existing business, but to reconstruct the business around intelligence as its core operating principle. The Headless Enterprise is one architectural pattern for doing this. MCP and its successors provide the protocol layer. The current generation of models (Claude Opus 4.6, Gemini 3.1 Pro and their forthcoming iterations) provide the intelligence. The Australian market, with its high adoption rates, diverse usage patterns and emerging government partnership framework, provides a context that is as favourable as any in the world. The question is not whether this transformation will happen. It is whether you will be the one doing the transforming, or whether you will be transformed by someone else. --- *The Kablamo AI Round Table is a private forum for technology leaders working through real problems in AI adoption. The next session will be held later in 2026. If you would like to participate, [reach out](/contact).* --- ### What breaks when you apply AI development patterns to a codebase nobody fully understands URL: https://www.kablamo.com.au/blog/ai-patterns-legacy-codebase Date: 2026-03-19 Author: Allan Waddell Thoughtworks recently published a useful series on AI-assisted development through Martin Fowler's site. [Knowledge priming](https://martinfowler.com/articles/reduce-friction-ai/knowledge-priming.html), [context anchoring](https://martinfowler.com/articles/reduce-friction-ai/context-anchoring.html), [design-first collaboration](https://martinfowler.com/articles/reduce-friction-ai/design-first-collaboration.html). Worth reading. Also written for a codebase that knows what it is. Most Australian enterprises don't have that codebase. One organisation we work with has over a thousand production systems. Average age: five to seven years. Average engineer tenure: shorter than that. The software is being maintained by people who didn't write it. In some cases, by engineers who were in high school when the original architectural decisions were made. Nobody is embarrassed about this. It is simply the condition of having been in business long enough. So when you sit down to apply these patterns to a system like that, things break in specific and predictable ways. Here is what we have learned. ## Knowledge priming hits a wall immediately The premise of knowledge priming is that you create versioned context files (architecture overview, naming conventions, anti-patterns) and load them before each session. The problem is that nobody has written this down. Or what has been written down describes a system that no longer exists. Or it describes what the architect intended, not what the developers actually built. The first time a team tries to build a priming document on a legacy system, they discover the archaeology project they are actually in. This is valuable. It is also not what anyone planned for in the sprint. What works better: build the priming document from the tests, not the documentation. If the codebase has reasonable test coverage, the tests describe the actual behaviour as it exists today. Feed the model the test suite and ask it to generate the priming document from there. The result is grounded in what the system does rather than what someone hoped it would do. ## Context anchoring goes from productivity tool to survival mechanism In a well-understood codebase, keeping a context anchor is a nice habit. In a legacy system, it is essential. Without it, every new session starts with the model defaulting to generic patterns from its training data, and you spend the first half hour undoing decisions that contradict things the team agreed to last week. More importantly: in a legacy system, the reasoning behind architectural decisions often exists only in the head of one or two senior engineers. When those engineers leave, the reasoning leaves with them. The codebase becomes progressively more fragile as subsequent decisions are made without it. A context anchor that captures the why behind legacy decisions, even retrospectively inferred from the code, is a form of institutional memory the organisation has never had before. That is worth treating seriously. ## Design-first conversation becomes a diagnosis The original pattern is about aligning on design before touching implementation. In a legacy context, the design conversation tends to surface something uncomfortable: nobody in the room has a coherent mental model of the system they are about to modify. This is actually the most valuable thing the pattern does in a legacy context. The model will find inconsistencies the team has been stepping around for years. The discipline is to stay in that conversation rather than rush to implementation once it gets awkward. The teams that have done this well expected the investment phase to be longer. They planned for understanding before productivity. The teams that struggled expected output from the first sprint and got frustrated when the early sessions produced more questions than code. That frustration is information. It is telling you something about the system that was always true and that you were not previously equipped to see. InfoQ's piece on [the oil and water moment in AI architecture](https://www.infoq.com/articles/oil-water-moment-ai-architecture/) frames this well: deterministic legacy systems and non-deterministic AI behaviour create a genuine architectural mismatch that cannot be papered over. The patterns that work are the ones that acknowledge the mismatch and work around it rather than pretending the codebase is something it is not. --- ### Non-engineers are in your codebase now. Here's what actually happens. URL: https://www.kablamo.com.au/blog/non-engineers-in-your-codebase Date: 2026-03-19 Author: Allan Waddell The use case seemed modest. A major Australian retailer started issuing AI coding tool licences to non-engineering staff. Marketing analysts. Purchasing managers. The idea was simple: let them ask questions about the codebase in plain English, reduce the volume of interruptions landing on engineering teams. How does the search ranking work? What factors drive product recommendations? Why does the price for this SKU display differently in two places? The interruption volume dropped. That was expected. Everything else was not. The first surprise was that marketing staff started finding inconsistencies the engineering team had either not noticed or had quietly parked. When an analyst can ask the codebase why two product categories have different pricing logic and get a coherent answer in seconds, they ask. When the answer is "because these two features were built three years apart by different teams and were never reconciled," they escalate. Several issues surfaced this way that had existed for years without anyone on the business side having the language to raise them precisely. The second surprise was better requirements. Purchasing managers who could inspect the logic behind inventory alerting wrote sharper briefs for changes to that logic. They knew what the system already did. They knew what they were actually asking for. The clarification cycle between business and engineering shortened significantly. Neither of these was in the business case. Then the things that did not go to plan. The assumption that non-engineers would only read and not write did not hold. Some staff members, having understood the system well enough to describe a change in plain English, asked the model to generate the code. Some of them submitted it as pull requests. The review process caught most of it, but it created a question the team had not worked through: what is the policy for AI-generated code submitted by someone without engineering accountability? There is also a real security surface here. An AI tool with codebase access can surface implementation details, data structures, and business logic that are commercially sensitive. Read access via a supervised AI interface is not the same as unrestricted repository access, but that distinction needs to be actively designed. Assuming it holds by default is not a governance strategy. The teams handling this well approached it as an access design problem from the start. Which systems are in scope? What can the model surface? What happens when a question reveals something the person asking it was not supposed to know? These are solvable, but they require the same rigour as any other access control decision. What is clear is that the boundary between people who understand a system and people who do not is moving. Not because non-engineers are becoming engineers. Because the tools that previously required engineering expertise to operate are becoming usable without it. The question is not whether this happens in your organisation. It is already happening. The question is whether someone is designing it. The broader shift has a name. InfoQ's work on [decentralising architectural decisions](https://www.infoq.com/news/2026/03/architecture-advice-process/) argues that architecture needs to move closer to the people doing the work, with a structured advice process rather than centralised gatekeeping. Giving non-engineers AI access to the codebase is, in practice, a step in that direction, whether it was designed as one or not. The organisations that treat it as an architecture decision tend to fare better than the ones that treat it as a tooling rollout. --- ### Geospatial Lessons for Product Managers URL: https://www.kablamo.com.au/blog/geospatial-lessons-for-product-managers Date: 2025-07-29 Author: Abby Phillips ##### **Lesson 1. The Map Isn't the Product** I started with the belief that if you have geospatial data, the goal is to put it on a map. It seemed obvious. But I’ve learned the most powerful products don't just show you where something is; they tell you what it means and what to do about it. **A Real-World Example:** I learned this lesson during a project with incredibly high stakes. Following a tragic firefighting plane crash, I was part of a team tasked with helping fire agencies make safer flight-tasking decisions. The goal was to shift the immense pressure of the go/no-go call from the pilots to the fire agencies making the tasking request My first instinct was to put the risks on a map. We started by plotting dangerous weather like wind shear (sudden, violent shifts in wind). But the more we talked to users, the more I realized we were answering the wrong question. They weren't asking, "Where is the wind shear?" but: "Is it safe for this specific helicopter to fly this mission?" ![turned on monitoring screen](https://cdn.prod.website-files.com/6555d1bced7999bb4a8b174f/6889589aaa828acebc64d6f7_photo-1526628953301-3e589a6a8b74.jpeg) Photo by Stephen Dawson on Unsplash The winning solution felt almost comically simple. It wasn't a map, but a dashboard with a clear, color-coded risk rating. Seeing 'Severe Risk' gave the decision-maker the unambiguous "No-Go" they needed in seconds. It was a powerful reminder: we aren't here to put dots on maps; we’re here to provide clarity. > **🗺️ The 'Map-First' Fallacy:** This experience now has me asking: When is a map truly the right tool? How many projects are sidetracked by 'map-first' thinking? And what game-changing, non-map visualizations are we failing to imagine? ##### **Lesson 2. Learning to Speak "Geo"** My team helped me build my mental glossary of geospatial terms, from rasters to vectors, GeoJSONs and Shape Files, netCDF, GRIB, LiDAR… the list felt endless. Learning new technical terms is hard, but I realised that I needed to get comfortable with a whole new vocabulary. Essential for understanding how to communicate with my team and deliver customer value. **Unlocking Contribution:** Learning to speak this language fundamentally changed how I could contribute. I could finally move from being a spectator to a true partner in technical conversations. I could ask more intelligent questions and better understand the trade-offs. My contribution shifted from 'Can we do this?', to providing more meaningful input like ‘What is the impact of latent data on insight accuracy, and is that an acceptable trade-off for the user?’ > **🧠 The Power of Specialists:** The most valuable asset in this journey has been having great geospatial expertise in the room. Those leaders flattened my learning curve. I learned my role was to be the chief learner and translator—bridging the gap between deep technical expertise and the user's goal. Watching the team sketch ideas that connected abstract concepts to real-world problems didn’t just accelerate my learning; it helped us build better products. ##### **Lesson 3. The Responsibility of Representing Reality** Perhaps the most important lesson is that a map isn't just a picture; it's a source of truth. People inherently trust maps. And since nearly all geospatial data is temporal, it’s a snapshot in time—one with its own expiration date, level of detail, and margin for error. If your product shows a road is open, people will try to drive on it. If it shows a property line, they’ll make financial decisions based on it. As product managers, the trust a user places in our work is a profound responsibility for any product we put out into the world. **Data vs. Perception:** This responsibility goes far beyond just having accurate data. A technically correct map can still lead a user to make a wrong decision. I saw this firsthand when experimenting with building an app tying air quality to the safety of outdoor activities. The app used an existing Air Quality Index from 1 to 10+, but I wasn’t even sure what that meant. Is 1 good or bad? If I assume 10/10 is excellent and head out for a run, am I putting myself at risk? Should I stay inside forever, or go for that hike? ![__wf_reserved_inherit](https://cdn.prod.website-files.com/6555d1bced7999bb4a8b174f/6889590723c19c598e5089b0_photo-1580207868427-f019836acf26.jpeg) Photo by Nick van den Berg on Unsplash > **🧭 The Guiding Principle:** So now, this sense of responsibility shapes the core questions I ask my team. We have to constantly challenge how our data is interpreted. The real test is to ask: Can users make informed decisions based on what we’re showing? Is this a real-time view, a forecast, or a snapshot from the past? How accurate is the data? Are we communicating anything we didn’t mean to? These answers shape user trust, usability, and the product's value. ##### **Lesson 4. Geospatial Isn't that Niche** One of the most common reactions I get when I tell other PMs I work on geospatial products is, 'Wow, that's a cool niche.' For a while, I agreed. But I’ve since learnt this is fundamentally wrong. **It's Everywhere:** Geospatial isn't a vertical industry; it's a fundamental, horizontal layer that powers the products we use everyday. Beyond obvious apps like Google Maps, the entire on-demand economy runs on geospatial data. Your Uber ride, your DoorDash delivery, the Amazon package arriving at your door. They are all orchestrated by complex geospatial systems for tracking, routing, and predicting arrival times. It’s how Strava tracks your 5k or why you can tag a café on Instagram. And it often works invisibly in the background, like the smart thermostats using your phone's location to turn on and off, your banking app flagging fraud, or the complex behavioral models that turn your location history into targeted ads that fund our free apps. > **💡 The PM Takeaway:** This reframed my entire perspective as a PM. The opportunity isn't just building dedicated 'map products,' but applying core product thinking to a fundamental layer. The real opportunity is for PMs in any domain to ask: 'How can we leverage a location component to make our product smarter, more personalized, or more efficient?' ##### **Your Turn** Every product manager working in a specialized field has that "aha!" moment when the jargon finally starts to click. For me, it was learning to "speak geo." This journey is always ongoing, and the best insights often come from sharing our experiences. So, let me ask you: What was the single most confusing concept you had to learn in your domain (geospatial or otherwise), and what made it finally make sense? --- ### The Product Owner Decision: The Make-or-Break Factor in Government Tech Projects URL: https://www.kablamo.com.au/blog/the-product-owner-decision-the-make-or-break-factor-in-government-tech-projects Date: 2025-06-18 Author: Olivia Breed In technology projects across government and emergency services, I've seen some deliver exceptional value quickly, while others drag on with a swathe of missed opportunities and a ROI hobbled by mismanaged input. The difference rarely comes down to technical complexity or budget constraints. One pattern has become crystal clear though - Product Owners can have an outsized impact on the value delivered, and the timeline it’s delivered on. Putting some forethought and effort into choosing the right person - when you’re investing potentially millions of dollars - is both a logical investment of time, and a critical task on your project planning journey. Here's what actually matters when choosing your project's product owner - and it might surprise you. ##### **#1. The Right Attitude (This trumps everything else)** **What I used to think mattered:** Deep understanding of the Product Owner role, personal experience as a user, knowledge of agile methodologies and frameworks. **What actually matters:** Boundless enthusiasm and an unrelenting drive to get things done. The best product owners I've worked with weren't necessarily the most process-oriented, and most had never done the job before. Some had never heard of Agile.  They were the ones who treated the project outcomes like their personal mission and worked as though they were truly a part of the development team - no matter what the project structure was. They genuinely cared about solving user problems, and didn’t just work within the bounds of a Jira board - they were constantly looking for ways to find value and deliver outcomes. **What to look for:** Someone who talks about the project's potential impact with genuine excitement, who asks thoughtful follow-up questions, and who brings up new ideas and connections outside of scheduled meetings. **What to avoid:** Someone who treats this as just another responsibility added to their existing workload, and a list of tasks to be done. ##### **#2: Dedicated Availability (of both the Product Owner and the relevant SMEs)** **The reality:** Your product owner needs to be genuinely available for the project - not squeezing it between existing priorities. But beyond their own time, they're also coordinating access to the entire ecosystem of inputs the project needs. Your product owner becomes the crucial bridge between: * **Development teams and end users** who understand the real problems * **Stakeholders with vision** and the people who can make it happen * **Data gatekeepers and the data scientists** who can unlock insights * **Decision makers and the users** the project is supposed to serve **The coordination reality:** For significant projects, this coordination function can easily become a significant portion of someone's role. If the product owner isn't truly available - or if the subject matter experts they need (military analysts, linguists, fire behaviour specialists, operational commanders) are constantly unavailable - you're looking at a string of hold-ups, blockers and ill-informed priorities for your development team. **What to look for:** Someone who can dedicate real time to the project and maintain momentum across competing priorities. They should proactively manage stakeholder expectations, navigate calendar coordination without becoming the bottleneck, and get key decision-makers and subject matter experts engaged when it matters most. **What to avoid:** If you HAVE to do fractional roles, I’d personally prefer to see a PO that’s split 50/50 between the project, and a user role, as opposed to a PO split 50/50 across 2 different projects. The exception, is if those 2 projects are closely intertwined (for example, 2 systems that form part of a critical workflow) - in which case, that kind of overlap could be exceptionally valuable. ##### **#3: Organisational  Influence and Credibility (The Hidden Superpower)** **The reality:** Your product will succeed or fail based on adoption by people across multiple departments and levels of seniority. Your product owner needs to be someone who: * **Has credibility across different functions** (not just in their home department) * **Can facilitate access** when you need specific expertise, data, or approvals * **Understands how decisions really get made** (beyond the formal org chart) The most successful projects I've worked on had product owners who could flick a Slack message through and arrange access to busy subject matter experts, they could schedule a meeting and the right people actually showed up, or they knew exactly which approvals were truly necessary versus bureaucratic theatre. **The network effect:** When your product owner has strong relationships, months of tedious question and answer, can compress into single conversations. When they don't, simple requests can become weeks-long approval processes. **The executive override challenge:** Here's a common scenario - a high ranking official who's funding the project appears in the final sprint with a brilliant idea for a feature they think would be valuable. The problem? The users (those who the project was actually funded to serve) have already established this feature is flashy but not valuable. Your product owner needs the credibility and backbone to advocate for user priorities in these moments. They have the context, the real-world data, and they know the actual use cases. They need to be able to respectfully but firmly stand up for their users when it matters.They won’t by any means be doing this alone - but their input will be critical, in these critical conversations. ##### **#4: Mission Motivation and Identity (Why They Care Is Why They'll Have Impact)** The people with the right attitude didn't choose their career path randomly. They've typically developed deep expertise in at least one critical area - GIS systems, counter terrorism, military affairs, operational planning, or emergency response protocols. The reason you should care about where they’ve chosen to build their career, is that this domain expertise is actually a proxy for being motivated by the mission. They care deeply about the work because they've dedicated years to mastering it. They're going to work hard to make sure the job is done well because it's not just a project to them - it's an extension of their professional identity and passion. They go home and think about this mission, and how they can better contribute to outcomes aligned with it. This domain expertise, and personal drive, often trumps formal product owner or product development training. They understand the real problems because they've lived them. They have instant credibility with end users because they've been in their shoes, and those same users probably already know how they functioned in their role - because they were good at it. **Here's the key insight:** product development should be a meaningful step in their career journey, not their entire destination. The best product owners see this role as a way to amplify their existing expertise and drive organisational impact beyond their traditional domain. ##### **Making the Investment Count** Most organisations approach product owner selection as "who's available and has some capacity." But in the government, defence and emergency services domains especially - if you're investing significant money, time, and resources in a major technology project, that casual approach undermines your entire investment. If your organisation is investing hundreds of thousands or millions of dollars in a major technology initiative, the product owner role deserves careful selection and support. **The strategic approach:** Identify your best candidates and make the product owner role attractive to them. Show how leading a successful technology initiative will: * **Expand their influence** across the organisation * **Develop new skills** in technology and change management * **Create tangible impact** they can point to in their career progression * **Build valuable relationships** across departments and levels When you frame the product owner role as a career development opportunity rather than just another assignment, you attract stronger candidates and get better outcomes. **The organisational benefit:** Investing in a great product owner doesn't just improve your current project - it develops internal capability for future technology initiatives and improves technical literacy across the organisation too. ##### **The Bottom Line** Your technology choices matter. Your development approach matters. Your budget and timeline matter. But none of that maximises value without the right person orchestrating the connection between what you're building and the people who need to use it. When you're making significant technology investments, treat the product owner decision with the strategic importance it deserves. The ROI of getting this right compounds through every subsequent decision in your project. *What's been your experience with product ownership in technology projects? What factors have you found most predictive of success?* --- ### Accelerating Nonprofit Impact: Strategic Technology Solutions for the Modern URL: https://www.kablamo.com.au/blog/aws-imagine-for-non-profit-event-2025 Date: 2025-06-11 Author: Kablamo #### **Our Journey in the Nonprofit Sector** Over the years, we've had the privilege of partnering with some of Australia's most impactful nonprofit organisations, each presenting unique challenges and opportunities: **Cerebral Palsy Alliance** * **Genomics Platform** - Sophisticated research infrastructure for breakthrough discoveries in cerebral palsy treatment and prevention, processing complex genomic data at scale. * **My Voice Library** - Digital platform empowering individuals with speech difficulties to preserve and share their unique voice, restoring dignity and agency. More details: **Cape York Partnerships** Technology solutions supporting Indigenous community development in remote Queensland, requiring cultural sensitivity and understanding of connectivity challenges. The "Pama" platform is an Australian first, transforming Indigenous Australians' lives in Money Management, Education, Health, Home Ownership, and Employment. **Black Dog Institute** Digital mental health platforms and research tools for suicide prevention and mental health awareness. This work required careful consideration of user vulnerability, privacy, and impact. Kablamo helped launch FAST, a design system supporting BDI's core applications and new product development. #### **Building on Experience, Starting Small** Successful nonprofit tech partnerships start with understanding the mission, constraints, and culture. Focused, low-risk initiatives can build confidence before larger projects. Our accelerator approach demonstrates methodology and expertise, often leading to deeper collaboration We have developed **Strategic Advisory Accelerators**—targeted, high-impact consulting engagements designed specifically to deliver immediate value whilst building foundations for future success. These fixed-price offerings enable organisations to: - Address critical challenges that may have been deprioritised during the year - Gain actionable insights within weeks rather than months - Build momentum for strategic initiatives in the new financial year - Demonstrate measurable ROI from budget allocation #### **Ready to Accelerate Your Impact?** Whether you're looking to optimise existing systems, explore new technological opportunities, or simply ensure you're making the most of your current technology investments, our Strategic Advisory Accelerators provide a risk-managed approach to technology improvement. We understand the nonprofit landscape and are committed to delivering practical solutions that recognise your unique constraints and amplify your mission impact. Please reach out to us for more details about our Strategic Advisory Accelerators for Nonprofit Impact. **Clare Burrows **[clare.burrows@kablamo.com.au](mailto:clare.burrows@kablamo.com.au) **Rochelle Pillari** [****rochelle.pillari@kablamo.com.au](mailto:rochelle.pillari@kablamo.com.au) --- ### Behind the scenes in Kablamo''s #AI Slack Channel URL: https://www.kablamo.com.au/blog/behind-the-scenes-in-kablamos-ai-slack-channel Date: 2025-06-11 Author: Dee Behan The one where folks exchange everything from AI frenzy to out-there hardware predictions. It’s everything we’re curious about, challenged by, and (regularly) poking fun at. Here’s what was discussed last week: 🤓Tested [**Google AI Edge**](https://ai.google.dev/edge)’s object detection and ended up asking, “*How does a cockatoo resemble a sheep at 65%?* 💬Commented on[**Xiaomi’s new chip**](https://www.phonearena.com/news/xiaomis-in-house-chip-has-competitive-geekbench-score_id170778). Numbers on Geekbench? Or the story of global innovation? And, China is stepping up as a player in the compute race. **🧐Debated RISC-V vs ARM**: RISC-V is open, free from licensing, and full of promise. Will Apple make the leap? One strong believer tells us that history shows they’re never afraid to piv-ohhhh-ttt. 🫨Concerns raised on [**Venice AI**](https://venice.ai/)’s uncensored claims. What does uncensored even mean here? We’re watching closely. NSFW? Is this the next step in creativity, or just marketing hooha? 🫣Uncovered a strange [**vegetative electron microscopy**](https://www.sciencealert.com/a-strange-phrase-keeps-turning-up-in-scientific-papers-but-why) phrase sneaking into academic papers. Is this a joke? Or just poor quality control in research. 💸Valuation hype chat as [**Cursor hits 1.0**](https://www.cursor.com/en/changelog/1-0) gets a $9.9 billion 🤯valuation. It has just reached version 1.0, featuring automatic code reviews from BugBot, Background agent support for everyone, Memories, and MCP One-click installs with OAuth support. Ok. 💡A low-key insight: the next wave of AI impact is as much about *hardware* as it is about *software*. Are you thinking about AI in your business? Read about our [AI Experience Offering](https://www.kablamo.com.au/ai-experience) --- ### Uncovering AI Needs When Users Don’t Know What They Need URL: https://www.kablamo.com.au/blog/uncovering-ai-needs-when-users-dont-know-what-they-need Date: 2025-05-06 Author: Dee Behan As I move deeper into AI strategy work, I’m reminded of something deceptively simple: people cannot ask for what they do not yet understand. And in the context of AI, that gap between possibility and perception is vast. This is not a failure. It is the path. To navigate it, we need more than models and infrastructure. We need something far harder to quantify: vision, trust, and a shared language to bridge the space between capability and comprehension. I used Google’s [NotebookLM](https://notebooklm.google/) to make this article into a podcast for your ears. #### The Lesson: Tools Don’t Land — Stories Do Recently, we introduced a human tool designed to enhance model performance through better quality data. The value was there. The potential was real. But we led with the how instead of the why. The result? Misalignment. Not because the technology was flawed, but because the story didn’t resonate with the people we were trying to help. The tool addressed a problem they hadn’t yet seen, let alone felt. This was the moment we pivoted (quickly) because people don’t adopt *tools.* They adopt *outcomes.* And outcomes require belief. #### The Quiet Power of Education In most organisations, AI conversations begin before clarity arrives. Leaders are asked to make choices about systems they don’t wholly speak the language of. We can see this as a gap — or we can see it as an invitation. Education isn’t a preamble to the work. It *is* the work. It creates a shared perspective. It transforms “What is this AI thing?” into “What could this unlock for us?” It prepares the soil so the tomatoes, I mean, strategy can take root. #### Listening Beneath the Ask Once understanding takes hold, the next task isn’t to respond with a feature. It’s to listen for the *unsaid.* What’s slowing you down? What do you wish you had more of — time, clarity, foresight? What do you reach for when nobody’s looking? This isn’t solutioning. This is uncovering. It’s the transition from problem-solving to problem-*finding.* And it’s where human-centred design becomes not just useful, but essential. It’s then translating an understanding of their fundamental needs into potential AI-driven solutions. #### Making the Invisible Visible Even when the right problem is found, AI can remain abstract. That’s why pilots matter, not as proof of concept but as acts of translation. A good pilot doesn’t just test a capability — it tells a story. It shows people what AI *feels* like in their world. It builds momentum by making the future touchable. #### Moving Beyond the Hype Yes, AI is everywhere. But impact lives not in hype nor headlines, but in the quiet clarity of alignment: Between what technology can do, What people need, And what the organisation is truly here to deliver. This is where return on investment lives. Not just in automation or savings, but in insight. In better decisions. In time regained and purpose restored. #### The Role I Want to Play AI is not just technical. It is deeply human. It asks us to sit at the intersection of logic and intuition, data and emotion, vision and care. This is the space I am drawn to. Where strategy is not just a roadmap but a shared imagining. Where adoption is not won by force but by trust. And where the first step is always the same: listen deeply. Because in the end, AI is not about the model. It’s about the moment it creates. When someone sees a little more clearly, acts a little more confidently, and feels a little more understood. That’s where the real intelligence lives. --- ### MOVING AT THE SPEED OF THOUGHT - Why Most Companies Fall Behind URL: https://www.kablamo.com.au/blog/moving-at-the-speed-of-thought---why-most-companies-fall-behind Date: 2025-03-24 I didn't build Kablamo to move at the industry's pace. I built it to operate at the speed of thought – where ideas transform into action without the friction of bureaucracy, pointless process, or death by committee. Most tech companies talk about agility while drowning in operational molasses. They mistake activity for achievement and confuse motion with progress. They're structurally incapable of the velocity required to lead in the AI era. Let's call it what it is: most organisations have a fundamental velocity problem. Not because their people are slow, but because their operating systems are designed for control, not speed. What kills velocity? I've seen this consistently: Consensus culture disguised as collaboration. When every decision requires universal agreement, you're not being collaborative – you're institutionalising mediocrity. At Kablamo, we don't need everyone to agree. We need the best ideas to win, regardless of who champions them. Process worship is another culprit. Companies build elaborate processes to prevent failure, then seem surprised when those same processes prevent success. They forget that every layer of approval, every mandatory checkpoint, every standardised template is a tax on velocity. In most organisations, middle management (folks like me, honestly) exists primarily to filter information, control resources, and manage access. This creates bottlenecks where ideas go to die and momentum evaporates. None of this works in the intelligence-driven economy we've entered. At Kablamo, we've built a company around what I call "intelligent velocity" – the ability to move with both speed and precision, clarity and intent. Intelligent velocity isn't about working faster; it's about removing the friction between idea and execution. It's about creating systems where momentum is the default state, not something you have to fight for. To operate with intelligent velocity requires a few fundamental changes: Decision rights push authority to the edge. The people closest to the problem make the decisions. Period. Leadership's job isn't to approve – it's to clarify context, set guardrails, then get out of the way. Trust replaces process. We hire exceptional people, then trust them to deliver exceptional outcomes. We don't micromanage the path. We focus on results, not activity metrics. Information flows without friction. In most companies, information is a form of currency, hoarded for advantage. At Kablamo, we've created systems where critical insights move without obstruction, ensuring decisions are made with complete context. This isn't just philosophy – it's embedded in how we operate every day. What happens when a company operates with intelligent velocity? Opportunities others miss become your standard work. When most firms are still writing proposals, you're already delivering solutions. While they're debating approach, you're gathering feedback on implementation. Talent gravitates to your orbit. The best people don't want to work in bureaucratic quagmires. They want environments where their ideas matter and they can see their impact immediately. Intelligent velocity becomes your strongest recruiting advantage. Clients experience the difference immediately. Nothing builds trust faster than demonstrating the ability to move from concept to execution without delay. Not recklessly, but with precision and intent. In a market saturated with similar services, velocity becomes your clearest differentiator. Building a company that moves at the speed of thought isn't accidental. It requires deliberate architecture around three core principles. First, eliminate approval chains. Most companies construct elaborate approval hierarchies, then wonder why execution is slow. Each handoff, each review, each sign-off is a potential point of failure and guaranteed delay. At Kablamo, we've replaced approval chains with clarity of intent: Leaders communicate outcomes, not methods. We're clear about what success looks like, not the specific steps to get there. Teams operate with bounded autonomy. Clear guardrails define the playing field, but within those boundaries, teams move with complete freedom. Mistakes are treated as feedback, not failure. When you eliminate fear of failure, you accelerate decision velocity exponentially. Second, design for momentum, not control. The default setting in most companies is inertia. Every action requires force to overcome organisational resistance. We've inverted this model: The default answer is "yes." Unless there's a compelling reason not to proceed, the system is designed to enable forward motion. Proactive beats reactive. We don't wait for permission or perfect information. We move, gather feedback, adjust, and keep moving. Experimentation over analysis. When facing uncertainty, we run small experiments rather than exhaustive analyses. Learning through action is faster than learning through contemplation. Third, communicate with precision and intent. Most business communication is noise masquerading as substance. It creates an illusion of productivity while wasting the scarcest resource – attention. At Kablamo: Communication is outcome-oriented. Every message, meeting, and document has a clear purpose and desired result. Clarity trumps volume. We've eliminated the corporate tendency to mistake word count for thoroughness. Right-sized communication for the decision. Small decisions get small discussions. We match the communication format to the stakes of the decision. This isn't about being terse or dismissive. It's about respecting that attention is finite and communication should create momentum, not consume it. Here's what most leaders miss: velocity isn't a bolt-on feature. You can't add it to a company designed for control and compliance. Velocity is architectural. It's designed into the operating system of your company – or it isn't there at all. Most attempts to "increase agility" fail because they treat the symptoms rather than the cause. They try to speed up existing processes rather than fundamentally reimagining how work flows through the organisation. At Kablamo, we've built velocity into our DNA from day one. Our culture doesn't just tolerate speed – it demands it. Our systems don't just allow for rapid execution – they're optimised for it. Our people don't just accept fast-paced environments – they're energised by them. In a world defined by AI, automation, and exponential technological change, velocity isn't optional – it's existential. Companies will either learn to operate at the speed of thought, or they'll become irrelevant. There's no middle ground. At Kablamo, we've made our choice. We're building a company that remains elite, fast-moving, and deeply original while scaling in ways most companies fail to. Our culture is one of curiosity, precision, and impact, where the best minds come together to solve problems that actually matter. The question isn't whether your company needs to move faster. The question is whether your company is structurally capable of the velocity required to lead. Most aren't. And that's why they'll be left behind. In this brave new era, organisations need a partner to guide them through the whirlwind of transformation. Kablamo is that partner, offering tailored strategies, seamless AI integration, and targeted training to help businesses not only adapt but thrive. By harnessing Kablamo’s expertise, companies can turn the challenges of this AI revolution into a strategic advantage, ensuring they remain agile, innovative, and ready for the future. Embrace the revolution with Kablamo and lead the charge into a redefined landscape of software engineering. --- ### X-FACTOR LEADERSHIP - The Hard Truth About Building Companies That Matter URL: https://www.kablamo.com.au/blog/x-factor-leadership---the-hard-truth-about-building-companies-that-matter Date: 2025-03-17 Author: Allan Waddell I didn't create Kablamo to be another predictable tech consultancy. I built it to shape a better tomorrow through innovation and intelligence. Within a decade, we'll be the most respected name in AI and product innovation. That's not hyperbole, it's the plan. Our culture is built on deep technical excellence, a refusal to settle for mediocrity, and a relentless commitment to creating impactful products. Guided by our values, Make, Heart, and Mind, we foster an environment where the brightest minds thrive, crafting meaningful, beautiful, and transformative solutions. Unlike competitors who focus on transactional delivery, Kablamo challenges customers to think differently, delivering outcomes that inspire and make lasting change. The foundation of this approach? X-factor leaders.**** **Forget "Good Enough" Hiring** Most companies hire whoever they can get. They settle for adequate talent and wonder why they deliver average results. We don't. At Kablamo, we hunt for X-factor individuals, the ones who redefine what's possible in their field. They're not just technically proficient; they're transformational leaders capable of building entire practices from scratch. You identify these leaders by looking beyond credentials. They have a history of exceptional outcomes. They spot opportunities others miss. They naturally attract top talent. They maintain standards that make average performers uncomfortable. And they've earned genuine respect from their industry peers.**** **Why I'm Willing to Loss-Lead on Leadership** Let's be clear: X-factor leaders require significant upfront investment. They take time to build effective teams before becoming fully billable. By traditional metrics, this looks financially reckless. But this is a deliberate strategy. I don't view these hires as expenses but as investments that yield exponential returns through team development, client trust, and market positioning. The short-term cost creates disproportionate long-term value. Most companies talk about long-term thinking but obsess over quarterly numbers. I'd rather take the short-term hit now and build something that truly matters.**** **Five Strategic Advantages of X-Factor Leadership** 1. **They Attract Better Talent, Period**. When an elite leader joins your organisation, something immediately happens: other exceptional performers take notice. Their reputation naturally attracts talent who wouldn't otherwise consider joining your company. I've seen this repeatedly, elite leaders create gravitational pull. 2. **They Eliminate the Credibility Gap**. Having an X-factor leader drive client conversations instantly transforms outcomes. They bridge technical complexity and business objectives effortlessly, creating immediate trust with decision-makers. When they speak, clients listen, no manufactured authority required.**** 3. **They Shape Markets, Not Just Products**. X-factor leaders don't merely respond to industry conversations, they create them. Their insights and thought leadership position both themselves and your organisation as industry authorities. At Kablamo, we deliver outcomes others can't, with technology others don't yet fully understand. Partners like Google, AWS, and Microsoft come to us for leadership, not just execution.**** 4. **They Reset Performance Standards**. The greatest impact comes from how X-factor leaders recalibrate the definition of "good." They demonstrate excellence, foster innovation, and provide guidance that elevates everyone around them. At Kablamo, the best ideas win, not the loudest voices or senior titles. We expect independent thinking, challenging assumptions, and solutions based on first principles.**** 5. **They Create Markets, Not Just Serve Them**. Average leaders react to trends. X-factor leaders identify untapped opportunities, developing solutions for problems clients haven't even articulated yet. Kablamo isn't here to mimic competitors, we're defining the next decade of AI, data, and business transformation, positioning ourselves as innovators rather than followers.**** **The Long-Term Payoff** X-factor leaders create sustainable value, not quick wins. They secure long-term engagements that evolve as clients encounter new challenges. They uncover market gaps that lead to new service offerings. Their credibility fosters deeper client relationships and drives growth through referrals and expanded engagements. In ten years, we won't just be consultants, we'll be market-makers.**** **The Risk: Getting It Wrong** I'm not suggesting this strategy is foolproof. A misaligned leader can damage existing teams, stall projects, harm client relationships, and negatively affect culture. The wrong hire at this level creates significantly more damage than a mid-level mistake. Careful selection aligned with company values isn't optional, it's existential.**** **The Choice: Follow or Lead** As AI and automation accelerate, companies face a simple choice: react to change or drive it. At Kablamo, we're betting on exceptional leadership, those rare X-factor individuals, to separate trend-followers from trendsetters. AI isn't just another tech trend; it's the defining platform shift of our generation, happening faster than most realise. By investing in elite leadership, even at an initial loss, we're positioning Kablamo to shape a better tomorrow through innovation and intelligence. Our values Make, Heart, and Mind, guide us as we create an environment for bright minds to thrive, crafting meaningful, beautiful, and transformative solutions. Unlike transactional competitors, we push our clients to think differently and deliver outcomes that genuinely inspire lasting change. In markets defined by constant disruption, genuine leadership is the ultimate advantage. Kablamo is that leader, guiding businesses through the transformation with strategic intelligence, targeted training, and seamless AI integration. Embrace the revolution with Kablamo and lead the charge into a redefined future. In this brave new era, organisations need a partner to guide them through the whirlwind of transformation. Kablamo is that partner, offering tailored strategies, seamless AI integration, and targeted training to help businesses not only adapt but thrive. By harnessing Kablamo’s expertise, companies can turn the challenges of this AI revolution into a strategic advantage, ensuring they remain agile, innovative, and ready for the future. Embrace the revolution with Kablamo and lead the charge into a redefined landscape of software engineering. --- ### WAKE UP WORLD - OpenAI's Operator Isn't a Tool, It's a Loaded Gun URL: https://www.kablamo.com.au/blog/wake-up-world-openais-operator-isnt-a-tool-its-a-loaded-gun Date: 2025-03-05 Author: Allan Waddell Imagine this: you hand over your bank details, your social media logins, and your daily routine to an AI that promises to make life easier. It books your dinners, chats with your mah, even handles parts of your job. Sounds like a dream, right? Not so fast. OpenAI’s Operator, launched in January 2025, is more than just a personal assistant, it’s an unchecked experiment with serious security risks. While the tech world races to embrace it, we should be asking: are we trading control of our digital lives for convenience? Our Dangerous Snooze Why isn’t everyone more concerned? Simple: we’re numb. We’re used to AI in our daily lives, Siri, Netflix suggestions, Google Maps. Operator, marketed as a $200-a-month super-assistant for ChatGPT Pro subscribers, feels like a natural extension of those tools. It books flights, orders groceries, and even handles emails. OpenAI frames it as a time-saver, and we’ve become desensitised to handing over control to Big Tech. But there are cracks in the narrative. While earlier technical glitches were noted during its launch, the hype has drowned out concerns. People assume OpenAI has it under control. The reality? This isn’t just another chatbot, it’s a tool with the *potential* to disrupt financial security, privacy, and even employment in ways we haven’t prepared for. The Tech Industry’s Rose-Tinted Glasses Industry insiders are calling Operator a revolution. MIT Technology Review praises its ability to automate digital tasks, while rivals like Anthropic and Google scramble to catch up. The selling point? Operator isn’t just responding to prompts, it’s acting on behalf of users, navigating the web, making transactions, and even posting to social media. At the core of Operator is the Computer-Using Agent, a system that interacts with websites much like a human would. Security researchers, however, are already pointing to major flaws. Alon Levin, a cybersecurity expert, warns that Operator’s ability to interact with sensitive sites makes it a prime target for exploitation. Even OpenAI acknowledges vulnerabilities, including prompt injection attacks, a method hackers use to manipulate AI into executing harmful actions. Despite these risks, the industry is treating concerns as fixable inconveniences rather than existential threats. The attitude is “patch later, profit now”, a mindset that has already caused significant harm in previous tech rollouts (think: data breaches, social media manipulation, deepfake scams). Five Reasons You Should Be Paying Attention Operator isn’t an AI tool, it’s an unregulated automation system with alarming potential for misuse. Here’s what you should be concerned about: 1. Your Sensitive Data is More Exposed Than Ever. Operator requires deep access to your personal data, credit cards, passwords, email accounts, so it can act on your behalf. OpenAI assures users that security measures are in place, but the company isn’t a bank or a cybersecurity firm. It’s a fast-moving AI startup with a mixed track record on privacy. Cybersecurity firm Chatbase has raised concerns about OpenAI’s ability to properly secure this type of information, especially with prompt injection attacks capable of tricking AI into revealing stored data. If hackers gain control over Operator, they don’t just get access to an account, they get an AI assistant with the keys to your digital life. 2. “Human-in-the-Loop” Safety? Not as Secure as It Sounds. OpenAI insists that users must approve critical actions, such as payments. TechCrunch calls this a “safety net”, but a recent report from security research group Embrace the Red warns that sophisticated cyberattacks can still bypass these checks. How? By manipulating AI interactions. If an attacker convinces Operator that a fraudulent transaction is legitimate, or worse, gets access to the user approval system itself, this so-called safeguard becomes meaningless. 3. Operator is Learning You, Too Well. Every task you give Operator makes it smarter. It’s not just helping, it’s learning your habits, preferences, and decision-making patterns. DataCamp praises this as a breakthrough in personal AI, but it also creates a security paradox: the more tailored Operator becomes to you, the more valuable (and vulnerable) your data becomes. This raises a key question: who owns this evolving profile of your behaviour? Can it be sold, analysed, or manipulated? OpenAI hasn’t provided a clear answer. 4. It Could Be Used to Impersonate You. Imagine waking up to find Operator has sent messages to your family, posted updates on X, or replied to work emails, all without your knowledge. AI-driven fraud is already on the rise, with Bit Wizards reporting a 67% increase in AI-powered phishing scams. Operator’s ability to mimic user interactions makes identity theft easier than ever. If an attacker gains access, they don’t just steal data, they steal your voice. 5. The Fraud and Disruption Potential is Off the Charts. With full web access, Operator can make purchases, create accounts, and interact with websites just like a human. OpenAI has placed rate limits and restricted access to high-risk sites (no gambling or adult content, per Amity Solutions), but attackers don’t follow rules. Security Boulevard’s analysis of emerging AI fraud highlights how easy it is to manipulate AI driven systems. Imagine cybercriminals using hijacked Operators for mass-scale phishing, misinformation campaigns, or automated fraud schemes. We’ve seen automation weaponised before, this just makes it easier. The Warning Signs Are Already Here Operator hasn’t triggered a disaster, yet. But the risks aren’t hypothetical. Prompt injection attacks (Apex Security's research team has extensively documented these vulnerabilities) are already manipulating AI into unintended actions. AI-powered identity fraud (raised by Bit-Wizards) is escalating as AI grows more advanced. Security-related delays in Operator’s launch (raised by GovInfoSecurity) suggest OpenAI is still scrambling to contain vulnerabilities. Tech history shows us that waiting for problems to materialise before acting is a losing strategy. The social media boom led to widespread misinformation, algorithmic manipulation, and privacy nightmares. Operator’s automation risks are bigger, and we have less time to react. What Needs to Happen Now It’s not enough to say “be scared.”, we need action. Users and regulators must demand transparency from OpenAI on how Operator secures sensitive data, especially in financial transactions and automation safeguards. Governments must impose stricter cybersecurity laws on AI agents like Operator before mass adoption makes regulation an afterthought. Businesses and individuals should rethink integration, convenience alone doesn’t justify the risks. Right now, the industry is moving too fast, and security isn’t keeping up. Operator is an innovation with serious potential, but if it’s rolled out irresponsibly, it could be the catalyst for the biggest AI security crisis we’ve ever seen. So no, this isn’t paranoia. It’s pattern recognition. And if history has taught us anything, it’s that ignoring these warning signs comes at a cost. In this brave new era, organisations need a partner to guide them through the whirlwind of transformation. Kablamo is that partner, offering tailored strategies, seamless AI integration, and targeted training to help businesses not only adapt but thrive. By harnessing Kablamo’s expertise, companies can turn the challenges of this AI revolution into a strategic advantage, ensuring they remain agile, innovative, and ready for the future. Embrace the revolution with Kablamo and lead the charge into a redefined landscape of software engineering. --- ### How Satellite Data and AI Can Shield Australia’s Wine Industry URL: https://www.kablamo.com.au/blog/how-satellite-data-and-ai-can-shield-australias-wine-industry Date: 2023-08-18 Author: Magdalena Kortas ## The Climate Challenge: The Intersection Of Climate Change And Wine Production Ranked as the 5th largest global wine exporter, Australia holds a prominent place in the world of wine. The Hunter Valley, Australia's oldest wine-producing region situated just a couple of hours north of Sydney, is facing a substantial challenge. According to Wine Australia's Climate Atlas, this region is anticipated to experience an **average temperature rise of 2.3 degrees Celsius over the next 50 years**. This brings unpredictable weather patterns and an escalated risk of bushfires driven by the intensifying heat. The Hunter Valley is already confronted with an increasing vulnerability to bushfires, a threat that magnifies in the face of climate change. The risk doesn't solely arise from direct fire impact. Beyond the vineyards that are directly impacted by flames, the danger comes as well from smoke emanating from nearby blazes. "Smoke taint," a phenomenon arising when smoke particles adhere to grape skins, compromises the quality of wine produced from these grapes, leading to substantial harvest losses. As the El Niño phenomenon approaches in the summer of 2023, there is a dual concern of record-breaking warmth and extreme aridity. Elevated fuel accumulation, dryness, fire-conducive weather, and lightning activity collectively heighten the probability of frequent bushfires. Consequently, the convergence of drought, parched vegetation and unprecedented heat could imperil the wine industry. Mitigating such risks necessitates effective fire prevention strategies, precise risk assessment, and strategic hazard reduction efforts. ## Nature's Watchful Eye: Harnessing Satellite Data For Land Health Assessment Satellites play a pivotal role in the toolkit of scientists, enabling them to monitor Earth's atmosphere, terrain, and oceans. The Sentinel-2, a component of the European Copernicus Programme named in honour of Polish astronomer Nicolaus Copernicus, is an Earth observation mission that captures optical images with a high spatial resolution (ranging from 10 metres to 60 metres) over both land and coastal waters. With a constellation of two polar-orbiting satellites, Sentinel-2 provides data every 5 days. Sentinel-2 leverages visible, near-infrared, and shortwave infrared sensors across 13 spectral bands. Here, a colour composite combines a few of the spectral bands — visible red, green and blue bands — with the corresponding red, green and blue channels, resembling what you would see with the human eye. ![](https://uploads-ssl.webflow.com/6555d1bced7999bb4a8b174f/6582f7ee078434b0027dde2f_IMG_7235%201%20(3).png) Observed region in Hunter Valley in July 2019 These 13 bands facilitate the computation of indices that estimate vegetation health, detect changes in the landscape, and even estimate the risk of bushfires. One of the invaluable indices derived from Sentinel-2's spectral bands is the [Enhanced Vegetation Index](https://en.wikipedia.org/wiki/Enhanced_vegetation_index) (EVI). Tailored to enhance the visibility of vegetation while minimising atmospheric interference, EVI offers insights into vegetation health. Healthy, green and hydrated vegetation corresponds to higher EVI values, while drier, less healthy vegetation, indicative of bushfire risk, corresponds to lower EVI values.An illustrative divergence is visible in the comparison between unhealthy and dry vegetation during the 2019–20 Australian bushfire season (Black Summer) and flourishing vegetation in December 2021. ![](https://uploads-ssl.webflow.com/6555d1bced7999bb4a8b174f/6582f8c6078434b0027e6883_IMG_7235%201%20(4).png) Detecting drought in January 2020 (on the left) using the EVI vegetation index Yellow means very healthy vegetation while dark green means unhealthy.EVI provides a quantitative measure of vegetation health, allowing wineries to track the overall condition of their entire vineyards, as opposed to individual vines. This can help identify early signs that might not be immediately obvious to the naked eye. By tracking EVI trends over time and comparing them to historical data, we can identify drought conditions early and alert vineyard managers to take appropriate actions. By analyzing EVI alongside soil moisture data, we can develop irrigation strategies that ensure efficient water use and prevent over- or under-irrigation. EVI data can also detect early signs of potential diseases affecting vineyards - unhealthy vegetation might indicate the presence of pests or diseases. ## Pixels To Precision: Refining Analysis: Ai-Powered Examination Of Individual Fields Moving beyond regional assessments, a finer-grained evaluation of individual fields is achievable. Given the scarcity of labelled data, an unsupervised approach is adopted to categorize similar agricultural fields based on their EVI and basic spectral bands. This approach rests on the assumption that similar plant types exhibit analogous responses to environmental changes.Since we lack knowledge of the exact field boundaries, we can use [the unsupervised machine learning](https://en.wikipedia.org/wiki/Unsupervised_learning) algorithm, [K-means clustering](https://en.wikipedia.org/wiki/K-means_clustering), to partition unlabelled data points into K clusters predicated on their similarity. In the context of Sentinel-2 data, K-means facilitates the grouping of similar pixels according to their spectral characteristics and EVI values. ![](https://uploads-ssl.webflow.com/6555d1bced7999bb4a8b174f/6582f959b228e251bee81020_IMG_7235%201%20(5).png) Clustering similar fields using unsupervised K-means clustering The outcome of K-means clustering is cluster labels that assign each data point to one of the K clusters. K-means is basically like sorting coloured balls into groups by finding their average colours. In the realm of Sentinel-2 data, these labels serve to identify areas characterised by similar spectral attributes. These areas can then be subjected to further examination for valuable insights, such as land use classification and environmental monitoring, and as input to the segmentation algorithm.In order to extract individual fields for an even higher resolution, to facilitate analysis of individual fields, we can use [Felzenszwalb's algorithm](https://en.wikipedia.org/wiki/Minimum_spanning_tree-based_segmentation), a segmentation technique widely employed in image processing and computer vision. ![](https://uploads-ssl.webflow.com/6555d1bced7999bb4a8b174f/6582f9b5f31ff0c531a70f3f_IMG_7235%201%20(6).png) Individual field retrieval (yellow) using Felzenszwalb's algorithm This algorithm functions as a bottom-up segmentation tool, aggregating pixels with similar characteristics and spatial proximity into segments or regions. It’s like drawing lines around squares of similar colours in a picture to make shapes. This method facilitates the extraction and analysis of individual fields for future investigations, such as precision agriculture management, crop yield prediction or individual field risk assessment. ## Estimating Bushfire Risk: An Advanced Application Of Satellite Data There is the potential for satellite data to be used in proactive bushfire management. Satellite imagery empowers us to assess both individual fields and entire regions for their bushfire susceptibility as well as, with the power of AI, forecast vegetation health, drought conditions and disease outbreaks.The Bushfire Risk Estimation can be calculated using the already mentioned EVI index, alongside other indices calculated from satellite bands, such as the Normalised Difference Water Index (indicative of liquid water presence), the Normalised Burn Ratio (used to identify burned areas and quantify burn severity), and current surface temperature.In addition, these indices and satellite data play a crucial role in aiding state and federal government agencies in enhancing industry resilience, planning for disaster preparedness, and in pre-positioning resource allocation for recovery activities. This collaborative approach ensures the preservation not only of the Hunter Valley's wine industry but also of other vital sectors vulnerable to the challenges posed by our rapidly changing climate. --- ### How businesses can build culture-first workplaces in the era of remote work URL: https://www.kablamo.com.au/blog/how-businesses-can-build-culture-first-workplaces-in-the-era-of-remote-work-53b26 Date: 2023-06-28 Author: SmartCompany *This article was originally published on* [*SmartCompany*](https://www.smartcompany.com.au/opinion/how-businesses-build-culture-first-workplaces-remote-work/) Recently we surveyed our team at Kablamo and 40% said they preferred to work fully remote with no weekly commitment to spending time in an office. What do you do with that kind of feedback when you believe, like I do, that human-to-human connection is essential to building and preserving great company culture? And if you’re trying to figure out, like me, how to achieve this human-to-human connection in a “remote first” workplace? What is management supposed to do when employee preference is so strongly against a return? As Stefan Stern recently [wrote in The New York Times](https://www.nytimes.com/2023/05/11/business/dealbook/back-to-office-battles-underscore-a-change-in-workplace-authority.html): *“A CEO steps out of the corner office, stares into the abyss of a sparsely occupied floor, and only the abyss stares back. Disconcerting questions arise: What kind of a place is this, and what kind of a leader am I if so few people want to show up? What has happened to my authority?”* But this isn’t really about me or any CEO; it’s about a shift in the way we do work culture that is ultimately going to affect us society-wide, and I’m not sure we can just assume personal preferences are enough to guide us here. ## Remote work matters I’m fortunate that we have a strong culture at my company, but would it have been as strong if we hadn’t had three years working in person with the core group of our team prior to Covid? Without that time, I genuinely don’t know if we would have been able to continue to build our culture as we have in the remote work era. What I do know –and would have known without our survey– is that remote work options are really important for a lot of our team. And who am I to tell a deeply talented individual, or anyone for that matter, how they are to best work and live? The days of the dictating CEO are over –at least for a company of our size in tech and especially as we begin to recognise new human dimensions, like the wonderful differences and strengths that come from neuro-diversity and the power of different personality types and work styles. After all, despite what Elon Musk has said about remote work being “morally wrong” (a questionable premise), if you begin dictating (and we never would), you probably won’t lose your worst performers, you’ll lose your best. For many years, there’s been extensive discussion about how voluntary redundancy might lead to a loss of your in-demand talent, because they’re not worried about finding another job. Will forcing office-based work have the same effect? And even if the industry starts becoming less and less remote-friendly, these top performers who want flexible work arrangements will keep moving until they can’t anymore. And even if they didn’t leave, what happens to your culture if 40% of your employees are showing up under duress? But still, I can’t shake the sense that some non-remote time is critical for culture and we have to find a way to re-introduce it as the norm. Our engagement survey engagement scores remain strong, and our attrition rate has been very low for the last two years, but we want to build the best place for people to work we can, one that can scale and last. Even so, I have to ask: do organisations run the risk of diminishing good culture without the rejuvenating effect of more in-person, on-site culture building? There are no guarantees here that we aren’t still running on the organisational adrenaline from powering through the COVID disruption any way we could. ## How the big end of town is responding Clearly many of the big guys are thinking the same, but the approaches are very mixed. When JP Morgan recently required its managing directors to work from the office five days a week it received ample media attention, mostly negative, despite keeping a hybrid system in place for many. Yet that hasn’t stopped CBA from mandating everyone back into the office at least 50% of the time. Meanwhile, Atlassian has doubled down on its Team Anywhere policy even though that now means 40% of its workforce is more than two hours away from an office. Considering construction has begun on their new headquarters, the world’s tallest hybrid timbre tower, I am looking forward to seeing how this market leader encourages their team to come to their amazing new space. And just a few months ago, Amazon CEO Andy Jassy informed his tens of thousands of employees that after years of working from home, they would now be expected to work in person at least three days a week. Foremost among his reasons why: workers would “absorb [Amazon’s corporate] culture” better than if they were allowed to continue at home indefinitely. “Our culture has been one of the most critical parts of our success the first 27 years, and I expect it will be in our next 27+ years as well,” he added. “Strengthening it further is a top priority for the s-team and me.” Jassy is right to focus on the challenge of “absorbing” culture, and CBA cited internal research that showed “innovation is an outcome of our people physically working together”. Our company lives and dies with its culture, but first, it has to be shared and absorbed. While we’ve done culture well remotely, this question of how do you best absorb culture doesn’t have a clear answer. For me being fully remote feels a little like staying in the shade all the time, when it’s well-known that humans need some vitamin D from the morning sun to stay healthy. At least every so often you need to soak up the rays of direct human exposure in a physical human environment. ## Still looking for answers It might be that a company-by-company approach is ultimately the way to go. The big guys might lead the way with enforced mandates and we’ll all be taking notes on how that goes, but companies like mine will have to play a more nuanced and sensitive game, working closely with where our people are and want to be and navigating together. That might be one way for us to attract and retain the best talent over the coming years. We don’t have all the answers, but we’ve gathered some clues to share for people navigating this journey like us. Twelve months ago, the first thing many candidates would ask is “how much do you pay and can I work remotely?” This script has flipped to an applicant’s primary concerns being around what type of company we are, what our values are and who they will get to work with – and, importantly, the kind of work we do. And also after a run of tech companies going south after gorging on cheap VC cash, they ask if are we running a sustainable business – in other words, will we be here for the long haul? Culture is clearly where it’s at. Thanks to my team’s thinking and a few in-person and remote culture experiments, we’re starting to see some ways forward. For starters, consider enabling opportunities for semi-structured casual learning and knowledge sharing whether remote, in-person or both goes a long way to keeping culture ticking along. We do that with twice monthly PechaKucha sessions (google it) where the presenter is randomly selected – it’s an excellent icebreaker and the learning is welcome by anyone on a growth-centred team. We’re still looking for more answers, but we know this now: if we really put our people first – not lip service, but genuinely believing that our company lives and dies based on each of these extraordinary individuals – and we build our culture and business around that belief, we will all eventually find what works. So why not make it even better than before? --- ### Turning limitless data into life-saving decisions URL: https://www.kablamo.com.au/blog/turning-limitless-data-into-life-saving-decisions Date: 2023-06-14 Author: Kablamo At Firestory, the cloud-based data and AI platform for bushfire management, human-centred design is embodied in their DNA. We sat down with Andy McDowell to talk about his work with spatial engineering, data science and frontend development on Firestory and his passion for work place culture. Geospatial engineering and 3D mapping technologies aren’t fields that many of us know much about, but spend half an hour with Andy McDowell and not only will you understand them, you’ll be as excited and enthusiastic about them as he is. Andy is the Spatial & Application Lead at Kablamo and his skill and experience as a software engineer is central to his role there. But his abilities and passions extend much further than AI and computational science. Passionate about building great engineering teams, Andy’s hearty, big-natured personality has found an ideal, if surprising, fit amongst the traditionally reserved software engineers he manages. One of Andy’s most significant projects at Kablamo is his work on Firestory a cloud-based data and Artificial Intelligence platform for managing bushfires. Turning the almost limitless amounts of bushfire data into a single source of decision-making intelligence, FireStory provides both prediction and management capabilities and helps in the prevention of bushfires. We talked to Andy about both his work on Firestory and his success nurturing his team. **What is Firestory and what are the real-time impacts it’s able to have for people on the ground?** Essentially, Firestory is a log of everything that happens around a fire incident. We focus on about four different roles from centralised headquarters like incident controllers, fire behaviour analysts, step-by-step operations controllers and the Public Liaison Unit. We digitise a lot of their workflows, integrating large amounts of data from many, many sources. This means the people who are trying to make the decisions on the ground don’t have 100 tabs open and they can see all their data within one platform, and within the context of the information that they’re trying to resolve. It's incredibly nuanced with complex workflows but there’s so much that we can do. We’ve taken workflows that were largely paper based, sometimes not easy to historically review, and completely automated them. This has helped a lot with enquiries after fire events. Rather than relying on masses of paperwork and individual recollections, it’s as simple as pressing an ‘export’ button and you’ve got all the information. **With so much information, a broad audience and a constantly evolving situation, what are some of the main challenges you’ve faced tying these webs of issues together?** We’ve had a lot of geospatial challenges around how you integrate different types of data and visualise them so you’re presenting complex data in a way that humans, with many different skills, can get insights from quickly. We’ve got historical data, observational data about what’s happening right now, and forecasted data of what we think is going to happen to the fire in the next 12 hours. The challenge is taking all those different types of data presenting it in a way that just lets people do their jobs and meets their needs. Firestory has to be really agile as well. There’s a constant inflow of data and new technologies that it needs to integrate, this isn’t a set and forget system. **Presenting complex data to people surely presents a design dilemma too? How do you overcome this?** First of all, we start by understanding what the job to be done is by asking ‘what do people need to do with this information?’ You could of course show them everything but that has challenges both around sending it and showing it in a web browser, because it would be so big and so busy. Stripping it back to give them the insights they need you can start to work on what is really important. Predictive workflows help incident controllers make the best decisions they can, showing them the most likely events that are going to happen in the coming 12 hours or six hours. For instance, you have information coming from the BOM so you can understand current and forecasted weather, what the vegetation will do in the wind, the fuel load, how dry it is, the topography of the land and a whole raft of other information. This is fed into the model and the model gives you a prediction. Cross referencing it with other data sources you know like where schools, houses, roads and hospitals are, where high voltage power lines are, where there’s access to water, if buses and trains go to an area so you know when to divert traffic, issue evacuation orders, change an evacuation route, redistribute fire appliances and personnel. We’re not here to tell people what to do, we’re here to give them the tools to do their job better, faster and more reliably. It’s really about understanding what people are trying to do and giving them the information rather than overwhelming them with it. **How is Firestory evolving?** Up until now it’s mostly been around the incident management situation but we’re working on a research and development piece to understand on a more granular and accurate scale, an understanding of what’s in the land, like how fast crops and grasslands grow. We’re starting to understand it on a small scale to build up to state wide and then national, understanding that there are different challenges, climates, topologies, and crops. We’re working with both publicly available satellite information but we’re also talking to companies with private satellites with higher resolution data, temporal and spatial. The next generation of satellites are called hybrid hyperspectral satellites which give a lot more granular intelligence, so the scale of information is much, much bigger, which brings its own challenges. There are pieces of the puzzle that are already solved but bringing it into Firestory is another layer of information. It’s a piece of work that’s never actually finished, a labour of love. **Your other passion project at work is around having a robust company culture. How are you shaping the culture at work in an industry that thrives on innovation?** I love the culture! We’re a bunch of people who are all highly excited to build code, software and products and we’re all constantly figuring out how to make remote working feel as inclusive as possible. Our front-end catch-up meetings that we have every two weeks is a place that no matter what project or team you’re working on it’s a place to meet your peers, catch up, discuss technology and trends, problems you’re having and things that we can all discuss as a team. Nothing’s off the table which makes it a really cohesive experience. We’ve also started to introduce a Pecha Kucha which is a little bit like a TED talk. Every two weeks we roll some virtual dice and the person with the highest number gives a presentation at the next meeting, about 20 slides with 20 seconds per slide, on any topic they like. If they’ve just joined the company, it might be on themselves, but we’ve had topics as diverse as Brazilian samba music, baking bread, fish tanks, anything that interests people. In a remote world, that helps build rapport and togetherness which is important when people are sitting in their own home rather than an office. But we’re always working on it, it doesn’t happen automatically, you must put the effort in. Getting people excited to work together is so important. We’ve started to have our office in Canada host them as well so it’s really a shared experience. **The pandemic accelerated the process of remote working, but do you think Kablamo would be in the same situation now if it hadn’t happened?** I joined in the middle of the pandemic, but I understand that was already something of a culture of remote working but perhaps more based in client offices. I do think in a post pandemic world it’s more important to offer flexibility because other employers are. So how do we make the best of that and maintain relationships like we had before and build culture like we had before? There are different challenges but it can be done, we just have to try. Take the Pecha Kucha. Software engineers aren’t known for their love of public speaking but as consultants we tend to do that a lot anyway. If you’ve had experience presenting in front of your peers about something you’re interested in, you’re learning to get out of your comfort zone but in a safe space. It takes the stress out of it and then we can take those skills that people are learning and apply it to speaking in front of customers. It’s not like learning from a module or ticking a box. Getting people really excited about things, whether it’s the project they’re working on, or the people they’re working with, is at the nexus of innovation and human psychology. ---