"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.
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....
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
At a certain point you have to just build a queue and start the next highest priority thing next. Too much WIP kills you.