The cracks appear later. Some part of the database is straining under load you could have predicted. A shared library has three incompatible versions living in three different pods. Nobody owns the work needed to fix it, because nobody was ever asked to.

The problem isn’t the pod structure — that part works. The problem is a missing team.

How the pod model is set up

The typical structure is elegant in its simplicity. You have five or six product managers, each paired with a pod of engineers — say, five or six people, led by a tech lead. A layer of engineering management sits across those pods. Engineers report up through management but work day-to-day with their product manager.

This creates something genuinely valuable: tight product-engineering alignment at the team level. Engineers understand the “why” behind what they’re building. Product managers develop technical intuition. The pod is largely autonomous, with few dependencies on other teams.

Product orgEng. managementPM 1GrowthPM 2PlatformPM 3Core productPod 15–6 engineersPod 25–6 engineersPod 35–6 engineersSolid = product directionDashed = reporting line

The standard pod structure — effective for product velocity, but silent on cross-pod technical work

At 40–50 engineers across six pods, this is a formidable product machine. But notice what’s missing from the diagram above: there’s no regular forum where the engineers in those pods talk to each other as a technical community.

The asymmetry nobody talks about

Here’s a tension baked into the pod model. The product organization is small — six people who meet regularly, coordinate roadmaps, and share context. They function as a team. The engineering organization is five or six times larger, and typically meets in fragments: each pod runs its own standups and planning, but the 40-person engineering org rarely convenes as a whole.

This isn’t a failure of management. A weekly all-hands with 40 engineers is genuinely unwieldy. But the practical consequence is that nobody is holding the cross-cutting technical picture.

Where it breaks down: Shared architectural components that two pods both touch. Technical debt that doesn’t belong to any PM’s roadmap. Infrastructure that needs re-architecture to support the growth the product team has already planned for — but hasn’t told engineering about yet.

The product team has visibility into what’s coming. The pod teams have deep visibility into their own corner. No one has the full technical view. That’s the gap.

The tech lead council

The fix is a standing team of tech leads — one from each pod — meeting on the same cadence as the rest of the organization. Call it a tech lead council, an architecture forum, whatever fits your culture. The name matters less than the habit.

This team does something specific: it holds the technical picture that no individual pod can hold on its own.

In practice that means: comparing implementation approaches across pods before work diverges, identifying opportunities for shared components, surfacing technical work that needs to happen for business reasons no PM has yet named, and developing a 6–12 month technical roadmap that runs alongside the product roadmap.

Product roadmapPM team, quarterlyTech roadmapLead council, quarterlyShared planningRisk, priority, sequencingLead, pod 1Arch, debt, shared codeLead, pod 2Arch, debt, shared codeLead, pod 3Arch, debt, shared code

The tech lead council bridges pod-level execution and org-level planning

The goal is that this team’s outputs — architectural recommendations, decisions to adopt new tooling, proposals to allocate sprint capacity to debt retirement — are treated with the same weight as product requirements. That takes time to earn. The team earns it by being right consistently, by communicating their reasoning clearly, and by building a track record the rest of the organization learns to trust.

“At the same time you’re developing a vision of what the product will look like a year from now, you need a group of people meeting regularly to discuss what the future of your technical stack looks like.”

In more mature organizations, this function often migrates toward staff engineers or a principal engineering group. The exact structure depends on where the company is. What shouldn’t vary is the underlying principle: technical planning must be ongoing, structured, and given organizational standing.

Team-ness at every level

There’s a broader pattern here, one that applies not just to tech leads but to every layer of the organization. The most effective teams aren’t collections of individuals each reporting to a shared manager. They’re actual teams — people with shared goals who work together on the business of their level, not just up and down their individual reporting lines.

One CEO put it well to his executive team: “You’re not six people who each report to me. You’re a team, and I’m the lead of that team.” The consequence was that most decisions got made and executed by the team, without the CEO needing to be in the room. Issues came to the weekly meeting; only the things that required a tiebreaker or an especially consequential call escalated further.

The same logic applies at the tech lead level. If those leads see themselves as a team — not just representatives of their respective pods attending a meeting — they’ll make better architectural decisions, resolve cross-pod tensions more quickly, and present a more coherent technical direction to the rest of the organization.

Putting it into practice

