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.
38 comments
[ 3.7 ms ] story [ 109 ms ] threadWhat's stopping you from handpicking a (willing) senior and having them shadow you / learn to do parts of the planning?
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.
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
The key is to have good company culture and pay above average (in local rates so 3x and more cheaper than USA). This give you great retention. People are loyal and aren't switching jobs every 2 years. Many of us are with the same company for 5+ years.
Which creates a sense of ownership. Give engineers freedom to make decisions [1], give them challenges. Not deadline challenges that lead to burnout. Foster collaboration and reward seniors teaching juniors. Maintain lean processes.
But truth to be told the dream starts to crumble. Our small to mid size company got acquired by a bigger one and the process bullshit and top down decisions start to creep up. I won't probably last long here but I am worried if I can find a company with a mindset we used to have.
[1] Perhaps controversial hot take: discard architects. Teams should own the technical design. If it's a huge project spanning multiple teams, host in-person designathon for a week. You should have staff engineers on board steering it, but involve seniors or even lower ranks. The people designing should be the same people who are going to implement it. Again, sense if ownership, lower communication overhead. If you are worried teams would stray in different ways, have guilds around core tech/architecture areas. Designs can be reviewed cross team. Let people join other teams for quarter or so to cross-pollinate ideas and best practices.
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.
I’ve also found that folding product workflows into the Kanban board gives the team more visibility and ownership over that end of the pipeline. We can observe how those items age before it ever gets to the dev team and swarm to fix things as a team earlier in the process.
Do you maybe ask for an estimate on “what”-tickets?
What I do instead is focus on priority. If the leadership thinks they need a date, I ask why. Often it ties to KPIs they need to hit, or promises they made up the chain, or sometimes even something real like: "We're out of funding in 4 months.". But once I know "why", I can tailor the "what" to focus tightly on that "why", and deliver. If they push for hard dates, then we're back into micromanagement to get the scope to hit the date, and we are wasting time again. So I don't measure effort... at all. I just let the team know what is most important, and we do the work.
The trick is to get leadership to trust that this works. Most of them are used to timelines, scrum cadences, 6 month roadmaps, etc. And if that works for them, great. But it isn't what I recommend for building an effective team who can deliver quickly while enjoying the work.
Edit: I always think of one more thing after I type up a comment... I can succeed in this scenario because I used to be an engineer. I know if something takes an hour vs. a day/week/month and can break things out accordingly. If a product person really does not have that sense, they'll need to ask about effort... but it can be at that high level of hour/week/day/month.
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.
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
This is how it should work. I don't see how having a few PMs do this is top down heavy?
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.
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.
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.