Brooke Baldwin

When I moved away from New York a year ago the most important thing to me was to get away from the break neck pace of the city. After 8 years I had enough of the Big Apple and it had enough of me. The energy that makes it such an exciting city sets a tempo that becomes exhausting. While that same pace fueled my drive, competitiveness, and career it also fueled my neurosis, obsessive behaviors, and stress level.

It all makes me wonder: was New York my chemotherapy?

I don’t think that I was sick in the first place, but NYC did act as an agent of fundamental, even cellular, change in me. It has altered my chemistry forever, for the better. It’s the kind of place that does that, it changes people.

And now it’s been a year of my life spent in the Bluegrass State. I’m leaving the job that I’ve been working at for the past year, a good decision on many levels.  Quiet and slow were good as a reaction to NYC but now I need more.  Just not more chemo.

No Comments »

Almost one year has passed since I left the Big Apple in search of a different lifestyle and so far it has exceeded and at the same time not met my expectations.

What I did not anticipate was the ease with which I would adjust to the life of a boring worker drone. This has been a year to slow down and re-center myself, to build up reserves (of a sort), and to take stock of my life.

Here’s what I have learned: it’s harder to make friends when everyone is married with children and I am not and it’s easier to save money when everything costs less. That’s about all I have learned. All the other lessons in the past 11 months have been reaffirmations of things I already knew: good people and friends are hard to come by, my instincts are usually right and should be trusted, and being outside in the fresh air is the best therapy.

Moving to Louisville has given me a place to stop and slow down for awhile, a place to enjoy the pace of an almost-southern city. And living here has shown me how good I had it in New York. New York was a place with a lot of friends, a lot of opportunity, and a lot of stress - while Louisville is the opposite.

No Comments »

On every project I have ever worked on there comes a time where deliverables must be transitioned from one team to another. Each time I go through it I seem to learn something new about how to make the next one better.

Here are a few simple guidelines to get your project on the right path:

1) The different teams should meet at the beginning of a project and discuss what deliverables will be received and what they look like. This means bringing hard copies of samples or old deliverables for people to point to when talking though what will be included in a functional specificiation.

Often these conversations happen in a vacuum, so by providing samples at an early stage the teams can negotiate what should be included.

2) Help people prepare to learn. What I like to do is send out the documents (or make them available for reading in a software application) a couple of days before the walk-though is scheduled.

Not everyone is going to read the documents before the meeting, but I can guarantee that people waiting for those deliverables will tear into them as soon as they are received.
3) Use warm hand-offs. By that I mean take the time to communicate the intent of a deliverable to the receivers. Generally use cases, workflows, functional specs, and any supporting user interface materials will take a few hours to present. Though I rarely see these anymore, if your team is using a waterfall type development cycle the meetings might last several days.

But for typical iterative development where you have items passed off by review sets you can get through one review set in a couple of hours.

The presenter should be able to speak in plain English language about what the system is supposed to be doing when they describe functionality. While some of the tangential conversations will likely turn more technical it is good to be very plain in communicating what the application needs to accomplish.

4) Use the transition meetings as a place to work collaboratively and be prepared to change the deliverables based on the outcome of those meetings. Often the combined perspectives of business analysis, development, architecture, and QA will illuminate questions, issues, or problems that were undiscovered previously.

5) And always review, review, review (and spellcheck!) your deliverables before they are submitted to another team. Something will always get through that isn’t correct, but your team will avoid loosing credibility if the documents are as tight as you can make them.

Once the deliverables are transitioned fully, which can take up to a week with cleaning up the documents from the hand-off meeting, any additional changes should enter into a change management process that we’ll talk about another time.

No Comments »