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).
When not to ship software
Filed under: Development, Product Management, Project Management
When planning a product release, you always choose a date. Choosing a date is difficult, and here are some dates which I suggest you try to avoid.
-
End of the Quarter
If you choose your shipping date as the last day of the quarter, your boss will tell the executive team in his next meeting. Your boss is now on the hook for delivering at the end of the quarter, whether the executives care or not.This isn’t the worst one because if you are late, you can usually get your way out of it by doing a demo to their boss. This demo, plus some nice words can usually buy you more time. The good thing about the demo is that it gives you a good wake up call of how far along you really are.
End of Fiscal Year
Never choose a date close to the end of the fiscal year. There is a chance that accounting may create forecasts of sales for what you are building. Once they make these forecasts, then it will be much more difficult to get the date modified.The end of fiscal year also causes problems due to vacations. Many companies limit vacation carry over, forcing people to burn up their vacation before year end.
Christmas
The last two weeks of December and first week of January is a bad time to try to get anything done. People have a lot going on in their lives, and are not as focused on work as they typically are. Even if your direct staff plans around the release, the accompanying staff will not. There is nothing more difficult than trying to get people around Christmas time. Also, executives will be off as well, so this will make it difficult to get sign off on a product delay.End of the Summer
People will take vacation in the summer, and even if you plan it so that each person is covered off during their vacation, it will result in pain. Shipping time is when you need all of your bench strength, and not people doing two jobs while covering someone.
In a future post I’ll try to address which date to choose.
The developers will rise up
For those of you not from a technical background, dealing with technical people may seem a bit alien. This is the story of what happened when Cara (who reported into the sales organization) attempted to run a technical project.
I don’t recall Cara’s title, but she was the interface between the customer and the development team. We were working on a customization of our product for the customer, so there was a to be a lot of communications between her and the team. During the initial phase, one of our more cranky engineers was assigned to complete the project. Cara was new, we didn’t know anything about her. Mr. Cranky was in his heart a decent guy, but did not suffer idiots. Within two days, Mr. Cranky was complaining about Cara. We were not surprised about this, as Mr. Cranky complained a fair amount. About a week in, Mr. Cranky told his manager that he refused to work with her and demanded to be put on another project. No one in the development team was surprised.
Over the course of the next two months, it seemed as if the engineers were added to the project than left. After half of the engineers unsuccessfully tried to work with Cara, several of them got together for a beer in the kitchen one evening to discuss Cara. They decided that Cara had to go. Several of the senior engineers approach the VP of development and told him of the problems with Cara and that the team was refusing to work with her. The VP listened to the issues and told the engineers he would escalate it to the executives.
After the escalation, they tried using sales engineers for the project. The sales engineers were unable to work with her either. The project ended up failing.
Cara considered engineers as interchange widgets and that engineers were a cast of “untouchables”. Her disdain for engineering contributed to her failure, but was not the root case. The two main problems which made it impossible for her project to succeed were a lack of understanding and a refusal to communicate.
The problem was that Cara could not communicate the proper requirements to the team. She would communicate requirements which were completely in left field. The requirements were obviously not something any customer would want. Development asked her for clarifications, and she would shout buzzwords at the engineers then return to her office. The development team attempted to get direct access to the customer, but she refused to allow anyone other than herself talk to them.
Cara was a one trick technical pony, she only understood one technical item, and mapped every problem into the one thing she understood. Cara joined our company and was placed on the project immediately. Her previous two companies were in the same domain, with those previous projects all using the one particular technology to solve the problem. Unfortunately, this time the problem (and the solution) were different. Cara didn’t understand the problem the customer was trying to solve, which doomed the project to failure. She could no longer keep spewing buzzwords at the team and get them to build the solution. Cara refused to seek help for herself (or the company) by allowing another person to communicate with the customer, which further contributed to the failure.
Build Systems
I hope someday to see a build system that is held together with more than twine and a prayer.
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.
Sunshine Report
Sunshine Report: A status report which only reflects the positive feelings one is having.
For the most part, I have found that engineers tend to focus on problems in their status reports, but the first person who gave me sunshine reports took me by surprise. These next few paragraph detail my first enlightening experience with the sunshine report.
-
1st Status Report
When asked for his status, he responded that, “Everything is great, I’m looking into this one issue, but I’m confident that I’ll be able to get everything done on time.” My first thought was wow, a part of this project is going well. I recorded his report and moved on to my next task.2nd Status Report
I asked him for his status report, he said again that everything is good. He was still looking into this one issue, but is confident that fixing this issue will resolve many other issues he has assigned to him. According to him, everything will still get completed on-time. At this point, warning bells started to sound. I was concerned that he is still on the same issue and that this issue is starting to spread to other sections of the code. But, he still seemed positive about it. I let it go to see where he would get to next week.3rd Status Report
Now, this time I came to the meeting much more prepared. When I asked him how it was going, he was still one big happy ball of sunshine and confident that it would be done on time. I thought differently. He had just spent three weeks working on the same issue. I began to question him much more in-depth about his work. Driving down on the issues. After only about 5 minutes of drill down, he started to come to the realization that he was in over his head. We worked together to come up with a plan to get him back on track.
After that, I monitored his project more closely. Unfortunately on the next project, when prompted for a status report he still gave “Sunshine Reports”, but it just took a few minutes to cut through the sunshine to get to the truth.
Demo Driven Development
Filed under: Crazy, End User, Product Management, Project Management, Small Company
• Your company is living paycheck to paycheck.
• No one has actually paid for your product.
• Product direction changes each time sales visits a lead.
Given the above situation, it is time to plan a software release. The PMBOK doesn’t cover this kind of project. There is no chapter for near Armageddon events. Planning a software release for a company which is just starting out or in a death spiral is not covered in classical project management literature.
The development plan will be:
The name of the game is to make it looks like you have what the customers needs as quickly as possible. You do not know your market, you do not know your product, you know nothing. Through many failures, the company will discover the market. The hope is that there is enough time and cash to realize this goal.
Someone on the sales team manged to get on the calendar of someone with budget and a pain large enough that they will spend 1 hour to see if you can help them. The sales team has provided you with the release date, and a feature set.
As usual, break down the tasks, figure out what is possible, drop everything that is not (ensure that you record what was not done, and that it came in from sales, not the customer directly). Then get started. While developing it is important to remember that if you are successful, this demo will most likely become the foundations of your code base. Also, this software on demo day will not be touched by anyone outside of your company (in its current form), it just need to be good enough that they believe you can deploy it when they purchase it. I am not saying to fake the demo, I’m saying that you need to focus on the core pain points and that you can illustrate the solution to the potential customer. Many times, before the demo, the requirements will shift when the sales guys enlightens you more on the problem that the potential customer has. Those changes need to be incorporated. You are trying to demonstrate that your product can satisfy their needs. Do the changes as best as you can. Refusing to demonstrate a product which can help a potential customer is a waste of both your time and theirs. No one loves the churn, but you need to suck it up and do it.
During the demo, ensure that you are able to listen to the feedback while it is happening. This is the closest thing to users you have. They will provide you with the next set of work you need to do on your program. Record all their feedback (product ideas and bugs). Discuss internally all their ideas and make a plan for addressing the issues. Start working on them as soon as possible because you have up until the sales team schedules the next demo.
Once the next demo is scheduled, all of the focus shifts towards it. When demo goes well, but the potential customer is not interested (this is the most likely outcome), record all the feedback. Triage all of the features (including the previous demos) and begin work immediately based on what appears to be the most important in your potential customers eyes which is blocking the sale. Hopefully after several demos you will begin to see pattern and specific items and themes which re-occur. The future of the company depends on if you can solve the customers problem before the company closes shop.
