Tuesday, August 26, 2008

My Annual Review - Areas of Improvement

. Tuesday, August 26, 2008

In my first post, I tooted my own horn and talked about how awesome an engineer I am. Here are the areas of improvement that we identified. What's great about our performance reviews is that it's a conversation between the employee and his/her supervisors. I identified and shared some of my own weaknesses. It wasn't just my boss telling me, "Boo, you need to get your ass in gear." Not only do we identify our weaknesses, we come up with a plan on how to fix and improve upon those weaknesses.

One area that I need to improve in are control diagrams and sequences of operation. They are the detailed instructions that are programmed into the equipments' control panels. For example, if the temperature in a space is too hot/cold then these valves open/close, these dampers open/close, these fans turn on/off, etc. A lot of the controls that we do are tailored for each individual project and are not simply boiler plate instructions. I rely on SL and VP to help me do those. I have improved compared to last year, but I still need to continue to improve in that area. Improving with this controls and sequences just comes with time and experience.

In a similar vane, sometimes I get a little too wrapped up in the details of my project, start wandering off into the weeds a bit, and start to lose site of the big picture. Having well detailed and organized drawings are great, and I need to maintain that level of detail in my drawings and specs, but I need to keep my "eyes on the prize". Here's an example of what I mean. I might spend a lot of time figuring out the most efficient ductwork layout or call out all the various options and accessories I want to see specified on a piece of equipment, but if you asked me at that point how I planned on a certain system being operated, sometimes I can't give you a really complete answer. I guess it would be like writing a novel without figuring out what the story is going to be about. One thing that I started doing over the past year that should help in this area is writing a systems narrative. It explains in plain English how the systems operate and the many design assumptions I made. I originally started this to help me out managing my projects that were in construction. Sometimes it's well over a year between the time I design a project and when a question might come up in the field. By having this narrative handy, it helps me to remember "what the hell I was thinking" when the Contractor calls me up and asks "Why did you design this this way? Wouldn't it be better if you did it this way instead?"

The last area of improvement that we talked about was my ability to delegate. I like things done my way. That way I know it's done right. I am a very efficient worker (despite all the time I spend on Yada) and typically produce more work than my fellow coworkers. But with the size and quantity of projects that I am responsible for, I sometimes have our junior engineers helping me out. Because I am so wrapped up in the details (see above), I don't give as much thought as I should as to how to divide up the work. Only one person can work on a drawing at a time, so I can't layout ductwork if a coworker is drawing something else on that same drawing. The tasks that I assign don't have enough thought or logic behind them in regards to time management and overall project efficiency. Let's face it. It takes time to plan and that takes time away from me being "productive". But if I want to "move up the ladder" and take on more responsibilities, I need to do a better job in delegating my work. I see two keys in achieving this. First would be train the junior engineer I work with in "The Bunny Method". Every engineer likes things done a certain way. When the drawings are done, it should look like they were done by one person and not like a troop of monkeys. If the junior engineer understand how I like things done, it will minimize the amount of rework. The second, most important, and also most difficult thing is to teacher the junior engineers to take ownership of their work. Taking ownership is easier if you have a lot of time and effort invested in a project. The design phase for the projects I work on sometime last more than a year. These same projects may take well over a year to build as well. It's hard for anyone to take ownership of their work and give 100% all the time if they're only doing bits and pieces and helping out here and there. I need to teach them to see the forest for the trees as well.

In my final post, I will talk about my future career goals at Forest Animals A/E.


Friday's Child said...

Boo as far as teaching the junior engineers to take *ownership* of their work....is this the same approach as you forming a *team* relationship with them? I would think that if someone felt they were a part of a team, part of a bigger picture, that then perhaps they could see the light at the end of the tunnel.