While I normally keep the political threads at arms length, this is an interesting enough game/voting-theory question that I'm honestly surprised no one has linked the fact that this is a well-studied effect, to the point that it has a specific name: Duverger's Law. [0]
I take a very mechanical view on this, but take this with a grain of salt as my success has been "banal" at best. You have people paying you for your product. This is more fit than most people achieve.
Some good advice I heard is to find and focus on a KPI that aligns with the sort of use that'd indicate healthy consumption of your product+costs, with a guiding principle of "if people are paying us and using it with a trendline moving the right direction, we're succeeding."
Have you thought about what you'd need to do to get more users/get more eyes? (Presuming you've proven enough traction+lack of churn from existing users that it wouldn't be premature) Similarly, are you talking to users who find value in your product and identifying ways you could provide more value?
I personally see tons of potential avenues for growth given what you've said; but obviously saying this ignorant of much of the reality on the ground so take it with a major grain of salt.
Ok, that's a good point. We are offering 2 week free trial, so I think we will know a little more next week. We have been using ads to drive traffic to our site. We are spending like $2 per sign-up and not sure how sustainable it will be in long run. We are thinking of conferences or community events where we can meet more users. We want to talk to more users and get more feedback, but I'm not sure how to approach this.
This is a bit orthogonal to the broader conversation, but you've hooked me with your predicament: Can you allow for preorders or "Expressed interest" at a new price point? (or at a hand-wavy price point to assess interest re: overhead/bulk/etc.) If tariffs come down, you can refund/credit, but for customers who wanted this, something-at-some-price may be better than nothing-at-any-price.
I'm going to disagree with this as a long-term ARPG fan and a long-since-washed-up game dev.
Up through the last few years, I was playing Path of Exile rather regularly. The grind in that game puts what we used to do in D2 to shame, to me at least.
(Comparing the amount of time I used to spend baal/cow/key/pindle running to gear a character sufficiently for e.g. ubers vs. what I'd consider equiv endgame bosses in POE from tree-boosted maven/Sirus/ubers/etc, outside of explicitly low-gear bossers like trapping)
I also regularly wish I could go _Back_ to playing it, specifically 1.13-1.15 (harvest) as it was, in my opinion, the peak of ARPG gameplay, as it turned progression from pure RNG where a wrong roll would brick an item or where you had to rely on the market to find your gear into something slightly less punishing where we could experiment with a far wider variety of builds. But the powers that be in POE saw it differently, that it watered down the endgame and made progression too easy, and proceeded to remove the vast bulk of the mechanic, while doubling down on other mechanics that were, frankly, not respectful of anyone's time. (e.g. scourge.)
This to say, I think game incentives have changed over the last few decades. Something subtle, motivated by microtransactions, subscriptions and streamers, has changed the nature of grind from primarily something that needs to be kept fun to make the game meaty enough to play, to something that must sufficiently extend gameplay to keep the microtransaction faucet going and keep certain goals effectively out of reach.
As another hybrid "TLM->EM" with a similarly sized team, over a similarly sized product, I definitely feel many of the same pain points you call out.
BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient."
My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?)
While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style.
(As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) )
I will admit your response gave me a little whiplash :P
When I started reading I was getting very ready to disagree vehemently ("remote work is overhyped and only works for a tiny sliver of the workforce")
But your last paragraph seems to describe far more what I've seen in reality; that it's often risk-aversion/not-wanting-to-commit-to-change/leaning-on-what-they-know/wanting-to-look-like-they're-doing-something that I've seen driving RTO in various locations. This hypothesis is supported by, as you point out, the increasing, albeit incrementally, list of companies and teams that have implemented remote successfully (my own included, obviously only speaking for myself/not for my employer).
So, to be clear, I don't think you're wrong that there's intentional focus on communication and collaboration that is _absolutely_ needed to make remote work, and that's harder for someone who doesn't know what that looks like (or for someone junior without experience working in that modality).
HOWEVER I would object to is the assertion that it's "overhyped and only works for a tiny sliver of the workforce."
Since starting to lead remote teams ~5 years back (after having been a dev on one for a few years prior) the delta between remote vs. in-person has been a _negligible_ friction point vs. much more "typical" aspects of management: Individual work habits, motivations, life externalities, team and org dynamic, "standard" disagreement or conflict, etc.
I'd be lying if I said the remote aspect was zero cost, but not only was much of it recouped in building better processes as you may have suggested above, but this enabled both hiring some amazing folks who likely wouldn't have been options if we only looked local, and supporting all of our lives with significantly increased flexibility, both in terms of personal life and in things like time-zone based coverage for outages and on-call. All-in-all, a massive benefit.
(Obvious disclaimer all views are my own and not my employer's)
First, let me say that I don't disagree, pragmatically, with the truth of what you're saying, in terms of increasing your odds on the whole as a candidate.
But that said, as another hiring manager, let me respectfully disagree with this as a strong hiring signal. I say this, to boot, as an engineer with an, in my experience, above average OSS contribution, research, and patent portfolio, although these things are a bit power-law-esque so obviously I'm nothing next to many.
When I interview, I want to know you have a track record of high quality delivery, and are good for the skills you attest to. I can understand some folks looking at the public displays as a proxy to that, but I'd argue, at that point, indexing on the "public" part is orthogonal to what we're looking for it to display, and carries both false positives and negatives.
To some degree we may be agreeing loudly here, where you'd say "well that's what them putting it in public is" but I'd worry that by caring about the public component vs. a more generalized examination of professionalism and accomplishment, we preclude folks who have no time or interest in curating that sort of profile.
If I put myself into the absolute edge case of two candidates all things being equal but one seems to have also made a more visible portfolio of work, MAYBE, MAYBE that would move the needle in terms of establishing a degree of external validation, but I think I'd be looking _hard_ for other aspects to differentiate that would seem to have more direct applicability to our day-to-day needs, and am hard pressed to think of a time in the last few hundred interviews I've had to make such a choice without a stronger differentiator for any candidate above a very junior level.
Documenting everything ruthlessly (meeting summaries, action items, personal knowledge, TODOs, passing thoughts ala things I want to discuss with peers, etc) in a centralized and easily searchable/cross-linkable/organizable fashion.
Build this doc repo as well as the TODO component within it for absolutely minimal mental overhead. In fact, optimize for minimal mental overhead in all things, and ability to reenter/pick up where you left off effectively "on autopilot." This (low mental overhead, reentrency) applies to things like email triage as well.
I realize this is both very terse and very open ended, but it's really the crux of my ability to deal with exponential levels of randomization, complexity, and parallel tasks. If there's any "Secret sauce" this doesn't contain, it's the need to adjust your systems/organization/methods to whatever is "natural" for you (this perhaps goes hand in hand with low mental overhead and reentrency, even the process must be low-overhead and easily 'reentrent', for instance, preparing for forgetting where I put something, I should know my own tendencies for where I'd look such that I buid my organization upfront that I'd readily find it again.)
I'll cap this with one more meta item before I turn this into an essay: Retrospect. regularly ask yourself "how are things? how is what I'm doing? can it be improved? has anything gone wrong/should I be paying attention to anything I'm not? are there any questions I'm not asking?"
While I can't speak for every manager, I can speak for myself managing a hybrid team going on 5 years now (obvious disclaimer, not necessarily the views of my company etc)
> Imagine being an IC software developer and being stuck on dial up. That’s what it’s like to be a manager in a remote environment.
This is hyperbolic. I would also suggest it takes some autonomy and responsibility away from managers to adapt and learn new ways for building an understanding of your engineers. If adapting to remote is problematic, adapting to employees with dramatically different methods of thinking and communication (of which there are many) will also be problematic.
Are there challenges? Sure. From my perspective, the largest among them likely being the loss of organic opportunities to casually interact and build rapport, such as over lunch. The second worth mentioning is the friction added to nonverbal communication. (Onboarding is one of the most critical places these hit, but they're ongoing headwinds as well.) But neither of these are in any way insurmountable, or even high on the list of "things that keep me up at night" managing a team.
At the risk of a simple answer, I've found they're usually well addressed by intentionally making opportunities to just... interact, and of course finding what works for an individual dev, with a team-wide emphasis on async methods of alignment, knowledge sharing, and consistency/coordination.
None of the things you mentioned, what a dev is doing, what they want and need, should have in-person as a requirement. The statement of "more intrusive" is especially ironic, as I find knocking on an office door and interrupting flow, or bugging someone in the hallway or over lunch "what's the status of X" far more intrusive than having a good process and cadence and ongoing awareness for work being done, and trusting/cultivating engineers to reach out if something comes up. (These are systems which, to emphasize my point, come very naturally when one is supporting a remote or hybrid team, but have broad benefit.) I'd add as well that "is someone smiling" is an... extremely lossy and unreliable heuristic for knowing your engineer, to put it more gently than I probably should.
The funny part with all this said: Your core point, that managers are contributing to the RTO push, potentially has some truth to it. (although I'm inclined to disagree that it's THE major component just knowing the discussions and tax implications between legislators/business owners/bigcos in my own city, it's totally a guess on my part) I've just been reading a bunch of posts lately that seem to defend what is, in my eyes, a cop-out for a manager who should be adapting to far more than remote on a day-by-day basis, resulting in concrete costs both for employees in ___location/commute and for managers in being unable to hire high quality remote engineers, and this being said so overtly pushed me to write this wall-of-text.
Question for ya if you don't mind: I had to do some PDF scraping a while back as part of a side project collecting alternative social/economic datasources.
Even within a single site, there were often errors at the fringes, especially if things like layout/styling changed, and my concern about giving bad data to users (or needing to constantly be checking data quality and adjusting custom parameters for each target site) held me back from ever feeling confident enough to convert it into a paid product.
I don't mean for you to give up your secret sauce here, but wondering if you ran into this same issue, and what your approach was from a business/customer expectations perspective?
Oh yes I ran into this issue many many times. The way I dealt with it is a bit insane. I classify bank statements using images or text on the first page. Then I run custom code for that document type.
I also have a "pretty good" fallback algorithm if the statement cannot be classified.
Usually banks have a template so the edge cases aren't so edgy. Had to do this with Canadian banks and each one had their own template, but once you parsed it, generally, it worked until they updated their template again.
[0] https://en.wikipedia.org/wiki/Duverger%27s_law
reply