None of this requires a reorg. It requires one standing meeting, a clear mandate, and leadership willing to treat the outputs as real inputs to planning. Start with the tech leads meeting biweekly. Give them a simple agenda: what architectural work is each pod planning this sprint, is any of it shared, and what technical work needs to happen in the next six months that isn’t on any PM’s roadmap yet.

The meeting will feel unfocused at first. Give it three months. By then, the leads will have developed shared context, a working vocabulary, and a sense of what they can resolve themselves versus what needs to escalate. That’s when the value shows up — not in a single decision, but in a dozen small ones that don’t require a VP to broker.

The pod model gives you product velocity. The tech lead council gives you the architectural coherence to sustain it. You need both.

I’ve been a professional software developer for almost 40 years. I’ve spent more than 30 of those years as an engineering manager and executive — CTO, VP of Engineering — watching the industry evolve through multiple generations of technology.

I started in the era of packaged software. We put programs on disks, sealed them in boxes, and sold them in stores. Then came client-server development. Then the web. Then mobile. Then social media. And now AI.

Across all of those waves, Silicon Valley — and American technology companies more broadly — have led the world in innovation. We’ve built new categories of products, created massive global businesses, and changed how people live and work.

But over the last 10 to 20 years, as companies have grown bigger, richer, and more powerful, I’ve watched the same tragic pattern repeat itself over and over again.

We invent something world-changing — and then we immediately chain it to the quarterly result.

The Moment Innovation Gets Constrained

The cycle is predictable.

A company builds a new technology. It proves itself commercially viable. Customers love it. The product begins to change the world in real, meaningful ways.

And almost immediately, the organization clamps down on it to satisfy Wall Street expectations.

The long-term vision that drove the innovation — the idea that we were building something transformative — starts to narrow. The horizon shrinks. Instead of asking what the technology could become in five or ten years, leadership becomes focused on how it performs next quarter.

The spirit of innovation doesn’t disappear. Engineers and product teams still believe in the big ideas. But structurally, the company shifts from exploration to extraction.

Shipping Too Early: The First Self-Inflicted Wound

One of the worst mistakes a company can make is bringing a product to market before it is ready.

I’ve seen this happen many times. A promising idea gets rushed out the door because leadership wants momentum, headlines, or revenue sooner rather than later. The result is predictable: customers become frustrated, trust erodes, and the original promise of the product gets overshadowed by early negative experiences.

Good ideas have been ruined this way.

There is a difference between iterating quickly and shipping prematurely. Healthy iteration builds confidence and improves quality. Premature release creates a reputation that can follow a product for years, even after it improves.

The pressure to meet quarterly expectations often accelerates this mistake. When timelines are driven by financial cycles rather than product maturity, teams lose the space needed to refine and stabilize what they’re building.

When Entire Technologies Get Distorted

There’s an even more dangerous version of this pattern: trying to extract too much value from a new technology before it has fully matured.

In those cases, it’s not just customer frustration that’s at risk — the entire category of technology can become warped by premature monetization and short-term incentives.

Social media is a powerful example.

Many early platforms carried a genuine promise: connecting people across distance, fostering conversation, and creating new forms of community. There was a sense that these systems could become forums for constructive discourse and shared understanding.

But once the pressure to maximize engagement and revenue intensified, the incentives changed. Feeds filled with ads. Algorithms optimized for attention rather than well-being. Doom scrolling replaced meaningful interaction. Online trolling and bullying became amplified rather than mitigated.

The technology itself wasn’t inherently flawed. The way value was extracted from it — too early, too aggressively, and too narrowly focused on growth metrics — reshaped the category into something far different from its original vision.

Heads Down, Eyes Off the Horizon

Once a company ties its identity to quarterly performance, something subtle changes in how decisions get made.

Roadmaps compress. Risk tolerance drops. Long-term investments become harder to justify. Teams spend more time optimizing metrics than imagining possibilities.

I’ve seen organizations put blinders on — not because people stopped caring about innovation, but because the system incentivized short-term predictability over long-term transformation.

Every year, plans are built around hitting numbers. Miss the numbers, and the market punishes you. The stock price drops. Investors look for a new CEO who promises tighter execution and faster results.

Over time, this creates a culture where innovation is tolerated only if it can be forecasted on a spreadsheet.

The Long Game vs. The Quarter

