Hacker News Reader

Comment by datadrivenangel | Hacker News Reader

"An example of uncertainty in business is when your CEO tells you they promised a feature to your biggest client and it needs to be built ASAP as highest priority, so all hands on deck. Then a day later they tell you another feature, completely contradictory to the first one, needs to be built as well and is also highest priority. When you tell them they both can't be highest priority, the answer is: make it happen."

At a certain point you have to just build a queue and start the next highest priority thing next. Too much WIP kills you.

View on HN

This is one of the reasons why kanban is my favorite project management methodology.

"Ah, new highest priority feature. Lets do a mini discovery session and it looks like this work can be represented with 20 sticky notes. Our historical team velocity is 10 sticky notes every two weeks. So we'll probably be done in four weeks. If we take down all the existing work in progress. Lets go to each existing sticky and you can confirm that we can stop working on it."

The stakeholders are still allowed to make decisions, but (hopefully) it forces them to be realistic and understand what they're asking the team to do.

Pivotal Tracker does something like this with release markers. You can set markers between any two stories and, optionally, set a date. Tracker does a very simple moving average projection and if the stories before the marker will take too long, it turns bright red.

I found it remarkably effective at getting business folks to actually prioritize. They don't believe you, but they'll believe the computer.

At one point many years ago I was Director of Engineering for a company that was planning a major new version of their product. After I'd been there a few weeks I said to the CEO that I thought I had a pretty good understanding of the scope and challenges for the new release.

The CEO said "no you don't" - which led me to ask why he thought this and he said he had thought up a new "must have" feature over the weekend - which was clearly very technically challenging. He then asserted that anything could be built in 48 hours....

I'm amazed I lasted as long as I did in that job.

The CEO tells the Director of Engineering how long a time a feature "could be built" in? A new one, they suddenly pulled out of their asses too?

Why even have a Director of Engineering position then?

To take the blame, so, so obviously.

Ah, of course!

Because the world of business runs on hubris.

Reminds me of my Director of Engineering gig where I was asked how quickly we could deliver a new feature that the CTO had thought of. After giving three different estimates on the spot and being told each was “unrealistic” and told to “try again” in a meeting with senior leadership present, I finally said “Just tell me what date you want to hear so we can pretend I said that.”

I was chastised for being unprofessional and embarrassing the department. Didn’t care then; no regrets now.

No sense worrying about getting kicked out of a sinking ship.

As a manager, if upstream changes priorities on me but what we’re working on is almost done, I just go ahead and finish it anyways.

When they eventually switch back to the original thing they are always surprised to know it’s been completed.

Bad tactics. You let them make stupid mistakes with impunity. That way they'll never learn.

This was my last job, anyone in this position for any longer than necessary should be looking for another role. You're on a path to burnout or apathy, either way.

I called it "Monster of the Week", as I was watching a lot of X-Files at the time. Still like that term for it.

One of the strongest skills as a business facing developer is being able to say no.

Many people misunderstand this. Just saying 'no' and being firm won't make you successful, it's not a very useful. Saying 'no' while convincing others that 'no' is actually the best strategy is a great skill.

A good way to say "no" is, "yes, but then the thing I'm working on will not be done".

I like the redirection strategy. Find something easier to do and convince them it's better. Same strategy works for training dogs.

https://grugbrain.dev/#grug-on-saying-no

> best weapon against complexity spirit demon is magic word: "no"

> "no, grug not build that feature"

> "no, grug not build that abstraction"

> "no, grug not put water on body every day or drink less black think juice you stop repeat ask now"

> note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer

> is ok: how many shiney rock grug really need anyway?

when mysterious packages (new sandals, new animal skins, etc.) keep arriving at cave door for mrs. grug, grug not save very many shiny rock.

also, wolves and sabretooth tigers get hungry, need grooming, need vet, etc. picky about food too, want expensive organic stuff. sometimes mrs. grug buy animal skins for wolves even though they have perfectly fine pelts of their own. and don't get grug started on lil' gruglets (which this grug not have).

then no pile of shiny rock for rainy day, when shiny rock stop coming and cave mortgage is due.

shiny rock very important. get as much shiny rock as can without compromising values. happy mrs. grug = happy grug.

It site is an amazing and hilarious encapsulation of pretty much every conclusion I've come to after programming professionally for 20+ years (except maybe generics)

I remember, early in my career, being excitedly shown the "Agile Manifesto" by a bearded older dev.

I recently caught myself excitedly showing grugbrain to a younger dev, quoting the microservices section - and realized that I've come full circle, and now I'm the old bearded dev passing on some piece of thing that I found inspirational / exciting.

Stakeholder management is an art and sometimes you have to say "yes, but here's your choices"

And people tend to trust you for it since they admire your honesty. Often pretty rare in companies full of people sucking up for promotion.

I have a feeling that the ability to say “no” may be one of the key abilities that good human developers have over coding AIs. Knowing how to figure out the actual business need and realistic technical solutions, as opposed to just saying “yes” to the initial request, without really understanding feasibility or the real requirements.

And, as happened to me recently, the customer states in the demo that it's useless to them and let's just all move on to the next release.

Worse is when it's a salesman, not the CEO. It's infuriating. I always wanted to tell that salesman that he got to go back to the customer and tell them that we weren't going to do it, since he was the one who promised it without finding out whether and when we could do it.

Of course, I never had the clout to force that to happen...

It's always sales it seems. We're doing stuff under the gun right now because sales promised a huge new client we had something that wasn't ready yet. They didn't bother to ask us, they just promised so they could get their commission.

Good salesmen can sell the product that we already have. Terrible ones can't, and instead sell a product we don't have and then frantically beg R&D to make that product right away.

Agreed on this. And there's also great people in the middle who keep sales people up to date with new features and deprecations if you want the system to work.

I've been so much happier ever since I took a position in an organization that doesn't feature a sales department.

Speculatively build a feature that you know a customer somewhere would want (but maybe not the customer you have now) and then demand he find someone to buy it within a month before the AWS bills for it are due.

"You're costing us a lot of money!"

And this is why you need sales engineers. To look at what was promised, see that it meets the customer's needs, and is doable on your end.

It isn't just about helping sell the customer. It is also about saying no to overeager salespeople.

That’s not an example of uncertainty in business, it’s an example of incompetence in leadership. The problem is not one of software engineering, it’s one of rampant bad management and business practices.

If both have high priority, it's the same as both have low priority.

This is why good developers are hard to find. There aren't a whole lot of developers who have the required technical abilities while also being able to communicate with clients/leadership effectively.

The CEO is doing that because they don't understand how things work in your org. If you're the one communicating with the CEO, then its your job to be persuasive when telling them why what they're asking can't happen the way they're envisioning.

If they come back with "make it happen" then you weren't persuasive enough.

> When you tell them they both can't be highest priority, the answer is: make it happen

"Quality or quantity?"

"Yes"

These types are some of the most insufferable people imaginable

Reply on news.ycombinator.com