I can’t imagine anyone on my dev team or the others at my company being able to spend multiple weeks consecutively on vaguely defined unplanned work. We collaboratively make a plan with product management covering many weeks of work (PI planning) with some date commitments on milestones we expect to achieve. Anyone spending a more than a few days on unplanned work risks making us need to revise the plan that we all made together, so we don’t want to do that because the opportunity cost is obvious.
Doing too much work on one's own before looping in others
161–170 of 395 posts
Re: Doing too much work on one's own before looping in others
#162Earlier quoted context omitted.
What's a PRD? Love the five-minute rule, by the way. I tried to apply that a lot especially when I was just starting at my job. So many things that I would spend two hours trying to fix, only to be told the next day that we had a super simple internal process to fix that thing.
Product Requirements Document ... a full specification of everything the software needs to do. Sometimes VERY detailed, sometimes not so much.
They could probably just write this in code, and save a lot of time.
Re: Doing too much work on one's own before looping in others
#163I am stuck with a delicate balancing act around this one.
Our organization arguably would not exist today if it were not for developers doing "too much" work on things before bothering others. Our product would certainly be worthless trash today if we had to design by committee for every feature. We took extraordinary risks that simply could not have been planned into reality. Most of those risks were taken by individual contributors without anyone being explicitly aware of the magnitude of those risks.
There is a price to be paid for asking permission. Especially if your team members lack the same vision/ambition and are unable to conceptualize the path you laid out. Clearly, this is a problem for both parties, but it is a big reason to sometimes go off on your own, build a whole goddamn thing in peace, and then show it to the team. When others see a complete solution, even if its not 100% what the business wanted, it makes the conversation substantially more productive. It's the fear of the unknown/unseen that makes project managers nervous in my experience. Why start a hard thing at all if the conclusion is ambiguous at best?
On the other hand, we lost ~4 major customers to technical iterations over time. This was something we could have avoided by polishing what we had at the time. Problem is, that thing we would have polished was an abject failure in terms of strategic sustainability for the organization and our customers at scale.
Re: Doing too much work on one's own before looping in others
#164This is a bit of a nuanced topic with lots of shades of truth or context, and overall I agree with the article, but that said: Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will t…
The reality is that it's not your call, it's the customer's call, and you need to stop trying to make a decision for the customer. Let them tell you what they want.
Re: Doing too much work on one's own before looping in others
#165Earlier quoted context omitted.
A lot. Technical managers need not be experienced technical talents who have made a potentially incompatible shift to management.
It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.
An experienced manager is not easy to bullshit regardless. Sometimes a non-technical manager is better for many reasons. Having business domain experience can be just as valuable
Re: Doing too much work on one's own before looping in others
#166Earlier quoted context omitted.
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…
> I've been doing this longer than some of my managers have been alive. In what organisation do 25 year olds manage 50 year olds?
I'm a 25 year old managing a global team of 8 people. I'm self-conscious about my age both in my 1:1s with my reports and when talking with customers. That being said, it seems like things are going well. My team is doing great metrics and achievements wise and the company we work for tripled in size in under a year.
Re: Doing too much work on one's own before looping in others
#167Earlier quoted context omitted.
> I've been doing this longer than some of my managers have been alive. In what organisation do 25 year olds manage 50 year olds?
I'm a 25 year old managing a global team of 8 people. I'm self-conscious about my age both in my 1:1s with my reports and when talking with customers. That being said, it seems like things are going well. My team is doing great metrics and achievements wise and the company we work for tripled in size in under a year.
You know what I usually tell my managers. "Thank you for your service" :-)
Re: Doing too much work on one's own before looping in others
#168Earlier quoted context omitted.
The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonab…
Non-trivial problems often require exploration of the solution space. You're not expected to ask management if they've changed their mind, you're meant to present your finding so far, and ask if they have any feedback. Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
> Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for.
Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
Re: Doing too much work on one's own before looping in others
#169Earlier quoted context omitted.
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…
> I've been doing this longer than some of my managers have been alive. In what organisation do 25 year olds manage 50 year olds?
Many organizations and it is a normal thing.
Re: Doing too much work on one's own before looping in others
#170> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…
> If your work is bullshot, I bill tighter than my lawyer
Lawyers must hate their work.