Setting the Right Expectations

January 1st, 2011 § 0 comments § permalink

I had a conversation a while back with a good old friend, Sonal, about how awesome Modern Family is and catching up with each other’s lives. It sparked a reason for me to share something that has been on my mind for quite some time, but could not figure out how to organize my thoughts. With a little discussion with her and some time to sound type out my thoughts, here is the breakdown:

  1. Learning when to say, “no”
  2. Learning how to say, “no”
  3. Learning how to get them to say, “no,” even before you do

Over the past six months, I’ve been learning a lot about setting the right expectations within the development team, with coworkers, and how it affects our customers.

The Dark Past

As discussed in my previous post, we weren’t (until recently) in a position to make decisions to have a positive impact in our daily development lives. We knew about the “fire-of-the-day” that we had to take care of while interrupting our current work and just had to buffer enough time to make sure we got things done in time and sacrificing quality. Readjusting the project plan, timelines, priorities, and resources wasn’t a part of our process.

Something had to change.

Saying, “NO”

1. Learning when to say, “no”

I can’t remember the exact moment I started saying no, but can remember an incident that kind of shocked a coworker who wanted something done. It wasn’t because I didn’t want to work on it, I just had way too many other things on my plate and over-promising would end up burning me out or under-delivering. I just kept it simple and said, “no.”

2. Learning how to say, “no”

Saying “no” is kind of rough and a little pessimistic, so I’ve learned to defer work. There was a request to fix the Partner listing because one of the descriptions is wrong. The application based the list on an Excel sheet I was provided, so the only way it could be wrong is if someone gave me wrong information to display. It wouldn’t take long, but it would interrupt my current stream of thought if I worked on it immediately. I put the request in a list for me to do later.

I really didn’t say no directly, but I did learn that I could say no for the moment and defer the work to do later. Rather than dropping everything to put out the fire, I just made sure we were all aware of the other issues at hand and I would get to it later.

3. Learning how to get them to say, “no,” even before you do

There are two ways I’ve been able to do this. First, is to get you to prove to upper management that your task is more important that what I have to work on. The second way is for me to just point to my Kanban board and ask where the trade off can most effectively ensure no interruption to a previously promised delivery.

Usually the fire-of-the-day task isn’t important enough to bother upper management with the question, so they’re happy with just creating a ticket, assigning to me, and holding the responsibility of bringing up the task at the next iteration meeting.

Now, most of the time, I’m approached not whether to decided if a task can be done, but instead if the ticket someone created makes enough sense for me to look at later on. That is ultimately amazing!

A Brighter Today

There has been a complete 180 from what we were earlier this year and today. Significant enough that people open to change and progressive ideas like Jason Fried‘s no-talk-Thursdays (our are Tuesday and Thursday 8am-11am) which makes our development team very productive which and in the end it helps keeps the Sales/Marketing team honest.

The best part about making sure everyone is on the same page is the positive impact on customers. It gives potential/current customers a good time frame for features/bugs to be delivered and our close partners a good time frame for future products not yet on the market.

My FIRST Production Release!

June 24th, 2006 § 0 comments § permalink

This is my first ‘real’ project and just went into production* this morning. The only code issue we ran into was a file. There’s a big difference between how it handles forward slashes (“/”) and backward slashes (“\”).

<param name=”File” value=”E:\WAS_Logs\projectName\treasury.log”>
<param name=”File” value=”E:/WAS_Logs/projectName/treasury.log”>

The first is wrong. the \W, \I, and \t (tab) was completely ignored by log4j. The second is how it should be done!

Why did this happen? I was copying and pasting file path from Windows Explorer. IT ALWAYS USES A BACKSLASH! Not to blame it; I simply should have been more careful.

*production: real world, real users, real life.

Bundles of Fun.

March 3rd, 2006 § 0 comments § permalink

[1] Interviewing is Awesome.
Watching how people are on the other side of the interviewing table really opens your eyes. There are those who blow you away and others who you wish you could take to side and prepare them. Some people say “people skills” are something we are born with. I completely disagree. No matter what, it’s still a skill and everyone should work on it, but some just haven’t had the chance. To those who are quiet, un-engaging, and give two sentence answers in interviews, please go practice. To those who ramble on-and-on-and-on-and-on, do the same. Whether it’s to a friend, professor, mentor, or (I think is the best) your career counselor.

[2] Cougars Kill Owls.
The red sea. Coogs. UH. Whatever you want to call us, we beat Rice: 74-71. It was an awesome game. I had a roller coaster of emotions. Thanks to all those who came out to support: Sohel, Vikram, Long, Dustin, Luke, and the other ~7000 coogs! And yes, I still use my student ID to get in free. Better yet, we got 2 free hotdogs, 1 bag of chips, 3 shirts, and a FREE ride back to the car (thanks Long!).

[3] FINALLY, got project working (lessons learned).
After almost 2 weeks of struggling to get a stable copy of the application, it took only about 2 more to get it setup. First I tried WSAD, then I tried Eclipse…to my pleasing with success! Sometimes free is better than paying. Wait, I’m kidding myself. Free is always better.

Lesson 1: Position titles mean nothing if you don’t do what your position says.
Lesson 2: Being too busy to produce effective documentation makes things harder for the new guy. In this case, ME.
Lesson 3: If you don’t know what you’re talking about, shut your mouth.
Lesson 4: Micromanagement is good and bad depending on the circumstances. Long-term micromanagement is always bad.
Lesson 5: Understand the co-worker. Some come from completely different backgrounds.
Lesson 6: 13 really is a bad luck number.

[4] Articles and Blogs Galore.
a. Transformers are back!
b. Art History helps. I’d never care about this article without it.
c. Bird Flu? Psshh…we cook it until we KILL the flu.
d. If you have this poster, email me. I’ll buy it.

Get Your OWN Domain.

January 20th, 2006 § 3 comments § permalink

Also, make sure you OWN the domain as well. I’m in Dallas working on a project with my previous employer for a few days. We just encountered some crazy things this morning on domain name ownership and expiration, yes…expiration.

Company [A]: Us, the current developers. We do the magic.
Company [B]: Them, the clients. They have the deep pockets.
Company [C]: Old developers. They don’t do the magic.
Company [D]: Domain name guys. They do what their title says.

Here’s the deal: A few months ago, [B] told [C] to renew their domain account. [A] found out around 3 AM this morning that the domain for [B] expired while he was working. (Yes, [A] works many hours, sleeping but a handful of hours a day.) [A] contacts [C] about the issue and calls up [D] to find they are on the west coast and have office hours starting at 9 AM, PST. [A] is still waiting for a response.

Lesson learned? If you’re working on a project, either as a developer or client, own your own domain. Make sure you get the clients to understand why this is important to avoid the above situation. It may be trivial to some, but make sure you OWN your domain!

Where Am I?

You are currently browsing entries tagged with lesson learned at thomas nguyen.