Having worked at startups all my life, there's infinite work for us. At the very least, lots of tech debt and insufficient test coverage. On FE, there's also supporting a wider range of devices.
And then things that could be done better (reactive programming, declarative UI, etc).
Then finding weaknesses in the code, documenting them, educating the team. For example, we're not handling enough error codes properly like no bandwidth and when certain endpoints are down, users tend to panic. Or sometimes, certain endpoints should be combined for performance.
It could be putting down more logs, benchmarking performance, integrating analytics into the sales funnel, monitoring user frustration.
No offense, but I think asking around for things to do is a fairly junior attitude. The more experienced ones usually don't look at tickets, but instead start proposing things that can be done.
No offense, but I think asking around for things to do is a fairly junior attitude. The more experienced ones usually don't look at tickets, but instead start proposing things that can be done.
There is a difference between going rogue and taking initiative though! Talk to your manager or set up some 1:1s with people on your team, just saying "I have bandwidth" during standup isn't really the best time.
While talking with your teammates try to ask what projects or tasks they would like to see done but don't have the time. Flaky integration tests? Implement a ticket flow for incoming bug reports? Improve team wiki and system documentation? There's got to be lots of things to do.
And like a previous comment said, waiting around for work is a junior mindset. Take a look around and try to improve the pain points for your team.
Depends on the culture. After working in startups, I joined a bigger company. I burned through the work they gave me & convinced myself that I’d get fired for not having stuff to work on. I started proposing stuff to work on, but the problem was I couldn’t get access to any of the systems. I couldn’t push containers to the container registry. I couldn’t access GitLab admin settings. I couldn’t commit to repos with our Chef recipes. Everything I wanted to improve was in someone else’s sphere of influence, and I had to justify extracurricular commits on my team’s projects because every change had to be review by our understaffed QA team. I finally realized that the expectations of me were really low and that I needed to accept being underutilized or I’d go crazy.
Perhaps you mean to say don't be a bull in a china shop? That could be a problem. I've worked in large companies and taking initiative is the way to get recognition and build rapport. Company size is irrelevant to people recognizing that you take initiative. Taking on new things doesn't have to involve disrupting others, stepping on people's toes or otherwise doing things that are harmful to other teams. In fact, the larger the company, the more there is to do. People get deep in the complexity and there isn't anyone to repair duct taped stuff that that makes the giant machine run.
When I had not much to do, I'd sharpen up my own skills by building tools for others. I quickly become the guy to go to for tools. Instant credibilty in a Fortune 50 company. Making others' life easier is a quick way to win them over and be your advocate for life. If you do this enough, it compounds and pays dividends in your career.
I think it's a balance. I worked at a large company for years and never felt weird picking up coding tasks that weren't strictly in my task list or even immediate responsibility area if I felt they needed to be done, or if I just had an interest in learning more about that thing. To an extent it's probably about having a good overview of what kinds of tasks are "up for the taking" and being able to find the right people to communicate with if unsure.
PM at early stage startups (mostly <50 people when I join, current company is ~25) - this is 100% correct not only for engineering, but also every other department in my experience. I can think of a handful of weeks in my career when things were very light (and a couple of these were when I was doing marketing in my first job and were the weeks after our big conferences ended, so everybody just kind of took a break after working 100+ hour weeks leading up to them).
I think it was great for my career/professional development early on, and I highly recommend early stage startups for people early in their careers for that reason. It's not just that you're doing a bunch of stuff, but you're doing stuff that really matters. There's just way too much important work to give the new person pointless work. You're going to get handed real tasks that affect the business immediately, and if you show you can handle them, you're just going to get increasingly important work.
It's also one of the reasons I got recruited from marketing in my first job to PM in my second - they knew I didn't have PM expertise, but I had done meaningful, visible work, been promoted every year, and had built up domain expertise that was valuable for my second job.
It's not just junior people, either - at my current job, which I started <2 months ago, I was doing doing meaningful work in week two. It's definitely hard work, but it's also really nice that your coworkers appreciate you, because you're immediately picking up stuff that either they were having to do or that just wasn't getting done.
The people who have the most to gain from it. Boss is a blurry concept. Someone who has ownership over the proposal.
If it's some bit of refactoring or performance improvement, then the tech team or engineering manager.
If it's a feature, perhaps the designer or product lead.
If it's marketing related, then the marketing team, mostly to see how they work and whether it affects them as expected.
If it saves money... then not finance, but whoever takes credit for cost cutting.
If you've been turned down, why? Is it not helpful? Unnecessary? Are you misunderstanding the situation? Are you making them look bad? Do they not trust you?
Comments
Having worked at startups all my life, there's infinite work for us. At the very least, lots of tech debt and insufficient test coverage. On FE, there's also supporting a wider range of devices.
And then things that could be done better (reactive programming, declarative UI, etc).
Then finding weaknesses in the code, documenting them, educating the team. For example, we're not handling enough error codes properly like no bandwidth and when certain endpoints are down, users tend to panic. Or sometimes, certain endpoints should be combined for performance.
It could be putting down more logs, benchmarking performance, integrating analytics into the sales funnel, monitoring user frustration.
No offense, but I think asking around for things to do is a fairly junior attitude. The more experienced ones usually don't look at tickets, but instead start proposing things that can be done.
This might be true in the startup world where product managers have less well defined boundaries on what their role entails. At bigcorp© it’s generally frowned upon to go rogue and start working on stuff at random.
There is a difference between going rogue and taking initiative though! Talk to your manager or set up some 1:1s with people on your team, just saying "I have bandwidth" during standup isn't really the best time.
While talking with your teammates try to ask what projects or tasks they would like to see done but don't have the time. Flaky integration tests? Implement a ticket flow for incoming bug reports? Improve team wiki and system documentation? There's got to be lots of things to do.
And like a previous comment said, waiting around for work is a junior mindset. Take a look around and try to improve the pain points for your team.
Depends on the culture. After working in startups, I joined a bigger company. I burned through the work they gave me & convinced myself that I’d get fired for not having stuff to work on. I started proposing stuff to work on, but the problem was I couldn’t get access to any of the systems. I couldn’t push containers to the container registry. I couldn’t access GitLab admin settings. I couldn’t commit to repos with our Chef recipes. Everything I wanted to improve was in someone else’s sphere of influence, and I had to justify extracurricular commits on my team’s projects because every change had to be review by our understaffed QA team. I finally realized that the expectations of me were really low and that I needed to accept being underutilized or I’d go crazy.
Perhaps you mean to say don't be a bull in a china shop? That could be a problem. I've worked in large companies and taking initiative is the way to get recognition and build rapport. Company size is irrelevant to people recognizing that you take initiative. Taking on new things doesn't have to involve disrupting others, stepping on people's toes or otherwise doing things that are harmful to other teams. In fact, the larger the company, the more there is to do. People get deep in the complexity and there isn't anyone to repair duct taped stuff that that makes the giant machine run.
When I had not much to do, I'd sharpen up my own skills by building tools for others. I quickly become the guy to go to for tools. Instant credibilty in a Fortune 50 company. Making others' life easier is a quick way to win them over and be your advocate for life. If you do this enough, it compounds and pays dividends in your career.
It's moving away from "I have nothing to do. Give me something to do," and towards, "I have nothing to do. Here's what I would like to do..."
It's why there's daily stand ups too, so the entire team can approve or reject.
I think it's a balance. I worked at a large company for years and never felt weird picking up coding tasks that weren't strictly in my task list or even immediate responsibility area if I felt they needed to be done, or if I just had an interest in learning more about that thing. To an extent it's probably about having a good overview of what kinds of tasks are "up for the taking" and being able to find the right people to communicate with if unsure.
This. At bigcorp the last thing you want to be doing is showing initiative.
PM at early stage startups (mostly <50 people when I join, current company is ~25) - this is 100% correct not only for engineering, but also every other department in my experience. I can think of a handful of weeks in my career when things were very light (and a couple of these were when I was doing marketing in my first job and were the weeks after our big conferences ended, so everybody just kind of took a break after working 100+ hour weeks leading up to them).
I think it was great for my career/professional development early on, and I highly recommend early stage startups for people early in their careers for that reason. It's not just that you're doing a bunch of stuff, but you're doing stuff that really matters. There's just way too much important work to give the new person pointless work. You're going to get handed real tasks that affect the business immediately, and if you show you can handle them, you're just going to get increasingly important work.
It's also one of the reasons I got recruited from marketing in my first job to PM in my second - they knew I didn't have PM expertise, but I had done meaningful, visible work, been promoted every year, and had built up domain expertise that was valuable for my second job.
It's not just junior people, either - at my current job, which I started <2 months ago, I was doing doing meaningful work in week two. It's definitely hard work, but it's also really nice that your coworkers appreciate you, because you're immediately picking up stuff that either they were having to do or that just wasn't getting done.
Who do you propose things to? The boss? What if you've proposed numerous things but they've been turned down?
The people who have the most to gain from it. Boss is a blurry concept. Someone who has ownership over the proposal.
If it's some bit of refactoring or performance improvement, then the tech team or engineering manager.
If it's a feature, perhaps the designer or product lead.
If it's marketing related, then the marketing team, mostly to see how they work and whether it affects them as expected.
If it saves money... then not finance, but whoever takes credit for cost cutting.
If you've been turned down, why? Is it not helpful? Unnecessary? Are you misunderstanding the situation? Are you making them look bad? Do they not trust you?
I have no idea.