How a Creekside Mentor Found Her Hybrid Career Path While Building a Local Team's Cloud Foundation

A mentor at Creekside recently shared how she built her hybrid career — part hands-on cloud engineer, part team builder — while establishing a local team's cloud foundation from scratch. Her story isn't about a single dramatic breakthrough. It's about the daily decisions that shape a career that serves both personal growth and community needs. This guide draws on that experience to help you navigate your own hybrid path.

For anyone who wants to combine deep technical work with mentoring and local impact, the path can feel unclear. You might worry that stepping into leadership means losing your hands-on edge, or that staying technical will limit your ability to grow others. The good news: you don't have to choose. Hybrid careers in cloud infrastructure are not only possible — they're increasingly necessary for teams that want sustainable, people-first foundations.

In this guide, we'll walk through the key lessons from one mentor's journey, from the concepts that confuse most newcomers to the patterns that actually hold up over time. You'll come away with a framework for building your own hybrid role, whether you're starting a new team or reshaping an existing one.

1. Where This Shows Up in Real Work

Picture a small but growing company in a mid-sized city. They've just decided to move their core applications to the cloud. There's no dedicated cloud team yet — just a handful of developers who know a bit of AWS or Azure, and a manager who wants to build internal capability rather than hire expensive consultants. This is where hybrid careers thrive.

The mentor we're following joined as a senior engineer but quickly realized the role demanded more. She needed to design the cloud architecture, yes. But she also needed to teach junior developers how to think about networking, security, and cost. She had to write runbooks, facilitate knowledge-sharing sessions, and create a culture where people felt safe asking questions. That's the hybrid career sweet spot: you contribute directly to the infrastructure while building the team's ability to own it.

Why Local Teams Matter

Building a local team's cloud foundation isn't just about technology. It's about creating opportunities for people in your community to develop high-value skills without relocating. The mentor noticed that many talented engineers in her area were overlooked by big tech companies that recruit nationally. By investing in local talent, she helped close that gap while building a team that understood the business context deeply.

Concrete Scenarios

In one project, the team needed to migrate a legacy application to AWS. The mentor paired with a junior developer who had never touched a cloud console. Together, they set up a VPC, configured security groups, and deployed a test instance. The junior learned by doing, and the mentor got to reinforce her own understanding by explaining each decision. That's the hybrid model in action: teaching and building happen simultaneously.

Another scenario involved a tricky IAM permissions issue. The mentor could have fixed it herself in ten minutes. Instead, she walked the team through her troubleshooting process, showing them how to read CloudTrail logs and test policies iteratively. The fix took an hour, but the team gained a skill they'd use repeatedly. That trade-off — short-term efficiency for long-term capability — is central to hybrid work.

The Career Arc

Over time, the mentor's role evolved. She spent less time writing Terraform and more time reviewing pull requests, designing training modules, and facilitating retrospectives. But she never stopped coding entirely. She reserved Fridays for hands-on work — a practice she called "keeping your hands dirty." That balance kept her technical credibility high while allowing her to scale her impact through others.

2. Foundations Readers Confuse

Early in her journey, the mentor noticed several concepts that consistently tripped up newcomers — and even experienced engineers moving into hybrid roles. Let's clear them up.

Cloud Foundation vs. Cloud Migration

A cloud foundation is not the same as a migration. A foundation includes the base infrastructure: accounts, networking, security baselines, identity management, and cost controls. Migration is moving applications onto that foundation. Many teams try to migrate without a solid foundation, leading to security gaps, cost overruns, and operational chaos. The mentor learned to insist on foundation first, even when business stakeholders pushed for quick wins.

Hybrid Career vs. Full-Time Management

A hybrid career is not a half-hearted version of management. It's a deliberate blend of individual contributor work and leadership. The mentor still owns technical decisions, but she also coaches, mentors, and shapes team culture. That's different from a manager who rarely writes code. If you want to stay technical while leading, you need to protect time for hands-on work and be explicit about your dual role with your team and your own manager.

Mentoring vs. Teaching

Mentoring is not the same as formal teaching. Teaching often involves structured curricula and assessments. Mentoring is more organic — it happens in code reviews, pair programming sessions, and hallway conversations. The mentor found that the most effective learning happened when she worked alongside team members on real problems, not when she prepared slides. She called it "shoulder-to-shoulder mentoring."

Local Team vs. Remote Team Dynamics

