5 ms·
Ask HN: How can I keep my Engineers properly fed with quality work?
Hi HN, I’ve been struggling with keeping my Software Engineering teams properly fed with good specs and enough work for them. I could use a little advice on what you all truly think is the right way to build software. This is an issue I’ve had for years and at multiple companies. I typically work in areas with high compliance burden like Healthcare or Fintech.
If I have my product teams use lightweight tools like user stories and scrum/kanban, I get terrible products that haven’t been thought through. We miss subtleties, test scenarios, and getting my Engineers to fill in those details doesn’t seem to work. Maybe eventually you get a few Senior Engineers who learn to do it, but mostly they end up helping everyone else. 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 but my org is really top heavy. I would end up needing more product people than developers, and training people to be able to do all that is really hard.
So in the end, I personally always work 70hour weeks to fill in all the gaps from a product and engineering perspective, just to keep the process moving in the right direction.
I recognize this is my failure in org design, and training, but what does good look like in your opinion?
Thanks in advance.
- extasia 3y agoNot 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?
- softprod 3y agoGood point. I historically have been weak on training, probably because it feels like so much work. I should look into investing more time and money into it. Sounds like maybe lack of training is a primary issue.
- bomewish 3y agoYou should be able to tell from the calibre of your people if they can be “trained” to actually do what you’re asking right? It sounds like a combination of experience, intelligence, and conscientiousness. The first can be changed but the latter two hard to do much about. That may not be resolvable as a “more training” issue.
- aristofun 3y ago> 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.
- softprod 3y agoI see. I’ve also seen there are some 4x+ Engineers who do this naturally but they are also really hard to find, along with being expensive as you’ve said. Which of these 2 paths do you think succesful tech companies rely on?
- aristofun 3y agobig companies don't have real choice, there are not that many 4x+ engineers on the market to cover all products and areas one good example of a product type that can be (and is) made by a small team of high performers is Telegram app I personally believe that inside a big company you still can and should have some top priority projects run by that kind of teams, if your management is smart and flexible enough
- dsattt 3y agoThere are plenty of 4x engineers available, you’re just bad at hiring.
- dr_kiszonka 3y agoI sound like the described engineer type (or so I was told), but without the 4x. I don't know if it helps at all, but I care deeply about my work and need 1) the environment to deliver results at least at the level of quality I expect from myself (in other words, don't make me produce crappy software), 2) technical challenges to help me grow, 3) meaningful projects.
- codingdave 3y agoPersonally, 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.
- softprod 3y agoThanks for the detailed response. It makes sense that you have a kanban board specifically for product. So you feel like devs do a good job with the “how” once you have a good outline of set of actions?
- robofanatic 3y agoIMO product people should not delve too much in “how” especially in large projects. Your role should be to communicate the requirements as clearly as possible to the engineering team and stay away from the “how” part as much as possible. I totally get the temptation of trying to influence the “how” part especially if your past life was in engineering. If engineers are not able to do the “how” then you need different engineers.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- gardenhedge 3y agoDo 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.
- softprod 3y agoMost of my devs are in Europe and I pay slightly above market rates in those areas. Perhaps not enough though.
- JonChesterfield 3y agoI'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.
- thebruce87m 3y agoI interpret it as ”useful work”, progressing toward a successful product, as opposed to rearranging the deck chairs on the Titanic.
- softprod 3y agoRight, that’s how I meant it.
- enormousness 3y agoWe 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.
- gardenhedge 3y agoCould you provide some more detail on what the architect does versus the developer? Is my example below along the right track? e.g. * PO says they want a way for customers to book an appointment on X product * architect identifies where that change should be made, how it integrates with the rest of the system, identifies any non-functional requirements that need to be addressed, identifies any third party dependencies, what docs should be updated, * dev writes and tests the code, supports through the testing, release and post-release phases
- Racing0461 3y ago> 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?
- deleted 3y ago[deleted]
- austin-cheney 3y agoTwo 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.
- 747-8F 3y ago[flagged]
- mattmanser 3y agoIf 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.
- softprod 3y agoI haven't really thought of that as a possibility and I'll accept it may be true. I definitely wouldn't do that on purpose so I will have to take a closer look at how I treat situations like this.
- simne 3y agoFirst, 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.