Category Archives : Leadership and Management
Lessons from Batman: Virtual Teams 1
![]() |
Batman can teach us many things: persistence, preparedness, and a mean jump kick. It came as a bit of a surprise when I realized he also exhibited some necessary elements of participating in a virtual (remote) team! Batman may fight crime alone but he definitely does not work completely singlehanded.I have been working with a virtual (remote) team at Epiphany for more than 7 years; managing for more than 4. Over that time I have fluctuated between believing that a virtual environment was an unconquerable obstacle to the greatest idea since batarangs. I have settled into the belief that, like most systems, there are strong points and weak areas that need to be considered. |
1. Reachable |
|
---|---|
![]() |
Batman does not have a public phone number; but there is a well-known failsafe way to reach him – The Bat Signal. While the system sprung up organically, Batman always responds to the Bat-Signal; ensuring that he can be reached anytime (or at least on cloudy nights). Working remotely can be a very isolating endeavor, for many people it is ‘Out of sight, out of mind’. Remember you aren’t locked in ‘Arkham Asylum’! You should feel comfortable reaching out to colleges, and also be available and reachable yourself. Regardless if the topic is work related or simply personal, the team should know you are around and can be signaled into action. You may not be able to respond immediately; but strive to respond when you can. |
2. Consistent Schedule
|
|
---|---|
![]() |
Same Bat-Time, Same Bat-Channel. Batman knows that some consistent meetings can drastically help to ensure teams grow; this counts double for virtual teams. You can bet Batman doesn’t skip his workout, along a similar vein you should not skip team meetings. I have found that a daily team meeting is critical to ensure a cohesive team in a virtual environment. This ensures there is a set time for the team to get together and discuss issues and current project statuses. It also helps ensure that there is some outside contact for each person, it is all too easy to realize that an entire workday was spent working alone. While those workdays can be productive, if there are an increasing number it can wear down even the most resilient of people. |
10 Software Development Myths 3
1. Adding developers to a late project will get the project back on schedule. |
|
---|---|
![]() |
This is a very common and intuitive response to a schedule slip in a project. Surprisingly after additional manpower is added the project actually slips later. Brooks’ Law is often cited to refute the common myth; stating ‘adding manpower to a late software project makes it later’ (Fred Brooks – The Mythical Man-Month). While an oversimplification, it is a good rule of thumb. The counter-intuitive result of a later project is due to the increase in necessary communication between the team; which increases exponentially as additional people are added to a team. |
How I ended up conducting the most successful technical interviews with a single question 3
How I ended up conducting the most successful technical interviews with a single question
i conducted my first tech interview in 2008. at that time, the company already had a working process that i followed: interviews were 1 hour. the candidates would have 30 minutes to answer a 15 questions quiz. then we would spend 15 minutes talking about their answers plus an additional 15 minutes answering questions about the job. i quickly realized how terrible that questionnaire was.
An interesting article for me; since I believe I started interviewing roughly the same time. We took similar paths (but I did not attempt to automate the process); migrating from some technical questions to a much more open ended process.
I recall one particularly rough interview; where after I started into my 10 technical questions the candidate quickly grew agitated. A agitated interviewee was a wholly new experience for me; I felt the blood drain from my face as he yelled, “I WON’T TAKE A TEST!” over the phone. Trying to regain my composure and calm him down; I let him know there was no score or grade. The questions are really discussion points to see how you code and design. The statement did little to soothe him; as I only heard a louder, “I WON’T TAKE A TEST!” in response. I decided at this point he was not a good cultural fit and started to bring the interview to a close. My salutation of “I appreciate your time and am sorry if I offended you. If you have any other questions for me, please ask.” was met with a quick “Click” and dial tone. Needless to say; this did spark a review of my interview process.
While the author coalesces on a single question, I have left mine at two:
- What has been your favorite project to build and what challenges did you face during the development?
- In your opinion what has been the most interesting bug you have had to locate and squash?
The follow up discussions on these questions easily leads into some technical questions on the language they used and which design patterns they implemented. More importantly it allows you to see which areas of software they are most passionate and interested in. Finding great talent and putting them into an environment where they can flourish will ensure excellent results. Switching to this open ended format took me from around a 20% success rate (ouch) to more than 80%; which have failed due to reasons other than technical prowess.
Looking back at the interview experience I touched on earlier; how much different could it have gone if I had asked my 2 questions and delved deeper into a subject near to them.