
Ask HN: Critique my company - asbestoshft
I&#x27;ve worked at the same company for the past 14 years, I am one of the founders.  We do mainly C++ work on Windows and Linux.  We&#x27;re in the financial trading industry.  We have grown to about 20 developers.<p>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 &quot;What do you see that we could be doing better?  It could be anything, our process, the tools we use, our structure, anything.&quot;  And I get literally nothing.  I just can&#x27;t believe it.  Am I not asking the right question?  Or I&#x27;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&#x27;m sure there are many other issues that I have trouble seeing.<p>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&#x27;t understand what was going on well enough but I like to think that some of them had merit.<p>Any ideas how we can get feedback from our new developers on how to improve?
======
johnwheeler
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.

~~~
hdhzy
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).

~~~
user5994461
Rules #1: Never talk when you leave. Just leave.

Whatever you say, it can only make it worse.

~~~
azdle
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.

------
reckoner2
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.

~~~
glenneroo
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).

------
brudgers
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.

------
rezrovs
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.

------
dugmartin
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.

------
meterplech
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.

------
aphextron
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.

~~~
jamestimmins
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.

~~~
SimbaOnSteroids
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.

~~~
aphextron
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.

------
AshWills
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.

------
mixmastamyk
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.

~~~
mixmastamyk
_took me_

------
chrisbennet
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.

------
itamarst
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/](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.

------
Mz
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.

------
snarf21
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?

------
nqzero
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

------
tmaly
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.

------
Helmet
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.

------
ccvannorman
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.

------
swsieber
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.

------
dharmon
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.

~~~
cookiecaper
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.

------
nzmsv
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.

------
hluska
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?

------
azylman
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.

------
TheAlchemist
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.

------
rb808
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.

------
solipsism
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.

------
highd
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:

    
    
      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

------
JSeymourATL
> 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.

------
dmlittle
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.

------
Spooky23
> 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.

------
kohanz
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?

------
alanmackenzie
Work on making people feel safe with the situation before asking for direct
feedback.

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.
    

It's hard to offer better advice through a HN post but easy to observe in
person. Perhaps you can hire an external consultant to help or ask a mentor or
advisor to fill this role by spending a few days in your office.

------
segmondy
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?

------
philippz
Use a very simple tool to give feedback. This is how we collect feedback
(internal and external):
[https://www.stomt.com/stomt](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)

------
zhte415
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.

------
cgrusden
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)

------
fwefwwfe
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.

------
cweagans
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?

------
bjornlouser
"There are even some pretty obvious flaws..."

List those on a piece of paper and have the new developer add one item.

------
rejschaap
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?

------
zeeshanm
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.

------
apris
"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 :)

------
orbz
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.

------
blacksmythe

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

Hire outspoken developers. Dan Luu would be an excellent choice:

    
    
        www.danluu.com

------
pvaldes
You probably need an independent critic that do not has nothing to lose in the
process.

------
bvi
Come up with a way for them to provide anonymous feedback.

------
i336_
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!)

------
maverick_iceman
Why don't you run anonymous surveys so that employees can give feedback
without fear of repercussions?

