At the end of the day, the stack is collapsing itself, and the lines are blurring because we want people to own the total outcome more often than throwing responsibilities over the wall to each other.
That doesn't mean engineers are going to design, but they should know what a good design looks and feels like. That doesn't mean designers or product should write code, but they should be able to engage in high level architecture discussion to understand the capabilities of their products.
I have not read it yet but there's a book by David Epstein (not that one), "Range: Why Generalists Triumph in a Specialized World". I'm interested because for the last 10 years I've thought of myself as a generalist but always thought companies were looking for specialists. I could show immense value when I got to those companies, but I don't typically think companies are looking for generalist. They are looking for specialists to solve an acute problem.
I thought it was interesting to think about what Clubhouse was displacing. It felt the most analogous to radio. So, what could you do if you had radio at internet scale? Or what would it take to make internet scale radio successful?
In my mind, it came down to how challenging it would be to produce and monetize content. It's non trivial work. Producing a good radio show that's worth listening to takes a lot of time and effort. Podcasts are a good example here. I think there's data out there that suggests most podcasts don't have more than 1 episode or survive the first year. Without a good way to monetize, it's not worth the effort.
So while easy in the short term for celebrities/influencers/celebrities/VCs to jump on the bandwagon, the effort wouldn't be sustainable or worth it to them in the long run, and then you have a content problem again.
I also experienced some dark onboarding patterns while I checked it out that make me suspect their growth numbers were a bit over inflated, in an ask for forgiveness later kind of situation.
We've had Internet radio for almost 2 decades; it's called "podcasts". It's literally eaten "real" radio; NPR probably has more podcasts than broadcasts now.
That seems to support christopherslee's point. NPR already had what it needed institutionally to do podcasts people wanted to listen to and the reach to make sure they have a chance to reach an audience. I could start one and probably do okay because I already know a bit about audio engineering and marketing and can make my own music, but most people start from 0.
I thought they could be an add on to podcasts or radio shows where instead of having a phone bank or twitter feed, people listen in on clubhouse and then when picked by the host they get to talk or win tickets or whatnot.
Clubhouse filled in for going out and talking to people.
I don’t think their decline is any great mystery. Concern about the pandemic declined, people started going out again, and stopped listening in on audio chats on the Internet.
Twitter Spaces is not doing great either, but it doesn’t really matter because it’s just a feature, not a whole business.
If you could go out and talk to celebrities, sure. Or hear off the cuff celebrities from different worlds mix.
That’s what made it so exciting in the beginning… making it feel like you were part of an exclusive club even if you weren’t a famous person. Eventually the hype fades because the bar lowers, and the most interesting people move on.
Your point about Covid is also fair… the timing was good.
I agree with this point. It's hard to know if the OP is talking about title progression, or growth in the same role. Without knowing your organization, I can't say whether or not people are perceiving growth as having to take on management responsibilities?
If we're talking about growth as individual contributor, above comment is on the mark. There are still ways to grow as an engineer. Broader knowledge, deeper knowledge, reflecting on how to improve things, how to better connect the work to customers and the business, etc.
But, as their manager, you can help them tease it apart potentially even advocating for changes to the IC/technical track within the company?
Disclaimer: I also recently started at HubSpot and am currently enjoying my embedding phase immensely.
The whole embedding onboarding is awesome and I think it raises the question of how engineering leaders can go through cycles of leading and refreshing their technology skills. I believe many people fear leadership tracks because they don’t want to lose touch with their technical skills.
engineers hate giving estimates for a variety of reasons that i'm not going to get into here. most modern agile organizations don't value spending time on getting accurate estimates, but some kind of best-faith estimate is still valuable for a lot of reasons.
for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is.
for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z).
or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day.
what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.
I like to do something similar - I break down what I see are the risks, add a risk factor accordingly, then provide the estimate as a range. For example, the risk factor my be 50%, so I'll say the cost will be between £100k and £150k (for example). I find this really helps to focus the customer stakeholders who can control some of those risks.
Some devs seem to have actual phobias of estimates. My team was asked if we can deliver features x or x+ some time next year. (IMO as the dev who knows both the code and x best, we can deliver x in 2018 easily and x+ maybe). In our discussions about it, one guy would only say you can't predict the future, and another guy argued we should say either of them would take two years so that we could have time to rebuild the app from scratch while we delivered them. It's a web app.
tl;dr - we engineers are bad at estimation because we're too optimistic, and then we don't want to be accountable to the estimate given based on limited information.
i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.)
i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.
Engineers hate giving estimates because they can never be as accurate as planners want.
The only accurate time estimate is a range with at minimum a 4x difference between best and worst case, and preferably more the less certain the estimate is.
Keep in mind that you also can try to sell the company for more money if there's competition. Competition from other buyers, competition from investors. You probably want to try going down both roads to see how hard it is to sell or raise money. At that point you'll know more and you can feel more comfortable with the decision, whichever one you make.
You can sell the company for more money if there's more competition. That was one of the lessons of The Hard Thing About Hard Things. This is actually the best book to read about this particular situation.
tl;dr - if you believe in the company future and are willing to make that sacrifice, stay. if you don't, leave.
all startups have risks. i think that's something people overlook and they tend to think about the non-corporate atmosphere. anyways, that being said, i think it boils down to if you believe in the future of the company.
if you believe in the company's plan and you're willing to stick it out, great! imo, you should expect to hear an explanation of a company/product strategy _you_ believe has a chance.
if you don't believe it has a chance, well, i imagine you are sticking around for other personal or professional reasons. that could be because the opportunity you are getting (with specific tech, roles, etc) that you believe will help get you to where you want to be. it doesn't have to be about money.
if genuine promises were broken, that makes it tough to trust the folks that you are likely looking to for said strategy and plan.
Just applauding your effort here, not only for being proactive about getting into the field you want, but also for finding ways to contribute to open source without having to submit code. Keep it up!
At the end of the day, the stack is collapsing itself, and the lines are blurring because we want people to own the total outcome more often than throwing responsibilities over the wall to each other.
That doesn't mean engineers are going to design, but they should know what a good design looks and feels like. That doesn't mean designers or product should write code, but they should be able to engage in high level architecture discussion to understand the capabilities of their products.
I have not read it yet but there's a book by David Epstein (not that one), "Range: Why Generalists Triumph in a Specialized World". I'm interested because for the last 10 years I've thought of myself as a generalist but always thought companies were looking for specialists. I could show immense value when I got to those companies, but I don't typically think companies are looking for generalist. They are looking for specialists to solve an acute problem.