Management Authority

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.

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

Interviewing Advice

I had to give a 5-10 minute talk on "interviewing tips" for a room full of college students. Since it's generally interesting, I wanted to post it, so here's my notes. I speak (as always) from my own point of view, and not my employer's.

--------------

An interview starts with a friendly chat about you.

• What's the last thing you've worked on that you're proud of?
  
• Why do you want to work here?
  
• What do you want to do here?
  

That's followed by a longer chat about a programming puzzle, focusing on:

• Algorithms - how do you solve the puzzle?
  
  • College courses in Data Structures and Algorithms; if you haven't taken these very recently, review the material!
    
  • Introduction to Algorithms is the Algorithms text I studied with.
    
  • lists, hashtables, heaps, trees, graphs
    
  • sorting, searching, recursion, Big-O, probability
    
• Coding - write clean code on a whiteboard in C++, Java, or Python.
  
  • Both correctness and readability count.
    
  • Practice on a whiteboard. Really!
    
• Design - how would you design it for maintainability? How would you scale it? How would you test it?
  

Some general tips:

• It's okay to simplify the question to build an initial solution, as long as you come back to the full question later.
  
• Don't be afraid to make mistakes. The goal is to have a conversation about the problem; interviewers want to see how you think, and it helps if you can talk through it. Your first solution won't be optimal, and that's absolutely fine.
  
• Feel free to ask questions, and clarify the problem before you dive in. If you're really stuck, ask for help. It's okay to admit if you don't know the answer to a problem.
  
• You will be asked follow-on questions until your knowledge and experience run thin. In every interview, you will be asked questions you do not know the answers to, and That's OK; that's the idea. They're looking to see how you use what you know to solve problems you *don't* know, just do your best.
  
• If you're doing multiple interviews in one day, they're independent of each other. If you don't do well in the first interview, work on starting fresh in the second. Each interview and interviewer starts with a fresh slate.
  
• Interviewers are glad to answer questions about their jobs. Have some questions for them! Some common questions include:
  
  • What's the workday like? What project do you work on?
    
  • What's good here? What's bad here?
    
  • Is there really no dress code?
    

What is the interviewer thinking?

1. How does this person think on their feet?
   
2. How does this person communicate their thought process?
   
3. Does this person know how to write and test code?
   
4. Do I want this person on my team?
   

Finally:

• If you've heard the programming question before, please say so. Interviewers can adapt or change the question if need be. They've asked the same questions quite a few times, and if you already know it, your cadence *will* be off, and they *will* notice.
  
• Read Steve Yegge's blog post "Get That Job".
  
• Be on time.
  
• Take the interview seriously; the interviewers will.
  
• Come prepared, well rested, and comfortable; it's a casual company.
  

Creativity at Work

A friend asked me to answer questions for a survey, with respect to whatever experience I have that's relevant. Here goes.

Please briefly describe your current position at your company, your professional background, and any involvement you've had with new product development.

I've spent ten years doing web development, largely in Java, HTML, and CSS2, but also touching C#, PHP, and JQuery.

Currently, I work for a large web company. I've learned C++, and do some of my code at the user interface level; actual users see the changes I make to our software.

How would you define new product development? What constitutes a new product?

I think of two things here. One is "a completely new product"; something that hasn't existed before. Much more common are "big improvements on existing products", which seems much more descriptive of how "new product" is used today. We're not always inventing the idea of a mousetrap, but we are making better mousetraps. When the difference between the old way and new way of doing something is noticeable to even the most casual user, it's a new product.

What percentage of your time would you say is dedicated to working on new products?

Of the time at work I spend on technical projects, nearly 100%; the company is only ten or so years old, so all of the products are new. In fairness, about half of what I work on was started by others, and about half is code where I wrote line #1, so call it a 50/50 split between new and old.

What percentage of the products that you work on which make it to market/production would you classify as new products?

Again, 50/50; everything we work on that's successful goes to production.

Please walk me through how you've seen successful new products developed, from ideation to launch.

There are three ways to drive ideas:
- Sales driven
- Engineer driven
- User driven

Some mix of the three is necessary. I've found that it's never wrong to put more focus on the users - all of them! - for long-term planning and success. Sales-driven organizations are *great* in the short-run, but fall flat if sales is sacrificing overall user quality for the opportunity to close one or two extra deals. Engineer driven companies are odd the other way; they might produce the best product that no one ever wanted to pay for. But user driven, *if* you can hit it, is ideal; you make a product. People like it.

Have you ever had a great idea for a new product that was started but never saw the light of day? Please expound as much as you can.


Yes. I have more good ideas than I have time to push them right now. I don't know if any of them are great; I haven't pushed on them yet.

On the plus side, having extra ideas gives me a large list to pull from when I have free time. When someone asks "what should we be doing with X", I usually have an answer; it's not always a great one, but something to get conversations started.

What are some typical reasons or roadblocks that prevent good ideas from coming to fruition at your company or in your experience? Any suggestions for how to avoid them if you were given a blank slate?


Getting the right people in the driver's seat - and letting them get the right people on the team - are the most important things I've seen for getting ideas into reality. Those people need to be:

- skilled at that task
- interested in that task
- optionally, but preferably: have their compensation/promotion benefited by success at that task,
- while measuring success in a way the team *all* agrees on up front.

Do idea raisers have the opportunity to stay involved, and if so, how? Do you feel it's important to keep them involved and why?


Largely, yes; you want to have two sets of people working on any project:
- The people who can Get The Job Done, and
- The people Most Passionate about the task.

Hopefully, these are the exact same sets of people. In the case of the person who had the idea, they're often the most passionate person you could possibly have on the job; it was their idea, and if they weren't passionate about it, it wouldn't have taken off! As long as the inventor is a productive part of the team, they should be kept in the mix.