It’s impossible to ignore the global context. Over the course of my career, China has emerged as a technology powerhouse.

Yes, some technologies originated here in the United States. Some were copied or adapted. But what stands out to me is not just what was built — it’s how long-term strategy was applied.

Chinese companies, from my perspective, have often played a longer game. They invest in infrastructure, ecosystems, and platforms with a time horizon that extends beyond the next earnings call.

That doesn’t mean they ignore financial performance — every business has to survive economically. But there is a visible willingness to think in decades rather than quarters.

Meanwhile, American companies frequently limit themselves with what is, in many ways, a self-imposed constraint: the belief that innovation must immediately translate into quarterly revenue growth.

A Made-Up Constraint

The quarterly cycle is not a law of physics. It’s a financial construct — one that has grown powerful enough to shape how entire industries behave.

And I’ve watched it hobble companies that were once bold.

As soon as a technology begins to succeed, it becomes less about building the future and more about protecting the number. Engineering decisions shift. Product strategy shifts. Risk appetite narrows. The organization becomes less willing to invest in ideas that might not pay off immediately.

Over decades, that pattern has had a real impact on how technology evolves, especially inside successful companies that should have the most freedom to take long bets.

What Gets Lost

What’s frustrating is that the innovative spirit never fully disappears. The engineers are still there. The ideas are still there. The ambition is still there.

But the structure around them changes.

Instead of asking, “How big could this become?” the question becomes, “How does this help us hit next quarter?”

And that’s where the real loss happens — not in talent or creativity, but in time horizon.

After nearly four decades in software, I don’t believe the challenge is a lack of innovation in the United States. We are still extraordinarily good at inventing the future.

The challenge is that we often stop ourselves from fully realizing it.

We build something transformative — and then we shrink our vision to fit inside a quarterly report.

I’ve been a professional software engineer for almost 30 years. Over that time I’ve served as a manager, engineering leader, VP of Engineering, and CTO across organizations ranging from small startups to companies the size of IBM. Watching engineering organizations grow from small teams into large, complex systems has given me a long view into how culture and incentives evolve — and sometimes break.

One of the most destructive tendencies I’ve seen develop over time is surprisingly subtle: engineers begin to believe that the only way to advance their careers is to work on the most visible, most successful products inside the company.

At first glance, that seems reasonable. Of course people want to work on the products that generate revenue, attract executive attention, and shape the company’s public identity. But inside a modern software organization, that instinct can quietly undermine the long-term health of the entire engineering system.

Visibility Bias Inside Engineering Organizations

Even in companies that technically have a single product — especially SaaS organizations — different parts of the system receive vastly different levels of visibility. The UI, the client experience, and customer-facing features are seen by marketing, sales, executives, and customers every day. Those parts of the system become the center of attention.

Engineers naturally gravitate toward that visibility. It feels like the place where careers are made.

But modern software systems are far larger than what users see. Reliability engineering, infrastructure, fraud mitigation, security, risk management, customer support tooling — these areas operate behind the scenes. They are less glamorous, less visible, and often harder to explain to non-technical stakeholders. Yet they are just as critical to a company’s success as the features that generate revenue.

When incentives drift toward visibility instead of system health, organizations slowly become unbalanced.

From Boxed Software to Web Systems: A Cultural Shift

Early in my career, I worked on packaged desktop software — the kind that shipped in boxes on store shelves. In those environments, nearly every engineer worked on the same deliverable. The entire team focused on what would go into the box.

As the industry shifted toward web-based systems, and later toward mobile and distributed architectures, that unity disappeared. Engineering work fragmented into layers: front-end, mobile, APIs, infrastructure, data systems, security, and operational tooling.

The engineers working on the visible layers received more attention from across the company. Sales teams, marketing teams, and executives could see the UI. They could interact with it directly. Naturally, conversations gravitated there.

Meanwhile, the backend systems grew larger, more complex, and more essential — but less visible.

That imbalance created a cultural gravity well.

The Executive Table and the Hidden Work

When I moved into leadership roles and eventually sat at executive tables, I saw this bias amplified. Entire executive teams would discuss what the product looked like, how it behaved for customers, and which features were driving growth. Those conversations were important — but someone had to worry about how the system actually ran.

More often than not, that responsibility fell to the engineering leader alone.

