Started in 2011 as my outlet to share my experiences on personal life and work topics. My handle is khanmjk. My friends & colleagues call me "Mo". This blog is an experiment, work-in-progress. Life: Self-awareness, personal development, growth hacking (quantified self). Work: Software and Systems Engineering, Leadership, Management, New Ideas and OpEds.
Wednesday, 10 September 2025
Why I left AWS after 4.5 years as an L7 Senior Engineering Manager
Saturday, 17 May 2025
How I used AI coding assistants (Gemini) to build an MVP for a Software Management Tool
A walkthrough of an app I decided to build to help me with my work as a software engineering leader. Core thesis: I wanted a planning management tool that is centered around core system architecture, working backwards from there to model the organizational / team structures that feeds the planning process. I found most project management tools lacking support of including software architecture inputs - so I decided to build something to close this gap.
My journey started in late 2024 (October), when LLM models started exposing coding capabilities. I wasn't too impressed by the likes of ChatGPT and Claude (at the time). But with Gemini 2.5 entering the scene, I picked this project up again in April 2025 - and slowly built out the MVP, first as a single page application (html/javascript) with basic old skool UI (this video), then refreshed the UI, refactored the code (next video "Building apps with AI (2) - MVP...". Since I stopped coding professionally in 2010, this entire journey was quite the learning experience. I'm going back to school again, but I've learnt so much about how to engage with the LLM, that I'm increasingly confident I will find a place in the new world of AI. AI-assisted coding is definitely the future, but it is not that straightforward yet, even with the latest craze in vibe coding.
Just take a look at my document sharing my conversation with Gemini here.
50 pages and counting!!! Essentially you need to be very clear with articulating the requirements and interacting with the model as a true assistant, like you would with any human engineer, business analyst, or UX designer.
Source code on Github here
You can play with the app here
Listen to the podcast generated by NotebookLM here
You can interact with my Google NotebookLM here
The rest of this blog post was written by partner, Gemini >>>>
From Vision to MVP: Building a Software Management & Planning Powerhouse (with an AI Co-Pilot!)
For any software engineering leader, manager, or even a senior individual contributor, the landscape of modern software development is a complex beast. We juggle intricate system architectures, dynamic team structures, ever-shifting priorities, and the constant challenge of aligning finite resources with ambitious goals. What if there was a tool that not only helped model this complexity but also empowered smarter, data-driven planning?
That's the question that sparked the creation of the Software Management & Planning Tool, an MVP we've been passionately building. This isn't just about another planning application; it's about a foundational belief: effective planning starts by working backwards from your systems and organizational architecture.
This blog post shares the journey of bringing this vision to life – from a core idea to a feature-rich Minimum Viable Product – and the unique experience of co-developing it with a generative AI coding partner, Gemini.
The Core Idea: Architecture-First Planning
The tool is built upon a hierarchical understanding of a software organization:
- Systems: The overarching products or platforms.
- Services & APIs: The functional components within those systems, each with defined interfaces.
- Teams (2-Pizza Teams): Agile squads owning services, each with software development managers (SDMs) and engineers.
- Engineers: The talent pool, with defined levels.
- Management Structure: Senior Managers overseeing SDMs.
- Dependencies: Critical platform components and inter-service relationships.
This rich data model allows the application to provide a holistic view, forming the bedrock for all subsequent planning and visualization.
Our MVP Journey: An Iterative Evolution with an AI Partner
What started as a concept rapidly took shape, built incrementally feature by feature. The initial scaffolding was a single HTML/JavaScript file – a testament to getting ideas off the ground quickly. But the vision was always much larger.
Key Milestones in Our Development:
- System & Org Modeling: The first step was enabling the definition of systems, services, APIs, teams, and their intricate relationships. This involved creating UI elements for adding, editing, and connecting these entities.
- Visualizing Complexity: Static data isn't enough. We introduced dynamic visualizations:
- System Architecture Diagrams: Showing services, APIs, and platform dependencies.
- Team Relationship Graphs: Illustrating how teams connect based on service ownership.
- Service Dependency Views: Drilling down into specific service connections.
- Interactive Org Charts & Team Breakdowns: Providing clear views of the organizational structure and team compositions. Initially, these were separate views, but based on user experience feedback, we evolved the system overview into a slick carousel navigation allowing users to seamlessly glide through these critical perspectives.
- The Game Changer: Yearly Planning: This became a cornerstone. The goal was an interactive table to manage initiatives against team capacity, showing what's "Above The Line" (ATL) and "Below The Line" (BTL). We implemented:
- Dynamic team columns and SDE Year estimations.
- Drag-and-drop prioritization.
- "Protected" initiatives that lock to the top.
- The crucial concepts of "Funded Headcount" vs. "Builders In Seats" (BIS).
- Introducing "Away Teams": Recognizing that real-world capacity isn't static, we enhanced the model to include "Away Team Members" – borrowed resources. This led to the "Effective BIS" metric, providing a more realistic picture of available capacity.
- Deep Dive into Capacity Tuning: This was a pivotal enhancement. We built a dedicated "Tune Capacity Constraints" module where users can define:
- Global defaults (working days, holidays, org-wide events).
- Team-specific adjustments (leave uptake, variable leave, team activities, recurring overhead). The output? A Calculated Net Project Capacity for each team, which can then feed back into the Yearly Planning view for a much more accurate ATL/BTL assessment. This module also includes a detailed narrative explanation and a waterfall chart to visualize capacity erosion.
- SDM Resource Forecasting: Leveraging the detailed capacity tuning, we integrated a forecasting model. SDMs can now select their team, input hiring and ramp-up estimates, and see a 52-week projection of their headcount and effective SDE availability, all adjusted by the previously configured capacity constraints.
- UI/UX Modernization: More recently, we've focused on enhancing the user experience, refactoring the codebase into modular files, and adopting a cleaner, card-based UI reminiscent of modern web applications.
The Gemini Co-Pilot Experience:
This journey wasn't a solo flight. As the human visionary and lead developer, I partnered extensively with Gemini, my AI coding assistant. This collaboration was an experiment in itself:
- Acceleration: Gemini was instrumental in rapidly generating boilerplate code, implementing UI components based on descriptions, and refactoring complex functions. This significantly sped up the development of the MVP.
- Brainstorming & Ideation: We bounced ideas for UI/UX improvements, data model structures, and feature refinements (like the Team Load Summary table in the planning view).
- The Learning Curve (for both of us!): It wasn't always smooth sailing. There were moments where context was lost between sessions, leading to regressions or suggestions that didn't quite fit the current state. Clarifying requirements meticulously, sometimes repeatedly, became key. Debugging involved a human-AI partnership – I'd often describe the unexpected behavior, and Gemini would help pinpoint potential issues in the code it (or we) had written. It was a process of learning how to "prompt" effectively and how to guide the AI when it drifted.
This experience has been a powerful demonstration of how GenAI can be a force multiplier for developers, turning ambitious ideas into working software at an accelerated pace, even if it requires a new kind of collaborative patience and precision.
Key Features That Shine
While the tool is packed with interconnected features, some of the "wow" factors that have emerged include:
- Holistic System Modeling: The ability to define not just services, but also the teams that own them, the engineers within those teams (including AI SWEs and their attributes like skills and experience!), and the management structure, all in one place.
- Insightful Visualizations: The carousel of system, team, and service dependency graphs provides powerful, at-a-glance insights into complex relationships.
- Realistic Capacity Tuning: Moving beyond simple headcount, the "Tune Capacity Constraints" feature allows for granular adjustments, factoring in everything from public holidays and company events to team-specific leave uptake and meeting overhead. The resulting "Net Project Capacity" and its narrative explanation offer a truer picture of what teams can achieve.
- Interactive Yearly Planning: The drag-and-drop planning table, combined with dynamic ATL/BTL calculations based on selectable scenarios (Funded HC, Team BIS, Effective BIS) and the option to apply the "Net Capacity Constraints," makes for a powerful "what-if" analysis tool. The Team Load Summary provides immediate feedback on team-level impacts.
- Integrated SDM Resource Forecasting: This module closes the loop by allowing managers to see how their hiring plans and attrition realities, combined with the tuned capacity constraints, will affect their team's SDE availability throughout the year.
- An Evolving, Modern UI: The recent shift towards a cleaner, card-based design with a persistent top navigation bar significantly improves usability.
The Journey Continues: The Power of Iteration
This MVP is a significant milestone, but it's also a foundation. The backlog, as detailed in our project's README.md
, is rich with possibilities: enhanced yearly planning with ROI tracking and versioning, a dedicated roadmap and backlog management module, deeper detailed planning with work packages, and, most excitingly, integrating more AI-powered enhancements for analysis and interaction.
The development of this tool underscores the power of iterative development and the transformative potential of collaborating with AI coding assistants. It shows how a complex vision can be broken down and built, piece by piece, learning and refining along the way. While the path of AI-assisted development has its unique challenges (like ensuring context retention and guiding the AI through ambiguities), the ability to rapidly prototype, generate code, and explore solutions is undeniable.
For any engineering leader wrestling with the complexities of software planning, or any developer curious about the potential of AI partnerships, we hope this journey provides some inspiration. With the right vision and the right tools (both human and AI!), ambitious ideas can indeed be brought to life.
Saturday, 14 September 2024
How I used ChatGPT o1-preview to build a rough interactive software engineering resource forecasting model
Prompt for this article: Great I think we have good baseline version to start with. Now using your PhD capabilities, write up an accompanying blog post that details the model, the thinking behind it, and call out the limitations using a critical eye, suggesting improvements for the next version.
Prompt for Image using Dall-E: "An isometric illustration of a diverse engineering team collaborating in a modern office space. They are gathered around a large table filled with charts, graphs, and laptops, discussing and planning. Behind them, a wall-sized calendar and a whiteboard display timelines, Gantt charts, and upward-trending graphs. Include elements like gears and clock icons subtly integrated into the design to symbolize engineering and time management. Use a professional, clean art style with vibrant yet muted colors to convey a serious but engaging atmosphere.
Engineering Resource Forecasting: A Comprehensive Model for Team Planning
By ChatGPT o1-Preview (took about 4 hours to get the tool to version 1)
Effective resource planning is crucial for engineering teams aiming to meet project deadlines, optimize productivity, and manage budgets efficiently. The Engineering Resource Forecasting Tool is designed to help managers and team leads forecast their engineering resources over a year, considering various real-world factors such as hiring rates, attrition, ramp-up times, efficiency, leave days, and public holidays.
In this blog post, we'll delve into the model behind the tool, explore the thinking that shaped its development, critically analyze its limitations, and suggest improvements for future iterations.
Understanding the Model
1. Objectives of the Tool
The primary goals of the Engineering Resource Forecasting Tool are to:
- Forecast Team Size: Predict how the engineering team will grow or shrink over time.
- Calculate Effective Capacity: Determine the actual productive capacity of the team, considering factors that reduce availability.
- Assist in Planning: Provide insights for hiring strategies, resource allocation, and project scheduling.
2. Key Components of the Model
The model incorporates several essential elements:
- Funded Team Size: The maximum number of engineers that the budget allows.
- Current Available Engineers: The starting point for the forecasting, representing the existing team.
- Hiring Rate and Time: The rate at which new engineers are hired and the average time it takes for them to join.
- Ramp-Up Time: The period new hires require to reach full productivity.
- Attrition Rate: The expected percentage of engineers who will leave the team annually.
- Efficiency Factor: The proportion of time engineers spend on productive work.
- Leave Days and Public Holidays: Time when engineers are not available due to vacations and holidays.
3. Model Calculations
a. Effective Engineers
The number of effective engineers is calculated weekly by adjusting the total number of fully ramped-up engineers for efficiency and availability:
Effective Engineers = Total Ramped-Up Engineers × Efficiency Factor × (Weekly Available Days / 5)
b. Weekly Available Days
Engineers aren't available all five working days each week due to leave and public holidays:
Weekly Available Days = 5 - ((Annual Leave Days + Public Holidays) / 52)
c. Attrition Modeling
Attrition reduces the team size over time:
- Weekly Attrition Rate:
Weekly Attrition Rate = Annual Attrition Rate / 52
- Cumulative Attrition: The total number of engineers who have left the team up to a given week.
d. Hiring and Ramp-Up Process
- Hiring Pipeline: Represents engineers who have accepted offers but haven't started yet.
- Ramping Engineers: New hires who are in the process of ramping up to full productivity.
e. SDE-Weeks and SDE-Days
- SDE-Weeks: Sum of effective engineer contributions per week within a month.
- SDE-Days: Sum of effective engineer contributions per day within a month.
These metrics provide a more granular view of the team's productive capacity.
Thinking Behind the Model
1. Realistic Representation
The model aims to mirror real-world scenarios by considering:
- Time Delays: Hiring and ramp-up times introduce delays between initiating a hire and gaining full productivity.
- Non-Productive Time: Leave, holidays, and non-productive activities reduce actual working time.
- Attrition Effects: Engineers may leave the team, impacting capacity and necessitating replacement hires.
2. Balancing Simplicity and Complexity
While the model incorporates multiple factors, it maintains usability by:
- Using Average Rates: Distributes leave, holidays, and attrition evenly over the year for simplicity.
- Assuming Linear Processes: Hiring and ramp-up are modeled as linear processes without accounting for fluctuations.
3. Providing Actionable Insights
By visualizing the forecast through charts and tables, the tool helps managers:
- Identify Hiring Needs: Determine the hiring rate required to meet team size goals.
- Plan for Attrition: Anticipate capacity reductions due to attrition.
- Adjust Strategies: Modify inputs to explore different scenarios and their outcomes.
Limitations and Critical Analysis
Despite its usefulness, the model has several limitations:
1. Uniform Distribution Assumptions
- Leave and Holidays: The model assumes that leave days and public holidays are evenly distributed throughout the year. In reality, leave may cluster around certain periods (e.g., summer vacations, year-end holidays), leading to temporary drops in capacity.
- Attrition Timing: Attrition is modeled as a steady rate, but actual departures may occur unpredictably and in clusters.
2. Lack of Granular Ramp-Up Modeling
- Binary Productivity: The model assumes engineers are either ramping up or fully productive after the ramp-up period. It doesn't account for gradual increases in productivity during ramp-up.
- Individual Variations: All new hires are treated identically in terms of ramp-up time and efficiency, ignoring individual differences.
3. Hiring Constraints and Real-World Challenges
- Hiring Rate Feasibility: The model calculates the hiring rate needed to meet targets but doesn't consider the practical challenges of achieving that rate, such as market conditions or recruitment resource limitations.
- Candidate Pipeline Variability: It doesn't account for fluctuations in candidate availability or acceptance rates.
4. Simplified Efficiency Factor
- Static Efficiency: The efficiency factor is constant over time, not accounting for potential improvements or declines due to training, process changes, or team dynamics.
- Team Composition: It doesn't differentiate between engineers with different skill levels or specializations.
5. Absence of Project Dependencies
- No Task Modeling: The model focuses on resource capacity without linking it to specific project tasks or timelines.
- Overtime and Workload Peaks: It doesn't account for periods when engineers might work overtime or when workload exceeds capacity.
6. Economic and External Factors
- Budget Changes: The funded team size is assumed constant, ignoring potential budget cuts or increases.
- External Events: Unforeseen events like economic downturns, pandemics, or natural disasters are not modeled.
Suggestions for Improvement
To enhance the model's accuracy and applicability, future versions could consider:
1. Incorporating Seasonal Variations
- Variable Leave and Holiday Distribution: Model leave and public holidays based on historical patterns to reflect periods of low and high availability.
- Attrition Peaks: Adjust attrition rates to account for known periods of higher turnover.
2. Enhanced Ramp-Up Modeling
- Gradual Productivity Increase: Implement a ramp-up curve where productivity increases incrementally over the ramp-up period.
- Individualized Ramp-Up: Allow different ramp-up times for different roles or experience levels.
3. Realistic Hiring Constraints
- Recruitment Capacity Limits: Introduce maximum hiring rates based on recruitment team capacity.
- Candidate Pipeline Dynamics: Factor in time-to-fill variations, candidate drop-off rates, and competition in the job market.
4. Dynamic Efficiency Factor
- Efficiency Over Time: Allow the efficiency factor to change over time, reflecting process improvements or team fatigue.
- Role-Based Efficiency: Differentiate efficiency factors for various roles or seniority levels.
5. Integration with Project Planning
- Task-Level Planning: Link resource capacity to project tasks and milestones to assess whether capacity meets project demands.
- Risk Modeling: Incorporate risks and uncertainties that could impact timelines and capacity.
6. Economic Scenario Planning
- Budget Flexibility: Allow for adjustments in the funded team size based on potential budget changes.
- External Shocks: Introduce scenarios for external events that could affect hiring, attrition, or productivity.
7. User Input Flexibility
- Custom Time Frames: Enable users to adjust the time frame of the forecast beyond a single year.
- Data Import: Allow users to import historical data to better tailor the model to their organization's patterns.
Conclusion
The Engineering Resource Forecasting Tool provides a solid foundation for planning and visualizing engineering team capacity over time. By accounting for critical factors like hiring, ramp-up, attrition, efficiency, leave, and holidays, it offers valuable insights for managers.
However, like any model, it simplifies complex real-world dynamics to remain practical and user-friendly. Recognizing its limitations is essential for interpreting the results accurately and making informed decisions. By incorporating suggested improvements, future versions can offer even more robust and precise forecasting, aiding organizations in navigating the challenges of resource planning.
About the Author
[Your Name] holds a PhD in [Your Field] and has extensive experience in project management, resource planning, and organizational development. Passionate about leveraging data-driven models to solve practical problems, [Your Name] contributes to advancing tools and methodologies that enhance operational efficiency.
Note: The Engineering Resource Forecasting Tool is intended as a planning aid and should be used in conjunction with professional judgment and other planning tools. Always consider your organization's specific circumstances when making staffing decisions.
Saturday, 1 June 2024
The Hawthorne Effect, a short story
So I was going through my Trello board today, catching up on my growing list of todos, things to learn and be curious, explore (from years ago), and tackled this card "Check out Hawthorne effect". As usual, Googling takes you to wikipedia to read... I went to chatGPT and instead prompted it with the following...:
Explain the Hawthorne effect through a short-story, framing the narrative in a style, similar to Goldratt's book "The Goal". Limit the short-story to no longer than two A4 pages
The Workshop Challenge
Chapter 1: A Problem Arises
Alex Raines, the plant manager of Evergreen Manufacturing, walked into his office to find a stack of reports on his desk. The company had been struggling with productivity issues for months. Despite numerous initiatives and new policies, the output remained stagnant. Frustration mounted as Alex tried to pinpoint the problem.
Chapter 2: A Visit from HQ
One afternoon, an unexpected visit from Emma Collins, a senior executive from headquarters, threw Alex off his routine. Emma, known for her innovative problem-solving skills, had a knack for seeing through complexities.
“Alex, I’ve been reviewing the numbers,” Emma began, taking a seat in his office. “We need to figure out why the productivity is lagging. Let’s start by observing the workshop directly.”
Together, they walked to the workshop floor, where the hum of machinery mixed with the chatter of workers. Emma suggested they conduct a series of interviews and observe the workflow discreetly.
Chapter 3: The Observation Begins
Emma and Alex set up a temporary observation station in a corner of the workshop. Over the next week, they meticulously noted the workers’ behaviors, machine efficiency, and workflow patterns. To Alex’s surprise, there was a noticeable uptick in productivity during this period.
“I don’t get it,” Alex said, scratching his head. “The only change we made was being present here.”
Emma smiled knowingly. “That, my friend, is the Hawthorne effect.”
Chapter 4: Unveiling the Mystery
Emma explained, “In the 1920s and 30s, the Western Electric Company conducted a series of experiments at their Hawthorne Works plant. They discovered that workers’ productivity improved when they were being observed. It’s a psychological phenomenon where individuals alter their behavior due to the awareness of being watched.”
Alex pondered this revelation. “So, our presence here made the workers more conscious and thus more productive?”
“Exactly,” Emma confirmed. “But this effect is usually temporary. The key is to understand why the workers felt the need to change their behavior and how we can sustain productivity improvements without constant observation.”
Chapter 5: Digging Deeper
Determined to find a long-term solution, Alex and Emma conducted anonymous surveys and held informal discussions with the workers. They discovered several underlying issues: lack of clear communication, inadequate recognition of hard work, and an outdated incentive system.
Emma suggested a few strategic changes:
1. Improve Communication: Implement regular team meetings to discuss goals and progress.
2. Recognize Achievements: Introduce a recognition program to celebrate workers’ contributions.
3. Revamp Incentives: Align the incentive system with productivity and quality metrics.
Chapter 6: Implementing Change
With a clear action plan, Alex rolled out the changes. They started with weekly team huddles, where workers shared updates and suggestions. A “Star of the Week” program was introduced, celebrating top performers. The incentive structure was reworked to reward not just quantity but also the quality of output.
Chapter 7: Sustained Improvement
Over the next few months, the changes bore fruit. The workshop buzzed with newfound energy. Productivity rose steadily, and the workers felt more engaged and valued.
During a follow-up visit, Emma observed the transformed environment with satisfaction. “This is the real impact we were aiming for, Alex. By addressing the core issues and fostering a supportive environment, you’ve achieved sustainable improvement.”
Alex nodded, grateful for the insights. “It all started with the Hawthorne effect, but we’ve turned it into something lasting.”
Epilogue: Reflecting on the Journey
Alex reflected on the journey. The initial spike in productivity from mere observation had been a catalyst. By addressing the root causes and implementing meaningful changes, they had created a culture of continuous improvement. The Hawthorne effect was just the beginning—a lesson in understanding human behavior and leveraging it for lasting success.
In this narrative, the short-lived productivity boost due to observation, known as the Hawthorne effect, served as a springboard for deeper changes that ultimately led to long-term improvements in the workplace. The story mirrors the style of Goldratt’s “The Goal,” emphasizing problem-solving and continuous improvement.
Wednesday, 24 April 2024
Advice for Technology Executives eyeing out AWS L7 Snr Manager role
My experience going into AWS L7 Senior Manager Role
Tuesday, 29 August 2023
Be the leader you wish you had
<quote> No one goes to the gym to willingly get punched in the face by the senior vice president of boxing. But some folks eagerly pay for a sparring partner when it's time to get better. The difference is obvious, but we've forgotten to say it out aloud. No grades, no check marks, no badges. I'm not in charge of you, and I'm not manipulating you. I'm simply establishing the conditions for you to get to where you said you wanted to go. You tell me where you're going and what you need. You make promises about your commitment and skills development. I'll show up to illuminate, question, answer, spar with, and challenge you. I'll make sure you're part of a team of people who are ready to care as much as you do. We can get real. Or let's not play. </quote>