Category Archives: Technology

My new favourite piece of technology

I’ve wanted one for a long time, but never had the nerve to buy one. I always thought I would look like a loser for having one. I can’t beleive the impact it has had on me in a few short weeks.

Olympus Voice Recorder

I’m talking about a Voice Recorder. It’s the latest input capture tool that i’ve added to my day to day life. For the longest time I’ve noticed that some of my best ideas or thoughts have come to me during my commute home in the car. This is usually when I decompress from the day and analyze my actions and those of the people I work with. I usually come up with lots of thought and ideas that need to be captured for processing the next day. For years I would call and leave myself voice mail. Dialing the office and waiting through my  greeting is a long process and usually meant I would only bother for the most profound ideas. Now, I carry the voice recorder wherever I go. I tend to leave myself 2 to 3 notes during every drive. The next day I process those notes and capture the next actions during my morning review.

I’ve played with variations over the years including voice recorder software that’s built into cell phones and pda’s. None of them stuck with me ultimately. Many of them took too many keystrokes to activate or required that I be looking at the screen in order to operate. It’s also easy to forget about your messages because you use your PDA or cell phone for many other functions. I find that having the voice recorder around prompts you to check it periodically to see what you’ve left on there. Being able to operate it with a single button without looking is a huge advantage and a must if you want to use it in the car.

If you’re serious about productivity or GTD I suggest you pick one up.


Knowledge is king

There has been much discussion in linkedin and the blogo-sphere about choosing the right knowledgebase technology for your business. The authors are focused on which wiki, blog or version of SharePoint is best. Having deployed enterprise knowledge bases using Sharepoint and various Wiki technologies in the last few years I can tell you that the technology itself makes very little difference. It’s the information and how you plan to collect it that is the key.
You will face resistance if you plan for people to start documenting everything they know and do. People have a natural instinct for job security and will most likely not comply or do a poor job of it. You will need to plan on a way to provide benefit to the employee for documenting their knowledge. I’ve had success in the past creating knowledgebase’s of support and maintenance information. I made documenting their knowledge a prerequisite for promotion out of that role.
A more natural approach could be to make the work itself the documentation. Software developers have been embedding documentation in their work for years. This eliminates the need for separate user manuals or development guides. The code itself becomes the documentation.  Providing your employees with an archive of documents, spreadsheets, images or objects created in the past could very well be the most effective approach to documenting your enterprise IP.

Pushing the envelope

We’ve just completed 2 back to back projects with tight deadlines over a 3 month stretch. This has been an extremely demanding period, I haven’t been through anything like this since Y2K! The team was asked to deliver on extremely tight deadlines and put in a substantial amount of over time hours and weekends. We we’re successful but it came at a cost, the team is tired and generally grumpy.

I’ve drawn some interesting observations from this experience:

1. When deadlines are tight you need to manage the team closely. You need to set daily objectives and make deadlines and priorities very clear. I found doing stand up scrum meetings with all stakeholders once a day very effective. Avoid the temptation to stand over people’s shoulders and nag them.

2. You need to let people vent. People are going to get frustrated or even angry. They will want to blame somebody or somebody’s mistake for getting them into a tight deadline. You just need to listen, let them get it off their chest. They will feel better and will appreciate your attention. Avoid telling them to suck it up, but instead give them the truth about why we need to do this and what happens if we fail. Be sure to cut them off if they get disrespectful, you need to make sure it stays professional.

3. You need to stay positive. Your attitude will be reflected by those in your team. If your team sees you being down or negative they will loose their motivation and work will slow right down.

I can’t say that I was perfect during this period, but I gave it my best. One of the big reasons I write this blog is to reflect on my successes and my mistakes and learn from them.

Innovate or grow?

It’s been crazy lately. Lots of work and lots of meetings. There has been a steady stream of new work coming in the door. The flow of work makes me uneasy, I’m wondering weather or not I have enough people to get it all done in the timelines the client wants. I guess I should be hiring more programmers; right? That leads me to my next problem. I don’t think I can effectively manage any more people. Currently I have 10 direct reports that I manage day to day, provide feedback for and coach. I would have to compromise my management style in order to manage more people. I also don’t think we can carry any more people from a financial perspective. The only thing I could do was to innovate. We needed to figure out ways of getting more productivity out of the people we had. This doesn’t mean making them work longer hours, it means finding methods and tools that will help them work faster.