Over time, I found myself investing more attention in infrastructure, reliability, and backend architecture — not because it was more interesting, but because it was necessary. The health of the company depended on systems that most people in the room couldn’t see.

This is where many organizations struggle: how do you convince engineers to invest their careers in parts of the system that receive less external recognition?

Why the “Best Product” Mentality Is Dangerous

When engineers believe promotions come from working on the most visible product areas, several problems emerge:

– Critical infrastructure roles become harder to staff.
– Reliability and security work become reactive instead of proactive.
– Organizational knowledge becomes skewed toward features rather than systems.
– Long-term risk accumulates quietly beneath short-term success.

Modern architectures make this especially dangerous. Backend systems are no longer simple servers running behind a UI. They include distributed services, data pipelines, observability platforms, and compliance layers that grow more complex every year.

Ignoring these areas doesn’t make them less important — it makes them fragile.

Engineering Leadership as Incentive Design

The challenge for engineering leaders has always been incentive alignment.

You cannot promote engineers faster or compensate them more simply because they work on the UI or on the product areas that executives see most often. If the incentive structure favors visibility over impact, engineers will optimize for visibility every time.

Instead, organizations need to reward outcomes that reflect true system health:

– System uptime and reliability
– Backend performance and scalability
– Risk mitigation and fraud prevention
– Operational excellence and maintainability

These achievements are harder to measure and often less glamorous, but they are the foundation that allows visible products to succeed.

In my own leadership journey, I tried to make infrastructure and backend work a first-class path to growth. That meant recognizing engineers publicly for reliability improvements, tying performance reviews to system outcomes rather than feature count, and ensuring that compensation and promotion paths reflected the value of invisible work.

Aligning Culture With Reality

The deeper lesson is simple: culture follows incentives.

If engineering organizations reward visibility, engineers will chase visibility. If they reward stability, collaboration, and long-term system health, engineers will invest in those areas instead.

The goal is not to diminish UI or product innovation — those are essential to any company’s success. But a sustainable engineering culture recognizes that the parts of the system no one sees are often the ones that determine whether the company survives.

After three decades in engineering, one truth has become clear to me: the strongest organizations are not the ones where everyone wants to work on the most successful product.

They are the ones where engineers understand that success comes from building — and valuing — the entire system.

But the debt only looks impossible in isolation.

When you place it next to where American wealth actually resides, a very different picture appears. Not a simple solution—but a real one, with real tradeoffs.

The Scale of the Problem (and the Wealth)

As of late 2025, total U.S. federal debt stands at roughly $38 trillion. Of that amount, about $31 trillion is debt held by the public—Treasury securities owned by investors, institutions, and foreign governments. This is the portion economists usually focus on, because it represents external obligations.

Now compare that with Baby Boomer wealth.

Americans born between 1946 and 1964 collectively hold about $83 trillion in net wealth—more than half of all U.S. household wealth.

This comparison changes the framing. The United States is not “broke.” The money exists. It is simply concentrated and lightly taxed at the point of transfer.

Average vs. Median: Why This Matters

Wealth among Boomers is highly uneven:

• Average (mean) net worth: roughly $1.2–$1.7 million

• Median net worth: roughly $200,000–$400,000

This distinction matters because estate taxes apply only to the top of the distribution. Most Americans—and most Boomers—are nowhere near today’s exemption thresholds.

How the Estate Tax Works Today

• Top federal estate tax rate: 40%

• Estate tax exemption: ~$14–15 million per individual

• Share of estates that pay: fewer than 0.2%

Despite an unprecedented intergenerational wealth transfer already underway, the estate tax raises relatively little revenue.

A Simple Thought Experiment

To understand scale—not to propose a literal policy—consider a simplified model:

Assumptions (for illustration only):

• Total Boomer wealth: ~$83T

• Estate tax rate: 40%

• Wealth above an exemption is taxed once, over time

• Ignore avoidance, deductions, timing, and behavior

This is not how policy works. It is a measuring tool.

Could Boomer Wealth Retire the National Debt?

• Total gross debt (~$38T):
  Even taxing all Boomer wealth at 40% raises only ~$33T → not enough.

• Debt held by the public (~$31T):
  Mathematically achievable at a 40% rate with a very low exemption.

The math shows capacity. But math alone is not policy.

The Overlooked Question: Would This Be Deflationary?

