diff --git a/attachments/2024-10/PROPOSAL Cross-IFT Buddy Program.md b/attachments/2024-10/PROPOSAL Cross-IFT Buddy Program.md
new file mode 100644
index 0000000..3d54d6c
--- /dev/null
+++ b/attachments/2024-10/PROPOSAL Cross-IFT Buddy Program.md	
@@ -0,0 +1,240 @@
+# Objective:
+
+The Cross-IFT Buddy Program aims to foster collaboration and relationship-building across all IFT teams by pairing CCs from different parts of the organisation. This program provides a structured way for CCs to learn from each other and understand roles, responsibilities, and workflows outside of their regular teams.
+
+# How It Works:
+
+## Maintenance and Management:
+
+- **Ownership**: Managed by People Partners from People Operations, who would coordinate pairings, monitor participation, and gather feedback.
+
+## Logistics:
+
+- **Opt-in Program**: CCs voluntarily join the program and are paired with a buddy from a different team. Opt-in assures motivation to engage fully with the program.
+- **Time Allocation**: Participants meet for approximately **1 hour per week**, with each pairing lasting **2 months.**
+- **Rotation**: Buddies rotate every 2 months per quarter, giving one month for additional matching, review and feedback loops. This will prevent diminishing returns and encourage exposure to different parts of the organisation. Afterward, buddies can rotate to new buddies or retire from the program, and will always have the option continue their relationship with their current buddy.
+- **Buddy ‘Matchmaking’ Based on Skill Sets**: Match CCs based on complementary skill sets or declared interests, ensuring productive matching.
+    - Consider [[#Process Inclusivity and Transparency]]
+
+## Mechanics:
+
+- **Casual Standups**: Each week, CCs conduct informal standups with each other, sharing what they've worked on and what they've learned. CCs are encouraged to relay this information to their own teams via their usual standup process, helping to promote cross-team knowledge exchange.
+- **Cross-Departmental Workshops**: Following the buddy program, participants could share key insights through workshops, boosting knowledge transfer beyond the buddy pair.
+
+## Growth:
+
+- **Mentorship Opportunity**: Some buddy pairing may be designed explicitly for cultivating internal talent. CCs could also act as informal mentors during the buddy period, sharing personal career insights or guidance that could help their buddy in professional development. For this reason leads should consider their own participation in this program.
+
+## Improvement:
+
+- **Feedback Loops**: At the end of each buddy cycle, both CCs provide formal feedback to the program owner(s) on their experience, suggesting improvements for future cycles, ensuring continuous program refinement.
+
+# Costs and Benefits:
+
+## **Costs:**
+
+1. **Potential Mismatches**: Not all CCs may match well with every other counterpart, resulting in possible inefficiency or friction if the pairing isn’t ideal.
+2. **Managerial Overhead:** The program will require maintenance and orchestration which comes with time commitments from a responsible party.
+3. **Distraction from Core Responsibilities**: Balancing the buddy program with existing workloads could divert focus from critical tasks.
+4. **Misaligned Objectives**: If the objectives of the buddy pairs are not clearly communicated, there’s a risk of unclear expectations and unproductive meetings.
+
+Also see [[#Staying On Track]]
+
+## **Benefits:**
+
+1. **Project Awareness**: Exposure to the work done in a different teams allows CCs to understand the challenges and accomplishments of other parts of the IFT organisation. CCs that share their learnings from their IFT buddies will allow their entire team an opportunity to realise new perspectives.
+2. **Improved Social Bonds**: Regular interaction with new team members strengthens inter-team relationships, enhancing collaboration and fostering a more cohesive work culture.
+3. **Career Development**: CCs gain exposure to new tools, workflows, and strategies, helping them diversify their skill set and explore potential career advancements.
+4. **Innovation Catalyst**: By understanding the work of other teams, CCs may suggest process innovations or new features that hadn’t been considered before, benefiting the organisation’s overall output.
+5. **Discovery of Synergies**: CCs may identify new opportunities for collaboration or process improvements that were previously unexplored, leading to potential innovation and efficiency gains across teams.
+6. **Increased Flexibility in Project Management**: CCs with a broader understanding of other teams can help mitigate resource constraints or bottlenecks by jumping into different roles when needed.
+
+## Staying On Track:
+
+Ensuring participants make the most of the buddy program is key challenge and there are several ways to approach it.
+
+### Clear Goals and Expectations:
+
+1. **Establishing Clear Goals from the Start:** To ensure participants make the most of the program, we should require each buddy pair to set **clear, mutually agreed-upon goals** at the start of their relationship. These goals could focus on areas like learning specific skills, improving cross-team relationships, or gaining insight into different workflows. Having these goals will provide structure and purpose, making it easier for both parties to measure the success of their partnership and stay on track.
+2. **Participants Defining What They Seek from the Program:** It’s also important that participants articulate what they want to achieve from the program. We can introduce a step where each CC, when joining the program, formally states what they are seeking—whether it’s mentorship, new perspectives, or deeper knowledge of another team's processes. This self-defined purpose will help ensure that participants are engaged with a clear focus on how they want to grow or contribute.
+3. **Preference Selection for Buddy Matching:** Additionally, we could give participants the opportunity to provide their top 3 preferences for their buddy match, as well as a brief explanation of why they believe those matches would be beneficial. This gives participants more ownership of the process and allows them to align their personal goals with potential buddies who they feel could best support those aims. While preferences will be considered, final matches would still be balanced with program goals, such as cross-team collaboration and knowledge sharing. Also see [[#Process Inclusivity and Transparency]]
+
+### Pairing Models
+
+1. **Diverse Interaction Models:** Beyond simple knowledge sharing, we could offer multiple interaction models like project-based collaboration or joint problem-solving sessions, encouraging participants to apply what they learn in real scenarios. This could be especially helpful for understanding how different teams function and improving cross-departmental relationships. Example developers from different programs working on specific technical challenges to give mutually fresh eyes to their respective problems.
+2. **Varied Pairing Models:** Depending on participants' goals, we can offer multiple engagement models, such as senior-junior mentorship, reciprocal learning, or simply sharing perspectives to deepen understanding of different teams. By offering this flexibility, participants can choose the type of relationship that best aligns with their goals, ensuring they extract real value from the program.
+
+### Feedback
+
+1. **Regular Feedback Loops:** Finally, we will include regular check-ins and feedback mechanisms, so if a pairing isn’t working or if goals need adjusting, we can respond quickly, keeping the program dynamic and effective.
+
+### Trials, Self-screening and Fast Exits:
+
+Unproductive pairings are a common issue in buddy programs, and it’s crucial to prevent them from dragging on without resolution. I like the idea of incorporating an optional pre-buddy ****phase to test the waters before committing to a full cycle.
+
+1. **Pre-Buddy Trial Phase:** For pairs who haven’t interacted or have had limited interaction, we could introduce a short, informal "trial" period, approximately 1-2 weeks. During this time, the pair could engage in a few light, unstructured conversations or shadow each other’s work to assess compatibility. Since this is an informal and private phase, both participants would feel more comfortable deciding if the relationship is productive without external pressure.
+2. **Private and Discreet Assessment:** If either participant feels the pairing isn’t working during the pre-phase, they can mutually agree to end the pairing without it being made public. This way, there’s no stigma or judgement around the cancellation, and the participants can move on to a new match.
+3. **Fast Exit Mechanism:** Should the pairing not work out, the program could include a quick and easy re-matching process, ensuring no time is lost for either party. The key is to prevent unproductive pairings from dragging on and to foster a culture where it’s okay to acknowledge when things aren’t working.
+
+By focusing on **goal-setting** at the start and allowing CCs to communicate what they want to achieve, we can help ensure that participants are motivated and get the most out of their buddy relationships, while also fostering a stronger, more transparent matching process.
+
+## How It Differs from Onboarding Buddies:
+
+- **Purpose**: Onboarding buddies help new hires integrate, while Cross IFT buddies expose established CCs to different teams and functions.
+- **Duration**: Onboarding buddies last a few weeks, whereas Cross IFT buddies last 3-4 months, allowing deeper relationships and better knowledge sharing.
+- **Implementation**: Onboarding Buddies tend to be matched within the local cluster of teams, Cross IFT Buddies a designed to weave all teams in the IFT closer together. In contrast to onboarding, both participating CCs will be experienced in their respective teams, which allows for a meeting of peers. Further the implementation is designed such that CCs who may never interact otherwise, can, with the explicit intent to understand each other’s roles and teams.
+
+# Next Steps:
+
+- **Pilot Phase**: Run a pilot for 3 months with volunteer participants, collecting feedback.
+- **Evaluation and Scale**: Adjust based on pilot feedback and scale for broader participation.
+
+# Appendix:
+
+## **Non-Technical CC Profile and Technical CC Profile Pairing**
+
+**Example Roles:**
+
+- **People Operations Partner:** Focuses on HR functions like recruitment, employee engagement, performance management, and workforce planning.
+- **Software Developer:** Responsible for coding, testing, and deploying software products, with a focus on solving technical challenges and building features.
+
+### **Skill Transfer:**
+
+### **People Operations Partner to Software Developer:**
+
+The People Operations Partner can offer insights into:
+
+- **Change Management:** The People Ops Partner could share best practices on how to manage organisational changes, such as new processes or systems, and how to get team buy-in for those changes. This could be valuable to the Software Developer when their team needs to adopt new technologies, workflows, or methodologies. The People Ops Partner could help the developer understand how to communicate these changes effectively to their team, manage resistance, and ensure a smooth transition.
+- **Employee Well-being During Transitions:** The People Ops Partner could provide insights on how to maintain employee well-being during periods of rapid change or increased workload. They might suggest strategies for managing stress and promoting work-life balance, which could be particularly useful during high-pressure development phases like release cycles or when dealing with large amounts of technical debt. They could also introduce techniques for promoting resilience within teams, like regular check-ins or mindfulness programs.
+- **Workforce Engagement & Retention Strategies:** They could share how engagement strategies (like feedback mechanisms, CC surveys, or career development programs) influence CC satisfaction and productivity. The Software Developer could gain insights into how their role fits into broader organisational goals, perhaps understanding the link between job satisfaction and their own productivity or team dynamics.
+- **Performance Management & Feedback Cycles:** The People Ops Partner can discuss the structure of performance reviews, feedback cycles, and how these processes are designed to encourage personal and professional growth. This could help the developer understand how their performance is evaluated and how they can leverage feedback for career advancement. They may also learn how to give more structured feedback to others.
+
+### **Software Developer to People Operations Partner:**
+
+The Software Developer can offer insights into:
+
+- **Managing Technical Debt:** The developer could explain the concept of technical debt, which is the accumulation of suboptimal code or systems that can slow down development over time. This could help the People Ops Partner understand why developers sometimes struggle with balancing new feature development and maintaining older code. By understanding this, People Ops could design initiatives or policies that support better time allocation for developers to manage technical debt, reducing stress and improving long-term productivity.
+- **Efficient Tool Adoption:** Developers often use new tools to streamline workflows, but getting the entire team on board can be challenging. The Software Developer could explain the pros and cons of specific tools, like project management software or communication platforms. They could work with the People Ops Partner to help evaluate which tools work best for cross-team collaboration and smooth the adoption process across the organisation, ensuring minimal disruption to day-to-day activities.
+- **Understanding of Software Development Processes:** The developer could walk the People Ops Partner through the software development lifecycle (SDLC), including Agile methodologies, sprint cycles, and version control (e.g., **Git**). This can give the People Ops Partner insight into how developers work and why certain processes (like sprint planning and code reviews) are crucial for building reliable software. This could inform how People Ops schedules and manages resources for tech teams, ensuring that HR policies align better with the developer workflow.
+- **Technology & Tools for HR Automation:** The Software Developer might explain the tools and platforms they use for task automation, project management, and workflow optimisation. They could recommend or help introduce software solutions (like automating repetitive HR tasks with scripts or using advanced tools like Zapier or Discord ****bots) to streamline administrative processes in People Ops.
+- **Communication Tools & Collaboration Platforms:** The Software Developer could share their expertise on collaboration tools like GitHub, explaining how developers track projects, manage issues, and collaborate across teams. The People Ops Partner could take these insights to enhance their own team's processes or even suggest relevant tools for improving cross-team communication and project tracking.
+
+---
+
+### **Example Interaction:**
+
+**People Operations Partner Insight:**
+
+The People Operations Partner shares a concern about how the company can better retain tech talent, noting that some developers feel disengaged due to a lack of clear career progression pathways. They explain that while exit interviews provide some data, they struggle to gather ongoing feedback from developers in a meaningful and actionable way.
+
+**Software Developer's Response:**
+
+The Software Developer suggests using tools like Anonymous Feedback Surveys integrated into tools developers already use, such as Discord. They could recommend setting up bi-weekly “pulse checks” or creating a workflow that collects feedback after each sprint cycle, making the process more organic and relevant to the development team's rhythm. They also explain how they value specific growth opportunities, such as working on challenging projects or learning new technologies, which could be communicated more clearly during feedback cycles or performance reviews.
+
+**Skill Outcome:**
+
+The People Operations Partner gains actionable ideas on how to engage developers using the tools they are comfortable with and in a way that aligns with their workflows. They also gain insight into what motivates developers, allowing them to tailor career development programs to these needs. On the other hand, the Software Developer learns about the strategic importance of employee engagement, realising how HR initiatives directly impact job satisfaction and performance within their own team. They also gain a clearer understanding of the feedback and performance review processes.
+
+---
+
+## **Two Non-Technical CC Profiles**
+
+**Example Roles:**
+
+- **Content Strategist:** Focuses on creating and managing content across platforms to support marketing and communication goals, ensuring consistency in tone, branding, and messaging.
+- **Finance Administrator:** Manages budgets, financial reporting, expense tracking, and ensures that financial operations are running smoothly, with an emphasis on compliance and resource allocation.
+
+### **Skill Transfer:**
+
+### **Content Strategist to Finance Administrator:**
+
+The Content Strategist can offer insights into:
+
+- **Content Marketing ROI (Return on Investment):** The Content Strategist could explain how content is used to drive traffic, build brand awareness, and ultimately lead to conversions or sales. They might help the Finance Administrator understand the metrics they track, like engagement rates, conversion rates, and lead generation, and how these relate to revenue. This helps the Finance Administrator better grasp why content initiatives are important and how to measure the financial impact of content campaigns.
+- **Budgeting for Creative Projects:** The Content Strategist could share how they plan and allocate resources for content projects, including managing freelancers, tools, and platforms. They might explain the varying costs associated with different types of content (e.g., video vs. blog posts) and the importance of investing in high-quality content. The Finance Administrator could use this knowledge to improve the financial planning and approval processes for content-related projects, ensuring the content team has the resources they need while staying within budget.
+- **Cross-departmental Communication:** Content Strategists often collaborate with multiple teams (marketing, sales, and product development) and are skilled at tailoring messages for different audiences. The Content Strategist could provide insights into how to effectively communicate complex financial information to non-finance stakeholders, like creative teams, in a way that’s clear and engaging. This would help the Finance Administrator improve their communication when explaining budget constraints or financial decisions to teams unfamiliar with financial terminology.
+
+### **Finance Administrator to Content Strategist:**
+
+The Finance Administrator can offer insights into:
+
+- **Financial Planning & Budgeting:** The Finance Administrator could explain how budgets are allocated across departments and how financial forecasting works. This could help the Content Strategist better understand the constraints and challenges the finance team faces when approving or rejecting project budgets. By knowing how the overall company budget works, the Content Strategist could plan content initiatives that align better with financial goals, ensuring more efficient use of resources.
+- **Cost-benefit Analysis:** The Finance Administrator might teach the Content Strategist how to conduct a cost-benefit analysis for content projects. For instance, when planning a major content campaign, the strategist could apply these financial models to evaluate the potential return on investment and determine whether the project is financially sound. This knowledge helps the Content Strategist make data-driven decisions when proposing content initiatives.
+- **Expense Tracking & Compliance:** The Finance Administrator could explain the importance of proper expense tracking and financial compliance, which would help the Content Strategist manage content-related expenses more efficiently. They could introduce tools or methods to track content production costs, such as freelancers, advertising spend, and platform fees, ensuring that everything stays within budget and is reported correctly.
+
+---
+
+### **Example Interaction:**
+
+**Content Strategist Insight:**
+
+The Content Strategist explains how a recent content campaign helped increase website traffic by 30%, but the challenge is connecting this metric to actual revenue. They also share how they balance limited budgets with high-impact projects, describing the creative decision-making process that prioritises certain content types, such as video or long-form articles.
+
+**Finance Administrator’s Response:**
+
+The Finance Administrator suggests a more structured approach to tracking the financial impact of content, recommending that the Content Strategist work with the sales or e-commerce team to link traffic increases with conversions and actual revenue. They introduce the concept of **attribution models** and offer advice on how to calculate the long-term ROI of a campaign by linking content engagement with eventual sales or customer retention. They also suggest a tool for tracking and managing content expenses more effectively to ensure projects stay on budget.
+
+**Skill Outcome:**
+
+The Content Strategist now understands how to align their content metrics more closely with financial performance, improving their ability to demonstrate the ROI of content initiatives. Meanwhile, the Finance Administrator gains insights into the creative process behind content production and learns to appreciate the strategic role that content plays in driving company growth. They also gain a better understanding of how to work with creative teams when managing budgets and resources for marketing initiatives.
+
+---
+
+## **Two Technical CC Profiles**
+
+**Example Roles:**
+
+- **Technical buddy: QA Specialist:** Responsible for testing software products, identifying bugs, ensuring quality standards, and automating test cases.
+- **Technical buddy: DevOps Engineer:** Manages the infrastructure for deploying, monitoring, and maintaining software applications, ensuring smooth integration between development and operations teams.
+
+### **Skill Transfer:**
+
+### **QA Specialist to DevOps Engineer:**
+
+The QA Specialist can offer insights into:
+
+- **Test Automation Frameworks:** Sharing knowledge about automation tools, and how test cases are created and maintained. The DevOps Engineer might learn how automated tests are integrated into the development process, providing valuable feedback on how to optimise testing environments and better support CI/CD pipelines.
+- **Bug Identification & Reporting:** The QA Specialist could explain their process for identifying bugs and how they categorise issues based on severity. This knowledge can help the DevOps Engineer set up monitoring and alert systems that capture the same kinds of issues in production environments, allowing them to preemptively address potential problems.
+- **Cross-platform Testing:** The QA Specialist might discuss the challenges they face when testing across different platforms, giving the DevOps Engineer a better understanding of the resource requirements or infrastructure adjustments needed to simulate varied environments for testing.
+
+### **DevOps Engineer to QA Specialist:**
+
+The DevOps Engineer can offer insights into:
+
+- **CI/CD Pipelines:** The DevOps Engineer can explain how they build and maintain CI/CD pipelines, which automate the process of testing, building, and deploying code. The QA Specialist could learn how to integrate their test automation scripts into these pipelines to make the testing process faster and more efficient. They can also gain insights into the best points in the pipeline to trigger automated tests.
+- **Infrastructure as Code (IaC):** The DevOps Engineer might introduce the QA Specialist to tools like Ansible, which automate infrastructure setup. This could allow the QA Specialist to provision test environments on-demand, increasing flexibility and reducing delays caused by waiting for manually-configured environments.
+- **Monitoring and Incident Response:** DevOps engineers often set up extensive monitoring tools to track system performance and log application errors. The QA Specialist could learn how these tools work and apply similar principles to enhance post-deployment QA monitoring. They might also improve their bug reports by referencing metrics collected from these monitoring tools, giving developers and DevOps teams better context when addressing issues.
+
+---
+
+### **Example Interaction:**
+
+**QA Specialist Insight:**
+
+The QA Specialist explains how they manually run performance tests on the software during peak network traffic simulations and how difficult it is to reproduce certain production issues in testing environments. They describe how they rely on tools to simulate load but often face limitations in configuring the test environments to match real-world conditions.
+
+**DevOps Engineer's Response:**
+
+The DevOps Engineer suggests automating the process of spinning up identical production-like environments for these load tests using Docker and Kubernetes. They can show the QA Specialist how to deploy containers that match the production configuration, making it easier to simulate real-world loads. The DevOps Engineer also shares how performance metrics from tools like Prometheus can be used to monitor the impact of different loads on the infrastructure in real-time.
+
+**Skill Outcome:**
+
+The QA Specialist now has access to more dynamic, production-like environments for their tests, leading to more accurate results. Meanwhile, the DevOps Engineer gains a better understanding of the test scenarios and conditions that are important for QA, which informs how they fine-tune the infrastructure to support the testing process. This collaboration improves the overall efficiency and effectiveness of both QA testing and the reliability of the software in production environments.
+
+---
+
+## Summary of Key Benefits in These Examples:
+
+- **Cross-functional understanding:** Each participant gains a deeper appreciation of the other’s responsibilities and challenges, allowing them to make more informed decisions that benefit the whole team.
+- **New perspectives:** Each buddy can offer solutions or process improvements based on their experiences, leading to more innovative approaches.
+- **Increased collaboration:** By understanding the tools, techniques, and workflows of other departments, each buddy becomes better equipped to collaborate across teams.
+
+This cross-functional exposure fosters a more cohesive organisational culture and leads to the discovery of synergies that might otherwise remain untapped.
+
+## Process Inclusivity and Transparency:
+
+Allowing CCs to have a say in their pairing preferences can greatly improve engagement and satisfaction with the program. We can incorporate the following items to strengthen inclusivity, transparency and program goals.
+
+1. **Preference Submission:** We could introduce a formal step in the matching process where each CC has the opportunity to submit their top 3 preferences for their buddy by name or profile, along with a brief explanation of why they think those pairings would be beneficial. This not only allows CCs to feel more invested in the program, but also provides the People Ops team with more context to make informed pairing decisions.
+2. **Balancing Preferences with Program Goals:** While preferences will be considered, the People Ops team would still balance these selections with the program’s broader objectives, such as cross-departmental collaboration and skill transfer. We’ll make it clear to participants that their preferences are taken into account, but pairings might still be adjusted to ensure optimal learning and exposure to different parts of the organisation.
+3. **Transparency in the Process:** We could also provide CCs with a clear explanation of how the final matches are made, including which factors were considered (e.g., complementary skill sets, learning goals, preferences). This transparency will help CCs understand the rationale behind their pairing and feel more confident in the process.
\ No newline at end of file