Ask HN: Critique my company

Every time we hire a new developer I give them a few weeks to get up to speed with someone else and then I meet with them and we talk. I always ask "What do you see that we could be doing better? It could be anything, our process, the tools we use, our structure, anything." And I get literally nothing. I just can't believe it. Am I not asking the right question? Or I'm not asking it the right way? I thought maybe people were intimidated by me so I had someone else do it, HR, team leads, but we get the same result. There are even some pretty obvious flaws that we have like a homegrown, google docs based project tracking system and our lack of using third party libraries but the developers never mention it. And I'm sure there are many other issues that I have trouble seeing.

Prior to starting the company I worked at six different companies and outside of the first one, my first real programming job, I would always have lots of ideas in the first few weeks about how things could be improved. Some of my ideas were bad because I just didn't understand what was going on well enough but I like to think that some of them had merit.

Any ideas how we can get feedback from our new developers on how to improve?

The devs in question may have real issues with confidence. Straightforwardly saying up front that their feedback is hands-down not going to get them fired or affect their position or compensation may help a lot here. Explaining how to give feedback, eg by focusing on objective criticism and avoiding personal attacks (and similar common-sense sentiment) may also help.

It may also be useful to think back to when you'd just started at the six companies you mention, and spend some time remembering the mindset you had - in particular the divide that was present between the ideas you had and the difficulty, if any, that you had with actually sharing these ideas. For these new hires this same exact situation is playing out with your employees.

Maybe the company culture could focus more strongly on feedback from the start, instead of abruptly posing the question a few weeks in. It should be integrated into the onboarding, possibly be part of the hiring, etc etc, so that new hires associate "$company == feedback". That may help with the intimidation factor.

Hopefully an approach like this results in a steady stream of feedback from the start.

You're right that ideas developed when adjusting can sometimes have a kind of 20/20 clear vision, but that they can also be bad because they don't fully grasp all the implementation details or culture or whatnot.

It may be a good idea to wait two months+, or until the person in question is consistently producing output, not much surprises them and they seem almost bored, to start looking at some of the less likely-sounding tidbits that come back. I can tell you that if you waited say six weeks before asking me anything I likely would not spit out any useful metrics due to nerves and the newness of everything.

One idea that could be interesting is to start a feedback page somewhere (perhaps a wiki page - or a Docs document everyone can edit would be a start), and add everything you can think of. The hope here is that since there's a bug list, a) there's now an already-started thing so people don't have to overcome that intertia, and b) people will go "wow, this is fairly scathing" and won't feel so bad adding to it. :P

I was also wondering about making feedback anonymous; this could be a good last-resort, but I wouldn't immediately try this: "oh, that was me" is too likely to come out at the most (needlessly) awkward of moments, it promotes a "you can't be honest" mentality (!!!!!!!!), etc. Like I said, very last resort, not recommended.

This topic reminds me of the "customers don't know what they want" problem - asking customers directly what they want in terms of new features or improvements can sometimes simply not produce actionable results, or result in false leads that can take an extremely long time (and in some unfortunate circumstances a lot of money) to discover aren't the core issues. Figuring out how to find the core issues can be tricky. (I unfortunately don't remember where on here that I read about this, but I do remember there not being any simple solutions; if anyone has any links I wouldn't mind remembering!)

1. The formality of the process.

2. A lack of previous informal conversations. The first time the boss shows up in a new hire's office, a good strategy is often to keep one's mouth shut.

3. Only asking new hires. A sophisticated new hire may realize that they do not know the big picture. Other new hires may not want to throw their team 'under the bus'.

4. The homegrown Google docs and in-house libraries are all "somebody's baby". And if they were a priority problem, then the founders would have fixed them. They haven't, so what is the point in mentioning something that obviously will not change.

My random internet advice:

1. Come up with a real plan to fix the problems everyone knows about.

2. Ask everyone how to improve the process, not just new hires.

3. Build a culture of trust.

Good luck.

Did you frame the conversation in advance with the new hire? Tell them - I want you to make a critical assesment of everything we do. We'll meet again in a month's time. I'll be looking for specific, actionable ideas on how we can do things faster/better/smarter. What would it take to grow 10%?

If new ideas your desired outcome-- formalize the process with a Quarterly Brainstorm/Review pulling together thoughts from the entire team. Then select the top 2-3 to work on. The process helps foster a culture of strategic thinking and innovation.