When ChatGPT launched, I was close to wrapping up my stint at Hearst. I watched our engineering and product teams start exploring AI use cases, and we experimented with replacing some algorithms we'd written at Semantics3. We tried having GPT-3 classify product attributes we'd spent months writing regex for, and it nailed 90% in the first attempt. We were floored at how far we could get with even zero-shot prompting. That's when I knew LLMs were going to transform how we approach engineering.

Fast forward to today, we've witnessed progress at breakneck speed. My teams are putting together POCs faster than ever using tools like Lovable, analyzing transcripts for action items, embedding powerful use cases into products, and we've even seen non-engineers leverage ChatGPT as their sounding board or data analysis tool.

As a VP of Engineering leading a team of 20 and working with other engineering and product teams across my organization, I've been a strong advocate of using AI tooling to enhance our day-to-day workflows. But I've also observed resistance or reluctance from some engineers to adopt these tools. I want to share the most common concerns I hear and how we've been working through them - not to dismiss these concerns, but to open up a broader conversation about how engineering teams can navigate this shift together.

"Is my data safe?"

This is not just a fair concern - it's a responsible question every engineer should ask. Skepticism here is warranted.

Here's what we've learned: while several AI tools on their free plans use data for training purposes, most (if not all) paid enterprise plans explicitly exclude data from training. OpenAI even allows you to opt out on their free plan. The key is reading the data usage policies carefully.

Here's what we've done to address this:

• Maintained a list of vetted tools approved by our legal and security teams that fit our risk tolerance
• Deployed company-wide paid plans with centralized access control
• Set up a private LLM deployment hooked up to Open WebUI for sensitive work (we use AWS Bedrock)
• Established clear guidelines: we strictly forbid using client data for analysis even on our paid ChatGPT/Claude plans

The goal isn't to eliminate risk entirely - it's to understand and manage it appropriately. Every organization will have different risk tolerances, and it's worth having these conversations explicitly rather than letting uncertainty prevent experimentation.

"Is it going to cost a fortune?"

I've had teammates worry that trying these platforms will rack up unexpected charges, especially with usage-based APIs. "What if it costs more than $10?" they ask.

Here's how I think about it: if spending $10 saves even a few hours of effort, or cuts delivery time from weeks to days, that investment pays for itself many times over. But I understand the anxiety around unpredictable costs.

To address this, we've implemented LiteLLM to manage per-API-key costs within the team. This lets us set budgets, prevent surprises, and most importantly, allows engineers to experiment without fear of an agent eating up all the credits.

As engineering leaders, it's important to set clear guidelines around experimentation costs and create an environment where teams feel safe trying new approaches without budget anxiety.

"It makes mistakes, so I don't trust it"

This concern often comes from early experiences with LLMs - limited knowledge, inconsistent outputs, the feeling that you could've done it faster yourself or the code is going to be unmaintainable. That's valid.

The landscape has shifted dramatically. With advances in reasoning capabilities and agentic frameworks, first-pass outputs are significantly more reliable. But here's what hasn't changed: engineers still need to verify the output. Think of it less like trusting a senior engineer and more like collaborating with a very capable but inexperienced team member.

The real skill isn't blindly accepting AI outputs - it's learning to:

• Break down complex tasks into smaller, well-defined pieces
• Prompt effectively to get the results you need
• Review and validate outputs critically
• Iterate when something isn't quite right
• Keep your codebase's documentation up to date

We've seen engineers on our team use Claude Code to refactor complex modules, not by accepting what it generates blindly, but by using it to explore different approaches faster, understand trade-offs better, and ultimately reduce timelines significantly while maintaining full ownership of the code.

"I'm worried about becoming deskilled"

This is one of the most thoughtful objections we hear, and it deserves serious consideration. There's a real risk that over-reliance on AI could erode skills, especially for early-career engineers who haven't fully developed their problem-solving muscles yet.

