Build the data product.
From source exploration to reusable reporting models: explicit grain, primary keys, documented definitions, and tested transformations.
SQL · Spark SQL · Python · PySpark · AWS Glue · Redshift Spectrum · Athena · S3
Seattle, WA · Business Intelligence Engineer
Turning complex workflows intoproduction data products.
I’m Suhas, a Business Intelligence Engineer at AWS Security. I build SQL and PySpark pipelines, trusted data models, and executive analytics that turn operational data into decisions.
SELECTED OUTCOMES & WORKLOAD CONTEXTAWS Security analytics
6 hrs per cycle
Executive reporting time saved
Automated P0 business-health metrics for organization-wide monthly business reviews.
$250KAnnual licensing savings enabled
Validated downstream reporting across 1,648 engagements, supporting the transition to an in-house platform.
55% → 78%Time-tracking participation
Customer-reported participation rose from 55% to 78%; on-time submissions reached 86.7% across 127 employees in 17 countries.
$38.1KAnnualized compute savings
Confirmed 67% monthly compute reduction ($3,175/month), supported by my rightsizing recommendation.
60% → 76%First-pass acceptance observed
60% to 76% among classifiable requests following launch of the acceptance and rework dashboard.
01 / SELECTED WORK
Behind the numbers.
Eight business challenges. Practical engineering decisions.
Explore the methods, outcomes, and measurement context.
8 case studies
01Executive measurement & analytics engineeringAutomating P0 business-health metrics for executive monthly business reviews
Automated P0 business-health metrics for organization-wide monthly business reviews by unifying operational data in Gold-layer datasets and building reusable PySpark functions for standard reporting.6 hours saved per reporting cycleOrganization-wide reviews for L8–L10 leadership
The challenge
Technical program managers manually assembled executive business-health metrics in spreadsheets. Disparate engagement, time-tracking, and ticketing sources required consistent definitions and a repeatable reporting process.
My contribution
I partnered with customers to understand business definitions, reporting needs, and preparation pain points. I built the Gold-layer reporting datasets and authored the reusable modular PySpark functions that generated standardized metrics for P0 monthly business reviews attended by L8–L10 leadership.
Decisions that mattered
- Established shared definitions across operational workflows. Worked with stakeholders to define demand, throughput, timeliness, workforce effort, utilization, and cost-to-serve measures, connecting each metric to the business question it needed to answer.
- Built a reusable reporting framework. Authored modular PySpark functions for month-over-month, year-to-date, and trailing-six-month reporting, transforming outputs into the standard monthly business review format.
- Exposed variation beyond headline totals. Calculated P50, P75, and P90 measures for engagement completion time, hours, and staffing requirements, allowing leaders to assess typical performance alongside resource-intensive engagements.
- Unified the executive view across sources. Integrated engagement management, time-tracking, and enterprise ticketing data into Gold-layer reporting datasets, bringing workload, service performance, and resource consumption into a consistent reporting process.
The outcome
Saved six hours of manual metric preparation per reporting cycle while delivering standardized P0 business-health metrics for organization-wide monthly business reviews attended by L8–L10 leadership.
02Reporting continuity & platform transitionEnsuring reporting parity across 1,648 engagements to enable $250K in annual licensing savings
Validated downstream datasets and executive metrics across 1,648 engagements, helping the organization replace an externally licensed GRC platform with an in-house solution.$250KAnnual licensing savings enabled · 100% reporting parity across 1,648 engagements
The challenge
Retiring an externally licensed GRC platform offered $250K in annual savings. The transition to an in-house tool required downstream datasets, historical reporting, and executive metrics to remain accurate and continuous.
My contribution
I owned downstream reporting reconciliation and validation across 1,648 engagements. I migrated existing Amazon QuickSight metrics to the replacement data source, tested their definitions and calculations against legacy outputs, resolved reporting discrepancies, and coordinated upstream corrections and historical backfills with data engineers.
Decisions that mattered
- Validated business results beyond record counts. Used SQL set comparisons and field-level reconciliation to check engagement attributes, lifecycle dates, classifications, and existing dashboard metrics against legacy reporting.
- Resolved differences in relationship modeling. Investigated how the two platforms represented multi-valued records and corrected reporting join logic so required relationships remained represented after the source transition.
- Addressed historical gaps before cutover. Identified missing publication dates and supporting metadata, then partnered with data engineers to restore historical values needed for consistent reporting.
- Made downstream metric parity a release requirement. Tested existing QuickSight definitions, calculations, and dashboard outputs with stakeholders before cutover, preserving the measures used in executive business reviews and compliance reporting.
The outcome
Achieved 100% reporting parity across 1,648 engagements, supporting the legacy platform’s retirement and contributing to $250K in annual licensing savings.
03Evidence quality & workflow analyticsMaking evidence quality and rework measurable through workflow analysis
Introduced the organization’s first automated view of evidence acceptance and rework by investigating 5,352 requests, validating how assessor activity was recorded, and designing a classification grounded in workflow history.60% → 76%First-pass acceptance among classifiable evidence requests
The challenge
The organization needed to understand how often evidence satisfied external assessors the first time and where rework occurred. Inconsistent acceptance records and offline reviews made a straightforward acceptance metric unreliable.
My contribution
I led the data investigation, worked directly with the assessor-portal product owner, designed the acceptance and rework classification, and delivered the acceptance dashboard through stakeholder review and customer validation. I partnered with a teammate on the supporting feedback analysis.
Decisions that mattered
- Challenged the original metric before implementation. Tested the proposed “passes until acceptance” measure against completed engagements and found that many requests never recorded acceptance. Demonstrated that relying on that status would omit a substantial population and misrepresent rework.
- Investigated the workflow behind the data. Worked with product and business owners to establish which status changes were automatic, which required assessor action, and how offline acceptance and subsequent edits affected the recorded history.
- Measured rework through observable feedback. Used chronological feedback transitions to identify rework, including requests that received feedback but were never formally marked accepted. Distinguished first-pass acceptance, rework, and requests without sufficient recorded activity.
- Made measurement coverage explicit. Kept requests without acceptance or feedback signals visible as excluded, documented the limitation with the customer, and presented the classification distribution alongside acceptance rates.
The outcome
Gave managers their first automated view of evidence acceptance and rework by engagement, program, and completion month. Among classifiable requests, first-pass acceptance increased from 60% before launch to 76% afterward, providing visibility into process performance and opportunities to address recurring feedback.
04Analytics engineering & CI/CDMedallion Gold-Layer & IaC Standardization
Established reporting-model and development standards that helped five engineers deliver consistent Gold-layer datasets through reviewed, version-controlled pipelines, with a common onboarding path for three BIEs.60% → 71%First-revision merge rate · 403 code reviews analyzed
The challenge
The team was moving from ad hoc dashboard SQL to code-managed data products. Inconsistent development practices, recurring design debates, and unclear validation requirements made changes harder to review and extend safely.
My contribution
I identified recurring gaps, authored four standards, and drove peer and stakeholder reviews covering development, customer access, reporting design, and dataset changes. I worked with data engineers on testing guidance and secured customer agreement on the approach for retiring legacy reporting fields.
Decisions that mattered
- Protected dataset grain as models evolved. Established explicit primary keys and rules for preserving upstream grain. Required separate datasets when measures needed different levels of detail, preventing enhancements from silently changing row meaning.
- Separated shared definitions from interactive calculations. Placed reusable business rules in code while keeping filter-dependent aggregations and rates in dashboards where they could recalculate correctly for the selected population.
- Turned validation into a repeatable release practice. Defined schema, uniqueness, row-count, and downstream metric checks, with before-and-after evidence required during review. Documented setup, testing, deployment verification, and troubleshooting.
- Established a controlled path for access and schema changes. Standardized viewer access from user acceptance testing through launch and secured agreement on replacement datasets for retiring legacy columns.
The outcome
All five engineers adopted the development standards, and three BIEs onboarded using the guide. Following adoption, first-revision merges increased from 60% to 71%, while average revisions declined from 1.58 to 1.44, approximately 9%.
05Engagement effort & operational measurementMaking engagement effort data trustworthy for cost and resource planning
Built submission, timeliness, and completeness metrics with manager exception reporting, helping turn data from a new time-tracking tool into a reliable foundation for engagement cost and resource planning.55% → 78%participation · 86.7% on-time submissions, customer-reported
The challenge
A new time-tracking tool captured PM hours against engagements to measure effort and staffing needs. Incomplete and late submissions made the data unreliable for cost-to-serve and capacity planning, requiring visibility into missing entries, timeliness, and completeness.
My contribution
I owned metric definitions, the expected-submitter data model, reporting ETL, QuickSight dashboard delivery, and customer validation. I also challenged the proposed timeliness definition, tested alternative cutoffs on real data, and secured customer agreement on the adopted rule.
Decisions that mattered
- Made missing submissions measurable. Built the expected employee-week population from the employee roster and a weekly calendar, then matched submissions to it. This kept people who logged no hours visible, giving managers a complete view of submission gaps.
- Reframed timeliness around what the source could support. The proposed daily lateness calculation required logging timestamps that the weekly submission model did not capture. I prototyped alternative cutoffs on real data and demonstrated the differences to the customer, who adopted the end of the following Monday, before Tuesday, as the weekly deadline.
- Defined the eligible population before calculating rates. Applied the organization’s location-based time-tracking exclusions so employees who were not expected to submit did not count against their teams. Kept submission participation, hours completeness, and on-time submission as distinct measures, each with an explicit definition.
- Turned exception reporting into manager accountability. Used employee-week flags to keep submission measures consistent across engagement views, and built manager leaderboards against agreed targets alongside weekly trends and regional breakdowns. Kept employee-level data restricted while giving managers visibility to act on gaps.
The outcome
Enabled more reliable engagement effort and resource planning through exception reporting and manager-level accountability. Customer-reported participation increased from 55% to 78%, while on-time submissions reached 86.7%, across 127 team members in 17 countries.
06Regulatory operations & data qualityAutomating regulatory assessment reporting and approval-pipeline visibility
Consolidated spreadsheet-based regulatory assessment reporting into a daily reporting product, with customer-approved definitions, upstream data corrections, and visibility into assessment and approval bottlenecks.~3 hours saved weekly10 business metrics · Four approval-pipeline stages
The challenge
A regulatory assessment team manually assembled metrics across spreadsheets and a separate dashboard. Fragmented reporting and inconsistent source records made it difficult to reconcile results and track changes through the approval pipeline.
My contribution
I owned the work from scoping through customer signoff: technical requirements, metric definitions, source investigation, reporting ETL, dashboard development, and validation. I also proposed an alternative data design when security restrictions prevented the requested use of ticket titles.
Decisions that mattered
- Resolved ambiguity before production development. Created a technical requirements document that captured metric definitions, filters, open questions, owners, and acceptance criteria. Secured customer agreement on all 10 metrics before implementing the production solution.
- Traced reporting errors to their source. Identified change records linked to multiple parents, inconsistent launch-date formats, and missing submission-batch start dates. Demonstrated their effects on counts and reporting periods, enabling source owners to correct the records.
- Preserved useful reporting within data-security constraints. Proposed a vetted, structured change-name field when storing unrestricted ticket titles was prohibited. Prepared ingestion and reporting so the approved-changes view worked once the customer populated the field.
- Combined throughput and bottleneck visibility. Brought approved changes, assessment timelines, submission volumes, hold reasons, and four pipeline-stage views into one daily reporting product.
The outcome
Removed approximately three hours of weekly manual reporting by delivering one customer-validated dashboard covering 10 business metrics and four assessment-stage queues.
07Engagement measurement & retrospective automationLaunching the organization’s first post-engagement snapshot dashboard and automated retrospective triggers
Saved eight hours of manual work per reporting cycle by delivering 37 engagement-level metrics across five categories and data-driven eligibility rules, introducing the organization’s first post-engagement snapshot dashboard and automated retrospective-triggering capability.8 hours saved per reporting cycle37 engagement-level metrics across five categories
The challenge
The organization had no standardized post-engagement snapshot dashboard or automated retrospective-eligibility mechanism. Teams needed a unified view of engagement performance and a consistent, data-driven way to identify which engagements warranted a retrospective.
My contribution
I owned metric definitions, data modeling, ETL, dashboard delivery, and customer validation. I also conducted the cohort analysis, proposed the P75 effort rule, and implemented the eligibility flags consumed by the data-engineer-built notification system.
Decisions that mattered
- Derived retrospective eligibility from cohort analysis. Analyzed total engagement hours across complexity, product, and region cohorts and proposed a P75 effort threshold. Incorporated status-history and complexity criteria into reusable eligibility flags, providing consistent, data-driven inputs to the retrospective-triggering workflow.
- Established a consistent engagement-level reporting model. Preserved the complete engagement population and kept metrics with different levels of detail separate. Missing source data remained visible as unknown values, allowing meaningful comparisons without silently excluding engagements or treating missing information as zero activity.
- Grounded staffing and duration metrics in recorded activity. Counted contributors using actual logged effort and calculated phase durations from system-recorded status transitions. Left unsupported durations unpopulated, giving stakeholders defensible measurements of participation and elapsed time.
- Designed sensitive-download metrics for privacy and accurate counting. Kept sensitive processing within the restricted layer and used email only during filtering, excluding it from reporting outputs. Counted distinct request–artifact–user combinations after identifying that bulk downloads could share timestamps, preventing separate downloads from being collapsed into one.
The outcome
Saved eight hours of manual work per reporting cycle while giving the organization its first unified view of post-engagement performance and its first automated mechanism for triggering retrospectives. Cohort analysis informed a P75 total-hours threshold, combined with status-history and complexity criteria, to identify qualifying engagements and feed the notification workflow.
08Workload analysis & cost optimizationReducing compute costs by sizing for the BI workload
Led workload analysis and recommended a smaller Redshift configuration, aligning compute capacity with the actual BI workload and contributing to confirmed annualized savings of $38,100.$38.1KAnnualized compute savings · 67% cost reduction
The challenge
A Redshift cluster served dashboards querying S3 through Spectrum. Assessing the right configuration required understanding active query demand, concurrency peaks, and memory needs separately from the historical data footprint.
My contribution
I investigated storage architecture, utilization, and BI concurrency; compared configuration costs and memory capacity; and recommended a smaller two-node configuration with headroom for peak dashboard workloads.
Decisions that mattered
- Sized against the workload being queried. Distinguished approximately 25.7 billion historical snapshot rows from 106 million latest-snapshot rows, establishing the relevant consumption footprint for the sizing analysis.
- Investigated peak demand rather than relying on averages. Reviewed dashboard query bursts and connection patterns, distinguishing four-to-five simultaneous queries from up to seven open connections.
- Balanced savings against memory pressure. Compared smaller configurations and recommended 32 GiB of memory per node over a 16 GiB option to retain more headroom for concurrent joins.
- Made the financial trade-off explicit. Compared the existing and recommended configurations, quantifying the opportunity to reduce monthly compute costs from approximately $4,760 to $1,585.
The outcome
The resulting configuration reduced confirmed monthly Redshift compute costs by approximately $3,175, equivalent to $38,100 annualized and a 66.7% reduction, rounded to 67%.
Explore aggregate outcomes, practical engineering decisions, and purpose-written portfolio case studies.
02 / HOW I WORK
Technical depth.
Business judgment.
I own analytics delivery end to end, translating ambiguous business needs into reliable data products, clear metrics, and actionable insights.
Measure what matters.
Coverage, timeliness, rework, and cycle time. I investigate the workflow before deciding whether a field is a trustworthy measure.
Metric design · Workflow history · Lifecycle modeling · QuickSight
Make quality repeatable.
Schema and key checks, row-count monitoring, source spot checks, and reviewed CI/CD. AI-assisted testing and code-review support stay within a human validation process.
Medallion / Gold layer · AWS CDK / IaC · CI/CD · Data quality contracts
03 / ARTIFACT LIBRARY
Take a closer look.
A resume for the overview.
Case-study briefs for the reasoning.
RESUME / PDF / 2 PAGES
The professional overview.
Experience, technical skills, and selected achievements.
- 01 / CASE STUDYP0 executive business-health reportingMD
- 02 / CASE STUDYReporting continuity & licensing savingsMD
- 03 / CASE STUDYEvidence quality & rework measurementMD
- 04 / CASE STUDYMedallion Gold-Layer & IaC StandardizationMD
- 05 / CASE STUDYEngagement effort data & resource planningMD
- 06 / CASE STUDYRegulatory assessment & approval-pipeline reportingMD
- 07 / CASE STUDYPost-engagement snapshots & retrospective triggersMD
- 08 / CASE STUDYRedshift compute cost optimizationMD
Download concise Markdown case-study briefs prepared for professional review.
04 / BACKGROUND
A career built
around the evidence.
My work spans security assurance analytics, revenue engineering, and industrial statistical modeling. I build analytics and business intelligence products that help teams understand complex workflows and make informed decisions.
EDUCATION
MS, Industrial Engineering
Statistics & Data Analytics · Arizona State University · 2019
BE, Mechanical Engineering
Visvesvaraya Technological University · 2017
- 2022 — PRESENT
Amazon Web Services
Business Intelligence Engineer, AWS Security Assurance
Seattle, WA - 2019 — 2022
Best Western Hotels & Resorts
Senior Data Analyst, Revenue & Analytics
Phoenix, AZ - 2018 — 2019
Arizona State University
Data Analyst Aide / Graduate Research Assistant
Tempe, AZ
LET’S CONNECT
Have a difficult
data question?
I’d like to hear what your team is working on.
