Ask HN: Critique my 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.

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

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

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

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

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

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

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

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

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

1. 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. The formality of the process.

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

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

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

My random internet advice:

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

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

3. Build a culture of trust.

Good luck.

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

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

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.

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.

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?

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

    www.danluu.com

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.

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)

Sounds like what is happening here.

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.

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.

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

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.

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

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.