Are we there yet
Filed under: Big Company, Crazy, Development, Management, Project Management, Small Company
Asking developers on an hourly basis if they are done, will NOT make the fix come faster. Just because you are receiving pressure from above, doesn’t give you a license to kill productivity for all of those around you. Now is when you need to control the situation and get things done by helping your team. This is not the time to request for up to the minute status updates and TPS reports. Interrupting your developer’s concentration constantly doesn’t help them work. Try the following instead:
-
Make sure the correct amount of people are dedicated to the problem. There are many times when less is more (I’m not just talking about the editor), where the right two people are infinitely more effective than the wrong 20 people.
-
Distractions must be minimized to ensure their focus doesn’t drift from the current work to other priorities.
-
Provide the stakeholders with accurate updates on progress. If there is any heat or anger related to the issue, take it for the team so that they can focus on fixing the issue.
-
Ensure the developers understands the issue, context, and time lines.
-
Remove roadblocks soon as quickly as you can (or ahead of time if possible).
-
Get the developers what they need to get the job done right.
Clear the path in front of them and let them work, don’t hold them back.
Students – The Many Month Interview
Filed under: Big Company, HR, Management, Small Company
The purpose of students is recruiting for full time employees. Their work terms are their interview. At the end of the term, you will have a good idea if they would fit into your organization.
Many companies have a probationary period, but it is usually not long enough to evaluate the effectiveness of the employee. With students, you have a 4 to 18 month term. Students will leave at the end of the term unless you ask them to stay. Full timers stay at the end of the probation term unless you ask them to leave (which usually tones of paper work).
Many people say, students are cheap. I would say that this needs to be clarified. Students are a cheap way to recruit new hires, but expensive when you factor in training from your full timers. Here are some of the costs associated with hiring students:
-
Resume Reading – I’ve found that marks are not necessarily the best judge of future work place performance. There have been many good people I’ve worked with who have had mediocre marks. The reason I bring up marks is that the filers offered by the schools for the employers are typically useless, resulting in a huge pile of resumes. Multiply this by the number of schools you are hiring from, then you start to see that this starts to add up.
Interviewing – The interview process for students goes much faster than full timers, but you will still need to dedicate half a day to a full day depending on the number of schools and candidates that have been selected.
Work Plan – With most students, I spend time to create a work plan for the term. This plan contains the training plan, ramp up information, and outline of their work for the term. This plan will be added as a template to the template section.
Training – People must be assigned to train this new resource, not manuals. This training (or interruptions) of your regular team members daily activities will reduce their productivity.
Salary – The salary of the student is lower than your full timers. Make sure to talk to accounting if you are in a small company as there may be government grants available to help subsidize their salary.
Now that you’ve got the student, it is important to give them real work. No one enjoys make work projects. The purpose of the student is to help determine if they are material to be a full time hire. This is best evaluated by giving them work just as if they were a regular employee.
Once the work term is over, you should have a good idea if they would make a good full time hire. When you bring this person on full time, their is much less risk and training.
Note: On the government student hiring incentives, there are many strings attached. Ensure that the accounting department doesn’t dictate that the new hires must qualify for the program. I have seen some programs structured so that a student who is in a coop program is unable to qualify as a new student hire because the qualification formula used involves number of hours worked over a period (which can be exceed by those in a coop program).
Developer Configuration
Filed under: Big Company, Crazy, Development, HR, Small Company
In a world where software developers spend 75% of their day at their desk coding, why is it that senior management goes cheap on the equipment? Here in order of importance are the items to provide your developers with a comfortable work environment.
-
Dual Large Monitors
Why is it that asking for two large monitors requires more paper work approval than a trip to Asia? Two large LCD monitors, maybe more, no less.Fast Computer
This may seem stupid, but many companies try to save a couple of hundred dollars when purchasing computers by going with slower computer and less ram. When it takes a long time to compile code, people are more likely to context switch to /. while waiting for it to compile. If it can be compiled quickly, developers are less likely to lose their train of thought.Comfortable Chair
If you are sitting at your desk for the majority of the day, spending the extra 1000$ for a nice chair. A developer once said about his chair, “You can have my Aeron chair when you pry it from my cold dead butt.” Over 1000$ for a chair seems expensive, but over 4 years (1000 working days) it is not that expensive. See Joel on software for his chair ROI calculation for the chair.Easy Meeting Room Access
A meeting room which can be accessed by developers without requiring them to book it ahead of time.
What I did not mention in here was offices. There is a large debate as to whether giving developers offices is better or worse, that will be left as a topic for a future post.
Best … Demo … Ever …
Filed under: Big Company, Crazy, Development, End User, Small Company
There are certain aspects of a good demo, but it all comes down to practice, practice, practice.
Lets set the stage. After starting coding four month ago, we were running out of cash. There was a potential VC deal on the horizon, but it wasn’t going to happen until we had a sale. This was `the demo` to our only real customer in the pipeline. We had all the right people in the room for the demo. The customer had made it clear in our last demo what the sales objections were going to be, and that they had to be resolved for this next demo. It was a hail mary pass with two seconds left on the clock.
Lets dissect the days before the demo.
Day: t – 14
We gave a demo to our early adopter evangelist on the inside. He provided valuable feedback and pointed out the areas which will be the objection points. We scheduled the demo two weeks from that day. Several show stopper bugs, but we have two weeks to fix them.
Day: t – 13 to t – 3
Code like you’ve never coded before. Keep cranking it out. Don’t stop. Fix all those bugs.
Day: t – 2
We created the demo script. Although the meeting was to be 1 hour in length, the demo part was scheduled only to be 10 minutes long. The script covered all the users important pain points along with the requested objection points. All of the show stopper bugs were resolved except for one. We still have one day till code freeze to fix that nasty bug.
Day: t -1
24h before the demo was to begin, we froze the code. From now on, it was nothing but practice. That nasty bug is still there.
Now, about that bug. If an item was dragged in our interface, it would crash the entire application. Think BSOD. The only way to prevent the crash was to drag it to an exact pixel co-ordinates. Think of having a 1280×1024 resolution screen and having to drag to an unmarked x,y co-ordinate. If you missed, the application could crash and the company could fail. No pressure.
Day: t – 0
After our demo’er practiced nearly for a day, we were ready. He typically was able to hit the pixel about 50% of the time. Hedging our bets, I made sure we had two applications running at the same time, with the second setup to be at the exact point right after the crash should occur in the script. If a crash should occur, hopefully we can <ALT-Tab> before anyone notices. The demo went perfectly. He hit the pixel right on, no crash!
Best demo ever!
Worst Interview Ever
Filed under: Big Company, Crazy, HR, Management, Small Company
Some people are used to large companies, and others small. This candidate was from a large company and didn’t realize that a large company and small company operate differently. Many of the items individually are not that bad, but the combination of all of them all made for the worst interview ever.
We were interviewing for a developers. It was a typical software development role. We had already done one interview in the morning, and this candidate was scheduled for the afternoon time slot.
His resume was quite different than other resumes I had reviewed. A bullet point at the top of the resume was, “Actively recruited by BigCompany Inc.” It also appeared to be on company letter head. Weird, but he seemed to have some of the skills we need and came from the recruiter.
Johnny arrives, I welcome him to the office and offer him a beverage. The third sentence out of his mouth was, “Is my Mercedes ok parked out front?”. Sure it is, I park my 9 year old Toyota out there all the time.
Two sentences later, he says that he had won the university congressional medal of honor for high academics. He then proceeds to spend five minutes discussing how rare an award it is and that is presented to the student with the highest mark in the class. I asked my coworker in the interview about the medal (I obviously have never won such a distinction, but know that my coworker had pretty good grades). He said that he has one, two of the other developers have one, and another developer has two (Bachelor and Masters). Damn, now that I think of it, we really need to get a trophy case in the front lobby to show off all the medals of our employees. The rest of the interview went ok, he appeared to be an average candidate from the interview.
We had troubles finding candidates for the interview, so we were considering an offer to him. A bit of context before I get into his demands. Johnny, a software engineer currently has a job at a large company, had graduated two years ago from his undergraduate, and had two years of professional experience. His demands were the following:
Vacation
Four weeks vacation. This is a little on the high side. We were typically offering three weeks, but we can work with vacation and salary to come up with a package which works for everyone.
Parking
He wanted us to pay for his indoor parking for his Mercedes. The company did not pay for anyone’s indoor parking.
Salary
His salary expectations were 50% higher than what our range and the other candidates.
Guaranteed Salary
This was the kicker. He wanted a guarantee of 1 years salary no matter what happens. Yes, if for some reason the company should implode, or he gets fired, or any reason what so ever, he is guaranteed at least one year of salary.
Needless to say, this candidate was not hired.