Building a local team has unique advantages and challenges. Proximity allows for spontaneous collaboration and deeper trust. But it also means you can't hire from a global pool. The mentor emphasized that local teams need different onboarding practices — more hands-on, more patient — because you're often working with people who are early in their cloud journey. She also found that local teams benefit from regular in-person workshops and social events that build camaraderie.

3. Patterns That Usually Work

Over several years of building and mentoring, the mentor identified patterns that consistently delivered results. These aren't silver bullets, but they're reliable starting points.

Start with a Well-Architected Framework Review

Before writing any infrastructure code, the mentor led the team through a Well-Architected Framework review. They assessed the current state against the six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. This gave them a shared vocabulary and a prioritized list of improvements. It also helped the team understand why certain decisions mattered, not just how to implement them.

Use Infrastructure as Code from Day One

Even for small projects, the mentor insisted on infrastructure as code (IaC) using Terraform or AWS CDK. IaC made changes reviewable, repeatable, and auditable. It also served as living documentation. New team members could read the code to understand the architecture, which reduced the mentoring burden. The mentor found that investing in IaC early paid off exponentially as the team grew.

Establish a Shared Responsibility Model

Cloud security is a shared responsibility between the provider and the customer. The mentor made sure every team member understood which parts they owned: identity and access management, data encryption, network controls, and incident response. She created a simple table that mapped each security control to the responsible party. This clarity prevented gaps and reduced anxiety about "the cloud being insecure."

Pair Programming for Knowledge Transfer

Pair programming wasn't just for code — the mentor used it for infrastructure work too. She'd pair with a junior engineer to write a Terraform module, explaining each resource and its purpose. The junior would drive the keyboard while the mentor navigated. This hands-on approach built confidence faster than any training course. The mentor scheduled two pair sessions per week, rotating through the team.

Create a "Cloud Guild"

To sustain learning beyond one-on-one mentoring, the mentor launched a weekly "Cloud Guild" meeting. Anyone in the company could attend. Each session covered a specific topic — like VPC design, cost optimization, or incident response — with a mix of presentation and discussion. The guild became a forum for sharing lessons learned and asking questions. It also helped surface issues early, because people felt comfortable raising problems in a learning environment.

4. Anti-Patterns and Why Teams Revert

Not every approach works. The mentor saw several anti-patterns that caused teams to stall or revert to old habits. Recognizing them early can save you months of frustration.

Over-Automation Before Understanding

Some teams rush to automate everything with CI/CD pipelines and auto-scaling before they understand the basics. When something breaks, they can't debug it because the automation hides the underlying mechanics. The mentor advised automating only after the team has manually performed the task at least once. She called this "learn before you automate." For example, they manually created an EC2 instance and configured it before writing a Terraform module. That hands-on experience made the module more robust.

Neglecting Documentation

In a hybrid career, documentation is a force multiplier. But many teams treat it as an afterthought. The mentor required runbooks for every operational procedure. She also maintained a "decision log" that recorded why certain architectural choices were made. When she was unavailable, the team could follow the runbooks without her. Documentation also helped new members ramp up faster. The mentor found that teams that skipped documentation ended up with "tribal knowledge" that created bus-factor risks.

Hero Culture

Some organizations reward the engineer who stays late to fix a crisis. That's hero culture, and it's toxic for hybrid careers. The mentor actively discouraged it by celebrating preventive work — like improving monitoring or writing tests — as much as firefighting. She also insisted on rotating on-call duties so that everyone shared the operational load. Hero culture leads to burnout and prevents junior engineers from developing troubleshooting skills.

Ignoring Cost Visibility

Cloud costs can spiral quickly if no one watches them. The mentor saw teams that deployed resources without tagging them, making it impossible to attribute costs to projects or teams. She implemented a tagging strategy and set up cost anomaly alerts. She also held monthly cost reviews where the team discussed trends and identified savings. Without cost visibility, teams often revert to on-premise thinking — "it's cheaper to just buy a server" — which undermines the cloud foundation.

5. Maintenance, Drift, or Long-Term Costs

Building a cloud foundation is not a one-time project. It requires ongoing maintenance, and the costs — both financial and human — can surprise teams that don't plan for them.

Drift in Infrastructure as Code

Over time, manual changes can cause IaC to drift from the actual environment. The mentor used tools like Terraform plan and AWS Config to detect drift regularly. She scheduled a weekly review of plan outputs to catch unauthorized changes. Drift undermines the reliability of IaC and can lead to configuration errors. The mentor's team treated drift as a high-priority bug, not a minor inconvenience.

Knowledge Decay

