A closed-loop technical system that develops products properly, defines the technical truth, transfers the knowledge to the people who need it, then learns from real-world support and feeds that learning back into improvement.
Source: Technical Architecture MeetingWorking vision for leadership validation
Engine purpose
Create a scalable technical system that keeps IKON ahead through disciplined product development, protects what IKON can confidently promise, transfers knowledge without creating bottlenecks, and continuously improves from field feedback.
Closed loop
Research and Product Development → Technical Integrity → Training → Support → Feedback → Research and Product Development
01 · Create
Research and Product Development
Build a repeatable product-development machine that applies first-principles thinking and releases products only when the technical package is complete.
Browser edits are local only. They do not update the master site.
1. Purpose
Create and improve IKON products through a disciplined, testable and repeatable development process.
Agreed direction
2. One-year finished state
A standard Research and Product Development project template is used for every development.
Stage, owner, due date, blocker and next step are visible.
Priority existing systems have been backfilled through the new process.
Every release hands over a complete approved technical pack.
Working proposal
3. Current reality
Past products have sometimes moved through development before all downstream technical knowledge was complete.
Manual CAD work, waiting time and outsourced prototyping can extend cycles.
Fusion capability is still being developed.
Source confirmed
4. Problems & constraints
Product development can depend too heavily on one experienced person.
Urgency for new products can recreate incomplete releases.
Cycle time is not yet reliably measured stage by stage.
5. What must be resolved
Define exact stages and stage Definitions of Done.
Identify avoidable waiting and automation opportunities.
Choose existing systems for backfill.
Establish a real cycle-time baseline.
Baseline required
6. Operating model
Concept → first-principles design → digital model → prototype → test → refine → validate → industrialise → complete technical pack → release.
7. Capabilities & training
Fusion and digital modelling.
First-principles problem solving.
Prototype and test planning.
Mechanical and automation capability.
Stage-gate project discipline.
8. Roles & accountability
One accountable owner for the Research and Product Development system, with clear project ownership for each active development. Seats will be designed after engine approval.
Engine before people
9. Systems, tools & documents
Strety project template.
Fusion/CAD environment.
Rapid prototyping capability.
Project brief, test plan, change log and release checklist.
10. Standards
No product is finished until the release package is complete.
First principles before inherited assumptions.
Reduce unnecessary steps before automating them.
Every design claim must be technically supportable.
11. Measurables
Research and Product Development cycle time by stage.
Finance supports approved tooling, testing and prototype investment.
13. Risks
Chasing new products before the engine is stable.
Locking a six-month target without baseline data.
Knowledge remaining concentrated in individuals.
14. Immediate priorities
Finish core Fusion capability building.
Pressure-test the Research and Product Development template on known products.
Backfill priority existing systems.
Use smaller improvements to prove the process before multiple major launches.
15. Definition of Done
A repeatable Research and Product Development process is documented, visible and actively used; every project has clear stages, dates and ownership; and complete validated releases transfer cleanly into Product Knowledge & Technical Integrity.
02 · Define
Product Knowledge & Technical Integrity
Own the single source of technical truth for every IKON system and protect the business from committing beyond what is tested, engineered or formally approved.
Browser edits are local only. They do not update the master site.
1. Purpose
Turn developed products into a controlled, credible and accessible technical standard that defines exactly what IKON can and cannot promise.
Agreed direction
2. One-year finished state
Priority active systems have approved current technical packs.
Limits, materials, hardware, engineering rules, testing and details are easy to find.
Documents have ownership, version control and scheduled review.
Changes update BOMs, drawings, Revit data, manuals and training.
Working proposal
3. Current reality
Important parameters have historically been formalised after development rather than as a complete release discipline.
Maximum sizes, weights, spans, material quality, hardware rules, testing and water-management details are increasingly critical.
Manuals are beginning to be built and linked into Strety for review.
4. Problems & constraints
Risk of promising beyond validated limits.
Old information can remain in circulation after product changes.
Bespoke applications can bypass standards.
Knowledge can live in people instead of the system.
5. What must be resolved
Define the minimum product technical pack.
Define approval authority for limits and exceptions.
Define review frequency and change-control triggers.
Prioritise existing-system knowledge gaps.
Leadership decision required
6. Operating model
Receive validated product → verify technical pack → approve limits and details → publish controlled version → review → process changes → trigger retraining and downstream updates.
7. Capabilities & training
Fenestration engineering principles.
Material and hardware performance.
Water-management and installation interfaces.
Compliance/testing interpretation.
Revision control.
8. Roles & accountability
One technical authority must own the integrity of the released standard. Research and Product Development can create source information, but the approved technical truth needs one owner.
9. Systems, tools & documents
Configuration and limitation tables.
Material/hardware specifications.
Engineering rules and calculations.
Testing/compliance records.
Technical and water-management details.
BOMs, drawings, Revit data and manuals.
Strety-controlled documents and review reminders.
10. Standards
IKON only commits to what it can back technically.
Anything outside the approved envelope follows a special process.
Published information matches the latest approved state.
Material quality is part of technical integrity.
11. Measurables
% active systems with complete technical packs.
Outstanding testing/compliance actions.
Overdue document reviews.
Errors caused by incorrect/outdated product information.
Open technical exceptions.
Baseline before targets
12. Dependencies
Research and Product Development supplies validated data.
Training consumes approved truth.
Support challenges the standard through field feedback.
Operations aligns factory documentation.
13. Risks
Multiple versions of the truth.
Technical authority becomes a bottleneck.
Uncontrolled bespoke commitments.
Documentation goes stale.
14. Immediate priorities
Approve the technical-pack template.
Complete the first system manual as the model.
Backfill highest-risk existing systems.
Implement ownership and scheduled reviews in Strety.
15. Definition of Done
IKON has one controlled technical truth for each priority system, including what can be made, what cannot, how it performs, how it is detailed and what downstream teams must use. Changes are controlled and propagated.
03 · Transfer
Training & Knowledge Transfer
Move technical knowledge out of individuals and documents into the capability of the internal team, factory, sales and agents.
Browser edits are local only. They do not update the master site.
1. Purpose
Create repeatable competence by transferring approved technical knowledge to each audience at the depth they need.
Agreed direction
2. One-year finished state
Priority products have audience-specific training.
Technical, factory, sales and agent learning paths are defined.
Competency is tested, not assumed.
New starters can follow role-relevant technical onboarding.
Working proposal
3. Current reality
Important knowledge still sits in experienced people.
Agent training is a significant backlog and installation errors show the cost of incomplete transfer.
Manuals and AI-generated competency testing were discussed as enablers.
4. Problems & constraints
Training can be postponed by day-to-day support work.
One generic package will not suit every audience.
Training without testing can create false confidence.
Content can become outdated after product changes.
5. What must be resolved
Define audiences and competencies.
Clarify final ownership of agent training between this component and Technical Support.
Define refresh/re-certification rules.
Prioritise the current training gaps.
Leadership decision required
6. Operating model
Approved technical truth → audience module → theory and practical training → competency test → gap closure → refresh after technical change.
7. Capabilities & training
Technical facilitation.
Practical installation/factory instruction.
Digital learning content.
Competency assessment design.
Training scheduling and tracking.
8. Roles & accountability
The training system needs one accountable owner. Delivery can be distributed to subject-matter experts, but completion and currency remain clearly owned.
9. Systems, tools & documents
Product manuals and role-based modules.
IKON Academy / learning pages.
Competency tests and records.
Training calendar/completion register.
Change notifications.
10. Standards
Train only from approved current information.
Teach what the audience needs to execute its seat.
Competence is demonstrated.
Major product changes trigger targeted retraining.
Turn the first completed manual into a repeatable module.
Clear highest-risk agent training gaps.
Build simple competency tests for priority products.
15. Definition of Done
People who sell, manufacture, support or install an IKON system can access the right approved knowledge, complete required training and prove minimum competence without repeated informal explanations from technical leadership.
04 · Support & Learn
Technical Support
Give agents and the business one competent support route, solve real-world problems professionally and turn recurring field issues into proactive prevention and improvement.
Browser edits are local only. They do not update the master site.
1. Purpose
Provide fast, credible technical support while reducing future demand through training, audits, standards and feedback.
Agreed direction
2. One-year finished state
Agents/internal teams know the single support route.
Queries, site issues, specials, drawings and escalations are visible and categorised.
Agent audits are proactive and scheduled.
Recurring issues create actions in Training, Product Integrity or Research and Product Development.
Working proposal
3. Current reality
Support has consumed significant technical capacity and crowded out other work.
Many site problems have been installation related and potentially preventable.
The workload is not yet fully measured or designed as a proactive system.
4. Problems & constraints
Firefighting crowds out product development and knowledge building.
Poor routing drags senior technical leadership into every issue.
Support demand is not consistently tied to useful numbers.
Rework boundaries with Operations need clarity.
5. What must be resolved
Define the support catalogue and exclusions.
Define response/escalation standards.
Clarify rework-related ownership.
Define proactive agent audit frequency.
Measure workload before long-term capacity decisions.
Technical Support needs a clear competent front door so agents do not shop around for answers. The seat can evolve as capability broadens, but the outcome always needs one owner.
9. Systems, tools & documents
Technical query register.
Site/agent audit checklist.
Special application request.
Standard agent feedback report.
Root-cause categories.
Approved technical library.
10. Standards
One professional answer based on approved truth.
No unsupported field commitments.
Recurring problems create prevention actions.
Audits are preventative, not only reactive.
11. Measurables
Queries received/closed.
Age and response time.
Queries by cause/product.
Agent audits completed.
Repeat installation issues.
Escalations to senior technical authority.
Baseline before targets
12. Dependencies
Product Knowledge provides the standard.
Training acts on competence gaps.
Research and Product Development receives improvement feedback.
Operations executes operational rework after technical definition.
13. Risks
Support remains reactive.
Experienced people stay permanent escalation points.
Agent behaviour does not improve.
Support data is collected but not converted into action.
14. Immediate priorities
Define exactly what Technical Support owns.
Measure current query volume and categories.
Create proactive agent audit process.
Close obvious training gaps causing repeat problems.
Establish feedback route into Research and Product Development and Product Integrity.
15. Definition of Done
IKON has a visible, measurable and competent support system that solves queries consistently, prevents repeat issues, protects senior technical capacity and feeds structured learning back into the Technical Engine.
Leader guide · from vision to traction
How to use the Engine Builder
The Engine Builder turns leadership thinking into a shared departmental vision, then gives the Seats, Data and Rocks GPTs the right context to convert that vision into execution.
What this tool is
A living vision and workshop platform. It shows what each departmental engine must become, what is missing today and what leadership may choose to build next.
What this tool is not
It is not the project-management system and it does not replace Strety. Seats, measurables, Issues and Rocks move into the appropriate GPT and then into the execution rhythm.
01
Vision Meeting
Define the department’s one-year vision: its purpose, desired future state, current reality, problems, capabilities and dependencies. Record the meeting.
02
Draft the Engine
Use the transcript to build the engine visual, component blueprints and proposed one-year finished state.
03
Pre-Quarterly Workshop
Leadership reviews each component, challenges the thinking and decides what must be built within the next 12 months or sooner.
04
Edit and Record
Edit the workshop blocks live. Add missing points, remove what does not belong and record the complete discussion.
05
Approve the Vision
Combine the original transcript, workshop transcript and edits. Update the engine and separate decisions from unresolved issues.
06
Build the Seats
Define the Seats and accountabilities required by the approved engine before discussing who should occupy them.
07
Build Data and Rocks
Choose the numbers that prove the engine works, then select the few quarterly Rocks that close the most important gaps.
08
Execute and Improve
Run the quarter in Strety, surface Issues, capture learning and feed material changes back into the engine vision.
The GPT sequence
Seats → Data → Rocks
Always follow this order. Rocks cannot be assigned properly until accountability is clear, and priorities should be informed by the numbers that expose the biggest gaps.
First
Seats GPT
Upload the approved engine pack and transcripts.
Define the Seats required
Set five major accountabilities
Clarify handoffs and capacity gaps
Define the Seat before the person
Output: approved Seats and accountabilities
Second
Data GPT
Add the approved Seats output to the engine context.
Select leading and lagging indicators
Give every number an owner
Set reporting frequency
Identify where baselines are required
Output: departmental Scorecard and outcome measures
Third
Rocks GPT
Use the engine, Seats and Data outputs together.
Identify the most important gaps
Select only a few quarterly priorities
Give every Rock one owner
Write a measurable Definition of Done
Output: focused 90-day Rocks ready for Strety
Do not try to build the whole engine in one quarter. The pre-quarterly identifies the 12-month destination. Quarterly planning selects the few parts that matter most now.
What leaders need
Workshop handoff checklist
Before the workshopRead the engine vision and relevant component blueprints. Bring corrections, missing issues and practical evidence.
During the workshopChallenge the content, edit the blocks and agree what the engine must look like within one year.
After the workshopProvide the original Architecture transcript, workshop transcript, edited blueprint and approved engine context.
Before executionComplete Seats first, Data second and Rocks third. Transfer the approved outputs into Strety.
Source documents
Documents
The Architecture Meeting transcript is the source for this draft. The blueprint does not replace the transcript or convert working discussion into approved decisions.
Technical Architecture Meeting Transcript
Source meeting with Dominic Pedreiro and Armand Bergman. It establishes the four-part closed loop and covers Research and Product Development, technical integrity, training, support, proactive agent audits, capacity, measurables and likely build sequence.
Architecture conclusions
Research and Product Development → Product Knowledge & Technical Integrity → Training & Knowledge Transfer → Technical Support → feedback to Research and Product Development.
Source control
Architecture source loaded: Pasted text(1).txt, 18 August 2026. This site stores the structured vision derived from that transcript. The original source transcript remains the controlling evidence for workshop validation and should be included in the protected Context Pack after the workshop.
Transcript download intentionally not exposed on the Pages site