Archive for the ‘Management’ Category

Fill in the Gaps

Monday, September 28th, 2009

Suppose your boss were to approach you one day and inform you that they were looking to hire another technical staff member for the team and he wanted you to outline the skills required for the position.  The specific requirements and position would be left entirely up to your discretion.

What would you do?

Most developers would immediately specify a development position (we always have more software to write).  They would then proceed to gather up all the technologies, processes, knowledge and skills currently in use (including domain knowledge), and list those as the requirements for the new position.  Most testers would immediately specify a test position (we never have enough testers to go around).  They would gather up all the different testing methodologies and techniques being used, add a heavy dose of domain specific knowledge and list those as required skills.

In the end, the new staff member will likely become a useful contributor to the team, things might even get finished faster, but it is unlikely they will make the project meaningfully better.

Now, imagine instead that you are working on a puzzle.  The puzzle has a lot of the pieces already filled in and the picture is beginning to take shape.  When you go to add a piece to the puzzle do you start by looking for a copy of an existing piece?  Or do you look for a piece that can fit into one of the gaps?  The answer is obvious.  You might use the existing pieces to refine and differentiate the piece, but it would be counterproductive to look for a copy of a specific piece.

Obviously, comparing a software development team to a puzzle is simplistic.  At the same time, if you want to add a person to the team that will make a meaningful improvement to the overall project, you will be better served to look at what is missing, as opposed to what you have.  If your team already has a top-notch tester, but no one with domain experience, look to hire a domain expert.  If your development team needs a database guru, don’t worry about whether the guru knows C#.  Your team can teach him or her C#.  You can teach them how to test.  What you can’t teach is what you don’t know.  So if you are missing some skill or knowledge, go and find someone with that skill or knowledge.  If they happen to already have some of the other specific skills your project needs, great.  Just don’t focus on those because your team can teach those skills.  Focus on filling in your gaps, and keep looking for new gaps to fill.  If you are going to risk hiring a new person, why not look to maximize the potential gain for everyone involved?

Posted in Management | Comments Off

Opening Doors

Tuesday, May 5th, 2009

Imagine that you have a pressing need to hire a top-notch software developer.  You contact all your friends and colleagues to put out the word.  You call up a couple of recruiters and put an ad on a couple of websites.  You canvas some relevant conferences.

Soon you have a pile of resumes.  Depending on your company and how much advertising you’ve done, you might have thousands of resumes.  So you sit down to run through them, rapidly discarding the vast majority until you find one with those magical three words, “Open Source Experience”.  BAM.  Search over, move on, right?

Looking around the web, it seems accepted that job seekers should participate in open-source projects because it will help them get a job.  The theory is that by participating, you make a portfolio of your work available to any prospective employer, so they can verify your technical aptitude.  It also seems to be the prevailing wisdom that only the “best of the best” participate in open-source projects (as it is supposed to be a meritocracy).

While I can’t speak to the general quality of open-source developers versus the average developer, I can speak to the value of an employer being able to look at your portfolio of work.  While I am certainly not the first person to suggest this, it bears repeating so that people do not fall into the trap of placing too much value on it.

I will not review your work on an open source project.

Having source code available bears no relevance to the hiring process.  Remember that I have thousands of resumes.  Most of the time I won’t even read the entire RESUME, much less go look at the source control history of some open-source project on the web to determine what code is yours and evaluate it. 

I am interested in your experience.  Whether you gave the code away or not generally does not matter as much as whether the code you wrote is relevant to the position I am hiring for, and I should be able to determine that from your resume.

I might check to verify that you actually committed code to the stated project.  I might even go so far as to see what parts you worked on.  But that is no different than me calling up a former employer to verify that you worked there.  By the time I do these things, I’m already interested in hiring you.  I’ve probably already interviewed you and determined you are a good fit for the position. 

If I want to see what kind of code you write, I’ll ask you to write some code as part of the interview, and if I ask you to write some code, you can bet I’ll ask the other candidates to solve the same problem.  This way I can compare and contrast everyone’s strengths and weaknesses from a common starting point.

So, essentially, my advice on whether to contribute to open-source projects is this.  If you want to contribute to open-source projects, please do so.  The networking and development skills you gain will be invaluable in finding a job.  The best way to become good at something is to practice, so learn how to read code, learn to fix bugs, develop new features, respond to complaints.  All these things are valuable skills you can gain by working on open-source projects.

