Engineering Management: ZIRP Era vs Now
From 2008 to early 2022, the tech industry thrived under the Zero Interest Rate Policy (ZIRP), characterized by abundant venture capital and a low cost of borrowing. This era enabled a period of unprecedented growth and competition for talent, spurring companies to deploy extraordinary measures to attract and retain employees.
The Hiring Frenzy and Employee-Centric Culture
Money flowed freely from venture capital channels, boosting startups and fueling the expansion of big tech. Companies were locked in a fierce battle for talent, sometimes hiring aggressively not just to meet their own needs but to prevent competitors from accessing key resources. This talent-centric approach pushed employers to offer innovative policies and perks, fostering an environment where employee satisfaction and retention were top priorities.
Employee Demands and Benefits
With tech firms eager to differentiate themselves, employee demands evolved and were often met with enthusiasm. Compensation packages reached record highs, extending across all experience levels. In addition to competitive salaries and equity, employees sought and received:
Luxurious office perks, such as sleep pods.
Options for a four-day workweek.
Flexible work arrangements, including hybrid or remote setups.
A strong emphasis on work-life balance.
Opportunities for consistent career progression.
Expansive diversity, equity, and inclusion (DEI) initiatives.
Meanwhile, trends like crypto, NFTs, and Web 3.0 emerged, attracting attention and resources, adding to the feeling of a tech-driven gold rush.
The Post-ZIRP Era: A Shift in Priorities
When 2022 arrived, the landscape changed abruptly. Rising interest rates and economic pressures drained liquidity from both public and private markets. The shift came with immediate consequences: hiring freezes swept the industry, followed by waves of layoffs. Even DEI programs—once a symbol of cultural investment—suffered deep cuts.
Employer Control and Policy-Centric Management
In the post-ZIRP reality, power dynamics shifted back to employers. Tech companies, facing financial headwinds, moved to tighten policies and exert control. Return-to-office (RTO) mandates became a focus for many C-suite executives, signaling a departure from the flexible norms of the previous era. High-cost engineering positions were replaced with lower-cost alternatives as cost-saving strategies took precedence.
AI as the New Frontier
While tech trends shifted, AI rose as a dominant focus in industry conversations and investments, replacing the speculative fervor of Web 3.0 and similar pursuits.
The Role of Engineering Management: Then and Now
The ZIRP era was primarily about attracting, hiring, and retaining talent. Today, it’s more about employer-defined policies, which employees can choose to accept or reject. If they don’t, the current talent pool is abundant enough that replacing an employee is feasible and often less costly for employers in the long run. Engineering managers (EMs) have had to adapt to this shift.
While EMs in the ZIRP era were focused on people—their growth, happiness, and overall well-being—now, they are more focused on enforcing employer-defined policies.
During the ZIRP era, EMs could hire aggressively and expand teams without significant budget constraints. The approach of “growth at all costs” was common, resulting in a competitive job market with generous compensation packages. Now, companies are more conservative with hiring and resource allocation. Engineering management must make do with leaner teams and optimize productivity per employee, leading to a stronger emphasis on cross-training, retention strategies, and building teams that are adaptable and resilient.
In the ZIRP era, managers had greater freedom to explore side projects, experiment with new technologies, and take risks on unproven initiatives. Failure was more acceptable as long as some projects led to breakthroughs or competitive advantages. Today’s environment, however, demands a more strategic approach. EMs must be selective about which projects to approve, prioritizing those aligned with business objectives and contributing directly to revenue or efficiency. The prioritization process is more rigorous, with increased pressure to demonstrate tangible outcomes.
During the ZIRP era, the culture within engineering teams was often more relaxed, with ample opportunities for team-building events, hackathons, and learning-focused initiatives. Managers aimed to create a collaborative, growth-oriented atmosphere. Now, EMs must find creative ways to maintain morale in a more constrained environment. Budget cuts and stricter deadlines mean that sustaining a positive culture requires more targeted efforts in communication, transparency, and support.
EMs during the ZIRP era often had the latitude to build features ahead of clear market needs, with the expectation that demand would follow. Now, projects are closely tied to market feedback and product-market fit. Engineering managers collaborate more with product, finance, and operations teams to ensure that features provide immediate or long-term value to customers.
Adapting to a New Reality
In conclusion, engineering management has had to pivot from a nurturing, people-first approach to one centered on policies and efficient execution. While the ZIRP era allowed for expansive growth and exploration, today’s landscape demands precision, accountability, and alignment with business goals. Engineering leaders who navigate these changes effectively will ensure their teams remain resilient and productive, adapting to the challenges of this new, more conservative era.
For those who were part of the ZIRP boom, it was a memorable ride. Now, it’s time for leaders to evolve and thrive in a different, more disciplined environment.
Deadlines are good!
"Work expands so as to fill the time available for its completion." – Parkinson’s Law
Yes, it’s a controversial topic, no doubt. Engineers often dislike giving estimates, precisely because of the debates around deadlines. But I encourage you to read this blog with an open mind. And if you strongly disagree, feel free to reach out!
A Story from the Trenches
Our team once embarked on a high-visibility project as a platform team. We drew clear lines between ourselves and the product team, planned the project carefully, and set deadlines based on engineers’ estimates. We factored in story points, QA estimates, and buffers (of course). The timeline? Three months, just for the platform work—without even knowing how long it would take the product team to integrate with us.
Then, everything changed. The CEO called a meeting, asked for an update, and dropped a bombshell:
Cut the deadline in half—release an MVP in 1.5 months, not 3.
Platform engineers need to integrate the product code—even though we had no prior experience with that part of the codebase.
We left the meeting shocked, worried, and, of course, cycling through the classic stages of grief. But after some denial and anger, I called the team to regroup. Here’s what we did:
The Game Plan
We knew 1.5 months wasn’t enough to ship all the features we had envisioned, so we reduced the scope. This exercise involved intense collaboration between Product Managers and Engineers. Together, we focused on what could realistically be completed in the shorter timeline.
Vertical slices, not horizontal layers. Instead of building software in horizontal layers (like backend first, then frontend, then integration), we chose to deliver vertical slices—complete, end-to-end features. This minimized integration time at the end and allowed us to show progress at regular intervals. It also gave QA a chance to build functional tests in parallel with development.
We also planned for regular demos to stakeholders. These were key for keeping everyone in the loop and ensuring that any issues were spotted early. Progress updates every two weeks helped maintain trust, and showing visible advancement helped alleviate the pressure of the reduced timeline.
Key Learnings
Timeline and Scope Are Inextricably Linked. Reducing the timeline without adjusting the scope is a recipe for disaster. Achieving the same scope in less time usually means one of two things: either the original estimate had too much buffer, or the team is being pushed to burnout. Both scenarios reflect poorly on leadership.
Plan for Regular Demos. Demos should be baked into the project plan. Waiting until everything is done to show progress is risky. By the time the project is finished, it could be too late to fix major issues, and you’ve already invested time and money. Regular demos help manage expectations and give stakeholders confidence that the project is on track. Think of them as a “loading status bar” for your project—they show that things are moving, even if slowly.
Work in Vertical Slices. Build features end-to-end so you can demo progress incrementally. Even if some parts are still under construction, show what’s ready. This gives stakeholders visibility and allows them to provide feedback early, while the project is still adaptable.
Testing Should Be Parallel, Not Sequential. QA shouldn’t be an afterthought. Ideally, functional tests should be built as soon as development is complete, allowing for a “crab approach,” where testing follows just behind development. This keeps quality checks continuous, rather than crammed in at the end.
Clarity Drives Speed. When everyone knows their role and the overall project plan is clear, execution speeds up. Momentum builds, and before you know it, deadlines are met. Assigning a dedicated project lead can also help maintain this clarity and pace.
Success Breeds Success—But Beware of Burnout. Once a team experiences success, they’ll want to keep that momentum going. But leaders need to be careful of burnout. A well-functioning team can handle big challenges, but only if they’re paced correctly.
Deadlines: A Double-Edged Sword
Unrealistic Deadlines: Aggressive timelines can lead to cutting corners, burnout, and a final product that’s far from perfect. If the pressure is too high, the cost of errors, rework, and team turnover can outweigh the benefits.
Creativity Under Pressure: Yes, deadlines can stifle creativity. Engineers and designers may opt for the quickest solution, rather than the best one. Deadlines need to be balanced—hard enough to push, but soft enough to allow creativity. Fun fact: many of Leonardo Da Vinci’s works were never completed because he didn’t impose deadlines on himself. A classic case of Parkinson’s Law in action!
Deadline Over Value: Sometimes, the focus shifts from delivering value to just hitting a date. That’s when projects start suffering from the "tick-the-box" mentality, where meeting the deadline becomes more important than solving the actual problem.
Demoralization and Impact on Collaboration: Constant deadline pressure demoralizes teams, leading to burnout and turnover. A demoralized team doesn’t just lose productivity—it also loses its collaborative spirit.
The Takeaway
Deadlines are necessary, but they must be balanced with the realities of scope, risk, and team dynamics. If used thoughtfully, they can sharpen focus and drive success. If imposed recklessly, they can crush creativity and ruin team morale. Use them wisely, and don’t forget that your team’s well-being and the value delivered are as important as the date on the calendar.
How do I hire for my Engineering teams?
"A players hire A players, but B players hire C players."
I’ve hired extensively throughout my career, for various levels and roles, from individual contributors to team leads, engineering managers, and even once, my own boss—a Senior Director of Engineering! Hiring the right talent is one of my most critical responsibilities as an engineering executive. The success of my team—and the organization as a whole—hinges on getting the right blend of skills, creativity, and alignment with the company’s values. With each new hire, my aim is to raise the bar and push the team toward greater excellence.
Here are some guiding principles I follow while hiring:
1. Have a Clear Goal in Mind
Unless I’m mass hiring, I always start with a clear goal for what I want to achieve with each new hire. Defining what success looks like at 30, 60, and 90 days post-hiring helps me crystallize these goals. If there are essential technical skills or programming languages, I ensure candidates being sourced for interviews meet those requirements upfront.
2. Hire for Strengths
Every candidate will have strengths and weaknesses. I focus on hiring for strengths, as long as their weaknesses are coachable, and I sense an openness to learning and growth. While I maintain a clear goal, I don't box myself into preconceived notions of the “type” of candidate I want to hire. Instead, I meet each individual with an open mind, prioritizing competency over specific skillsets.
3. Problem Solving and Collaboration
Great engineers not only need to solve problems but also collaborate effectively with others—whether it’s fellow engineers, product managers, designers, or stakeholders. While problem-solving capabilities can be gauged through technical interviews like system design or algorithmic challenges, collaboration is equally important. To assess this, I often ask candidates to describe a situation where they disagreed but committed. Both problem-solving and collaboration are non-negotiable. Missing either of these will likely result in a suboptimal hire.
4. Balance Between Generalists and Specialists
I decide whether I need specialists with deep expertise in a particular area or generalists who can navigate multiple technologies and domains. A well-rounded team usually benefits from having a good mix of both, allowing us to remain adaptable and innovative.
5. Sell the Vision
In a competitive market for top engineering talent, it’s not just about evaluating candidates—it’s about convincing them to join my team. I take an active role in selling the company’s vision and showing how the team fits into that broader mission. I’m transparent about the challenges we’re facing but also emphasize the exciting opportunities. At the same time, I look for signs of whether the candidate is genuinely excited about our vision. Engineers who are invested in the company’s mission tend to outperform those who are simply there to check off tasks on Jira tickets.
6. Strive for Diversity
Building a diverse team is critical for bringing fresh perspectives, improving problem-solving, and fostering innovation. I actively seek out candidates from various backgrounds, reaching beyond the usual recruiting channels. I partner with organizations that promote diversity in tech, target underrepresented groups, and expand our hiring beyond traditional geographic areas. I also work to minimize unconscious bias in the interview process by using standardized questions, diverse interview panels, and data-driven evaluations to focus on a candidate’s abilities and potential rather than irrelevant factors.
7. Onboarding for Success
Hiring doesn’t end when the offer is signed. A comprehensive onboarding process is essential for making new hires feel welcome, helping them understand their role, and ensuring they can ramp up quickly. I pair new hires with mentors to help them navigate both technical challenges and team dynamics in the early days. I also encourage early and continuous feedback, which helps new employees adjust, grow, and feel valued. Creating a culture where feedback is constructive and recognition is frequent is crucial to their long-term success.
Final Thoughts
As an engineering executive, building the right team is a mix of strategy, thoughtful evaluation, and understanding the balance between technical skills and cultural fit. By focusing on potential, creating a rigorous but fair process, and making diversity a priority, I aim to build a high-performing team that drives innovation and success.
Complexities of building a Billing System
I have had the pleasure/pain of building a billing system from scratch. Documenting my thoughts and learnings.
Building a billing system may seem straightforward at first glance, but once you delve into the details, the complexities quickly become apparent. Let's begin by addressing the question: why even consider building a custom billing system?
This is a critical question and must be approached with care. There are several valid reasons an organization might opt for a custom billing system over an off-the-shelf solution. However, it's equally important to recognize the weight of such a decision. Here are a few common, reasonable justifications:
Competitive Advantage: A custom-built billing system can potentially provide an edge over competitors. It allows organizations to design features specific to their business model, customer base, and operational workflows, enabling greater flexibility and scalability.
Off-the-Shelf Systems Don't Meet Specific Needs: Many organizations find that generic billing systems lack the granularity or customization required to meet their unique requirements. However, it's crucial to thoroughly investigate whether existing solutions truly cannot meet your needs before going down the custom path. This point often needs careful rethinking, as modern off-the-shelf systems are more customizable than they used to be.
Compatibility with Existing Infrastructure: Organizations often have legacy systems or highly specialized infrastructures that don't integrate well with third-party billing platforms. In such cases, a custom solution ensures seamless integration without having to overhaul the entire ecosystem.
Data Privacy and Security: Some industries, especially those in finance or healthcare, have stringent data privacy regulations that mandate keeping sensitive customer information in-house. A custom billing system allows complete control over data handling, which is critical when compliance is a top priority.
Accounting Practices: Some companies have highly specific accounting rules that don't align neatly with commercial billing systems. A custom solution can address these discrepancies by adapting directly to the company's unique financial practices.
Invalid Justifications for Building a Billing System
While the reasons above may justify a custom solution, there are also several commonly cited reasons that don’t hold up to scrutiny:
Billing Systems Are Easy to Develop: This is a dangerous assumption. Billing systems involve handling money, applying tax rules, managing subscription models, and ensuring regulatory compliance. It's a complex and delicate process, where even minor errors can have significant consequences, including legal issues or loss of customer trust. We'll explore these challenges in detail below.
Engineering and Product Teams Can Define Requirements on the Fly: Building a billing system requires precise, well-thought-out requirements from the start. Attempting to develop a system without a clear and complete specification can lead to endless rework, delays, and cost overruns.
Building In-House Will Be Cheaper: This is often not true. While it may seem like building your own system will save costs in the short term, the long-term expenses of maintenance, updates, scaling, and handling compliance changes can quickly outweigh the initial savings. Moreover, if the system is poorly designed, you may face significant costs to fix or replace it later, not to mention the impact on your customer experience and brand reputation.
Accounting Rules Don’t Apply: Even if you believe that standard accounting rules don’t apply to your business, it’s critical to double-check. Misunderstanding or ignoring accounting standards can have severe legal and financial ramifications. You don't want to discover this oversight after your system has gone live.
Real-Life Challenges of Building a Billing System
I had the opportunity to work with a skilled team of developers tasked with creating a billing system for a company. Our goal was to take full control of our billing processes, specifically for handling subscriptions, rather than relying on a third-party payment processor. On the surface, this seemed like a straightforward task: handle billing, apply discounts, process refunds, manage disputes, and ensure the system aligned with accounting standards. But as we dug deeper, we encountered a myriad of complications.
Here are just a few of the complex scenarios we had to address:
Line Items in an Invoice: Each invoice can have multiple line items, potentially with different billing cycles, pricing models, and tax rules. Handling these variations requires intricate logic and careful attention to detail.
Tax Calculation: Taxation varies by country, state, and even city. A robust billing system must account for these regional differences, applying the correct tax rates depending on where the customer is located.
Bundling and Unbundling of Products: Offering bundles of products or services, and then having to unbundle them for refunds or modifications, adds another layer of complexity. Different pricing structures can apply to bundles versus individual items, making this a tricky part of the billing process.
Mixed Subscription and Non-Subscription Items: Customers often purchase both subscription and one-time items in the same transaction. The billing system needs to handle the different invoicing rules for each, ensuring that subscription renewals and one-time purchases are accurately reflected.
Discount Codes: Managing discount codes might sound simple, but when you factor in timing (e.g., expiration dates), eligibility criteria (e.g., first-time customers), and partial refunds, it becomes more intricate.
Refunds: Processing refunds isn’t just about reversing a transaction. The system must account for partial refunds, prorated subscription cancellations, and any corresponding tax adjustments.
Disputes: Handling disputes can involve pausing payments, issuing partial refunds, and negotiating with customers. The billing system needs to support this level of flexibility without causing billing errors or delays.
Accounting Rules: Billing isn’t just about getting money from customers; it’s also about ensuring that every transaction aligns with your accounting practices. Revenue recognition, deferred revenue, and accurate financial reporting are all critical components of a well-functioning billing system.
Third-Party Charges: If your business relies on third-party services, their charges need to be reflected in your billing system. These could include processing fees, platform usage costs, or partner commissions. Integrating this data into your system, while ensuring accuracy and transparency, adds to the complexity.
Final Thoughts
Building a billing system from scratch is not a decision to be taken lightly. While there are situations where a custom system is the right choice, the process is fraught with challenges, from technical difficulties to compliance risks. It requires a thorough understanding of your organization’s needs, an accurate assessment of costs, and a commitment to ongoing maintenance and updates. In many cases, leveraging an existing billing solution with customizable features may be a better, less risky, and more cost-effective path.
Before embarking on the journey of building your own billing system, ensure that you’re doing so for the right reasons and with a full understanding of what lies ahead.