Yes—by default, retiring all or most of the national debt would be deflationary.

This is where many “just pay it off” arguments quietly collapse.

Paying down federal debt removes financial assets from the private sector. Treasury securities are not just liabilities—they are core infrastructure of the financial system.

How Fast Matters More Than Whether

The economic risk depends almost entirely on speed.

What this chart shows:

• A slow payoff (~0.5T/year) creates manageable drag

• A moderate payoff (~1T/year) is meaningfully contractionary

• A fast payoff (~2T/year) risks recession and financial stress

Three Payoff Paths

1. Fast Payoff (High Risk)

Aggressive estate taxation and rapid debt retirement.

Likely outcome:
Strong deflationary pressure, tighter credit, recession risk.

2. Phased Payoff With Offsets

Gradual debt reduction over decades, paired with:

• Public investment

• Tax cuts elsewhere

• Monetary accommodation

Likely outcome:
Debt declines without choking demand.

3. Partial Payoff (Most Stable Option)

Reduce debt relative to GDP, not to zero, while preserving a deep Treasury market.

Likely outcome:
Lower long-term fiscal risk without destabilizing the system.

The Deeper Insight

The national debt is not like household debt.

From a macroeconomic perspective, it represents the net financial assets of the private sector. Eliminating it entirely would mean fewer safe assets, tighter credit, and less financial flexibility.

The goal should not be zero debt, but the right amount of debt, sensibly balanced against private inherited wealth.

Final Thought

Over the coming decades, Baby Boomers will pass on more than $80 trillion in wealth.

We will choose:

• To fund the future through inheritance, or

• To fund it through debt

Lowering the estate tax exemption would not magically solve everything. But it would force an honest reckoning with how wealth, risk, and responsibility are shared across generations.

The debt exists.
The wealth exists.
What remains is deciding which one we want to pass on.

Carina is a 20 something broke, exhausted professional living alone in a tiny one room mid-Manhattan apartment. Her apartment is so small and cramped that her parrot Bart has more room in his cage than Carina does.

For someone so young and seemingly successful, Carina has never figured out how to correctly use an alarm clock to get herself to her subway train by 9:00am. She’s tried every conceivable trick over the years but nothing has worked and now she is still in bed asleep at 8:55am.

The sun is shining through the partially opened curtains and a narrow beam of sunlight pokes through into the room. The sunlight falls on Carina’s face, she yawns, stretch herself gently while the memory of a pleasant dream rolls around her head until her eyes snap open suddenly.

She casts her eyes around the apartment, she can’t even be sure where she put her alarm clock but she is certain that she is late again. Carina screws her eyes shut for a moment, she wants so much to go back to sleep and pretend this isn’t happening again.

She has been late so many times she is sure this time she will lose her job. She jumps out of bed, dashing across the room to her closet to get dressed but trips and falls over the only appliance in her place, a little refrigerator.

“You could have just asked me to wake you up Carina”, says Bart. Bart has never spoken before. Carina is so stunned she lays on the floor for a few moments before opening the fridge and giving Bart the only thing she finds in there: an old carrot.

It’s a rather lovely morning in the city Carina thinks when she reaches the street via the back stairwell. She has a second to check her looks in the reflection of the subway car window before she jumps aboard.

I recently revisited Isaac Asimov’s short story The Last Question. Without spoiling too much, it explores the fate of the universe and humanity’s place in it. The story traces the arc of human civilization: from living alongside artificial intelligence, to merging with it, to eventually spreading among the stars and populating entire galaxies.

Running through the narrative is a powerful theme: human survival. Asimov asks whether, given humanity’s relentless expansion, there will always be enough resources to sustain us — no matter what form we take.

At one point, Asimov describes a future where humans have achieved a kind of immortality. Consciousness is separated from the body, the body is perfectly preserved, and death is no longer possible. This liberation of consciousness allows humanity to exist and act indefinitely.

That idea made me think of Liu Cixin’s The Dark Forest, the second book in his Three-Body Problem trilogy. Its “dark forest theory” offers one of the most chilling answers to the Fermi Paradox — the question of why, in such a vast and ancient universe, we have never encountered alien life.

The dark forest theory suggests that the universe is teeming with intelligent civilizations, but that every civilization is both a potential threat and a potential target. Because resources are finite, any species that expands unchecked could one day endanger others. As a result, the safest strategy for any intelligent lifeform is to eliminate other civilizations as soon as they detect them.

