How can I keep my Engineers properly fed with quality work?

Personally, I run a Kanban board for product planning - the end of my board feeds into the beginning of the dev board, with the devs accepting the work onto their board so that if I missed anything or they need more info, it stays with me until it is complete enough that they can work it without questions. This speeds things up because I am not constantly just putting out fires due to poorly written cards.

I also find that product people tend to forget our purpose. PM 101: We say "what" needs done, Engineers say "how". So that is exactly what I write up. I don't diagram technical details, even though I also am an engineer and could do so... but I do get very tight on details of "what" should happen - "Click button a, do thing b, expect UI change c, etc." Cards typically outline a set of actions like that to comprise a feature, and I let the devs worry about whether it needs broken down into subtasks and shared amongst themselves or whether one dev will work it all. Again, my job is "what", theirs is "how".

Forgetting the goal of the product role often leads to product people who spend all their time in meetings micromanaging the dev process, instead of letting the engineers run free to do what they do. Which in turn leads to devs who complain about product people, and the whole team's morale tanks. If you can escape all that, the devs have autonomy to do their jobs and you have time to write good specs while keeping a lightweight process.

Edit: I should add that I don't set my specs in stone - devs are welcome to come to me and say, "Wouldn't it be better to do it this way?", and if their idea is better, I say yes.

> We miss subtleties, test scenarios,

This is something only 4x+ perfectionist types of engineers can do naturally.

They cost double the price tag, they need freedom and respect, you don’t attract them by leetcode interviews or arrogant managers but its the only way to get high quality product in reasonable time.

Otherwise you have no alternative but do it like everybody else — spend time and money on training, layers of management, elaborate system of acceptance tests, feedback loops etc.

Including training your users to live with your mediocre product and hope for the best.

Do you pay above market rates? It sounds like you have a team of code monkeys (not meant to be offensive, but just a description) when you want senior software engineers and architects.

We use architects for what you've described. It's a distinct technical track from developers and from team leaders. They're usually senior developers with outstanding experience in multiple technologies. They deal with technical design, specification and documentation. They sit in-between the product owner and the team in the story flow. The PO feeds the team with user stories and priorities, the architect fills in the technical spec, developers choose the implementation and provide the time estimates, QA uses the spec to test.

I'm confused by the problem of finding enough work to keep engineers busy.

For one thing there is always more work. For another engineers should be totally capable of finding it for themselves.

Some industries really like specifications. Others don't bother with them.

Two things: rewards and separation of business concerns.

First, you need to properly motivate your people to take maximum initiative to build things. If there is time to spare there is time to improve internal automation and refactor existing internal software processes. Do it, because that churn is normally hard to financially justify but it’s how you build superior software.

Also, use that time to make massive advancements in documentation. The documentation should be human readable and not specs. Specs are technical documents created for either planning purposes or conformity in the wild.

You need to reward your people for small successes that increase automation, reduce tech debt, and so on. Rewards can be things like recognition programs, points for periodic evaluations, lunch coupons, PTO, awards, and so forth.

Separate out business concerns so that the developers are not churning on product decisions unless the developers are creating new original software tools. When managing open source projects there are many product decisions to be made but most of the energy is actually documentation and maintenance. If necessary bring a product owner into the mix to advise your developers on these internal initiatives.

First, you need to understand and accept fact, this is not engineering question, but economy.

From this economy point of view, you could start your looong journey to project management.

Or you could hire some person, who will done this work for you, but for quality, you must obey what he say.

I will tell you some words to google, but without deep understanding of economy this will be mostly waste of time.

But to show I'm serious, short list (not complete, but most important things):

1. Goldratt Theory of constraints.

2. PERT (project management), and critical path PM.

3. Business models.

Good luck. And sure, you could contact me if interested in more details, or who knows may you decide to hire me.

If you're constantly having this problem, it sounds like you're the problem.

You're gate keeping the end-users so the engineers can't become domain experts, albeit maybe inadvertently.

Good engineers will become domain experts naturally from talking to clients, usually experts far beyond the actual business users. That is, unless someone's interposing themselves between the engineers and the users.

It sounds like you are the person interposing, and you are the reason the engineers are not becoming domain experts.

That or you've always worked with bad engineers.

Not a senior engineer, but my instinct is that you need to train people s.t you are confident delegating at least parts of your current role to them.

What's stopping you from handpicking a (willing) senior and having them shadow you / learn to do parts of the planning?

> If I go more heavyweight, and write large specs with use cases, state diagrams, sequence diagrams, gherkin BDD scenarios, we tend to get much better software.

This is how it should work. I don't see how having a few PMs do this is top down heavy?