Just don’t expect your open-source experience to magically open any doors for you.  Proprietary-source developers are all learning the same thing.  You still need to demonstrate all the same intangible qualities and experience that companies look for to set a candidate apart.  If you can’t even be bothered to show me why you would be a good candidate, why should I be bothered to find out if you are or not?

Posted in General, Management | Comments Off

Performance Reviews

Monday, May 4th, 2009

Its that time of year again.  The time when employees everywhere are forced to justify their existence to management, and talk about all the great things they have done for the company.  So, in honor of the occasion (and since I’m still recovering from my whirlwind few weeks of travel), I want to point you to this commentary on performance reviews.  Even after all these years (it was first published in 1993), the accuracy of the commentary still hits home.

So, here’s to another day spent filling out useless forms and identifying “accomplishments” suitable for presenting my work in the appropriate context to upper management, and for everyone else going through the same charade, good luck.

Posted in General, Management | Comments Off

Standing out in a Crowd

Monday, April 13th, 2009

How many of you have ever commented on a manager’s lack of technical ability and/or knowledge?  I’d wager that most of us have been astonished at least once in our careers by the technical incompetence of someone in charge of a technical project.  A manager who doesn’t understand what “compile” means, who can’t grasp the concept of “automated testing”.  Someone who doesn’t understand the domain of their employees.

It is difficult to work for someone like that.  It can be difficult trusting their judgment when you know that they can’t grasp the simplest functions of your day-to-day job.  Now, before you think this is another internet rant about clueless managers, let me ask you a question:

Can you have a conversation with your customers in their domain? 

If you write financial software, can you sit down and talk with the financial analysts who use their software, without requiring the use of a “domain expert” to translate for you?  If you can’t, you should consider learning how. 

Too often we focus on learning our domain.  We learn all the neat tricks in our chosen language.  We become experts in the quirks of automated memory management.  We learn about the differences between allocating on the stack versus on the heap.

Honestly though, when was the last time a successful release hinged on some arcane development trick that only 10 people in the world know about?

Every software release hinges on the ability of that software to solve some pressing need of its customers.  And unless you are selling software and services to other software developers, those customers do not care about the software development domain.  They care about the financial services domain.  They care about the medical domain.  They care about the cellular phone domain.

Become a domain expert.  Learn to talk to your customers so you can anticipate their needs before they do.  Don’t be content to be just an expert developer, strive to be more, so that the next time a customer calls you, you don’t become that clueless manager, asking what exactly it means to compile your software.

Posted in Best Practices, Development, General, Management | Comments Off

Adventures in Remoting – Part 2

Wednesday, April 8th, 2009

In my last post I covered some of the lessons I have learned during my time spent telecommuting.? Today, I want to focus on some of the things my team has learned dealing with a remote version of me.

Integrating Remote Employees

  • Communicate, communicate, communicate.
    • Sound familiar?? If you think your team is communicating enough to the remote employee, you aren’t.
  • Have the employee start in the office.
    • The team needs to time to integrate a new member, and that is best accomplished locally.? Before an employee is allowed to telecommute full time, they should be required to work locally for at least a month so that everyone can meet and learn to work together without the additional burden of being remote.
  • Video-conferencing works when travel doesn’t.
    • Obviously, it would be preferable to have the employee local for meetings and so forth, but that can be prohibitively expense and time-consuming.? Install and use a reliable video-conferencing system, along with virtual white-boards and any other program that can make the meeting virtual.
  • Ad-hoc is not a process.
    • Dealing with place- and/or time-shifted employees amplifies any and all randomness in your process.? If your build is not automated, it will break.? If your code is not controlled, it will be lost.? If your tasks are not prioritized, your release will be late or won’t have needed functionality.? Your process must be able to handle the absence of hallway conversations.? If there is ambiguity or if it is too onerous, it will not work.? Be prepared to tweak, modify, and retool your process to meet your needs.
  • Define roles and responsibilities up front.
    • Without a clear delineation of who does what, there will inevitably be duplication of effort.? This is amplified when a remote employee may not discover the duplication until several days later.
  • Take every opportunity to include the remote employee.
    • Remote employees are just as important to your team as your local employees, so include them in everything.? If the team is celebrating a milestone, ask your remote employees to attend.? Cover their time and costs.? Treat them as if they are local and offer them the same opportunities the rest of the team has.

