So the rule is actually "yes, and..". The "and" is actually the crucial bit because if you just say "yes" without adding information the scene stalls (you always want to be filling in more and more details). "No, but.." tends to be frowned on because it reboots the scene and invalidates your partners scene painting... but in a corporate context I think "no, but instead.." might be the better answer (if you have an "instead", of course). Then youre still addressing the concern by adding new info, but youre not committing prematurely

Its in the same spirit because you're not invalidating the problem or concern that created the request, but youre adding new information and context that way. I like your attitude but I think saying Yes to everything can be harmful if you have info they dont have that might factor into decisions. I think no, but with an alternative, can be really productive.

My first real programming job I had was working for a guy who hired lots of contractors. And he was frequently angry with the programmer that loved to say "no I can't do that" only to have the same programmer come back a week later with a possible solution.

Since this experience I almost always answer "yes" to all client requests but with a list of compromises required to get something built. It keeps everyone involved happy, even me.

This approach is covered extensively in the book 'Getting to Yes And: The Art Of Business Improv' by Bob Kulhan, which is one of the few books I would consider a must read for anyone interested in technical leadership.

Any other recs?

I can relate to this a lot. Probably the reason of saying NO most often is the fear of bad things that could happen. On the other hand, if people spent less time discussing things and rather iterated on working (!) software, it would be less of a problem.

In any case, I think engineers should in general do more creators work and product people should focus on keeping the business alive. Indeed there must be people that know the market, the business implications and the competition.

I today agree, that devs being part of the creative process and not being drones leads to more happiness and has a lot of upside: they bring new ideas to the table, are more invested in the solution and feel owner ship -> quality of outcome is better.

However, in my experience working on a big product with multiple teams, the main problems with devs getting creative is

(a) the consistency of the user experience suffers badly

(b) the overall architecture erodes as everybody builds particular solutions fitting their specific problem

I am not sure what the best way is to reconcile Dev happiness and (a,b) in this context.

About (a) and (b), in my first 2 jobs this was a non-issue since my boss always had the last word. I guess today's Agile/Scrum situation is a big improvement over that, where people work data driven and not by personal taste of one person.

Anyway, one could solve it by maintaining a ratio of people with a lot of experience.

(a) A Designer needs to be on the team that can do a Corporate Identitiy (CI) => this way it's possible that Engineers create their own Bootstrap

(b) Either solve it top-down by having an engineer with enough architecture experience; or have architecture guidelines in place / develop them consensus-based

At most places there are very concrete guidelines about codestyle, usually ensured by linters. One can also put more emphasis on architecture style

One thing I try to do is to never say something is impossible or to refuse to do as instructed outright. Of course everything is possible, it's just a matter of how much effort is reasonable to put in.

If my boss comes up to me with "can we do unreasonable thing X" it's not my job to change his mind. It's my job to provide him all the relevant data and then let him decide on the course. If the request would take a large amount of effort I let him know. If the request would cause bugs or problems elsewhere I let him know. If the request would (in my opinion) upset users I let him know. What I don't do is tell him no.

If when given all the pertinent information my boss still decides it's a good idea to spend a month straight implementing a bug then I'm happy to oblige but only after all the information is on the table.

He's captain Picard and I'm chief engineer La Forge. The captain decides, and the crew executes.

Of course there's a couple catches to this approach where it doesn't work. If my boss would ask me to do something unethical I'd first try to tell him why it's a bad idea, before firmly refusing. I do this knowing full well that this might injure our working relationship.

The other assumption this method makes is that your boss is actually good at his job. A boss that makes unilateral decisions without consulting the experts that work under him is bad at his job. A boss that takes it personally when you tell him his ideas aren't good is bad at his job. A boss that isn't open to discussing approaches is bad at his job. A boss that tries to dictate how exactly you do your job is bad at his job.

Now of course all the above doesn't mean I'm acting weak-willed or indecisive. If I disagree with a course of action I let it be known. I'm not hiding my opinion. But I do respect that my job is to implement business demands and my boss' job is to gather, distill, and communicate business demands.

Anyways that's my approach and it has served me well so far.

I also try to do this at work, with the exception of ethical/moral and interpersonal stuff. Don't "yes and" into harassing someone, or into your drunk boss's passenger seat.

I prefer to say "yes but" and bring the prioritization discussion front and center. I wrote more here:

https://letterstoanewdeveloper.com/2019/09/02/the-art-to-and...

More improv "don't" tips from The Office: https://m.youtube.com/watch?v=C6wY9OwqJ2A

yeah, the converse of what the article talks about is that software engineers tend to be pretty arrogant and dismiss suggestions and requests from users and designers, and just treating them like people and seriously trying to find common ground gets you very far.