If team members don't practice cloud skills regularly, they forget them. The mentor noticed that after a few months of focusing only on operations, junior engineers lost the ability to design new architectures. To combat this, she encouraged "innovation sprints" — two-week periods where team members could build prototypes or explore new services. This kept skills fresh and generated ideas for improving the foundation.

Technical Debt in Security Baselines

Security requirements evolve. A baseline that was adequate a year ago may no longer meet current standards. The mentor scheduled quarterly security reviews to update IAM policies, encryption settings, and logging configurations. She also tracked security findings from AWS Inspector and GuardDuty, assigning remediation tasks with deadlines. Neglecting security debt can lead to compliance violations or breaches, which are far more expensive to fix later.

The Cost of Mentoring Time

Mentoring takes time, and that time has an opportunity cost. The mentor estimated she spent about 20% of her week on mentoring activities — pair programming, guild sessions, and one-on-ones. That's time she could have spent on technical work. But she viewed it as an investment. The payoff came when the team could handle incidents without her, freeing her to work on higher-level architecture. She advised being transparent with stakeholders about this trade-off so they understood why certain projects took longer.

6. When Not to Use This Approach

The hybrid career model isn't right for every situation. Knowing when to step back is just as important as knowing when to lean in.

When the Team Is Too Small

If you're a team of one or two, spending 20% of your time on mentoring may leave you too stretched to deliver on core responsibilities. In that case, focus on building a solid foundation yourself and document everything. You can shift to mentoring mode once the team grows to at least three or four people. The mentor's team started with three, and she waited until they had a stable base before investing heavily in mentoring.

When the Business Needs Speed Above All

If the company is in a race to launch a product or meet a compliance deadline, the slower pace of mentoring may not be appropriate. In such cases, it's better to bring in experienced contractors or consultants who can move fast, while the internal team observes and learns. The mentor used this approach during a critical migration: she led the effort but paired a contractor with a junior engineer on each workstream, so learning happened without slowing the timeline.

When the Culture Doesn't Support Learning

Some organizations view training as a cost, not an investment. If your company isn't willing to allocate time for learning or doesn't value mentoring, pushing a hybrid model will lead to frustration. The mentor encountered this in a previous role and eventually left. She advises having an honest conversation with leadership early: "If we want to build internal capability, we need to invest in mentoring time." If the answer is no, consider whether the role is right for you.

When You Personally Need a Pure IC Focus

Not everyone wants a hybrid career — and that's okay. If you prefer to dive deep into technical problems without the responsibility of developing others, a pure individual contributor path may be more fulfilling. The mentor herself went through phases where she stepped back from mentoring to focus on a complex architecture challenge. Hybrid careers should be flexible, not rigid.

7. Open Questions / FAQ

Based on conversations with readers and workshop participants, here are answers to the most common questions about hybrid careers in cloud foundations.

How do I convince my manager to let me spend time on mentoring?

Frame it as a business case. Show that mentoring reduces bus-factor risk, accelerates onboarding, and improves team retention. Offer to track metrics: time to first deploy for new hires, number of incidents handled without senior involvement, or survey scores on team confidence. The mentor used a simple spreadsheet to show that after six months of mentoring, the team could handle 80% of incidents without her.

What if I'm the most senior person and have no mentor myself?

That's a common challenge. Look for external communities: cloud meetups, online forums, or professional coaches. The mentor joined a local cloud user group and found a peer mentor there. She also subscribed to a few newsletters and attended virtual conferences. You don't need a formal mentor — just a network of people you can ask for advice.

How do I keep my technical skills sharp while mentoring?

Protect at least one day a week for hands-on work. Use that time to build something new, not just maintain existing systems. The mentor called this "innovation time." She also rotated through different areas of the cloud stack — networking one month, security the next — to avoid getting rusty in any one area. Teaching others also reinforces your own knowledge, so mentoring itself can be a learning tool.

What's the biggest mistake teams make when starting a cloud foundation?

Underestimating the importance of identity and access management. Many teams start with a single AWS account and overly permissive IAM roles, then struggle to tighten security later. The mentor recommends starting with a multi-account strategy (using AWS Organizations) and least-privilege IAM policies from day one. It's harder to retrofit security than to build it in from the start.

If you're ready to start your own hybrid career journey, here are three concrete next steps: (1) Identify one junior colleague you can pair with for two hours this week on a real infrastructure task. (2) Schedule a Well-Architected Framework review for your current cloud environment. (3) Block out Friday afternoons for your own hands-on learning. The hybrid path isn't a straight line, but with intentional practice, you can build a career that serves both your team and your own growth.