I forgot to follow up here, so apologies for the delay. Honestly, concise is a challenge here. Here is a lot of words, and they barely scratch the surface, but just in case they might be helpful:
- Embracing the idea of a manual valuable process is a great one - as engineers we often want to start by automating and/or building, and dive right in - only to realize later we either didn't understand the product, or our stakeholder didn't and now wants changes once they've seen what it does.
(Deeper dives here: "Escaping the Build Trap"[1], "The Minimalist Entrepreneur"[2]
- Understanding negotiation is extremely helpful as you are often operating under constraints, and need to get those across to your stakeholders such that you can both move forward together. Negotiation is basically about aligning two stakeholders with different goals and arriving at an arrangement they can both live with. (Highly recommend "Negotiate without Fear"[3])
- Another excellent concept surrounds the theory of constraints and getting good at recognizing bottlenecks, and subordinating all other processes to them. Essentially, if work is piling up somewhere, look at where it is coming from, and attempt to re-route those efforts to something productive (the bottleneck moves the same speed regardless of how much work is piled up in front of it). The classic book on this matter is "The Goal"[4] but a fun retelling more oriented around an IT department is "The Phoenix Project"[5].
