|
Are you proposing a new product or service, or a change to how work is done?
|
#
?
Nov 18, 2023 19:46
|
|
|
|
| # ? May 23, 2024 18:37 |
|
|
Rocko Bonaparte posted:Does anybody have anything for improve how to technical writing that "aims upwards?" I'm talking less about documentation and manual stuff and more about proposals and arguments. I'm having to do that a lot more and hoped there was a book or two that go that way. The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change Smart Work: The Syntax Guide to Influence Getting to Yes: Negotiating Agreement Without Giving In Stories That Stick: How Storytelling Can Captivate Customers, Influence Audiences, and Transform Your Business Outcomes Over Output: Why customer behavior is the key metric for business success Escaping the Build Trap: How Effective Product Management Creates Real Value Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty How to Measure Anything: Finding the Value of "Intangibles" in Business Measure What Matters Fanatical Prospecting: The Ultimate Guide to Opening Sales Conversations and Filling the Pipeline by Leveraging Social Selling, Telephone, Email, Text, and Cold Calling Focus on business outcomes, learn what your leaders' jobs actually are, and tune your communications to them in a way that shows that you value their time. (Take what you need to get things done; don't waste it by pulling them into things you're utterly unprepared for.) Learn how to sell, but don't go overboard. If you sound like a LinkedIn cold caller, it's triggering more than it's helpful. The most important thing that I never see anyone touch on is that leaders are extremely surprised when they hear about new problems for the first time from an IC engineer and not from one of their trusted deputies. It makes them think that either the engineer is catastrophizingthis is it, most of the timeor every single person they trust has failed to report a major problem upwards, which is a tough thing to convince them of. Someone who is caught off guard is not someone who is listening intently to you. If you find yourself putting a leader in between these two extremes, you are now in your own crossfire. Vulture Culture fucked around with this message at 22:08 on Nov 18, 2023 |
|
#
?
Nov 18, 2023 21:54
|
|
|
To really dumb this down, what I tend to do is try and figure out what the goals of the team I'm trying to propose something to are and then tie my proposals directly to those goals as tightly as possible. For example, if you work on a team that does support for others, and wants to have more customers, then something like 'wow these tickets suck and we should automate them' becomes 'in order to reduce our operational workload per supported team, we should do X/Y/Z that will reduce the time needed for this ticket from Z to Z * .25' or something like that. Vulture Culture posted:Learn how to sell, but don't go overboard. If you sound like a LinkedIn cold caller, it's triggering more than it's helpful. This whole post is good, but I do want to point out this part because it's one big thing I struggled with - you can find a middle ground between 'totally gormless IC' and 'sales dude' and once you get used to it you'll realize this is how seniors have been communicating the whole time. Also it's very important to try and be genuine as much as possible. For example, if something you're doing saves money, that's great! Put it in your deck and mention it - it is useful - but don't lean into it too hard just because you know your boss likes saving money, because you'll come off as disingenuous very quickly, which is offputting.
|
|
#
?
Nov 18, 2023 23:18
|
|
|
Vulture Culture posted:The most important thing that I never see anyone touch on is that leaders are extremely surprised when they hear about new problems for the first time from an IC engineer and not from one of their trusted deputies. It makes them think that either the engineer is catastrophizingthis is it, most of the timeor every single person they trust has failed to report a major problem upwards, which is a tough thing to convince them of. Someone who is caught off guard is not someone who is listening intently to you. If you find yourself putting a leader in between these two extremes, you are now in your own crossfire.
|
|
#
?
Nov 18, 2023 23:39
|
|
|
StumblyWumbly posted:This is true, I've been on a few different sides of it, and there are good ways to handle it with phrases like "This problem has recently come up because", "This problem is getting worse because", "This has been causing friction for a while but I think it is now worth solving".
If you have too many answers for any one of these questions, you've picked the wrong problem. Answers that are too high-level or vague communicate that you have a surface-depth understanding of the problem. Answers that are too low-level communicate that you have a surface-depth understanding of the work needed to fix it. Aim for the middle: here's the impact on people, here's who's going to have to chop wood and carry water to get it done, and here's what we're asking for right now. Made-up answers to these questions are better than incredibly detailed and 100% vetted answers to the wrong questions, because your leaders' ability to build a stake relies on actually being able to keep tabs on how well reality reflects the plan you put forward. Vulture Culture fucked around with this message at 00:06 on Nov 19, 2023 |
|
#
?
Nov 18, 2023 23:58
|
|
|
Thanks Vulture Culture for bringing Thanksgiving early, for I now have so much to eat. I can get anything from O'Reilly and a bunch of other stuff, so I think I can hit this stuff through my work's online library thing when I check in on Monday. I didn't have a specific situation going on where I need to do a specific thing right now. I just notice I've been writing a lot more upwards-facing stuff in the past three months, it follows where I am in my career, and I know my upper managers are very hungry for that from anywhere.
|
|
#
?
Nov 19, 2023 10:34
|
|
|
Vaguely related, but does anyone have advice on how to get your coworkers to take on work that you find? In my current team we have a lot of tech debt, but some of it is a lot more of a problem than others. For example, broken monitoring, or other issues on production systems. When I'm oncall I tend to drag up issues that I think are important but it tends to turn into 'well I guess I get to somehow fit this into my next week of work', and I get a lot of feedback that I'm taking on too much (not to mention it's stressing me out.) Once or twice when something is such a big deal that it could lead to an outage, I've been able to argue successfully for management to help assign this work out, and every time the feedback has been positive. However, it's getting a little frustrating that we have this very clear social rule that 'if you found it, you have to solve it'. I understand that nobody likes a coworker telling them what to do, and it's just as frustrating for other people to have to fit this work into their schedules, but I seem to be the only one that's actually digging up these issues instead of burying them. Any tips for trying to tackle this? We have some general programs ongoing that could be helpful, but they;'re a little long view.
|
|
#
?
Nov 20, 2023 00:33
|
|
|
What sort of project management framework do you have in place?
|
|
#
?
Nov 20, 2023 00:37
|
|
|
do you just not plan anything ever? when work is scoped, include the tech debt. make fixing it a blocker for a feature that would benefit from it being fixed if you have to picking what to work on next is planning. make a ticket for the thing and give it to the person who picks what the team works on next.
|
|
#
?
Nov 20, 2023 00:39
|
|
|
I can think of two general approaches: Convince decision makers of the importance. Back up the importance of this tech debt with numbers like "This issue is causing significant development friction. if we invest a month in this, we can increase feature development velocity, saving X months of effort." Or find reasons to pull tech debt into the projects that are being prioritized and inflate your estimates to match. "It's important to fix this first because..." I call this 'laundering' tech debt. Often you don't even need to bend the truth much.
|
|
#
?
Nov 20, 2023 00:51
|
|
|
ultrafilter posted:What sort of project management framework do you have in place? Yeah I read this and then audibly went 'ohhhhh yeaahhhhh.' We don't. We just...don't have a project management framework in place. We technically have a kanban but there's no mechanism to move work out of it into people's laps. I guess that answers that, I'll go back to yelling about that problem them.
|
|
#
?
Nov 20, 2023 01:07
|
|
|
The way my team does it is to write up an issue or Confluence page on the proposed work, add it to the backlog and convince someone to add it to the sprint. Manager free Kanban sounds... interesting.
|
|
#
?
Nov 20, 2023 01:12
|
|
|
StumblyWumbly posted:The way my team does it is to write up an issue or Confluence page on the proposed work, add it to the backlog and convince someone to add it to the sprint. We basically are a very old team at a very big company with a very broad scope; we just have a shitton of work. So it's such a target rich environment that basically people are busy all the time working on things reactively. Certain projects get their own PM handling (which is also a problem but at least we're trying) but it's separate from operational work like I'm describing. We do have some general projects that aim to tackle this stuff but...well, they're not done yet, so I'll go find the owners and start shaking trees again.
|
|
#
?
Nov 20, 2023 01:19
|
|
|
Here is another question outside of planning: what is your team incentivized to do? What are you held accountable for? How is your performance assessed? In the absence of an explicit planning structure it can be difficult to convince your team to tackle things like process or tech debt if they don't see the reward. You may have to get them on board with the idea that life would be better for you all if, as a team, you budgeted a certain amount of time every quarter to fix things. If people are worried about ensuring a balanced contribution then scheduling an all-in "fix-it" week/sprint throughout the year can help everyone feel like the effort is equitable.
|
|
#
?
Nov 20, 2023 02:12
|
|
|
Falcon2001 posted:Vaguely related, but does anyone have advice on how to get your coworkers to take on work that you find? In my current team we have a lot of tech debt, but some of it is a lot more of a problem than others. For example, broken monitoring, or other issues on production systems. When I'm oncall I tend to drag up issues that I think are important but it tends to turn into 'well I guess I get to somehow fit this into my next week of work', and I get a lot of feedback that I'm taking on too much (not to mention it's stressing me out.) Try to decouple the language of "you have to solve it" from the interpretation of "you have to personally implement the complete solution". What a competent but busy manager wants you to do is show that your project is important enough that you can get resources for it on your own. You have then done the job of proving to someone, who doesn't really care about the technical details of your work enough to know if you're making up all your impact numbers, that you're proposing something worth working on. They can then do the part of the job they're good at, which is finding enough resources to staff up an obvious priority. So your first step is to beg, borrow, or steal people's discretionary time on the project. It really doesn't matter how much that is. A couple hours a month each from a handful of different people is huge. What matters is that you demonstrably have the interest from other people. You then have the ability to take that and, as a group, say "we think this is an important problem to solve, but we aren't able to prioritize it without dropping something else." Management wants you to bring this full scenario to them so they can first gain situational awareness on what you think are the most and least important/successful things on your plates, and then make decisions. They probably want to own the prioritization decision; pushing that upwards gives them the ability to give you actual air cover. If the scenario is that everyone is burnt out on urgent ops work, and you're all struggling just to keep the lights on, "implement a solution yourself" might not really be a bad idea. It seems like the intent there is to keep focus on the work at hand instead of infighting about equivalent priorities. If you find something that can really drop the load more than what anyone else is working on, your call to action is to substantively prove it. Process-wise, a starting point might be to create a dedicated team meeting time to discuss new ideas or designs, where everyone is expected to be focused on hearing each other and not bringing their own work to the table. This usually requires a good facilitator and management air cover, but in my experience, I've found both of these to be pretty easy asks. Vulture Culture fucked around with this message at 16:01 on Nov 20, 2023 |
|
#
?
Nov 20, 2023 15:52
|
|
|
Falcon2001 posted:we have this very clear social rule that 'if you found it, you have to solve it'. quote:I seem to be the only one that's actually digging up these issues instead of burying them. This is definitely a management issue. People should feel psychologically safe to submit issues about problem areas without fear that it'll get ignored or they'll get "penalized" by having it immediately assigned to them. And if the team is constantly in "running around with hair on fire" mode all the time, then this might be one of the reasons why. Management should be identifying "force multiplier" opportunities like this, e.g. "Fixing this flakey monitoring is a force multiplier because less false positives to deal with means we now have more time to spend on other issues."
|
|
#
?
Nov 20, 2023 18:52
|
|
|
If your direct manager sucks rear end but your skip seems to be pretty good, how do you navigate this? When they pry for info, do you answer with honesty? People know my team has issues, particularly my boss, who has a very low approval rating (and our team lead too) but I'm not sure how to speak honestly without it basically being ratting. Albeit, ratting at least one of my teammates agrees with!
|
|
#
?
Nov 20, 2023 21:56
|
|
|
Good Will Hrunting posted:If your direct manager sucks rear end but your skip seems to be pretty good, how do you navigate this? When they pry for info, do you answer with honesty? People know my team has issues, particularly my boss, who has a very low approval rating (and our team lead too) but I'm not sure how to speak honestly without it basically being ratting. Albeit, ratting at least one of my teammates agrees with!
|
|
#
?
Nov 20, 2023 22:46
|
|
|
Our team's dev process is way too slow because our TL is involved in too much PM work and it slows many things down. It impacts velocity, my entire team suffers, and my manager doesn't see it as an issue because he relies on the TL to cover his ineptitude
|
|
#
?
Nov 20, 2023 23:03
|
|
|
Thanks everyone for the feedback; you're all various shades of right and once we get done with this imminent big holiday thing that's ruining my life I'm going to go chat with my manager and re-push the issue again. Not to potentially identify myself too hard, but basically my team has just a ridiculous scope. minato posted:And if the team is constantly in "running around with hair on fire" mode all the time, then this might be one of the reasons why. Management should be identifying "force multiplier" opportunities like this, e.g. "Fixing this flakey monitoring is a force multiplier because less false positives to deal with means we now have more time to spend on other issues." FWIW this is a big focus for management right now, and it's part of why I'm sticking around, but the problem is that some of our stuff is like 'we're going to spent 12 months fixing one fire through proper automation', and I'm fighting for 'I recognize a fire department is a great idea, but for now I would be happy for a bucket, does anyone have a bucket. No? Alright, I made a bucket.' Buckets aren't great on promo docs though, so...y'know.
|
|
#
?
Nov 21, 2023 02:29
|
|
|
Good Will Hrunting posted:Our team's dev process is way too slow because our TL is involved in too much PM work and it slows many things down. It impacts velocity, my entire team suffers, and my manager doesn't see it as an issue because he relies on the TL to cover his ineptitude I was the TL in a very similar situation. Our PM was awful and didn't understand fundamental principles like "stories need acceptance criteria" while the manager seemed to just kind of coast and rubber stamp vacation requests. I raised this issue to my skip and we tried to work through it, but he was hamstrung by his VP in turn, who seemed to want to solve the situation directly by beating down the will of anyone willing to change anything. At least our PM quit and we got a new one who was good and the VP explicitly prohibited me from doing anything even remotely managerial which at least forced me to focus on the product. Unfortunately I can offer very little in terms of an actual solution. In my case, the skip at least raised my concern all the way to the CTO, who promised me that if I quit rocking the boat, he'll forget that any of this ever happened. By that point I already had an offer in hand for a manager title at a non-disastrous company with a healthy pay bump, so there was nothing keeping me there. On the day after I put in my resignation, it was announced that the VP was also leaving and it was already known that the CTO was one foot out the door, so maybe they both gave up on the company and didn't want to perform any non-trivial duties. Last I heard, the skip is now a senior director and the place really turned around once there was someone who gave a poo poo in charge.
|
|
#
?
Nov 21, 2023 06:29
|
|
|
Good Will Hrunting posted:Our team's dev process is way too slow because our TL is involved in too much PM work and it slows many things down. It impacts velocity, my entire team suffers, and my manager doesn't see it as an issue because he relies on the TL to cover his ineptitude Am I your tech lead? Because this perfectly describes my situation. Im solving it by replacing the PM. Although I guess we were lucky because the only problem with our PM was he had too many teams to support so hes happy to let me take two of them. The other team is in worse shape because their tech lead wasnt as able to cover for the PM and Im starting to feel in over my head. Hopefully just normal new position problems.
|
|
#
?
Nov 21, 2023 07:04
|
|
|
Oh I should have mentioned the tech lead is a bit of a control freak at the product level! We have essentially never had a stable PM, until now (our PM is a poach hire from a competitor and very filled with knowledge, needs improvement in PM skills) and our TL has been inadvertently covering up so much in light of our manager(s) who have been rotating forever cause we can't seem to keep one. The problem is the TL thinks this is okay, probably because he loves being the one with all the knowledge as the most tenured on the team by 5x, but his inability to grow engineers on the team has really slowed us. Every single decision has to go through him. Our current manager is too dense to realize the immediacy of the problem, but the skip absolutely does. He just needs fuel and examples, but giving them to him feels like undermining the TL my manager.
|
|
#
?
Nov 21, 2023 16:25
|
|
|
Good Will Hrunting posted:Our team's dev process is way too slow because our TL is involved in too much PM work and it slows many things down. It impacts velocity, my entire team suffers, and my manager doesn't see it as an issue because he relies on the TL to cover his ineptitude Good Will Hrunting posted:Oh I should have mentioned the tech lead is a bit of a control freak at the product level! We have essentially never had a stable PM, until now (our PM is a poach hire from a competitor and very filled with knowledge, needs improvement in PM skills) and our TL has been inadvertently covering up so much in light of our manager(s) who have been rotating forever cause we can't seem to keep one. It seems impossible to actually assess a PM or any of their skills in the circumstances you're describing
|
|
#
?
Nov 21, 2023 16:36
|
|
|
Going around a bad manager is self-care.
|
|
#
?
Nov 21, 2023 16:37
|
|
|
What are some things to ask when considering joining a small, early stage startup? Think fewer than ten employees and less than a year since starting.
|
|
#
?
Nov 21, 2023 17:05
|
|
|
Check the first few posts of the YOSPOS interviewing thread.
|
|
#
?
Nov 21, 2023 17:11
|
|
|
Vulture Culture posted:It seems impossible to actually assess a PM or any of their skills in the circumstances you're describing Yes and no. His ability to actually make concrete decisions without needing my TL's approval, clearly define requirements in a spec, or convey drift as it develops between releases and things like that are objectively things he does poorly. Specs are never updated. They're written once and discussions are had in random tech designs, slack threads, etc, discussions that are ultimate spec-altering. The fundamental problem is my TL is both the gatekeeper of all PM decisions and ENG decisions. Nobody feels comfortable before roping him in because of his knowledge but also because our manager has never cared to change this culture. ultrafilter posted:Going around a bad manager is self-care. My biggest concern is stoking flames in this economy while being at a company that just did layoffs and is moving tons of work oversea, and my TL being part of the problem and also here 10+ years.
|
|
#
?
Nov 21, 2023 17:14
|
|
|
Im 0 for 2 with good experiences with startups, and I dont know if my problems could have been caught at an interview, but those were also places where I was practically employee #1. At a ten employee company Id want to know about employee turnover and average length of stay. I think thatd be a good warning sign of trouble.
|
|
#
?
Nov 21, 2023 17:19
|
|
|
Good Will Hrunting posted:Oh I should have mentioned the tech lead is a bit of a control freak at the product level! We have essentially never had a stable PM, until now (our PM is a poach hire from a competitor and very filled with knowledge, needs improvement in PM skills) and our TL has been inadvertently covering up so much in light of our manager(s) who have been rotating forever cause we can't seem to keep one. Don't think of it as undermining your TL, think of it as another avenue of delivering feedback. It's really easy to get stuck in the rut of "I have to do everything since if I don't, no one will". In the ideal case, your skip is going to offer support for the manager to be managing and the TL to be tech leading and this feedback plus support are going to make him better at his job.
|
|
#
?
Nov 21, 2023 17:19
|
|
|
I don't think that TL will be receptive to the feedback that he's doing too much PM work and making too many PM decisions, and the quality of the engineers lives are deteriorating, though. I don't think he thinks there's a problem. I could be wrong!
|
|
#
?
Nov 21, 2023 17:22
|
|
|
If you're wrong then he's an rear end in a top hat and you don't need to feel bad about undermining him. Either way, your skip will be much better equipped and motivated to deal with it if you give him concrete examples of how this behaviour is negatively affecting you and the team.
|
|
#
?
Nov 21, 2023 17:44
|
|
|
Good Will Hrunting posted:Yes and no. His ability to actually make concrete decisions without needing my TL's approval, clearly define requirements in a spec, or convey drift as it develops between releases and things like that are objectively things he does poorly. Specs are never updated. They're written once and discussions are had in random tech designs, slack threads, etc, discussions that are ultimate spec-altering. Vulture Culture fucked around with this message at 22:43 on Nov 21, 2023 |
|
#
?
Nov 21, 2023 22:39
|
|
|
Well our PM doesn't write user stories either. He writes a giant spec doc once that's usually presented for review in front of a bunch of PM and engineering leads across teams that gets hundreds of comments, and addresses things in the comments that he then expects to be implemented as part of the feature without modifying the spec or doing something iterative like going from big spec doc to user cases. I'm not talking about iterations in the spec based on system knowledge, we have those details in our tech designs. I'm talking changes to the actual product functionality strictly from reviews coming in from PM and team lead. As a staff eng who leads one part of the product I have no qualms being the digestion layer, but even when I (or other leads for product comments make decisions for Eng stuff) the team lead vetoes us regularly and when we explain our decisions will regularly walk back on vetoes slowing us down even further.
Good Will Hrunting fucked around with this message at 23:15 on Nov 21, 2023 |
|
#
?
Nov 21, 2023 23:12
|
|
|
TLs need to be the glue or grease the situation calls for. If you need more project management, that's on the TL to fill in and help smooth things out. Where that sucks is when it becomes permanent. If you have a PM they need to step up their game. If you don't have one, everyone else on the team needs to step up and learn how to manage themselves.
|
|
#
?
Nov 22, 2023 01:00
|
|
|
Good Will Hrunting posted:Well our PM doesn't write user stories either. He writes a giant spec doc once that's usually presented for review in front of a bunch of PM and engineering leads across teams that gets hundreds of comments, and addresses things in the comments that he then expects to be implemented as part of the feature without modifying the spec or doing something iterative like going from big spec doc to user cases. I'm not talking about iterations in the spec based on system knowledge, we have those details in our tech designs. I'm talking changes to the actual product functionality strictly from reviews coming in from PM and team lead. As a staff eng who leads one part of the product I have no qualms being the digestion layer, but even when I (or other leads for product comments make decisions for Eng stuff) the team lead vetoes us regularly and when we explain our decisions will regularly walk back on vetoes slowing us down even further.
|
|
#
?
Nov 22, 2023 01:38
|
|
|
The TL glue is being distributed to three of us my manager calls "stream leads" and the coordination across them is something the TL is doing but introducing this layer is slowing us down and, in my opinion, producing dubious results because one of the other stream leaders is new and the other has zero idea to communicate.
|
|
#
?
Nov 22, 2023 01:44
|
|
|
So the real question for your manager's manager (finding tactful wording is on you): why is your manager letting your TL have a special arrangement that allows them to delegate basically their entire job, while taking no apparent accountability for whether or how well that work gets done?
|
|
#
?
Nov 22, 2023 01:52
|
|
|
TL goes to meetings (an absurd amount of cross team ones), does code reviews (very slowly and generally blocks all 3 streams, and meets with the PM to review specs and usurp decisions. TL does whatever he wants because he's been here 10 years and has tons of knowledge so people view him as untouchable. We've lost two people on the team because they felt TL had zero capacity to grow engineers or the team. To be fair there are so many side effecting possibilities of our code base, tons of the work the more important ICs do require someone with some knowledge of years back understand specific flows. It's also a huge part of the problem.
|
|
#
?
Nov 22, 2023 01:54
|
|
|
|
| # ? May 23, 2024 18:37 |
|
|
In many places that sort of "distinguished engineer" greybeard would have a role where they consult on all sorts of things where that institutional knowledge is useful, but aren't in a position where anyone else is depending on their leadership abilities. 10 years is pretty small ball though unless there are some serious skeletons in the closet.
|
|
#
?
Nov 22, 2023 02:08
|
|
