At any large enough company, people on projects far from yours make decisions that occasionally look like idiocy. Assuming they passed the same interview process that you did, there's a pretty good chance that the person who made that decision is reasonably smart. But human nature being what it is, we forget that, and sometimes assume the worst. Cries of "why would they do that?", "don't they realize that's dumb?", and "that's the worst idea ever!" abound. But due to the nature it's a big place, the decisionmaker can't possibly answer the criticisms individually, morale sucks all around, and employees on other teams are more likely to leave than to transfer to the team they now think is spending their efforts Doing Something Dumb. Google started an event called TGIF when it was a tiny company. The idea was that late Friday afternoon, everyone got together and talked shop. It it's current incarnation, someone picks a topic (Android, Chrome, Self Driving Cars, Benefits), and then the five or so most knowledgeable people on the topic have half an hour to explain what they've done since last time they took the stage. They're joined by one or two of the founders. And this is where it goes outside my experience in industry; the founders and experts spend another half hour taking live questions, from an engineer-voted list. About one question in four comes unscripted from a live microphone. No question - no matter how awkward - is taboo. The rules are really simple; speak your mind, but don't be rude. There's occasionally an answer that's not really satisfying... but that's the rare exception instead of a regular occurrence. The audience is engineers-only, which lets them talk freely about topics that would be management-only at other organizations. And employees who ask really hard public questions of managers (and the CEO!) aren't punished for it. The effect is stellar; instead of having the issue of decisions on the far end of the company occasionally looking like idiocy... everyone has the chance to get the *context* for those decisions; odd choices start looking like works of genius once everyone knows why they did what they did. Instead of the size of the company becoming something that divides people and slowly eats away at morale, engineers know what's going on, why it's going on, and a good bit of what's coming next. It keeps folks happier, which makes for harder workers and helps keep attrition notably low. It has some flaws, but overall? Aces on this cultural landmark.
So, related advice I give to both interviewers and interviewees. Interviewers: If you give a candidate a question that has several answers, they might say "well, we can do A, B, or C. Let's try B." At that point, politely stop them and make them pick a different path. If they chose B, it means they probably know B the best of any of the choices; if they can knock A or C out of the park, they would have done at least as well with their own choice. You get much better signal about a candidate when you (gently!) knock them out of their comfort zone. Push candidates away from near-certain success; it's not worth your time or theirs. Interviewees: Some interviewers will intentionally knock you out of your comfort zone, and since their are a lot of folks with asbergers in technology, even if they think they're being nice... sometimes, they really aren't. Roll with it; every good interview is going to push you out of your comfort zone, and you're not always supposed to succeed at everything they ask. (It's nice if you do, but honestly, almost never, ever required to get the job.) Be aware that interviewers may nudge you on the hard path, and don't give up until you get a call telling you to do so a few weeks later.
One thing I've noticed over the years is the correlation of the effectiveness of a team and the source of authority of their management.
Software development teams managed by MBAs who have no hands-on experience writing software are hit and miss. If the managers are engaged and proactive, this often works really well, especially if the team is large; formal training in managing large projects is absolutely worthwhile, especially for being able to better peg far-off deadlines or complex integrations.
The problems can occur when management wants to go in a different direction than the coders believe is correct. Maybe it's a heavy lean towards new features (with too little maintenance), or it's time spent polishing, but not making the system more robus, or any number of things; management needs to have the team believing they're working on the most important part of the software for the business. (If that's improving reliability so that the coders aren't woken up at 4 AM on a page, that's what it takes to keep those coders coming in to work.)
Software development teams managed by software developers who willingly took a promotion away from development have a different set of benefits. It's often far easier for these managers to motivate the team; they have the same mental wiring for weighing rewards, and the same wiring for feeling good about building things in general. Teams follow these managers more easily.
Peter's Principle can bite a manager here; if they were a phenomenal coder promoted to their first level of incompetence, they could be a terrible manager, misprioritizing tasks and leading the team into a hole they're not going to escape.
- If you have an MBA, realize that relating to the developers is important.
- Have a developer you check things by from time to time.
- If developers seem to be burning out, prioritize fixing the issue.
- A $100 cash bonus might go a lot less far in their heads than taking them out to a $50 dinner. *Ask*, and don't waste money.
- If you were a developer, realize that the developers don't always have the context of the big picture.
- Look longer term.
- Spend a bit of time reading up on what you don't know from experience.
- Gant charts and other management tools for long term goal prediction and managing complex integrations are always wrong... but you'll know you're wrong *sooner* than if you were flying without these.