Our perspective: AI should amplify capabilities, not replace thinking. The engineers we see thriving with AI are those who:

• Use it to handle boilerplate and repetitive tasks, freeing time for complex problem-solving
• Leverage it to explore unfamiliar domains faster, then dive deep to truly understand
• Treat AI-generated code as a starting point for learning, not a black box to copy-paste

If you find yourself blindly accepting AI outputs without understanding them, that's a red flag. The goal is "you plus AI" being more effective than "you alone" - not "AI instead of you."

"I need to stay ahead of this"

I won't sugarcoat it: AI is reshaping what engineering work looks like. But the future isn't "AI replaces engineers" - it's "engineers who effectively leverage AI will be far more productive than those who don't."

The engineers who will thrive aren't necessarily the most senior or experienced today. They're the ones who are curious, adaptable, and willing to evolve their workflows. This doesn't mean everyone needs to become an AI expert overnight. It means staying open to experimentation.

"This feels overwhelming - where do I even start?"

If you're feeling this way, you're not alone. The pace of change can be daunting, especially if you're earlier in your career.

My advice: start small.

Phase 1: Low-risk assistance

• Use AI for writing documentation or test cases
• Have it explain unfamiliar code or concepts
• Generate boilerplate code for well-understood patterns

Phase 2: Collaborative development

• Pair programming with AI tools like Cursor or GitHub Copilot
• Use it to explore different implementation approaches
• Let it handle repetitive refactoring while you focus on architecture

Phase 3: Advanced workflows

• Experiment with agentic frameworks
• Build custom RAG systems for your domain
• Design AI-augmented development workflows

You don't need to master everything at once. Pick one small, repetitive task you do regularly and see if AI can help. Learn from that experience, then gradually expand.

Creating space for different adoption speeds

What we've learned as a leadership team: this isn't a mandate to transform overnight. Different people will adopt at different paces, and that's okay. What I'm suggesting is openness to experimentation.

If engineers are skeptical, we encourage them to start with low-stakes tasks. If they're concerned about data security, we review our policies together. If they're worried about costs, we help set up appropriate limits. If they're anxious about deskilling, we build in review processes that ensure understanding.

The role of engineering leadership isn't to force adoption - it's to create an environment where teams feel safe exploring these tools, learning from failures, and gradually building confidence.

Approach AI with curiosity and healthy caution

Every time I try a new AI tool, I go through the same cycle: the first two hours leave me in awe of what's possible. Then a sense of unease creeps in as I wonder whether we're moving fast enough, whether we risk falling behind.

I think both reactions are healthy. The awe keeps us curious and experimental. The unease keeps us honest about the pace of change and the need to evolve.

What we should be building in our engineering organizations is a culture where we embrace AI tools not out of fear of irrelevance, but out of excitement for what becomes possible when we augment our capabilities. Where we approach new technologies with both optimism and critical thinking. Where we support each other through the learning curve rather than judging those who adopt more slowly.

The future of engineering isn't AI versus humans. It's humans and AI working together in ways we're still figuring out. And that's a conversation worth having across the industry.

A practical suggestion: Monthly AI exploration day

Here's something we're implementing that might work for your team: dedicate one day a month for engineers to explore a new AI tool or capability. No specific deliverables required, just pure exploration.

The rules are simple:

• Pick any AI tool you're curious about
• Spend the day experimenting with a real problem or task
• Share what you learned (even if it didn't work out)
• If there's a cost involved, the company covers it

This removes the financial barrier, creates protected time for learning, and normalizes experimentation. Some explorations will lead nowhere. Others might transform how your team works. The key is building a culture where trying new things is expected, not exceptional.

If your organization doesn't have budget flexibility for this, start even smaller: a monthly lunch-and-learn where someone demos a tool they've been using, or a shared Slack channel where people post their AI experiments. The format matters less than the habit of continuous exploration.

I'd love to hear your thoughts and experiences. What resistance have you encountered? What's worked in your organizations?

Like pretty much all of us, our daily routines were turned upside down in February 2020 when COVID lockdowns hit. Most of us who were used to braving Bay Area traffic for an hour found it a relief that we could just work from home in the comfort of our pajamas, waking up 2 minutes before our 9am standup and gaining back all that lost time. I too shared that mindset in the first few weeks of the lockdown.

But over time, I began noticing some unique challenges in working with a fully remote workforce. While Individual Contributors (ICs) loved the fact that they could work uninterrupted, I was a manager - and a manager needs to understand where things are, how people are doing, influence and take decisions - all without micromanaging and scheduling endless catch-up calls. What could be done subconsciously while observing people work at an office suddenly became anxiety-inducing.

A Head Start with Remote Management

This wasn't entirely new territory for me. Since 2016, I was one of the few people working out of the San Francisco office for my startup while my entire team was based in Bengaluru. When our startup got acquired by Hearst in November 2020 (entirely over Zoom, I must say), I was tasked with leading a growing engineering team during the 2.5 years I was there. This presented a new challenge: managing people I barely knew in a completely virtual environment. Continuing that trend, in my currently role leading engineering for radar360, I am building teams in Chennai and Bengaluru while sitting 12.5 hours away in San Francisco.

Key Strategies for Effective Remote Management

1. Lead with Empathy

When you're not seeing someone face-to-face, you miss out on many subtle signals about how they're doing. It's easy to overthink delays or assume "away" statuses mean someone is slacking off. Remote management requires developing a new kind of emotional intelligence.

Let me share a personal example: I once had a team member who seemed unfocused and wasn't completing tasks on time. In a remote environment, it's easy to jump to conclusions about productivity issues. Instead of making assumptions, I scheduled a one-on-one and simply asked how they were doing. This opened up a conversation where they shared that their spouse was dealing with medical conditions, requiring frequent doctor visits and support. With this understanding, we were able to adjust their schedule to accommodate these important personal needs.

While such situations might have been noticeable in an office setting too, remote work tends to magnify our perception of productivity gaps. When we can't see the human behind the screen, we need to be even more intentional about:

• Pay attention to written communication tone and patterns
• Schedule regular one-on-ones focused on wellbeing, not just tasks
• Acknowledge the challenges of remote work openly
• Give people the benefit of the doubt when communication hiccups occur
• Create safe spaces for personal conversations

2. Overcommunicate, But Don't Overwhelm

In a remote environment, there's no such thing as too much clarity, but there is such a thing as too many meetings:

• Document decisions and discussions thoroughly
• Use asynchronous communication channels effectively; no communication should be on private chats unless absolutely necessary
• Set clear expectations about response times
• Create structured channels for different types of communication

One additional method that I practiced was always emphasizing the "why" rather than the "how". I spent a lot of time documenting my intention and vision, and I spent a lot of the meeting times explaining why I wanted to take something in a particular direction. I also always welcomed collaboration and input from others but the final decision was always with me. This was tiring and time consuming in the beginning but this turned out incredibly helpful when the team size grew. Teammates began to understand "how" I made decisions and they could take day-to-day decisions without inputs from me. This also meant fewer escalations to me.

3. Empower Regional Teams

Since I clearly communicated the "why", I could essentially delegate and empower people within the same region:

• Create regional pods or sub-teams where possible
• Account for time zones when structuring teams
• Enable local decision-making where appropriate
• Foster regional team culture while maintaining global connectivity

What this allowed me to do was to have a sync up my night with my Indian team leads on priorities for the day and I wake up in the morning to progress updates and sometimes even completion. This meant my team could effectively work 24/5 since my other teams were based out of New York and Ukraine. This definitely cannot be done on day one and needs one to gain some trust in the first place. But once established, it is truly empowering.

Building Trust in Remote Teams

One of the most critical aspects of remote management is building trust, which becomes even more challenging when you can't have casual coffee chats or impromptu hallway conversations. Here's how I approached building trust with teams I had never met in person:

Start with Small Steps

• Begin with well-defined, smaller tasks that allow team members to demonstrate reliability
• Provide clear success criteria and regular feedback
• Celebrate small wins publicly and learn from setbacks privately
• Gradually increase responsibility as confidence builds on both sides

Be Consistently Available

• Maintain predictable "office hours" across time zones
• Respond promptly to messages, even if just to acknowledge receipt
• Follow through on commitments, no matter how small
• Be transparent about your own challenges and mistakes

Create Psychological Safety

• Make it safe to ask questions and raise concerns
• Encourage experimentation and treat failures as learning opportunities
• Share credit for successes and take responsibility for failures
• Protect your team from external pressures while keeping them informed

Demonstrate Trust First

I found that to receive trust, you need to extend it first. This meant:

• Sharing strategic information openly
• Involving team members in important decisions
• Backing their decisions publicly, even if you might have made a different choice
• Giving them space to implement solutions their way, focusing on outcomes rather than methods

Trust Takes Time

Building trust remotely requires patience. In my experience, it took about 3-4 months of consistent interaction before team members felt truly comfortable taking major decisions independently. The investment in building trust pays off exponentially - what starts as needing approval for every decision eventually becomes autonomous execution aligned with team goals.

The Reality Check

While remote work has its advantages, we must acknowledge its limitations. As Microsoft CEO Satya Nadella pointed out, there are consequences to embracing remote work permanently. The key is finding the right balance for your team and organization.

Microsoft CEO Satya Nadella warns about the consequences of embracing remote work permanently

Microsoft is not taking the same financial beating as many of its peers due to the pandemic. Revenue jumped 15% in the first quarter of 2020, Microsoft

GeekWireMonica Nickelsburg

What We’ve Lost During the Pandemic…and What We’ve Gained

The pandemic created a fully digital global workforce overnight. Ongoing research shows the distinct challenges and advantages of this momentous shift.

WorkLabAll StoriesLeadershipCultureInnovationCollaborationPerformanceWellbeing

What We've Gained:

• Eliminated commute time
• Increased flexibility for team members
• Better work-life balance for many
• Access to global talent
• Reduced office overhead

What We Need to Work On:

• Building and maintaining team culture
• Spontaneous collaboration and creativity
• Mentorship and learning opportunities
• Mental health and burnout prevention
• Clear boundaries between work and personal life

The Blurred Lines of Remote Work

One of the most significant challenges of remote work is the blurring of work-life boundaries. Without the physical separation of an office, people tend to fall into one of two extremes: they either work constantly because their home has become their office, or they struggle to focus because home feels like it should be a place of rest.

Setting Healthy Boundaries

As managers, we need to actively help our teams establish and maintain healthy work-life boundaries:

• Encourage the creation of a dedicated workspace when possible
• Respect and model regular working hours
• Avoid sending non-urgent communications outside of working hours
• Support team members in setting up "work start" and "work end" rituals
• Recognize that different team members may need different scheduling flexibility

The goal isn't to enforce rigid schedules but to help people find their sustainable rhythm. Some team members might prefer early mornings while others are more productive in the evenings. The key is having clear boundaries between "work mode" and "personal mode," whatever those hours may be.

Looking Forward

The future of work will likely be hybrid, combining the best aspects of remote and in-person collaboration. As managers, our role is to continue adapting our leadership style to support our teams effectively, regardless of their physical location.

The most important lesson I've learned is that successful remote management isn't about controlling or monitoring - it's about enabling, supporting, and trusting your team to deliver their best work, wherever they are.

In 2010, while I was interning at a small Bay Area startup, I was in charge of DevOps and server administration. One day, while I was working on something, I noticed that our primary SSL certificate was expiring in 24 hours. I went into a full on panic mode because I knew the moment the certificate expires, all the connections to our backend will start failing for our customers.

I knew I had to alert others ASAP but I also knew time was of the essence. I spent the next 30 minutes quickly researching options, figure out how long it would take me to swap things out (remember I was an intern, so I wasn't really experienced). I collated everything, drafted an email to the CEO and a Senior Engineer alerting them about this and listed out the steps I was going to take in the next few hours. In a few minutes, I got a response from the CEO asking me to proceed with my proposal. But the engineer's response stuck with me throughout. He responded in the thread:

On another note, I love this email. I like how Vinoth not just came to us with the problem but also mentioned proposed steps to mitigate this.

As you progress higher up the ladder, your role tends to become less operational and more strategic. Put yourself in your manager's shoes - they are likely juggling a lot of context and responsibilities. As a reportee, you can get more out of your manager if you reduce their cognitive overload by providing options. This means not only identifying problems but also offering well-thought-out solutions. When you come to your manager with a problem, include possible solutions and the pros and cons of each. This allows them to quickly make an informed decision without getting bogged down in the details, freeing up their mental bandwidth for other strategic tasks.

This experience taught me the value of proactive problem-solving and how it can significantly ease a manager's workload.

Tell, Not Ask

I once had an excellent engineering manager reporting to me. He was a staff software engineer who was looking to become a manager so I decided to give him a shot and he exceeded all expectations.

During the annual appraisal review, he asked me for areas of improvement. I suggested something simple but powerful:

Instead of asking me if you can do something in a particular situation, tell me what you are going to do.

This approach demonstrates confidence and decisiveness. Managers appreciate team members who can independently assess situations and take appropriate actions. It shows that you are taking ownership and are capable of handling responsibilities without constant supervision. Moreover, it reduces the number of decisions your manager has to make, allowing them to focus on higher-level strategic initiatives.

But "Ask for Forgiveness" is Bad Advice

This common adage might seem bold and proactive. However, in practice, it can be risky and counterproductive. Acting without informing your manager can lead to misunderstandings, duplicated efforts, or worse, unintended consequences that could have been avoided with a bit of upfront communication.

Instead, aim for a balance. Keep your manager informed, but take initiative. Frame your actions in a way that shows you have thought through the implications and are prepared to take responsibility for the outcomes. This builds trust and demonstrates that you are a reliable team member who understands the bigger picture.

Happy Manager == Happy You

To make your manager love you, strive to make their job easier. Approach problems with solutions, communicate your actions confidently, and maintain a balance between independence and accountability. By reducing their cognitive load and demonstrating strategic thinking, you position yourself as a valuable asset to the team and an essential part of your manager's success.

One effective method to ensure your manager is always kept in the loop is the 5-15 method, a concise and structured way to communicate weekly updates. This was recommended to me by the head of our division at Hearst Magazines, and I religiously practiced it with my reporting managers. This technique involves spending 5 minutes writing a report that takes your manager 15 minutes to read. Here’s how it works:

1. Weekly Updates: Every week, spend 5 minutes summarizing what you have accomplished, what you are working on, and any issues or roadblocks you are facing.
2. Clarity and Conciseness: Keep your report clear and concise. Focus on key points and avoid unnecessary details.
3. Proposed Solutions: When reporting issues, include proposed solutions and potential next steps. This demonstrates your proactive approach and reduces the decision-making burden on your manager.
4. Consistency: Send these updates at a consistent time each week. This regular cadence helps build a habit and ensures that your manager can rely on your updates.
5. Feedback Loop: Encourage your manager to provide feedback on your updates. This helps you refine your reports to better meet their needs and keeps the lines of communication open.

The idea is that your manager will, in turn, do a 5-15 on all their reportees and share it with their manager (all the way to the CEO). By implementing the 5-15 method, you ensure that your manager is always informed about your progress and any challenges you are facing. This not only helps them stay updated but also builds trust and shows that you are reliable and proactive in managing your tasks.

By practicing these strategies, you'll not only gain your manager's appreciation but also foster a productive and trusting working relationship.

The 5-15 is an easy way to improve communication at your company

The technique has been around for decades, so why aren’t we all using it?

QuartzThe A.V. Club

Aim to keep all discussions in public channels unless it definitely has to be private. This ensures others on the team can follow discussions, decisions and have context that they can search for in the future.

Channel Naming Conventions

As the teams grow, so do channels. Keep them consistent and ensure members follow the topic of the channels.

One structure I follow for my products (lets assume the product is called "Mango"

#mango - general channel for all PMs, engineers and stakeholders. Anyone in the org can join and follow along.

#mango-engineering - only for engineers and engineering related discussions. You could either keep this private or only allow engineers to post

#mango-monitoring - pipe all monitoring related alerts to this channel (more on this below)

#mango-logs - only info/debug messages from services. These are set to 24 hour retention

Signal vs Noise

People wrongly assume that pushing all the monitoring alerts to a channel means engineers will have the info they need to make decisions. Monitoring channels need to be free of distraction and any alert that comes up on that channel should be actionable.

Whenever I saw a message on the #emergency Slack channel, I used to have a mini-panic attack.

Did one of my teams release something that broke the service?

Anything on the emergency channel was visible to all stakeholders, so we had to immediately jump on the alert and triage. My team was in-charge of a revenue critical service, whose downtime could mean a non-trivial revenue loss. And unfortunately, our services used to go down fairly frequently. So, I was always on high-alert.

If it ended up being our service:

• we had to triage it (no one knew who specifically)
• we had to fix it (what if that person is not available?)
• we had to release it (again who?)

With over 20 people in charge of the service, we baldy needed an improvement to our processes.

Current Processes

Two things our org did well:

• We were only allowed to deploy between 9am-3pm M-T. We needed to get approval for after-hours deploys, but nothing actually prevented the deploy itself from running. Some issues were later noted during post mortem to have occurred due to after-hour deploys.
• We had a strict roll-back-first policy if something goes wrong in production. So our services had to have been setup to handle this appropriately (database migration downgrade is written when deploying a new version to production, for example)

Each team had their own deployment processes and we used to follow on-demand deploys. When the tech lead feels like there are enough tickets, there is a hotfix or a new feature, they may choose to deploy it anytime during the day.

Testing was done by another team, but they were swamped with work so there was no approval process. We may push something to production before we get the testing team or the product manager's approval (!!).

Inspiration

According to Google's report, a team should ideally be in the Elite column for all aspects. We were in principle "Elite" for Deployment frequency, but that impacted our Change failure rate and Time to restore service. We needed to take a step back and rethink our strategy.

Bespoke Release Management

Each team may have their own requirements and SLOs to adhere to, so instead of focusing on org-wide changes, I focused on how we can ensure we are pushing out high quality and reliable code. There are several aspects to improving the reliability of an application but this post will talk specifically about the release management process.

Release Management Pair

First, we wanted to distribute the role of releases to ALL the engineers of the team. All the engineers were paired up based on their experience and were assigned a week in rotation. Pair transitions happened on Tuesday EOD (after minor release day) so that the context of the week remains with the same release pair until the service is in production.

This strategy sounds counter-intuitive and people were skeptical. But my take was this - release engineers get a first hand view of:

• how their PRs directly impact releases
• what other teams are working on
• what are the issues that plague production, and how the code written by them/others cause this

This turned out to be a fantastic decision. All the engineers started taking more ownership in the combined success of the service and actively started having discussions around how to reduce the chance of our service going down.

Primary

Primaries were the senior engineers on the team.

• Tracking PRs ready for release
• Cutting release and deploy to stage
• Coordinate with secondary to monitor deployment
• Notifying release manager when ready for production deployment
• After confirmation, deploy to production

Secondary

Secondaries were usually the more junior engineers. By shadowing a senior engineer, they get to learn while still playing an important role in the stability of the service

• Monitoring slack channels
• Reporting bugs on respective Jira boards
• Confirm if appropriate monitors/alerts have been setup. Adjust if too noisy

Manager

This role was either played by the tech lead, engineering manager or me as the director.

• On deploy days, managers will be on call with Primary and Secondary to walk through deployment
• Run through the deployment checklist
• Get PO sign off
  

Schedule

Doubling down on the org-wide mandate, we made sure no deployment happen after the cut-off time, 3PM. Any urgent deployments/fixes will need approvals from the product manager, engineering director and Devops.

In addition to that, we created 3 release days:

Minor Releases

Major (and if no major PRs, minor) releases will be done on Tuesdays 10am. They could be significant changes like optimizations, minor refactors but are not breaking changes. Major release essentially mean a minor semver version bump.

Tuesday gives the team almost 4 working days to monitor the service and roll back if needed.

Patch Releases

Minor releases will be done on Thursdays 10am. They can be minor fixes, logging, more observability code, tests etc.

Minor releases are the semver patch releases.

Major Architecture Changes or New Feature Releases

These releases were more involved and may even need multiple other teams on calls to coordinate. These were scheduled separately (again, either on Monday or Tuesday to give us time to monitor and roll back).

While there is no hard and fast rule, observation had shown that major release happen 2-4x a year, minor releases happen 2-4x a month, and patch releases very often

Release call

At 10am on release days, we have a call with all the representatives present - product manager whose PR is being released, testing engineer, release management pair, myself and any engineer whose PR is being released. We took these calls seriously and had to run through a checklist before the deploy.

The release management pair committed to pushing a release candidate to stage atleast 24 hours before a major release day. That gives the PMs and test engineers ample time to test key workflows. They could now also allocate time on Monday to test, instead of it being any part of the week.

Release calls were optional for minor releases because by definition nothing should be breaking.

Checklist

Heavily inspired by the Checklist Manifesto, we put together a simple template doc that we ran through during every release call. It served two purposes:

1. it had all the details about the release in a central place. If something goes wrong, we could immediately jump to this doc
2. it is now a shared responsibility. No one person can be blamed for a production issue because multiple people would have signed off

What now?

Once these changes were implemented and the engineers got used to this new process, we got a lot more efficient. By slowing down the process to only 2 releases a week, we actually ended up being more deliberate in our releases, code quality improved and the release was better tested for functionality.

Now, if I see an alert on the #emergency channel, I first look at the date/time. If it was a Wednesday, I could just return to what I was doing before.

Peacetime vs Wartime

The "Peacetime vs Wartime CEO" paradigm, popularized by Ben Horowitz, delineates the contrasting leadership approaches required during times of stability versus crisis. In the world of engineering, this dichotomy is just as pertinent. A "Peacetime Engineering Leader" might operate in an environment where innovation, long-term planning, and iterative improvements are priorities. They have the luxury to experiment, refine, and optimize, taking calculated risks to advance the technological frontier. Conversely, a "Wartime Engineering Leader" is thrust into a scenario of pressing challenges—be it system outages, architectural flaws, or urgent product rollouts. Here, swift decision-making, resource triage, and immediate problem-solving become the order of the day. Much like Horowitz's CEOs, engineers too must adapt their strategies and mindsets based on the situational demands of their projects and organizations.

When would this be necessary

Lack of an Engineering Roadmap

When I took over the team, there wasn't a set engineering roadmap for the product. The team started off as a few engineers writing a wrapper service around Semantics3, but quickly grew way past its intended use case when stakeholders started seeing a lot of potential in the service. What then happened was a product driven roadmap which resulted in a lot of interesting features being built, but at the expense of proper technical architecture. Adding something new used to break some other part of the service. The service would not scale. There were several other bugs which plagued the service and soon the optimism of the stakeholders turned into frustration.

Lack of Consistent Processes

Deployment Schedules

Whenever I saw a message on the #emergency Slack channel, I used to have a mini-panic attack. Did one of my teams release something that broke the service? Anything on the emergency channel was visible to all stakeholders, so we had to immediately jump on the alert and triage. My

Vinoth GopiVinoth Gopi

Lack of Motivation

Without a goal to be working towards, the engineers started losing the drive to work on the tickets. This was a death spiral and resulted in poorer and poorer output over time.

Everything is Failing

We sometimes had no idea what was happening or what was going wrong. We had several tools at our disposal for monitoring, SLOs and observability but they were not being used to its fullest potential.

What to do?

Take ownership

The first instinct of a new person joining an existing team is to look at all the ways things are going wrong. When I was brought on board, while recognizing the issues, I tried to dig deeper into why things were the way they are. This led me to uncovering the decisions that were taken along the way and the assumptions of the service owners.

Once I had this distilled down, I knew I had to be the one to ring the alarm on the situation. As a leader, you should not only be the one ringing the alarm, you should also be the one bringing solutions to the table. So I drafted a detailed notion doc listing out how we got here, why this is unsustainable and what I'd like to propose.

Armed with the proposal, I now had to convince the rest of the org that this was the path to take.

Alignment with PED counterparts

The next course of action is to get buy-in from your product, design and engineering counterparts. This is probably the crucial part of the step because if you do not have alignment with them, you are going to be in loggerheads with them for every product feature or ticket.

We agreed upon a higher than usual % of story points for engineering related efforts - 50% in the beginning and gradually ramp down to 20% as the service was more stable and we hit pre-defined milestones.

Transparency with stakeholders

I vividly remember having this call in May 2022 - over 10 people on call representing different aspects of the business - editors, ads, affiliate revenue and others. I was prepared for this call to be a challenging one for multiple reasons:

• I was about to pitch a plan that asked for 6 months to turn things around. This meant some of their product asks would need to take a backseat.
• I knew I wasn't the first person proposing drastic changes to the architecture. There were a few attempts before this and they weren't successful.

I pre-empted this and made sure my presentation addressed these concerns. I set out 3 plans:

• In 6 weeks, deliver 2 quick wins in terms of improvements to data quality and uptime
• In 3 months, fix 2 medium sized issues
• In 6 months, fix 2 foundational architectural issues

I wasn't in this alone by this point though. I had the PMs backing my plan and we presented a united front.

Eventually, I had a few questions come in from the stakeholders but they decided to give me a chance and gave me the thumbs-up.

All-hands on deck

I aimed to ensure that all engineers involved in the product were aware of our current situation, the promises I had made to stakeholders, and the ongoing progress within our established timelines.

To achieve this, I initiated a weekly engineering all-hands meeting dubbed the "War Room." I strictly emphasized that these discussions were exclusive to me and the engineers under my supervision. This exclusivity was not well-received by my counterparts in product management. Even my direct superior, the VP, was only briefed on the happenings of the meetings but not invited to participate. This approach was designed to foster a secure environment where engineers could express their thoughts without reservation. I pledged to consider all feedback attentively, ensuring no suggestion was dismissed without due consideration.

The call's Notion doc only had 3 questions:

• Topics of Discussion (Filled up by any engineer with questions or suggestions the night before the call)
• Highlights (Filled up by engineers who have fixed a previously identified issue or a new feature)
• Action Items (Filled up by me, during the call, as we run though the discussion topics)

Outcome

Week after week, for an entire year, our focus was on solidifying the platform. By December 2021, after nearly 6 months of these intensive sessions, we successfully shifted our discussions to a different phase, rebranding our meetings as simply "All-hands." Our persistent efforts had resolved all pressing issues, allowing us to repurpose these gatherings. Instead of troubleshooting, we moved on to sharing weekly updates and giving engineers the floor to showcase their recent work.

The stakeholders were overjoyed - we delivered what we committed to delivering and also set the stage for faster feature releases.