Oct 4 2011

People Over Process

Processes are supposed to support people, not people support processes. A process should be documented in one document or checklist or directory or wiki or website that everyone has access to. Everyone should have a copy readily available. It should not be outlined in emails or sporadically over several documents across different locations. Always review the process and remove friction. Try to minimize steps when possible, centralize the information, anoint clear responsibilities, build in safety nets, empower developer to make decisions, let it grow as the team grows. Automate the process as much as you can, make reports people can use, make everyone’s progress visible. For some certain teams, there is diminishing returns for adding more processes.

Oct 1 2011

Team We

Even when I have been the sole developer in a class, interface, module, library, or feature I try to always report progress as “We.” For defects and issues it’s always easy to point out the fault and personalize the problem when it was caused by someone else. Avoid naming names or singling out an individual. Saying “Your broke this” doesn’t make you look better or solve the issue. Restate it as “This was broken by this change list you committed on this date while trying to resolve this other issue.” Don’t personalize blame or fault, and provide as much information as you can gather to better solve the issue. Don’t stop when you find something is broken, or when you find who broke it, find out why it was broken in the first place, and if at all possible suggest viable solutions.

A few days ago, a engineer called me over for some help. He immediately started making using accusatory language as if I had committed some crime. “There is a bug and you wrote this so you did it and you didn’t do it well because there is a bug.” He was pointing to 20 lines of code that I had written over a year ago in a much larger feature whose requirements had changed over time and because of his tone and desperation in his voice I could tell he was lost just dropped the anchor of blame wherever he could. I tried to get focus to the task at hand an not my code and asked a series of questions, what does the system do now? What should the system do? Does this always happen? What is unique when there is an error? Using this approach we found the issue in 10 minutes without staring down the code or focusing who wrote what method.

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.

Apr 14 2011

Keep is Short and Simple

No one has time to read long rambling text. One of the great things about Twitter is that it has a 140 character limit, it forces people to be concise, precise, to the point. It is so much easier to follow someone twitter than someones blog. This is also true for corporate communication. Within a team, the best way to ask short question is through instant messages such as Skype. The one draw back to instant messaging systems is that people expect instant responses. But for quick yes or no questions this is the best approach. More detailed questions can be escalated to email. But always be short and precise in emails. Always stay on point when emailing someone. If you are making multiple points separate them to their own bullets or paragraphs. Don’t intermix different ideas in the same paragraph. Always outline and simplify key points to one line bullet points. When asking for something, be clear as to what you are requesting or asking and always outline what you have tried, research, or done prior to asking.

Effective communication is a skill. There are tools, habits, and best practices that can help maximize the results of your team communication efforts. One of my most effective tool in communicating is to keep to the Three Sentences practice. One way to successfully achieve reply within three sentences is to never answer the same question twice, to refer to existing documentation, wiki sites, and other resources.

Sep 8 2009

Retweet August 2009

From time to time I just blast tweets about software development, project planning, team dynamics, or whatever else comes to mind. Here is a synopsis of recent tweets and rants. If you want to follow the conversation follow me at techknow and/or juixe and I’ll be sure to follow back.

Software Development

  • sudo gem install mixico; wishing sudo gem install vacation.
  • Version control tools need a better way to diff source history than just diffing two versions of a file…
  • If all bug defects are set to high priority, how are you to know, which one are really really really important ones?
  • I have 20 bugs marked a high priority, but some are higher than others. In addition to the having a priority and severity on defects we need color code too, ‘high pink’ is lower than ‘high crimson.’
  • Just remember, a two line fix can cost you a two hundred thousand dollar deal! Any code change to a production system must be tested.
  • LOL, getting a NullPointerException in a method called initNullValues.
  • Give me open source or give me piracy!
  • Let your users help drive the development of your product, not the accountants.

Team Leadership

  • Sometimes it seems that team meetings are anti-team building!
  • You can still compare apples to oranges, but it is harder to compare apples to some ill-perceived subjective metric.
  • Sometimes people tell you whatever you want to hear, because you are not listening to whatever they are trying to say.
  • People are crazy, and you getting upset about other people’s craziness, will make you crazy.
  • Not losing is not winning.
  • Take your competitors and make them your competitive advantage.

Product Placement

  • I don’t think Apple sponsored #iPhoneDevCamp 3, which is interesting because the iPhone dev camps generate a lot of business for Apple.
  • One feature implemented in many MS products is to restrict other features unless you upgrade from the home to the super business edition.
  • Why does Edible Arrangements require an answer to the following question ‘How did you hear about us?’ before I can place an order?
  • Finally figured out how to cancel @UsWeekly, just typical of a old media company their web site/design/usability makes absolutely no sense!
  • Facebook adds so many obstacles before you can follow someone… It’s like they don’t really want you to have friends.
  • Updating and adding new plugins on my WordPress bloggie! Plugins are like bling for blog!
  • You might have heard of ttyl, maybe of ttyn, but what about ttyat&t? ttyat&t: Talk To You if I get cell reception from AT&T.

Business Planning

  • When you have lemons don’t just make lemonade, make lemon cake too!
  • Having your mommy pay for your business plan is not a business plan.
  • Everyone has a million dollar idea, I have a billion dollar idea, care to invest?
  • Cash in your million dollar idea!
  • If content is king, then context is like emperor.