Ask HN: Critique my company
73 comments
Your developers are smart - they don't want to shake the tree. They know that even though you say you want constructive criticism, there's a good chance you'll resent them for giving it to you, so they take the safe road.
Ask the ones who leave, but wait 5 months until they're comfortably settled into new employment. You can bet they'll give it to you straight, but you might not like that either.
Ask the ones who leave, but wait 5 months until they're comfortably settled into new employment. You can bet they'll give it to you straight, but you might not like that either.
Yeah, one of the most important things to learn is that people do not mean what they say. Frequently, they don't realize they don't mean what they say. It takes a lot of work and a good grounding in psychology to start to get some useful introspection on even our own motives, let alone the motives of others.
It's easy to say "Yes, I want harsh criticism!" Indulge this a few times and see what happens. I have been fortunate to meet one or two people who mean it and roll with it. However, most people who say this will end up reacting violently anyway, thinking of some reason why that specific thing you said was out of bounds. Never trust someone to act reasonably based on their promise to do so.
The issue of "leadership blindness", where you get tuned out because everyone you around is so interested in pleasing you and never wants to give you adverse information, is serious and real. It's one of the most important things for a company's leader to circumvent, and sadly, not very many corporate leaders have the humility to do so.
I experienced this even when I was just barely up the ladder. As soon as one starts climbing up (that is, gets any subordinates), the dynamic instantly changes.
To OP: give up on asking directly. It's not going to help. Any information you get in direct reply will be useless or worse. Do not expect to get it straight. Assume that there's a bug in your employees' log function that is causing only INFO level messages to get logged even though you asked for DEBUG. You need to think of other ways to get the data you need to run and evaluate your company objectively, knowing that `log()` is never going to work.
It's easy to say "Yes, I want harsh criticism!" Indulge this a few times and see what happens. I have been fortunate to meet one or two people who mean it and roll with it. However, most people who say this will end up reacting violently anyway, thinking of some reason why that specific thing you said was out of bounds. Never trust someone to act reasonably based on their promise to do so.
The issue of "leadership blindness", where you get tuned out because everyone you around is so interested in pleasing you and never wants to give you adverse information, is serious and real. It's one of the most important things for a company's leader to circumvent, and sadly, not very many corporate leaders have the humility to do so.
I experienced this even when I was just barely up the ladder. As soon as one starts climbing up (that is, gets any subordinates), the dynamic instantly changes.
To OP: give up on asking directly. It's not going to help. Any information you get in direct reply will be useless or worse. Do not expect to get it straight. Assume that there's a bug in your employees' log function that is causing only INFO level messages to get logged even though you asked for DEBUG. You need to think of other ways to get the data you need to run and evaluate your company objectively, knowing that `log()` is never going to work.
That is a bleak answer. Upvoted because despite what the idealist in me says, I believe it to be largely true.
I think the remedy for a company is to slowly change the culture from command and control to directed collaboration. Why do I need a team lead to apportion work if I am a senior developer? Probably I don't. Maybe the team can burn through work and collaborate on decisions.
Then criticism becomes normal and non offensive and can be used constructively to make the team better because you are convincing peers not overlords.
Then criticism becomes normal and non offensive and can be used constructively to make the team better because you are convincing peers not overlords.
You're right that the problem has to be solved through subtle manipulations in the environment. That's why terms like "directed collaboration" have become "corpo-speak".
Many of us have had "open-door" bosses and we've found out that they're actually not unlike "shut-door" bosses or bosses who haven't stated a door-type. The difference is that open-door bosses are professional managers who know that framing the environment in approachable terms makes their job easier (or are at least hypnotically copying the actions of those who know this), even if "open door" doesn't actually mean "open door".
Being "open door" doesn't change the overall situation though, it just makes it easier in the unlikely event that someone will want to come talk to you. Bosses still need to analyze their employees carefully and attempt to coax them into revealing their true feelings.
Consider that even in the most intimate relationships, like marriage, people frequently hide their true feelings for years. If they can live like that in their marriages, they can live like that in their jobs, too. Don't let problems fester.
If you wait until the time that your employees are coming to you under "open door" pretenses, the problem is usually pretty bad; you've waited too long to discover and fix it.
Corpo-speak has become detested precisely because normal people see the hypocrisy and condescension in them, but in the real world, this doesn't seem to matter much. I guess people prefer to hear the version that they don't really believe because it leaves open the possibility that you'll choose to honor it in their case.
Many of us have had "open-door" bosses and we've found out that they're actually not unlike "shut-door" bosses or bosses who haven't stated a door-type. The difference is that open-door bosses are professional managers who know that framing the environment in approachable terms makes their job easier (or are at least hypnotically copying the actions of those who know this), even if "open door" doesn't actually mean "open door".
Being "open door" doesn't change the overall situation though, it just makes it easier in the unlikely event that someone will want to come talk to you. Bosses still need to analyze their employees carefully and attempt to coax them into revealing their true feelings.
Consider that even in the most intimate relationships, like marriage, people frequently hide their true feelings for years. If they can live like that in their marriages, they can live like that in their jobs, too. Don't let problems fester.
If you wait until the time that your employees are coming to you under "open door" pretenses, the problem is usually pretty bad; you've waited too long to discover and fix it.
Corpo-speak has become detested precisely because normal people see the hypocrisy and condescension in them, but in the real world, this doesn't seem to matter much. I guess people prefer to hear the version that they don't really believe because it leaves open the possibility that you'll choose to honor it in their case.
Good idea. I personally had given feedback every time I left a company and the reaction was always either no improvement to slight adversity. So naturally I stopped giving feedback.
Maybe instead of simple feedback it would be worth to just task the developer with improving something that they will see as problematic (kind of 20% time but for improvement).
Maybe instead of simple feedback it would be worth to just task the developer with improving something that they will see as problematic (kind of 20% time but for improvement).
Rules #1: Never talk when you leave. Just leave.
Whatever you say, it can only make it worse.
Whatever you say, it can only make it worse.
I disagree.
Now, let me start by saying I don't intend for this to be a suggestion for everyone in every situation, I just want to suggest that sometimes it can make things better.
I left my job three months ago, but I had actually tried to quit about 6 months earlier, instead I ended up switching positions. None of the problems I was having really ended up getting resolved after the my first attempt to quit, which is why I ended up actually leaving after giving it 6 months. But from what I've heard from friends still there, since I left they've actually been trying to fix things.
For the last month or so, my boss knew I was again debating leaving and we ended up having at least one conversation a week about things that were wrong. For me personally, it was great, I didn't have that stupid voice in the back of my head telling me to downplay everything. I think he appreciated how candid I was too.
Now don't get me wrong, I'm not saying everyone should always do this. I worked for a company with ~150 people and I was the 12th hire, with my boss coming in shortly after me. However, saying you should never do it isn't true either.
Now, let me start by saying I don't intend for this to be a suggestion for everyone in every situation, I just want to suggest that sometimes it can make things better.
I left my job three months ago, but I had actually tried to quit about 6 months earlier, instead I ended up switching positions. None of the problems I was having really ended up getting resolved after the my first attempt to quit, which is why I ended up actually leaving after giving it 6 months. But from what I've heard from friends still there, since I left they've actually been trying to fix things.
For the last month or so, my boss knew I was again debating leaving and we ended up having at least one conversation a week about things that were wrong. For me personally, it was great, I didn't have that stupid voice in the back of my head telling me to downplay everything. I think he appreciated how candid I was too.
Now don't get me wrong, I'm not saying everyone should always do this. I worked for a company with ~150 people and I was the 12th hire, with my boss coming in shortly after me. However, saying you should never do it isn't true either.
I tried to quit my job a few weeks ago. My boss suggested I could stay and work on something completely different, part of what I do in my free time, but getting paid for it.
Much happier now, it's worked out well for both of us.
Much happier now, it's worked out well for both of us.
Well, you're leaving, so everything you say will be viewed in that light. People should be objective about feedback, but they aren't. The way they see it, you're telling them they suck on your way out the door, and they probably want to answer "fuck you too".
Well I never left because someone "sucked" (didn't have X, Y, Z or didn't do A, B or C) and the feedback was generally actionable sometimes even with references to literature and research.
But if people have problem with feedback why are they asking for it?
But if people have problem with feedback why are they asking for it?
It's company policy and it gives them an opportunity to think of a positive spin for things before someone else hears about the complaints first, say though glassdoor or some other means.
I agree and moreover why risk losing a reference? When older references may be non contactable that's a risk that many including me wouldn't take.
Instead of asking new hires, he should be asking the people who are leaving. They have nothing to lose.
How much time are you giving them to prepare an answer?
If a senior member of the company scheduled a meeting and then asked me on the spot what I would improve about the company I wouldn't be able to give any good ideas.
If instead they sent me a note saying that in three days they would like to meet with me for twenty minutes, and that during this time they would like to hear my thoughts so far about working for the company and to please think about ways in which you think the company can improve. I would be able to provide many ideas in this scenario.
If a senior member of the company scheduled a meeting and then asked me on the spot what I would improve about the company I wouldn't be able to give any good ideas.
If instead they sent me a note saying that in three days they would like to meet with me for twenty minutes, and that during this time they would like to hear my thoughts so far about working for the company and to please think about ways in which you think the company can improve. I would be able to provide many ideas in this scenario.
This would definitely help. We all have yearly "performance reviews" with our next highest-up in command. 2 weeks beforehand they email a questionnaire (roughly 12 questions) which we are expected to at least read over, though it's preferred that we fill it out and bring it with us to the meeting so we can have a proper constructive discussion. AFAIK many things that are mentioned by multiple people are implemented in some form or other, or if not, management tells us their justification against implementation. The meeting is confidential and they remind us that any feedback that is passed on will be anonymous (though I'm guessing after mentioning 10 years in a row that we need a ping pong table, they probably know who it is).
Agreed. Almost any meeting is more productive if an agenda goes out ahead of time giving participants a chance to prepare in advance of sitting down.
Exactly! In the past I asked high level/generic questions and often got very little out of it. Shallow responses or no responses at all in some cases.
Nowadays I send the email I will paste below to every new hire after a couple of months in the team..
Some people never bother to schedule the conversation (less than 20%) and I leave it at that. For the other folks - the big majority - I had great conversations/results from this effort. Learned a ton of surprising things, found hidden talents within the team, found and then went to fix serious problems.
The email:
Subject: Talk.
Oi <Joe>, how are you doing?
I would like to establish a communication channel between us, and as a first step towards this have a conversation - can you please schedule a 30 minutes conversation with me using https://<my-own-url>.youcanbook.me/ ? Feel free to pick any available slot there - if it is open it means I will be available and working at this time. We can talk using <videoconferencingservice> (if we happen to be at the same building we can have the conversation personally).
Before the conversation I would like to ask you to please think carefully about the following questions, and be prepared to discuss what you understand as most important:
- How can I help you?
- Is there anything you would like to tell me?
- Is there anything you would like to ask me?
- What is your profile? What are your strenghts that you like to mention? What do you like doing the most? What motivates you?
- If you were in my place, is there anything you would change? What?
- Who are the 2 people you most admire within the company? Why?
- What information you assume I don't have that you can give me and will allow me to do my work better?
- Where do you inconsistencies between what we preach and what is in our culture document at <URL> and between day-to-day practice?
- Is there anything you would change in our culture document? Is there anything missing that you judge it is important?
- What are you current attributions? Do you judge you day-to-day challenging enough and do you see the company helping you grow or do you feel you need more space?
- Is there any self-managed project ( <URL-TO-EXPLANATION> ) that you would like to establish?
- What do you understand as key to grow in our company?
- Do you receive enough feedback to grow and improve performance?
- Do you consider your leadership micromanages you, stays pretty far, or typically can find right balance in each situation?
- Do you feel your leadership cares about you?
- In your view does your leadership communicate very clearly what are the objectives to be achieved? Does it support the team in staying focused on what is most important?
- How do you evaluate the quality of the company information you receive? Do you feel you regularly receive relevant information from senior leadership to understand where we are going? How do you evaluate your own participation in setting the company direction?
- Do you feel your leaders have the necessary technical skills to manage your work effectively?
- Would you recommend your leader to other people in the company?
- What feedbacks you have to give me? What concerns you the most in my work? What makes you happy and you want to make sure I continue doing?
Regards,
Nowadays I send the email I will paste below to every new hire after a couple of months in the team..
Some people never bother to schedule the conversation (less than 20%) and I leave it at that. For the other folks - the big majority - I had great conversations/results from this effort. Learned a ton of surprising things, found hidden talents within the team, found and then went to fix serious problems.
The email:
Subject: Talk.
Oi <Joe>, how are you doing?
I would like to establish a communication channel between us, and as a first step towards this have a conversation - can you please schedule a 30 minutes conversation with me using https://<my-own-url>.youcanbook.me/ ? Feel free to pick any available slot there - if it is open it means I will be available and working at this time. We can talk using <videoconferencingservice> (if we happen to be at the same building we can have the conversation personally).
Before the conversation I would like to ask you to please think carefully about the following questions, and be prepared to discuss what you understand as most important:
- How can I help you?
- Is there anything you would like to tell me?
- Is there anything you would like to ask me?
- What is your profile? What are your strenghts that you like to mention? What do you like doing the most? What motivates you?
- If you were in my place, is there anything you would change? What?
- Who are the 2 people you most admire within the company? Why?
- What information you assume I don't have that you can give me and will allow me to do my work better?
- Where do you inconsistencies between what we preach and what is in our culture document at <URL> and between day-to-day practice?
- Is there anything you would change in our culture document? Is there anything missing that you judge it is important?
- What are you current attributions? Do you judge you day-to-day challenging enough and do you see the company helping you grow or do you feel you need more space?
- Is there any self-managed project ( <URL-TO-EXPLANATION> ) that you would like to establish?
- What do you understand as key to grow in our company?
- Do you receive enough feedback to grow and improve performance?
- Do you consider your leadership micromanages you, stays pretty far, or typically can find right balance in each situation?
- Do you feel your leadership cares about you?
- In your view does your leadership communicate very clearly what are the objectives to be achieved? Does it support the team in staying focused on what is most important?
- How do you evaluate the quality of the company information you receive? Do you feel you regularly receive relevant information from senior leadership to understand where we are going? How do you evaluate your own participation in setting the company direction?
- Do you feel your leaders have the necessary technical skills to manage your work effectively?
- Would you recommend your leader to other people in the company?
- What feedbacks you have to give me? What concerns you the most in my work? What makes you happy and you want to make sure I continue doing?
Regards,
My suspicion is that the silence reflects the company culture (and perhaps the larger culture depending on where the company operates). Some elements that may be in play (but I am imagining based on very little information):
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.
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.
A previous CEO used to hold breakfasts once a month. It was really informal with a mix of people and a wide variety of work related topics got discussed. We could ask him things and he could ask us things. The setting made it really good for breaking down that communication barrier between juniors and The Boss.
How about giving your new hires a few mostly blank pages with a letterhead of "My first two weeks WTF moments...". On day one give it to them and let them know you will take them out to dinner in two weeks to talk about what they write down. Let them know it is really valuable to you to have fresh sets of eyes on company processes and that there will be no negative repercussions. I'd then give them a few examples of what you would like to know.
Given all that I still think you won't get much feedback until you've done this a while and the current employees let the new hires know that there are no issues with them telling you that things are wrong.
Given all that I still think you won't get much feedback until you've done this a while and the current employees let the new hires know that there are no issues with them telling you that things are wrong.
I am not the founder of my company, but I ask the same thing of new hires (it's probably easier to give ideas to the non-founder). One thing that has worked well for me has been to say "One of my favorite things to hear from a new hire is what we could be doing better. You have the perspective of someone who has been elsewhere and have fresh eyes, and don't just accept things that aren't working. One example of something that isn't working is X. Another is Y. Besides those, can you think of other ways we can make the company better?"
That way you start by being self-critical, which makes people feel more open to complaining.
Btw, remember if you ask this... you have to follow through to _fix_ some of these problems or you can lose trust. Only ask if you really do want to hear feedback and action on some of them.
That way you start by being self-critical, which makes people feel more open to complaining.
Btw, remember if you ask this... you have to follow through to _fix_ some of these problems or you can lose trust. Only ask if you really do want to hear feedback and action on some of them.
Feedback needs to be anonymous or it will always be worthless. Few people have the courage to point out even blatant truths to their employer. Just set up an email that anyone can submit to anonymously.
I think this significantly undervalues the importance of developing a culture where things can be talked about in a frank and open manner. It may be rare, but is extraordinarily valuable, and if people are never given the chance to have uncomfortable conversations, then there's no possibility of it developing.
When anonymous feedback comes in and its taken and acted on positively the team may be more likely offer up non-anonymous suggestions, a foot in the door if you will. I may be totally off base though I don't have that type of real world experience.
This is basically how I feel about it. If my employer acted positively on some anonymous feedback at a first, I feel like I'd be a lot more likely to feel open and willing to engage knowing there's good faith. Unfortunately this doesn't scale to larger companies, though. What the OP is describing is the classic problem of management.
Another commenter pointed out that company culture is most likely the underlying issue with people not being honest during their post-hire interviews. If that's the case, then the culture is already damaged.
Maybe they could begin to repair the culture with the suggestion box, by asking why everyone is so hesitant to critique during face-to-face interviews. That alone should show that they're making an effort, and acting on any of the suggestions will further the cause. Basically, use the anonymous suggestion box to get rid of the anonymous suggestion box.
Maybe they could begin to repair the culture with the suggestion box, by asking why everyone is so hesitant to critique during face-to-face interviews. That alone should show that they're making an effort, and acting on any of the suggestions will further the cause. Basically, use the anonymous suggestion box to get rid of the anonymous suggestion box.
It's not cultural; it's human. You can't undo it. People who believe their culture is the exception that causes employees to be honest with their superiors are naive.
What generally happens with strong technical employees is this. While they're idealistic and new, they will be relatively honest and direct (simultaneously trying to be polite) for the first couple of years. After a while, they will try to figure out why they've been forced out from their company every 6 months.
It will click that maybe the boss didn't really mean it when he asked for an inventory of problems and concerns. Maybe all those people who smiled and nodded while a technical "debate" was going on were secretly developing resentment. Maybe people disliked them because their behaviors were interpreted as snobby, arrogant, insensitive, condescending, or detached, despite the politeness with which they delivered their opinions.
Then, they will either a) nope out of the career track entirely and become a consultant/freelancer/entrepreneur; b) lie to themselves and believe they can find the magical land where this doesn't happen, which only sets up for a harder fall down the line when you realize no such magical place exists, because people are people everywhere; or c) embrace the realities of human collaboration and try to raise a successful career from the ashes.
I've done both A and B. A usually loops back around to a full-time gig at some point. Some people will remain unaware and try to believe in B for the duration of their career. When you exit denial from B, you have to embrace C (even if you loop back to A, C is informative for your ongoing ventures).
What generally happens with strong technical employees is this. While they're idealistic and new, they will be relatively honest and direct (simultaneously trying to be polite) for the first couple of years. After a while, they will try to figure out why they've been forced out from their company every 6 months.
It will click that maybe the boss didn't really mean it when he asked for an inventory of problems and concerns. Maybe all those people who smiled and nodded while a technical "debate" was going on were secretly developing resentment. Maybe people disliked them because their behaviors were interpreted as snobby, arrogant, insensitive, condescending, or detached, despite the politeness with which they delivered their opinions.
Then, they will either a) nope out of the career track entirely and become a consultant/freelancer/entrepreneur; b) lie to themselves and believe they can find the magical land where this doesn't happen, which only sets up for a harder fall down the line when you realize no such magical place exists, because people are people everywhere; or c) embrace the realities of human collaboration and try to raise a successful career from the ashes.
I've done both A and B. A usually loops back around to a full-time gig at some point. Some people will remain unaware and try to believe in B for the duration of their career. When you exit denial from B, you have to embrace C (even if you loop back to A, C is informative for your ongoing ventures).
Yeah a large company I worked for used to have one of those apparently. They said they got rid of it because they got too many suggestions.
Anonymity is a double-edged sword, as anyone who's used the internet should know.
It's great that you set time aside to have a 1-to-1 with new hires but I personally think a few weeks is too soon to be asking new hires that particular question. Not to mention it also depends on personaility types; you may have an employee who is fairly comfortable answering that sort of question with complete honesty. But more often that not, you will find that they probably haven't had chance to get up-to-speed with their work environment or gain a thorough understanding of how the dev team operates.
You would probably get more benefit by asking questions that are more related to company culture, such as, how they're settling into the team, how they find the team morale/company culture, who in the team has provided them the most value so far. Those type of questions would hopefully help the new hire understand that you care about the culture at the company and also helps build a more personal relationship, which consequently will build trust between you and your employees to allow them to truthfully answer your initial question a few months later when they are more embedded into the team.
Definitely keep up the regular engagements with new hires though, despite not necessarily receiving the answers you're looking for.
You would probably get more benefit by asking questions that are more related to company culture, such as, how they're settling into the team, how they find the team morale/company culture, who in the team has provided them the most value so far. Those type of questions would hopefully help the new hire understand that you care about the culture at the company and also helps build a more personal relationship, which consequently will build trust between you and your employees to allow them to truthfully answer your initial question a few months later when they are more embedded into the team.
Definitely keep up the regular engagements with new hires though, despite not necessarily receiving the answers you're looking for.
I've worked at a few places where the products were mature and sophisticated enough that it too me six months to get a handle on them and start to become truly productive on implementing improvements. Before that time I felt like a deer in the headlights.
Sounds like what is happening here.
Sounds like what is happening here.
took me
I could see that if you were hiring inexperienced developers but it seems pretty strange otherwise.
[1] Are you hiring from a pool of developers who used processes/tools that are the same or inferior to what your company is using? In other words, your company is already excelling compared to their previous experiences.
[2] Could you be hiring from a pool of developers who have been previously conditioned or selected to "keep their heads down"? From the outside looking in, the finance world seems pretty rough and tumble. The geek/nerd response to being with a bunch of jocks is be to stay quite. [I'm a geek/nerd in case that can be taken the wrong way.]
[3] Lastly, honest feedback requires either anonymity or trust. Trust is tough. A single case of a guy getting marched out by security when he told his manager "I'm not happy with my salary." trumps all the other times a manager tells someone, "If you're not happy, come see me." Heck, seeing someone marched out by security for any reason destroys pretty much any trust in management. If your new hire worked a place like that before, it's understandable that he might be reticent to trust his new company.
[1] Are you hiring from a pool of developers who used processes/tools that are the same or inferior to what your company is using? In other words, your company is already excelling compared to their previous experiences.
[2] Could you be hiring from a pool of developers who have been previously conditioned or selected to "keep their heads down"? From the outside looking in, the finance world seems pretty rough and tumble. The geek/nerd response to being with a bunch of jocks is be to stay quite. [I'm a geek/nerd in case that can be taken the wrong way.]
[3] Lastly, honest feedback requires either anonymity or trust. Trust is tough. A single case of a guy getting marched out by security when he told his manager "I'm not happy with my salary." trumps all the other times a manager tells someone, "If you're not happy, come see me." Heck, seeing someone marched out by security for any reason destroys pretty much any trust in management. If your new hire worked a place like that before, it's understandable that he might be reticent to trust his new company.
There are different skill trees developers can have:
1. Implementation skills: can implement a solution, e.g. knows C++.
2. Problem solving: given a problem, can come up with a solution. "We need an API for X" -> can come up with a design for the API.
3. Identifying problems: can notice problems exist.
4. Teamwork.
(Probably other skill trees as well.)
Assuming confidence, trust and culture aren't an issue, it may just be the developers you're hiring lack the relevant skills to identify problems.
These skills are rarely if ever taught explicitly, so many programmers get by with just implementation skills, or just implementation and problem solving skills. As you realize, though, problem solving and even more so identifying problems are key to productivity (https://codewithoutrules.com/2016/08/25/the-01x-programmer/).
Maybe you should consider teaching these skills, or change hiring process to screen for them, or both.
1. Implementation skills: can implement a solution, e.g. knows C++.
2. Problem solving: given a problem, can come up with a solution. "We need an API for X" -> can come up with a design for the API.
3. Identifying problems: can notice problems exist.
4. Teamwork.
(Probably other skill trees as well.)
Assuming confidence, trust and culture aren't an issue, it may just be the developers you're hiring lack the relevant skills to identify problems.
These skills are rarely if ever taught explicitly, so many programmers get by with just implementation skills, or just implementation and problem solving skills. As you realize, though, problem solving and even more so identifying problems are key to productivity (https://codewithoutrules.com/2016/08/25/the-01x-programmer/).
Maybe you should consider teaching these skills, or change hiring process to screen for them, or both.
Since you are one of the founders, you are a 900 pound gorilla. You asking them to their face is you putting them on the spot. This is not likely to go good places.
I submitted ideas at BigCo to their Bright Ideas program and basically got rejection letters and felt crapped on. Expecting me to not only see that something could be improved, but also provide a fully formed solution that would pass muster politically was probably just an exercise in how to make new people feel like they don't belong at all.
Let me suggest you come up with something like a suggestion box or constructive feedback box where you can at least hear "I see a problem with X and my (possibly off the cuff solution would be Y" so you are getting some kind of feedback.
Good communication is incredibly hard, much harder than most people seem to appreciate. Actual good communication tends to be a long, drawn out process. You need to foster the first step here of "I just want to hear what you think is going badly" and that requires trust, assurances that it won't bite them in the butt and willingness to really listen and take it seriously. All of that is extremely, incredibly hard to do. If you, as one of the founders, cringes or winces because someone said something not nice about your baby, you can expect that no one will want to say anything again. You will need to really work at making people feel not only okay but actively good about pointing out problem areas.
This runs against the grain for the vast majority of social experience that the vast majority of people have. "Don't rock the boat" is pretty deeply ingrained in most people. "Don't question authority" is another biggie. It is incredibly hard to convince people you really and truly want to hear how you can improve things.
So, start with finding some method other than one of the founders getting all up in their face to try to give them a safe and welcome path for tossing out ideas. Because this is not it.
I submitted ideas at BigCo to their Bright Ideas program and basically got rejection letters and felt crapped on. Expecting me to not only see that something could be improved, but also provide a fully formed solution that would pass muster politically was probably just an exercise in how to make new people feel like they don't belong at all.
Let me suggest you come up with something like a suggestion box or constructive feedback box where you can at least hear "I see a problem with X and my (possibly off the cuff solution would be Y" so you are getting some kind of feedback.
Good communication is incredibly hard, much harder than most people seem to appreciate. Actual good communication tends to be a long, drawn out process. You need to foster the first step here of "I just want to hear what you think is going badly" and that requires trust, assurances that it won't bite them in the butt and willingness to really listen and take it seriously. All of that is extremely, incredibly hard to do. If you, as one of the founders, cringes or winces because someone said something not nice about your baby, you can expect that no one will want to say anything again. You will need to really work at making people feel not only okay but actively good about pointing out problem areas.
This runs against the grain for the vast majority of social experience that the vast majority of people have. "Don't rock the boat" is pretty deeply ingrained in most people. "Don't question authority" is another biggie. It is incredibly hard to convince people you really and truly want to hear how you can improve things.
So, start with finding some method other than one of the founders getting all up in their face to try to give them a safe and welcome path for tossing out ideas. Because this is not it.
It seems like one or both things is not true. Your developers think that the tools work well enough and the system is stable enough that they don't think there is a need for arbitrary changes, meaning only you think there are issues.
Or, they don't really feel comfortable giving feedback about how to make it better. Maybe they already make such a good salary that they are afraid to risk it. In this case they are disincentivized from actually giving you the feedback.
Have you tried doing a hackathon week? No normal work except system operations but have everyone work on a new feature or streamlining of an existing process. Have you tried offering bonus for people who offer up new ideas and plans to improve the software and processes?
Or, they don't really feel comfortable giving feedback about how to make it better. Maybe they already make such a good salary that they are afraid to risk it. In this case they are disincentivized from actually giving you the feedback.
Have you tried doing a hackathon week? No normal work except system operations but have everyone work on a new feature or streamlining of an existing process. Have you tried offering bonus for people who offer up new ideas and plans to improve the software and processes?
i suspect you're hiring the "wrong" type of developers. since you took the leap and founded a company, i'm assuming that you're fairly aggressive and at least at one point were willing to think outside the box. the developers you're hiring may be technically strong, but they likely don't have that same mentality. my gut is that "c++ work on windows and linux ... financial" is going to filter for this pretty strongly
this may be exactly what you need for development, but it'd probably be healthy to bring in some more precocious elements ... maybe as interns so you're not committed to a culture shift
this may be exactly what you need for development, but it'd probably be healthy to bring in some more precocious elements ... maybe as interns so you're not committed to a culture shift
I think if you had a way for all new hires to submit questions they have while learning the system, this would be a better way to go.
Let them know you are building a manual to help other new hires. Maybe even let Senior people add questions or answer it. This would be sort of like an internal StackOverFlow for just your company, but organize it as a manual.
So instead of them trying to identify what you should be doing better, they just inherently point out where they are getting tripped up in your process.
The only other similar thing that comes to mind is how Tim Ferris wrote about this method of maintaining a FAQ to automate the customer service process in the 4 Hour Work Week.
Let them know you are building a manual to help other new hires. Maybe even let Senior people add questions or answer it. This would be sort of like an internal StackOverFlow for just your company, but organize it as a manual.
So instead of them trying to identify what you should be doing better, they just inherently point out where they are getting tripped up in your process.
The only other similar thing that comes to mind is how Tim Ferris wrote about this method of maintaining a FAQ to automate the customer service process in the 4 Hour Work Week.
Put yourself in their shoes. You're the founder of this company, it's your baby that I'm sure you're very passionate about and proud of, and you just sat down a relatively new employee and asked them to critique your company.
There's an enormous amount of perceived risk on their end as they have nothing really to gain, and everything to lose.
And I say perceived because it sounds like you're a good guy and are genuinely seeking honest feedback, but they don't know that, to them this whole thing might be a shit test and if they say the wrong thing they could get on your, the founders, bad side.
There's an enormous amount of perceived risk on their end as they have nothing really to gain, and everything to lose.
And I say perceived because it sounds like you're a good guy and are genuinely seeking honest feedback, but they don't know that, to them this whole thing might be a shit test and if they say the wrong thing they could get on your, the founders, bad side.
I have always felt like I would appreciate candor in people talking to me about my business. But every time I have offered constructive criticism it has not benefited me. So I stopped doing it.
Not sure what the solution is, but I feel like building a culture around "best ideas win" and rewarding the process of coming up with improvements and implementing them could be good. You could seed this at first with improvements you were already trying, but when people see "Hey, Joe Schmoe came up with this great idea and now we do it" would be a boon to your improvement culture.
Not sure what the solution is, but I feel like building a culture around "best ideas win" and rewarding the process of coming up with improvements and implementing them could be good. You could seed this at first with improvements you were already trying, but when people see "Hey, Joe Schmoe came up with this great idea and now we do it" would be a boon to your improvement culture.
Fix one of your known issues. Announce you're fixing one of your known issues because you're hoping to improve the company. Make sure that it actually improves stuff, not just checking a box (ie. don't use a ticket tracking solution that's actually worse than your google docs).
I think employees at that point would be more willing to offer up requests for improvement.
Maybe do your issue tracking first, and set aside some thing (story points if your agile, time per week/month, etc), visibly there for process/structure/tool improvement in the issue tracking.
I think employees at that point would be more willing to offer up requests for improvement.
Maybe do your issue tracking first, and set aside some thing (story points if your agile, time per week/month, etc), visibly there for process/structure/tool improvement in the issue tracking.
Be glad you hired savvy employees. Anyone who comes into a new company and starts enumerating everything they are doing wrong is a fool who will have poor career longevity. That's how we end up with shitty tech blogs from people who keep insisting they have the answers if just somebody will listen (cough Michael O'Church cough).
You need to put something concrete behind your words. One off-the-top-of-my-head suggestion: Have a few current engineers start working on some of your known problems as part of their responsibilities. It doesn't have to be 100% their job, just a "kaizen" approach is ok (improve some small part each time they use it). Let them know it will be part of their evaluations.
Now when you ask new employees point to these examples: "John noticed our tracking system was crummy and important issues were slipping through the cracks, so we offered to let him be in charge of re-vamping it."
Obviously you'll have to manage what you allow them to improve, and who gets to work on it. This idea isn't perfect, of course, but the idea is to show them you are serious about these suggestions.
X% of management is aligning incentives (X is some large number). Think about how to incentivize them to give the information you want, and how to remove disincentives. Money and responsibility / autonomy are the most basic incentives.
You need to put something concrete behind your words. One off-the-top-of-my-head suggestion: Have a few current engineers start working on some of your known problems as part of their responsibilities. It doesn't have to be 100% their job, just a "kaizen" approach is ok (improve some small part each time they use it). Let them know it will be part of their evaluations.
Now when you ask new employees point to these examples: "John noticed our tracking system was crummy and important issues were slipping through the cracks, so we offered to let him be in charge of re-vamping it."
Obviously you'll have to manage what you allow them to improve, and who gets to work on it. This idea isn't perfect, of course, but the idea is to show them you are serious about these suggestions.
X% of management is aligning incentives (X is some large number). Think about how to incentivize them to give the information you want, and how to remove disincentives. Money and responsibility / autonomy are the most basic incentives.
Great post. The snide remark toward michaelochurch might be the cause of your downvotes, but I upvoted you for the rest of it, because it is smart and right.
>X% of management is aligning incentives (X is some large number). Think about how to incentivize them to give the information you want, and how to remove disincentives. Money and responsibility / autonomy are the most basic incentives.
All of management is systemic. You can rarely change behavior by sitting down and tackling the problem head-on; people have an internal defense mechanism that interprets this as an attack and shuts everything down.
Any change one wants to make without triggering hostility/resentment has to occur as a side effect of gently and gradually manipulating the structure that the employee finds himself in, including the incentives and the environment.
Your example, which normalizes working on an internal processes and will make the employee feel like the odd one out if he doesn't have a suggestion for fixing the insides, is a pretty good one.
>X% of management is aligning incentives (X is some large number). Think about how to incentivize them to give the information you want, and how to remove disincentives. Money and responsibility / autonomy are the most basic incentives.
All of management is systemic. You can rarely change behavior by sitting down and tackling the problem head-on; people have an internal defense mechanism that interprets this as an attack and shuts everything down.
Any change one wants to make without triggering hostility/resentment has to occur as a side effect of gently and gradually manipulating the structure that the employee finds himself in, including the incentives and the environment.
Your example, which normalizes working on an internal processes and will make the employee feel like the odd one out if he doesn't have a suggestion for fixing the insides, is a pretty good one.
There's little point in complaining about stuff if it's never going to get fixed. That just labels one a complainer. Try rephrasing the question like this: if you could take 1-3 months away from your regular job to fix something in our infrastructure or codebase, what would it be? Then you can follow up by actually letting people do this. And there is no reason to limit this to new hires. Plenty of frustrations come up over time.
How senior are your hires in terms of experience? And, if your hires range from new grads to developers with 10+ years of experience, do you notice any difference between the two cohorts in terms of how much feedback they'll give?
I'm a sample of one, but when I was 25, I would have tons of feedback after my first couple of weeks in a company. Much of it was bad as I hadn't been there long enough to know why things were as they were.
Now that I'm 40, it takes more time before I have any meaningful feedback. I'm more comfortable with what I don't know, so consequently, I'm more comfortable reserving judgement until I know a little more of why things are.
That said, I have a couple of ideas:
1.) Schedule the 'feedback' session more than a few weeks into their job.
2.) Give your new hires some time to prepare. I think it's best to assume that individual contributors feel uncomfortable with spontaneous, candid conversations until they prove otherwise.
3.) Have you considered trying an anonymous feedback system and comparing the results?
I'm a sample of one, but when I was 25, I would have tons of feedback after my first couple of weeks in a company. Much of it was bad as I hadn't been there long enough to know why things were as they were.
Now that I'm 40, it takes more time before I have any meaningful feedback. I'm more comfortable with what I don't know, so consequently, I'm more comfortable reserving judgement until I know a little more of why things are.
That said, I have a couple of ideas:
1.) Schedule the 'feedback' session more than a few weeks into their job.
2.) Give your new hires some time to prepare. I think it's best to assume that individual contributors feel uncomfortable with spontaneous, candid conversations until they prove otherwise.
3.) Have you considered trying an anonymous feedback system and comparing the results?
Just giving them a few weeks at the company before asking seems like a problem. After only a few weeks, they probably don't have enough experience to answer with anything other than their own biases.
For example: you call out your Google Docs tracking system as something that should be obvious. But that's probably not obvious after only a few weeks. Some companies (especially smaller companies) can get by totally fine with that, and if you've only been at a company for a few weeks, you don't know what kind of company you're at. If they tell you that your Google Docs tracking system is bad, they're probably just reacting to it being different than what they had before.
Anyone who responds with a long list of grievances after only a few weeks is probably the type of engineer that you _don't_ want on your team: it probably means that they're unwilling to evaluate problems and solutions within the current context.
For example: you call out your Google Docs tracking system as something that should be obvious. But that's probably not obvious after only a few weeks. Some companies (especially smaller companies) can get by totally fine with that, and if you've only been at a company for a few weeks, you don't know what kind of company you're at. If they tell you that your Google Docs tracking system is bad, they're probably just reacting to it being different than what they had before.
Anyone who responds with a long list of grievances after only a few weeks is probably the type of engineer that you _don't_ want on your team: it probably means that they're unwilling to evaluate problems and solutions within the current context.
You're asking the right question, but I suppose not in a right way. From my experience you need to show them that it's the company culture to challenge things in a smart and constructive way. To do that, you do nothing very formal, just sit your best guys with the newcomer, explaining how things works and why. And sometimes, criticizing the current stuff, but not in a authoritarian way - something like we know we can do better, just nothing really worked well or we didn't have time but now we do.
That way it feels much more like -> we have something we could do better, and the guys are trying to improve that, let's do that with them. While 'critique' immediately feels negative and kind of creates a barrier.
That way it feels much more like -> we have something we could do better, and the guys are trying to improve that, let's do that with them. While 'critique' immediately feels negative and kind of creates a barrier.
Its great to hear you asking about such things because normally no one asks and its a huge waste of experience.
I'd say a few weeks in a short time to get up to speed. The biggest problem is that lots of places are "different" and not just "better". Often I'd like to do things the way I did at my previous job but that could just be unnecessary - taking time to change and breaking everyone elses process.
I would ask more specific questions. Like if you want to improve CD - ask the guy what tool they used in their previous job and how well did it work.
Someone else mentioned monthly informal chats I'd agree. Over a beer after work you can talk about old companies and what your employees miss about them.
I'd say a few weeks in a short time to get up to speed. The biggest problem is that lots of places are "different" and not just "better". Often I'd like to do things the way I did at my previous job but that could just be unnecessary - taking time to change and breaking everyone elses process.
I would ask more specific questions. Like if you want to improve CD - ask the guy what tool they used in their previous job and how well did it work.
Someone else mentioned monthly informal chats I'd agree. Over a beer after work you can talk about old companies and what your employees miss about them.
I agree with those suggesting you might want to look at your company culture. If, when you look around, you don't see a multitude of people working on improving every facet of your process, then you may have built a "heads down, don't rock the boat, worry about now screwing up my own job" kind of company. This mindset will pervade the management chain. And it will be a huge impediment to growth.
If in fact that's what you've got, you need a massive change. Promote based on demonstrated positive impact to the entire company. Encourage risk takers, discourage blame. The people you want working for you would never work at the kind of company I describe above.
If in fact that's what you've got, you need a massive change. Promote based on demonstrated positive impact to the entire company. Encourage risk takers, discourage blame. The people you want working for you would never work at the kind of company I describe above.
Make sure to really spend a lot of time explaining your setup. It's really easy for interviewees to nod and say sure even if you're going too fast for them.
Remember it's stuff you've seen everyday for 14 years, and these people have seen it for maybe 20 minutes. I'd suggest giving them some flow charts / high-level info either in advance or with 20 minutes of quiet time on-site.
The only people I'd expect to respond in the current setting would:
Remember it's stuff you've seen everyday for 14 years, and these people have seen it for maybe 20 minutes. I'd suggest giving them some flow charts / high-level info either in advance or with 20 minutes of quiet time on-site.
The only people I'd expect to respond in the current setting would:
1) Have really high natural intelligence to pick everything up super fast,
2) Be really confident in their skills in the relevant disciplines, and
3) Be really confident you'd take feedback constructively> Or I'm not asking it the right way?
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.
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.
I remember hearing about a CEO that was unable to get any feedback from the board of directors until the phrasing of the question asked shifted from criticism/feedback to advice.
People are worried of giving criticism because you're effectively asking them to rate/evaluate your performance. However, when you ask for advice you're either asking what the other person would do in your shoes or you give them an opportunity to boast about their knowledge. While the end goal is the same, at a psychological level, the perceived reason for the question is different.
People are worried of giving criticism because you're effectively asking them to rate/evaluate your performance. However, when you ask for advice you're either asking what the other person would do in your shoes or you give them an opportunity to boast about their knowledge. While the end goal is the same, at a psychological level, the perceived reason for the question is different.
> 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.
Did you go to one of the company founders with problems and solutions?
I would be very wary of such an ask unless I had a pre-existing relationship with the person asking the question. You also may have folks telling your new guys to STFU.
Did you go to one of the company founders with problems and solutions?
I would be very wary of such an ask unless I had a pre-existing relationship with the person asking the question. You also may have folks telling your new guys to STFU.
I think for many people, especially junior to mid-level hires, a few weeks is not enough time to achieve the familiarity, credibility, and just general sense of belonging to feel comfortable sharing genuine critiques. I would expect only senior-level developers with a lot of experience and confidence, would feel secure in their responses at that stage (and even then, it depends on how receptive your culture feels). If you want genuine feedback at this early stage, have you thought about enabling it anonymously?
Work on making people feel safe with the situation before asking for direct feedback.
A few examples of how this could be done:
A few examples of how this could be done:
Give them more than a few weeks to get comfortable with you and the company culture.
Give concrete examples of things that have improved due to employee feedback.
Start by critizing yourself. What I do before asking this question is point out our known flaws.
Hey, we have some issues here and here, this is how we are working towards improving it. For example, we could be doing a better job at writing documentation, etc, etc. What I love about having new developer join us is the new ideas they could bring on board, we are open minded to learning and getting better, from what you have seen so far, what can we do to improve? What should we try?
Hey, we have some issues here and here, this is how we are working towards improving it. For example, we could be doing a better job at writing documentation, etc, etc. What I love about having new developer join us is the new ideas they could bring on board, we are open minded to learning and getting better, from what you have seen so far, what can we do to improve? What should we try?
Use a very simple tool to give feedback.
This is how we collect feedback (internal and external): https://www.stomt.com/stomt
And it creates a great feedback culture as i can give feedback as a normal user or anonymously and i can even vote anonymously. The simplicity reduces the perceived effort and makes it more likely that someone gives feedback. The optional anonymity takes out the fear.
(Disclosure: I work for STOMT)
And it creates a great feedback culture as i can give feedback as a normal user or anonymously and i can even vote anonymously. The simplicity reduces the perceived effort and makes it more likely that someone gives feedback. The optional anonymity takes out the fear.
(Disclosure: I work for STOMT)
Use an external agency to give truly anonymous 360 degree feedback for everyone in the organisation.
This can get you get to the roots of problems. Take their advice on administering.
From what you stated, it sounds like the company is in a hierarchy power structure where others don't want to stick their head out too much.
At only 20 people, to have this problem sounds like a problem. Getting an external consultant to do some investigation seems to make sense.
This can get you get to the roots of problems. Take their advice on administering.
From what you stated, it sounds like the company is in a hierarchy power structure where others don't want to stick their head out too much.
At only 20 people, to have this problem sounds like a problem. Getting an external consultant to do some investigation seems to make sense.
Hire me, I'll tell you - short of that, keep asking like a broken record at the end of every week. At some point they might break down and tell you -
Here's how I implemented what you're asking to my company: I would first ask how they are doing and how the project is going. And then I would ask if theres anything we could improve - the first few times, nothing. After that, they would tell me improvements (finally)
Here's how I implemented what you're asking to my company: I would first ask how they are doing and how the project is going. And then I would ask if theres anything we could improve - the first few times, nothing. After that, they would tell me improvements (finally)
Managers always seem quick-witted enough to come up with justifications for anything, sometimes even preemptively declaring they don't want to hear about subject X. So why would I point out obvious things? And why not ask the other devs? You have lot more of them. Plus a week is pretty early. You could ask them every month or every other month.
When you have that meeting, let them know that there is an anonymous suggestion box in some public location and that you really, genuinely want to know what can be improved. They may not tell you to your face, but maybe if there was some anonymous way to handle suggestions, that might be more effective?
"There are even some pretty obvious flaws..."
List those on a piece of paper and have the new developer add one item.
List those on a piece of paper and have the new developer add one item.
The question is pretty big. There are so many things that could be improved on so many levels of your organisation. Where to start? Did you try asking more specific questions?
How about building up a relationship with the people first by having regular one-on-ones?
How about building up a relationship with the people first by having regular one-on-ones?
One thing to note why you'd always have all these ideas and others don't is because you're a founder and they are programmers. It takes a certain level of conviction to voice your ideas. Not every programmer has that conviction.
"Give a man a mask and he will tell you the truth"
I don't usually speak up because i'm too afraid that the other person might not take it constructively. Create an anon survey, that might help. It always does :)
Have you tried being self deprecating a bit? I've found that ripping on yourself/the company a bit will show them you're not afraid of the truth and will loosen some inhibitions.
>> Any ideas how we can get feedback from our new developers on how to improve?
www.danluu.comYou probably need an independent critic that do not has nothing to lose in the process.
Come up with a way for them to provide anonymous feedback.
Some random thoughts from someone who is not in the industry but has read too much HN:
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!)
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!)
Why don't you run anonymous surveys so that employees can give feedback without fear of repercussions?
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?