Obviously, this is not a complete list, but I have found that when my team observes these simple points, the whole experience improves.? When one is missing, the experience quickly devolves into unpleasantness for everyone.

Posted in Best Practices, General, Management | Comments Off

Adventures in Remoting – Part 1

Tuesday, April 7th, 2009

In my day job, I have one of the perks that many folks dream of – I telecommute full time.? Working remotely (I am not even in the same time zone as the main team) requires a level of discipline from both the remote members and the overall team that most groups are not prepared for.? These are some of the things I have learned.

Working Remotely

  • Communication, communication, communication.?
    • If you think you are communicating the right amount, you are not sharing enough.
  • Who pushes you to excel??
    • You have to learn to work and be productive through the periods when you might have other distractions or the rest of the team may not have enough work to occupy you.? You need to be able to help the team towards your goal even when the team may not know what to do next.
  • Work space vs. personal space.?
    • This is not just the standard “have a private room with a door you can shut” advice.? Use a separate work-only laptop.? Log into a work computer remotely via VPN.? Create a virtual machine that contains your work configuration.? When you are telecommuting, you should be working on the same configuration as if you were in the office.? This improves compatibility with the rest of your team, and helps reduce the temptation to play just one more round of solitaire.
  • Manage your career.
    • Telecommuting full-time means that you do not have as much of an opportunity to build contacts and the relationships that are necessary to excel in your career.? This means you must focus that much more on managing and building those professional relationships.? Try to make travel on-site as often as possible to remind the team that you are an actual person.? Join professional groups and attend conferences.? Make yourself indispensable.? Work with your manager to develop a plan and make sure that you follow through.? Update frequently with your manager to ensure he/she is doing the same and nothing has changed.
  • Attack problems when they occur.
    • If something is wrong or bothering you, attack the problem head on.? Do not rely on someone else to notice and fix the problem because no one will.? Learn to deal with people in a straightforward, honest manner and learn to accept criticism.?
  • Prepare for change.
    • Unless you and your team has an established history of telecommuting, there will be growing pains which necessitates change on both sides.? Processes and roles will be updated and modified.? Privileges will be added and removed.? The organizational structure of the team will change.? Be proactive in making these changes, even if you do not know exactly what to do.? Experiment and admit failure if it doesn’t work out.? There is no set of magic rules and processes that will work for every team and every situation, so commit to finding those roles and procedure that work for you.

I can’t admit to always following all of these items, but I have found that when I do adhere to these lessons, things tend to go much smoother.

Posted in Best Practices, General, Management | Comments Off

Removing distractions and building relationships

Thursday, March 19th, 2009

I've been thinking a lot about management lately.? After a long stint working my way up the management ladder, I am now back “in the trenches”.? This has given me an opportunity to assess other management styles from the point of view of an employee, while also being able to evaluate it based on my own knowledge and experience.

Scott Berkun wrote that as a manger your “relationship with your programmers is everything”.? I like this statement.? You often hear that a manager's job is to protect the programmers from everything else so they can do their job.? Frankly, I find that position rather annoying.

Some programmers need and want to be sheltered in that manner.? They want to be left alone to create their next great class.? They don't care whether the customers like the software or that they customer can't use it because it is too slow.? That is someone else's problem.? For these developers, having a manager that hides all that messiness is a blessing.

Other programmers love to work in that environment.? They want to know the details.? They want to know how what they do fits into the overall plan.? If their manager were to make them simply work on their code without an understanding of the larger context, they would go nuts.

Still other programmers want to move beyond simply programming into leadership positions.? They want to be on the front lines, interacting with customers and clients, making the decisions that affect the direction of the project.? Their manager has to work with these folks and give them opportunities to learn and demonstrate that leadership abilities.

The moral here is that every employee is different.? They all want different things, and to simply say that a manager should block any distractions from the developer's job is dumping everyone into the same category.? Instead, as a manager you have to learn what it is your team needs, and give them that.? It will be de different for every person, and sometimes you won't be able to give them what they want.? But your relationship with them lets you accomplish your goals, while helping them accomplish theirs.

Posted in Development, Management | Comments Off