May 31 2011

CEO of You

I’ve worked for large companies and I’ve worked with small companies. There is a big difference in your day to day responsibilities when working in either of these environments. In a large company, you know your rank, your salary pay, and your place in the org chart. In a large company, you can predict product releases by the conference room schedule months in advance. I remember working on a project in a large organization and I wanted to add a boolean property to a single database table but the there was so much bureaucracy in place that that it took two meetings and the review of the local database expert who used his tenure to carve out a little fiefdom for himself.

It’s completely different in a small organization. In a startup, there is no room for bureaucracies, or org charts with more than two levels, or egos of experts but at the same time everyone is the CEO of something. In a company of less then 10 people, there is no room for middle managers, everyone has to manage themselves, everybody has to be a CEO of something. In such an organization, you may have to be the technical lead, the hiring manager, or the vice president of phone system, or directory of version control, as well as the senior technical writer, and even maintenance guy. In a small organization you have to do it all. In a small organization, when printer is stops functioning you are the printer expert. When the phone system stops functioning, you need to take the lead.

I’ve found that this approach also works for other aspects of life. There are people that wait for a scheduled meeting to to figure out what they need to do next, I like to get done.


May 24 2011

Manage Your Manager, Organize Your Organization

No matter what your position in an organization, no matter your title, or pay grade you often need to manage those you work with. Sometimes you need to manage your own manager, co-workers, and other resources. You might work with the boss that travels often and consistently sends you notes on features and requirements right after client demos. Maybe you may work with a project manager who keeps hand written half crossed out tasks scattered in a series of prints out. Worse yet, you work in a team that delegates work by forwarding and replying to essay length emails.

Highly effective development teams have a series of habits that they routine practice including using a version control system and bug tracking software. As an individual contributor, you also need to develop habits to help you team. Here is a short list of habits you can develop to help you succeed in a team environment.

  • Manage tasks in a single document.
  • Keep lists of work items.
  • Keep correspondence with other short and simple.
  • When email people about separate issues, separate issues in different bullets or different paragraphs.
  • When describing a problem, list possible causes and solutions.
  • Use screenshots and image editing software to help you illustrate your point.
  • Use screenshots and image editing software to help you illustrate your point.

There are a multiple tools to achieve this, you can use Outlook Tasks, Google Documents, Microsoft Project. An effective organization has every member using the best tools available to organize their tasks and those of the people around them. The key to success is to make it easy for yourself and those around you to achieve your goals.


Apr 17 2010

More Hats, More Problems

Software users didn’t take Knuth in college and you should not expect them to have a Computer Science degree to understand how to use your application. There is no worse assumption that a software programmer can make than to assume that end users know what you are talking about, especially when there is so much miscommunication involved in specifying, designing, implementing, testing, and releasing a software application within an internal team. Your users don’t understand your language, they don’t understand what you mean when you say object-oriented, exception handling, concatenated document, application server log file, null pointer, database query and they don’t care so don’t use these expressions in labels or descriptions in your UI! If you have to explain your User Interface to a end user, your are doing usability wrong. Forget leaky abstraction, there is nothing worse than leaky implementation details in your UI. If your users have to use suspended disbelief and take your word for it to understand how your User Interface works, you should go back to the drawing board.

One of the reasons why the User Interface and User Experience is so horrible in applications, especially internal and enterprise applications, is that they are done by programmers, usually prototyped quickly, and shipped soon thereafter. The truth is that programmers have to wear multiple hats, depending of your company size, these included tester, computer programmer, domain expert, UI designer, type editor, IT, security guru, database administrator, system architect, document writer, and more. In addition of having to fill all of these roles, there usually must be done in a tight deadline with many technology risks, unknown factors untested partners, and already late dependencies.

The simple fact is that the more hats a programmer wears the less productive he will be. If you have programmer having to manage your version control system, update your application UI, and debug memory you are not getting your monies worth. The more hats you have developers wear, the more time it will take to context switch, the more time you spend tracking down issues, and the more you pay in the end.