The metaphor is that the universe is a dark forest. Every civilization is a hunter, moving silently through the woods. The moment one becomes aware of another, its survival instincts demand that it attack before it is attacked.

But Asimov’s vision raises an interesting challenge to this grim worldview. If a civilization achieves immortality — true immortality — does it still need to reproduce and expand? Reproduction is, in a way, a biological strategy for achieving immortality by passing on DNA. But if individuals never die, reproduction becomes unnecessary.

A species that no longer needs to reproduce would also no longer expand at the same rate, and its resource needs could eventually stabilize. In that scenario, such a civilization might no longer feel compelled to destroy potential competitors.

Of course, there’s another possibility: immortal civilizations might still feel threatened by species that are reproducing and expanding, and thus act as the “hunters” in the dark forest — wiping out younger species before they grow too large.

This interplay between immortality, reproduction, and survival opens up fascinating philosophical questions. Is endless expansion inevitable? Or could the path to universal peace lie in transcending the need to reproduce at all?

I highly recommend reading both Asimov’s The Last Question and Liu Cixin’s The Dark Forest. Together, they offer two very different but deeply thought-provoking visions of humanity’s future — and the universe we inhabit.1

Subscribe now

Something interesting happened to me recently during a staff meeting. It was a strategic discussion among senior engineering leaders, including my boss and several colleagues. We were talking about a new product development initiative—an area where the company had previously invested effort, but ultimately canceled the earlier project. I was part of that original effort, so I have some history with both the domain and the engineering team that worked on it.1

Given my background, I offered my thoughts on how we might want to approach the internal conversations surrounding this new initiative. I emphasized the importance of involving and aligning with the broader organization as we move forward.

Then a newer colleague responded. His reaction made it clear that he didn’t agree with my take. In fact, he offered an alternative approach with a tone that came across as a bit dismissive and somewhat self-important. You know the kind: someone hears your perspective and immediately offers what sounds like a more “enlightened” way to handle the situation—something higher-minded, more strategic, more polished.

In the past, I would’ve felt the need to respond. To correct him. To clarify that I had considered that approach, or to explain why it might not be as straightforward as he seemed to think. I would have wanted to make sure I didn’t look like I missed something—or worse, let him have the last word.

But this time, I didn’t.

Instead, I sat with it. I let it pass.

Partly because I’m learning that in more political environments, timing and discretion matter. But mostly because I realized something deeper: I don’t need to correct every misunderstanding. I don’t need to defend every nuance of my thinking. And I certainly don’t need to prove that I’m the smartest person in the room.

If my colleague chooses to jump to conclusions about my perspective—if he assumes that my brief comment was the extent of my insight—that’s on him. If he decides not to engage further with someone who has experience and context he doesn’t yet have, that’s his mistake to make.

And I don’t need to stop him from making it.

Instead, I can take note. I can proceed accordingly. I can save my energy for when it matters most—and trust that the value I bring speaks for itself over time.

There’s power in restraint. In letting someone else have the last word—not because you lost the argument, but because you’ve already won something more important: perspective.

I've been writing code now for more than 40 years and been a professional engineer for more than 30 years, most of that time in startup companies. I’ve been an individual contributor, manager, Vice President, CTO, every technical position you can hold within a startup company, I've done it. I've managed hundreds of engineers, across hundreds of releases and I have worked with my teams against many, many deadlines.

At this late stage in my career, I am managing a team of engineers again, at a startup company, working with younger engineers on many releases. One thing I hear over and over again, and when I think about it I've been hearing it for some time, for decades, from these engineers is this idea of a made up date. To many engineers it seems that releases often get defined before engineers get involved, and that deliverables, milestones, deadlines are dictated in a top down fashion. Therefore, they seem made up, not based in reality by anyone within the engineering organization.

If you zoom out on startup companies, you've got this idea of an entrepreneur, the somewhat mythological figure that starts businesses. What that person is trying to do, a highly simplified version of what a startup company is, is they’ve identified a need in a market. They believe that need can be met with a product that has value to certain people, therefore those people will pay for that value, or you can find a way to monetize the value. So they have a way to make money but of course they need that product.