We started by looking at different software development technologies like Ruby on Rails, Grails, Drupal, Joomla, PHP etc.. At the time we were developing front ends in Flash and Flex and developing the back end in pure Java. I was interested in simplifying the Java development and enabling the reuse of code. After evaluating the options we landed on Grails. Grails is a Web application RAD framework. It is to Java what Ruby on Rails is to Python. We choose it because it fit perfectly into our Java culture and technology footprint. The team is ecstatic with the shift into a new cutting edge technology. Learning a new platform has boosted morale and improved employee engagement. I expect that this will also have a positive long term effect on turn over.

We’re now working on our second project with Grails and it has improved productivity by at least one third. I’m confident that we will continue to speed up as the developers become more proficient in the language.

Adding 2 or 3 developers to the team would not have given me this kind of return and would have cost a fortune. Our shift to Grails has been a huge success, it has bought me some considerable breathing room, it made everyone happy and it didn’t cost me a cent!

Recruit, Recruit, Recruit…

It feels like I’ve been recruiting non-stop for the last 2 years. Through all this I’ve learned some valuable lessons.

Your success starts with the right people. There is no doubt in my mind that the best way to avoid problems in your career is to surround yourself with good people. Good people will elevate your game, bad people will drag you down. It all starts when you recruit. You need to approach it as if your job depends on it. It probably does.

I have never been in the position where I am recruiting for future growth. I’ve alway been under the gun and needed someone yesterday. The temptation to hire quickly is strong, especially if your busy. It’s is important to think about how much trouble it actually is to terminate someone if you need to. It’s much easier not hire than to hire the wrong person.

Take some time and think out your approach. Treat recruiting like a project; think through your goals and your success criteria. Formulate a systematic approach for how you will screen applicants. \

My approach looks like this:

1. Filter resumes using education and work experience.
2. Phone screen
a. Assess language.
b. Determine salary requirements.
c. Ask one simple yet deep technical question. This is called the gateway question.
3. Technical interview with my senior team leads.
4. Final interview with me.

The gateway question has been an amazing tool for me. It’s usually 1 or 2 sentences and can be answered with one or two sentences so it works well over the phone. It’s an extremely basic programming question that tests whether the candidate really knows the fundamentals. You will find that many applicants are proficient with the tools but don’t understand the core principles of software engineering. The people who don’t understand the fundamentals will only take you so far, they won’t be able to offer real innovation or problem solving.

It’s amazing how many so called seasoned professionals will blow it during the gateway question. They must answer correctly to move to the next step. It’s tempting to cut people a break because they almost got it, or because they were nervous. That’s not your problem, if they can’t answer the gateway they will definitely not be a star performer. You also don’t want to waste your team’s time during the next step with weak candidates.

It’s important that your team does a good job interviewing candidates. They must come prepared with an array of technical questions. If the candidate is able to wow your team then it’s likely they will be accepted by his peers. I’ve paired 2 senior architects together for my peer interviews. I’ve encouraged some healthy competition between the two by getting them each to prepare their own technical questions and taking turns grilling the candidate. This is a tough hurdle for your candidate, if they get over it you can be confident that they’ve got what it takes technically.

The last step is assessing fit. You must assess whether or not this person will fit into your team and your organization. Do you like them? Do you think you can work with them over the long term? These are all questions you need to answer. Don’t hold back, ask them tough questions about their failures and successes and what they want out of life. I always ask people what they do for fun. For some reason the best software developers also seem to be musicians. Above all else, trust your gut. If you are suspicious don’t be afraid to walk away from a candidate.

Your approach my vary, the key thing is that you approach it systematically, throw in some gateway questions along the way and trust your instincts.

Here are some resources that helped me along the way:

1. – This guy used to interview / recruit for amazon. This particular posting talks about some good phone screen/gateway questions.

2. – Some more phone screen tips.

3. Top Grading – My former mentor is using this recruiting system. He raves about it. If you don’t want to create your own, you may want to give it a try.