Posts filed under 'Development Teams'
Do you feel like you are in a creative rut either as an individual or a team? How many sacred cows does your organization have? Are they holding you back in developing the best software you can? I started thinking about this after reading the US Navy Monkey Experiment article. Often in software development teams and individual programmers as well, invent sacred cows. These ‘cows’ can be a particular language, tool kit, or methodology. Eventually it gets to the point where the organization, or person, becomes unable and unwilling to adapt to change. Ultimately, it’s a self-defeating paradigm.
I see this a lot in teams and individuals who’re unwilling to move on from VB6. They cling to their sacred cow and refuse to consider alternatives whether it’s VB.NET, C#, Java, or something else. You’ll see this in the fervor some attach to the latest new methodology. The problem is that creative thinking is sacrificed to the cow. People get so locked into the approach they’re using that they’re unable to see the merits of alternative approaches. Like the monkeys in the experiment they attack anyone who tries something out of the norm.
Time for a BBQ?
Is it time that you turn your sacred cows into steaks? Here are some steps you can take.
1. Ask why are we doing things this way?
If you can’t answer this then you might be like the monkeys in the story, simply acting on what someone else told you without really knowing why. But, if you can answer it, then…
2. Ask does this reason still exists?
Maybe you know why you or your team started doing things this way but are the reasons for this still applicable? It may have been a good idea to start a new project in 1998 with VB6 but is it still a good idea in 2007? Perhaps a programming library worked well for Project A but it’s a burden to use it in Project B. Is it really a good idea to use it? Be willing to make some tough choices and stop paying homage to the cow.
3. Ask what are the pluses and minuses of continuing to do things this way?
There could be good reasons to continue doing what you’ve been doing. Are there? Once you’ve reached this point you should prepare yourself to honestly answer if the pluses outweigh the minuses or vice versa. At least by going through the exercise, especially as a team, you should be able to identify where improvement is needed. Sometimes only minor adjustments are needed but other times tougher measures may be required. Sometimes a destructive change, where old ways are discarded, can be helpful. Take the time to evaluate this possibility in yourself or in your team and see if it applies to you.
Let me know if you have made this kind of change or if you think this kind of change isn’t necessary by leaving me a comment. I would like to hear your opinions.
October 8th, 2007
Part of a development lead or manager’s job is to be a good coach to other members of the team. The further you go along the management track the more important this becomes, however, even at the team lead level it is quite important. Here are six tips you can use to become a better development team coach.
1. Provide Encouragement But Be Sincere
When a team member is doing things right, notice it. Far too often it’s easy for a lead to forget to offer praise for a job well done. Don’t let the opportunity to praise a team member slip by. Managers who take their team’s good work for granted only insure that their team’s morale and performance will eventually suffer.
Don’t do something silly like Schrute Bucks or other such vapid or vague gestures to show your approval. Programmers generally despise such things more than the general population. Also, avoid contests between team members since this can cause undesirable in-fighting. Instead, say something simple and to the point, like “You handled the deployment of the new version very well” or “I was impressed by your solution to the memory leak problem.”
2. Share Praise in All Directions
If praise is unheard it has a lesser impact than praise offered in public. Make sure that everyone on the team knows that if they do a good job they’ll win your approval and that you’ll let everyone know about it. If you hold team meetings, mention it there. If there is a company web site or newsletter, get it mentioned there. Make sure your managers are told about the excellent work that members of your team are accomplishing. Note that you give the credit to the team members, not yourself.
3. Keep Criticism Private and Positive
If you need to criticize the performance of a team member, do it in private. Never do this in public where other members of your team can hear. Also avoid making a show of calling someone into your office or a conference room for a one-on-one meeting when it is obvious to everyone that you’re intent on criticism of that individual. Nobody else needs to know or even guess about anything that was said.
Never criticize a team member when you or the team member are angry, tired or stressed out. This can quickly devolve into a shouting match or, later, bring out passive-aggressive behaviors or other negative actions. Be sensitive to both your emotional state and the employee’s. It can be very difficult to retract hurtful things said in the heat of the moment. Don’t let this situation happen to you.
When you need to make a point about substandard behavior, make sure you work toward a positive outcome. If you approach it like, “Improve your code or you’re fired.” or “Your code isn’t functional or elegant” , you will only put them on the defensive. Defensiveness shuts down listening.
Instead, state your exact problem with the team member’s performance, such as “When you’re telecommuting we’re having trouble contacting you by phone and email.” or “Your work has been behind schedule for the past month”. Then follow it up with a way to have the person participate in the solution such as, “What do you think would be some ways we could improve your communication with the rest of the team?” or “What can I do to help you get back on track?”
4. Define Your Expectations and Goals
If you don’t say what you want, how you define successful work, then you will find it difficult to provide appropriate praise or criticism. For example, if you expect a particular part of a project to be completed in 2 weeks but don’t tell this to the responsible team member it is quite unfair to criticize them for not meeting your expectations. They can’t read your mind and you don’t want them guessing about what you want.
5. Be Fair
One common problem is where one or more team members are held to a different standard than others. For example, you might like Joe and, although you know he slacks off regularly with long lunches and personal activities, you let him get away with it. But you don’t really care for Bill so when he leaves early one day for a dentist appointment you criticize his dedication to the team, project, and company. Team members will pick up on this quickly even if you do try to keep it private so don’t let favoritism or your personal dislikes and prejudices enter in to your treatment of team members.
6. Do It Now
One common problem in the personnel review process at many companies is that it’s once a year or once every six months. If you wait that amount of time to impart your praise or criticism the opportunity is lost. Also you’re more prone to creating a defensive reaction to criticism or a “so what” attitude toward praise if you delay. Instead insure that both excellent work and problems are dealt with in a timely manner.
As I mentioned above, you want to avoid jumping right into a negative situation but neither do you want it to fester for months. Handle the situation calmly and appropriately within a few days. Problems don’t resolve themselves. Likewise, praise for something a team member did 4 months ago won’t mean as much as praise within the first few days after their accomplishment.
What do you think? Are there any coaching tips you have? Any other thoughts on this topic? If so, leave me a comment.
September 30th, 2007
When you’re in a team lead or management role you will inevitably be called upon to do a job interview. Even if you are a team member you might interview a potential peer. So, once you’ve given them your programming language trivia quiz, asked them why manhole covers are round and had them to tell you a little bit about themselves what should you look for in the job candidate in order to hire the best candidate possible? What should you look for ‘between the lines’? And what should you avoid doing?
1. Look For Intelligence
This, of course, is the point of your programming language quiz and brain teasers. Do they know their stuff? It seems pretty straight forward, doesn’t it? Just pass or fail, right? However, you have to look beyond just what might be rote memorization. Do they seem like they’re just reciting answers to you? If you follow up with a “Why?”, can they launch into a detailed explanation or do they give you a ‘deer in the headlights’ look? Remember, you’re not looking for someone who can memorize a lot of stuff but someone who can also apply this knowledge in a meaningful way.
2. Look For Compatibility
How well do you click personally with the candidate? Do they seem able to get along with the people they’re interviewing with? Is this someone you can work with on a daily basis? Are they a know-it-all or champion BS’er? Do they seem overly nervous or reserved? Do they seem aloof or disengaged or are they involved and engaged in the interview and with the interviewers? Do you think this candidate helps you think and does it seem that you make them think? How do they make you feel? Comfortable or uneasy?
Ultimately, a programmer might be quite smart but if they don’t mesh will with the group this will reduce their ability to perform at the top of their game. Just beware of being too selective in this area or trying to find someone who’s exactly like you.
3. Look For Problem Solving Ability
If you ask them an open ended question, how do they seek more information from you? Do they just make assumptions or is there give and take between you? Are they willing to ask for or accept help or are they too arrogant or unsure to ask? Do they seem confident or confused?
Once they’ve solved the problem or stated they can’t solve it, ask them about the mental process they used to solve, or try to solve, the problem. Note, them saying, “I didn’t even know where to begin” or “I just guessed” is a bad sign while them giving you a rough outline, even if it isn’t completely right, is usually good.
This is where you examine how they apply their intelligence and use it to interact with others, a combination of the first two items on our list. Hopefully you will gain some insight into their internal problem solving process.
4. Look For Creativity
Often you’ll find programmers who lack creativity. You can give them a detailed spec and they can code it quickly but if you give them something fuzzy or incomplete where they have to fill in the blanks, they can’t do it. Or, if you give them a user interface assignment, it is very dull and takes a brute force approach rather than an elegant one. Do you need creativity in your position? Maybe not. However many organizations do need it.
So how do you gauge creativity?
One way is to ask them about outside activities. Some of the best programmers I’ve known have had outside creative interests like music, painting, or furniture making. While this isn’t a 100% solid indicator of creative programming ability it is a good sign in my book.
Also look how they draw out their thoughts on a white board or piece of paper in response to a puzzle or a design question. Do you get the feeling that they’re painting-by-numbers or are they capable of developing a masterpiece?
5. Look For Passion
Does the candidate have a passion for programming and computers? How can you determine this?
One way is to ask about the most recent programming books they’ve read. Another is to ask about which web sites they use to learn about the latest industry trends. Where do they go for help in solving problems. Do they participate in online programming forums? Do they have a programming related blog or web site?
Ask them about their home computing setup. A passionate programmer is likely to have quite a home network setup and will be able to describe it to you. However, a not so passionate one might tell you they’re still using their college PC from 10 years ago and that they only boot it up occasionally.
6. Look For Diversity
You don’t want a clone army in your organization. If every programmer is from the same school and has roughly the same background you’ll end up with a case of groupthink that will limit the overall brainpower of your group.
If you’re were a heavy duty computer science major, don’t be afraid to hire that sociology major who has a knack and passion for programming. If you went to a highly rated technical university don’t summarily dismiss the ability of a night school grad. Likewise, if you’re the sociology grad, don’t allow yourself to be intimidated by the CS major.
Don’t get hung up on finding a candidate that has extensive knowledge already in your specific field. A smart programmer should be capable of applying knowledge from one field to another. In fact, they may be able to offer a different insight from their experience in another industry.
Everyone has different perspectives and can learn from someone else. Don’t let your hiring practices cause your team to become inbred.
7. Look Past Stereotypes
Many programming job want ads ought to read like this if they were truly honest:
Wanted: Senior Level Expert In VB.NET
6+ years of increasingly responsible professional experience
A minimum of 4 years of working with VB.NET
Database experience in SQL Server 2000/2005
Successful candidate must be a healthy Caucasian, Asian, or Indian male of between the ages of 25-35. No women, people over 35, people with disabilities or those of other ethnic groups or racial minorities need apply.
Hopefully you don’t think and hire this way. Sadly I’ve known many organizations that do behave this way to some degree. While such discrimination is illegal, at least in the US, many use clever HR approved code phrases to not hire or even interview people who don’t fit within a narrow stereotype of what some think a programmer should be. Narrowing your choices by allowing yourself such prejudice will cause you to cut yourself out of a pool of potential talent and often lead to hiring someone less skilled, less smart. Don’t let this kind of thinking poison your ability hire the best people.
I hope you’ve found this article helpful. Let me know what you think by leaving me a comment.
September 23rd, 2007
The software development world is filled with bosses who treat their words as if they were edicts from the throne. This works, sometimes, but it is often at the expense of team morale. Without the prevalence of bosses like this, we wouldn’t knowingly laugh at Dilbert’s “pointy haired boss” or Office Space’s Bill Lumbergh. However, a pure majority rules scenario also encounters problems when a tough, contentious, decision has to be made. Most often the ‘decision’ in this case is no decision at all and the problem goes unsolved. Between these two extremes is where the Benevolent Dictator comes into play.
Leading Without Leading
The first idea is to allow the team to make the majority of their decisions as a team. You don’t have to jump into every difference of opinion with your words from on high. Instead, listen, find points of agreement and bring them up, and help the team to reach a consensus. This gives the team a feeling of group achievement and comradery that would be missing if you forced the issue.
You shouldn’t make important decisions without some input from the team, either in the form of a vote or a group discussion. Too often, managers will make decisions on things like which version control system or coding standard is to be used and barely consult the team or even not consult them at all. By allowing participation the benevolent dictator insures popular support for a decision.
However, you should not simply abdicate your role as leader to someone else. I have seen some managers, particularly ones with lacking technical or interpersonal skills, allow a more forceful person to become the defacto leader. This can undermine your ability to lead a team when your leadership is needed. And there will always be time when it is needed.
But You May Need To Impose a Decision
One common failing in self-lead teams is the inability to reach a decision, particularly on tough choices. As one team member I used to work with was fond of saying, “That’s a non-issue”. Unfortunately, often it was an issue and it came back to bite us later. The benevolent dictator’s role is to identify those areas where a hard decision is needed. If the team can’t reach a consensus by being guided toward it, then it will become time to impose a choice to break the deadlock. Sometimes just the implication that this will happen will be enough to have the team develop a consensus.
Sometimes a decision might be so polarizing, like those that often come up when discussion coding standards, that putting it up for vote or organized group discussion might damage the team’s ability to function. In that case, it may make sense for you to impose a solution or compromise rather than having the team at each other’s throats. They might not like you for a while but, with any luck, the team should be intact. The key thing here is to use your power very judiciously and not arbitrarily and to give a good, solid, explanation for your decision.
The Goal: An Effective Team
The goal of anything a benevolent dictator does should be to build an effective team, a team that develops software that solves the problem at hand. When your decisions, or lack of decision, fails to work toward that goal, your leadership of the team has become ineffective. If your interpersonal or technical skills are holding you back, take steps to improve them. Likewise, if you find yourself bullying your team, learn to keep this tendency in check. It’s all about seeking the right balance to achieve your goal, a high performance team.
September 16th, 2007
Back in 1999 when I first started a VB related web site, then on a free dotcom era host, I wrote this article, VB Interview Questions, that provided a list of interview questions for VB6 related jobs. The article hasn’t been revised in years but is still one of the most popular of my archived site’s articles. So, I thought I’d revisit the programmer interview process. I went through several interviews last year as part of a job search, some good, some bad. I’m not going to get so much into specific questions here but more into what kinds of questions to ask and the interview process as a whole.
Getting a Good Start
In my original article, I said, “The interview should be conducted by someone who knows VB well preferably someone involved with the project the person is being hired for.” I still think this is true. While a Human Resources department can be valuable in doing some initial and background screening, it should be up to the hiring manager to do the initial technical screening of candidates. This helps insure that you don’t frustrate qualified candidates and don’t waste a lot of time on those you don’t. For example, for one job a HR rep gave me a 25 question multiple choice test on .NET over the phone. I did quite well and got a face-to-face interview lined up. However, when I came in for the interview, it quickly came out that they were looking for someone with more of a C#/C++ background than VB. So, we ended up wasting each other’s time.
Certifications or No Certifications? Tests or No Tests?
My opinion is that certifications don’t mean that much in the long run. They’re somewhat helpful in eliminating those with inferior skills but, by insisting on them, you may also miss out on excellent programmers. From what I’ve seen from the system administrator side of the IT house, certifications are not a good indicator of future success within a company nor technical competence beyond the ability to regurgitate trivia. They’re a plus but shouldn’t be a make or break criteria.
Should you give written or online tests prior to an interview? I’d have to recommend against this. This used to work somewhat back in the pre-Internet days but today, with answers just a Google away, it’s mostly a waste of time and money. If you want a pre-test for screening, I’d suggest going with an open ended, personal level, model like, “Describe how you coded some of the major features of your latest VB.NET program?” or “Which array or collection methods do you find yourself using most often?”. This increases the likelihood of getting back a meaningful response rather than a borrowed blog or forum post.
You can do the interview over the phone or in person. As both the giver and receiver of interviews, I prefer a phone interview first. This is usually a big time saver for all involved and has the advantage of being ‘green’ since no extra gasoline will be required. It also can be conducted after hours from home as well, making it more convenient for all. Just don’t try to do an interview on a cell phone while driving please!
OK, so you’ve started the interview so let’s start with some trivia questions. These questions can be as few as 3 or 4 or as many as 25. I suggest starting with some softball questions like, “In .NET, what is an Object?” and build up to more difficult ones like, “Explain how to multicast delegates.” You can probably find a number of good questions you can put together from my VB Tutorial articles as well as on other VB.NET related sites. The point of this part of the interview is to see how well they know the basics. Don’t ask pure trivia like “How many overloads does the String.Format function have?” or a set list of standard questions. Instead, ask questions that will give you a good idea of what the interviewee knows without trying to purposely trip them up and ones that track well with the apparent skill level of the candidate.
In most cases, you’ll know within about 10 questions if the person has the knowledge level you are seeking. If they don’t, it’s probably best to wind up the interview at this point quickly and politely. If they do, move on to the next phase.
What Have You Done and What Can You Do For Me?
Now that trivia time is done, you can get into the meat of the interview. In this part of the interview you want to find out what the candidate has done on projects in the past as well as getting an idea of how their skills might apply to your projects.
I’ve found it best to ask questions that allow them to describe their previous work. Most will be enthusiastic about it and give you a lot of detail about it. Ask leading questions like, “What did you use for your database layer?”, “How do you debug problems in your web service?” or “How did you document your code?” With these questions you should be able to gauge the level of participation the candidate had on these projects and where their head is at from a coding perspective and how they would fit within your department.
Also, now that you know how they stand with something they should know, their own work, give them a situation from your problem domain. For example, if you deal with importing randomly formatted ASCII data files into a database, ask them how they would approach this problem. You don’t have to make it complex but get them to describe the basics of how they would handle it. In a face-to-face interview, have them write it out on a whiteboard or paper to also test their presentation skills.
Should they show you a code portfolio? Given that it can be faked rather easily these days, I don’t think it’s of much value anymore. However, it is a good idea to ask if they have any samples of their they could send you or that you could download. Just don’t give it a lot of weight.
Should they know something about your company? Yes. The Internet works both ways. They should have researched your company prior to the interview. If they haven’t, well, you aren’t that important to them so maybe they shouldn’t rank so high in your book either.
Do You Fit?
This is really the key question once you’ve determined that you’re interviewing a good programmer. As I mentioned in my old article, I like to see if someone has a spark of creativity and a sense of humor. While they don’t have to be a musician who’s also a Monty Python and Star Wars fan it makes the days go smoother if they don’t give you a blank stare when you bring up a bit of popular geek trivia.
Essentially you’re looking for someone that you wouldn’t mind working with on a project. They’re probably looking for the same thing. Throw out some light conversation as you wrap things up to get a feel for this.
What Do You Want To Know About Us?
Another key part of the interview is to make it two way. Have them ask questions. You can get a feel for where they’re at from this as well. For example, if they ask “When do I get days off?” or “How did you get out of that recent FTC investigation?” you might want to be a bit cautious but if they ask questions like “What is a typical work day like here?” or “What do you use for source control?” this could be taken as a good sign.
Let them know what the next step in the process is and when they should hear back from your company. Try not to leave them hanging. Nothing is worse as a job candidate than having an excellent interview and not hearing back from the company until after you’ve already had to accept another position. If they didn’t do well, let them know although you should make it as non-personal as possible.
That’s all for this article. It went on a little longer than I thought it would but I hope it’s helpful to you. I had some other ideas I wanted to include but I’ll just put them in a follow-up article. Let me know if you have any thoughts or questions on the interview process by leaving me a comment or using the contact me button to send me an email.
August 26th, 2007