Most of the time, especially in modern software startup companies, you need money to realize that vision, you need money to execute on your plan starting usually with developing the product. So the entrepreneur has to go out and convince other people of their vision for the business in order to get the money they need. Those people you convince will become your investors.

One of the key things that needs to be added to your vision of the product and the value is going to be timing. Investors will start asking you, when is this going to happen? When are you going to deliver this product? When are you going to start realizing this value you are describing? As an entrepreneur, one of the first things that you will have to do is to come up with a date. This is an essential part not only of bringing your product to market but of explaining to investors when they will start to see returns from the company. You have to look out into the future and think about what your capabilities are, what you're trying to do and you have to come up with a date.

As I was saying earlier, you have to make up a date.

As an entrepreneur you have to pick a date practically out of thin air and say, yes, this is the date on which all this is going to happen. Then you have to set about making that a reality within your company. You begin a planning process from the top down and usually this goes through the product management organization and turns into milestones and deliverables that ultimately land in front of your engineers. That's when engineering says, whoa, whoa, these dates are totally made up.

In a later post, I will talk about what can be done about this but for now let me point out how important it is what has just happened. As the saying goes this is not a bug it’s a feature. The entrepreneur, the person who believes that they can solve a problem in the market, this person has decided when this needs to happen. This one thing, maybe more than anything else, is the fundamental thing about being an entrepreneur. You have to be willing to say when this will happen.

Think about that. You may have just started your company, you may not have written a single line of code yet and yet you have to decide on the future of the company. Not just any future: a definitive point in time when something is going to happen which has never happened before. If you are not capable of doing that, then you're not an entrepreneur. You are not somebody who should be starting a company. If you want to go to work for a start up company and therefore be entrepreneurial yourself you have to accept that this is a vital part of your decision.

I recently joined a new engineering team and was given my first coding assignment. I was told that time was of the essence in this case and so did a rather hasty implementation in Ruby and opened a PR fully expecting to get some interesting suggestions and even some of the dreaded “change requests”

I got some legitimate questions and concerns about the code, in particular related to getting the tests to run in our CI system.

There were two types of comments that I took issue with.

The first was “not idiomatic” which I have heard before, especially from Ruby engineers. All modern languages have their cool language features and their eccentricities and learning those things is part of the fun. Knowing a particular language well - be it Javascript, Ruby, Go, Rust, Haskell, whatever - is a real accomplishment and people should be proud of doing so. But they should not use that pride and knowledge to belittle people who write code “with an accent”.

In my case, I have written production code in perhaps 20 different languages over my 30+ years in this business and still actively code in 3 or 4 at any given time. When I haven’t used a particular language heavily in a few months it takes me a while to get caught up and fluent again. I have learned a lot in the past from PR comments and suggestions and I have no problem incorporating these into my code going forward.

The refrain I often hear from the “idiomatic” perspective is “your code is too hard for me to read”. I find this a weak argument with elitist implications. In this development team, as is almost always the case in the year 2022, we have a few engineers who speak English with an accent. On our Standup calls with these engineers, we don’t interrupt them and say “I can’t understand you because of your accent, can you please speak more like a native”. If we don’t understand someone, we politely ask them to perhaps try another explanation or maybe write out their ideas. We take it upon ourselves to help understand them, we don’t put that burden completely on them.

I once worked with a very talented and sharp Ruby engineer, someone I admire and learned a great deal from. This engineer spoke Spanish and English fluently but had a significant speech impediment. Not once when I worked with him did I stop him and say “can you please not stutter when you speak, I can’t understand you”. Instead I waited patiently for him to work through his stutter and I appreciated the enormous effort that he made to communicate.

The other comment I received which bears some examination is “no reason”. As in “there is no reason to do it this way”. This is a breathtakingly arrogant thing to say to another person regardless of the context. When I hear someone say this I mentally convert their statement into “I can’t think of a reason” or perhaps “I am too lazy/dumb/narrow-minded to think of a reason”. Younger people who may be reading this, take some advice from a middle aged professional who used to be as narrow-minded and arrogant as anyone: there is always a reason why people do what they do. Just because you don’t understand their reason, or disagree with it does not mean they didn’t have one.

A younger, less experienced version of me would have been insulted by these types of comments. Lucky for me, I am not that engineer anymore. I am well-seasoned: salty and spicy.