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.
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.
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 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.
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.
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!
To build on the suggestions other people are making, I would say that one thing I look for in the transition from to "senior" is the ability to make the people around you better. At the junior/entry level, a lot of your focus is about consistent delivery for yourself. As you move up the ranks, its about making you and your team better.
That could be removing roadblocks by flushing out designs and specs like other people have mentioned, or finding better processes and practices to make the team more effective. Of course, there is also the proper introduction of new technology or techniques to raise the company forward as well.
Software is all about tradeoffs, and there are so many ways a single problem could be solved. What works for me is to show them an alternative way that the code could be written.
Then you can have a practical discussion about the differences and what the differences are. Maybe their code is complex because they are considering more scenarios.
Sometimes, (not always), complex code is difficult to test. When I hear "the test is hard to write", it's a small to me that the code might be too complex.
not trying to discount this or my perceived intent of it, but i was wondering if any women could share specific examples when they were being mentored/coached differently than men. i understand that every individual, man or woman, responds to better to different communication styles.
i'm asking because i specifically want to know what unintended biases/habits I may have that i didn't realize.
Not sure if this is your first 6 months in the working world or not. I'm guessing that it is. I'm not trying to discourage you from leaving, but I wanted to offer some perspective.
If your startup is indeed rapidly growing, I think it is invaluable to see the growth first hand. Only a fraction of startups really see true rapid growth. Having that first hand experience will give you some perspective when hopefully, one day, your startup experiences that growth. Additionally, when interviewing at the "big hot startups", I think it's a major plus to have seen that growth somewhere else. But be honest with yourself if it's real, rapid growth, and not just some vanity metrics.
Secondly, I share some concerns that if you're burned out after your workday now, that quitting to do your own thing is going to be better. However, I can certainly empathize and understand that it is possible, but harder, to build a product part time at night. To hedge your risk, you should find that idea that you're really excited about, commit to getting an MVP and some traction to prove to yourself that you have an idea, and then quit.
While doing so, keep your responsibilities and cost of living structure low. Don't sign a new bigger apartment while you're getting a salary. Also, I'm not sure if you've thought about how long you can live without a salary. Do you need to supplement your ramen profitable startup with any extra income (contracting or otherwise?) If that's necessary, you'll need to spend time getting work and doing the work. I personally dislike contract/consulting work. I could never mental hack my way into feeling ownership of it. I've learned I'd rather work at a product company and work on something on the side, than do a startup "full time" while part time consulting to cover bills. Your preferences may be different.
Remember that startups are really hard. I've been through it to an acquihire, and I've had friends that were acquired for tens of million of dollars. And when I talk to them, I'm reminded that even though they're doing well, it's really hard. I absolutely think it's worth it if you're willing to bet on yourself.
Feeling like you've hit a ceiling at work and that you're only learning from yourself, sometimes can be fixed. Talk to your manager. Let them know. Maybe there's more responsibility for you. If you strike out on your own, guess who you'll have to learn from. Just you again. While joining a large community of people working on their own startup is fun, it's also lonely. No one cares about your startup more than you.
Yeah, it's tricky. I guess I should amend the suggestions to be:
A) start by understanding the tools and libraries available to you, and how to integrate them to build product/features faster.
B) start to understand what is going on under the covers in those libraries. it's not uncommon that, as awesome as these libraries can be, you'll have to look at their source code eventually to work through some unintended behavior or corner cases.
What I tell most people to do is to build a lot of toy projects. A lot. Ship a lot of code out onto the internet for the world to see.
There are several purposes:
1) Building a lot of things will hopefully help you uncover different problems that you will have to struggle to solve. Hopefully after struggling to solve them, you will gain understanding. Just following hello worlds doesn't really help much. But when you're trying to figure out how to implement a "real-world" product problem, you'll have to figure out how to develop features that don't come for free with whatever framework you are using.
2) Also, don't write everything from scratch. Research what frameworks or libraries might help accelerate your development. Understand the pros and cons of using them.
3) Hopefully as you build more things, they will get better. And then you will have something to showcase to prospective employers. You'll have real code you can share with them. Be humble, get pointers on how you can improve. Bonus points if you have tests too.
4) It shows initiative and interest. I'd imagine these are important intangibles. I'd be very reluctant to hire an engineer who didn't tinker with things at night. (not necessarily all night, every night.)
5) Additionally, taking vague concepts and requirements and turning them into products does take some discipline. Which features will you keep, which features will you cut. How can you change your requirements and still get what you want. It shows that you can do things without being told exactly what to do, or how to do it.
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.