October 21, 2011

Refreshing Change

Our local Ruby Meetup lost it's meeting place at the last minute this week and we ended up combining with the Sacramento Web Standards Group at the The Urban Hive.

I heard a well-prepared talk from Mark Aplet and Andy Ford on the topic of Responsive Web Design. It definitely fell outside my normal discussion topics -- like Ruby, Rails, TDD, etc. I felt strangely invigorated and refreshed when I left.

That feeling caused me to reflect on the Pragmatic Thinking And Learning book by Andy Hunt I've been reading. He points out that change stirs creativity.

Part of it was the space: Urban Hive oozes creativity.
Part of it was the topic: I have a huge appreciation for beautiful things, especially web apps.
Part of it was the people: front-end developers and designers are just different enough from programmers. They dress differently, speak differently, use different tools, think differently about problems. And yet they do work so very closely related to traditional developers. It upsets something in my brain in a good way.

I should get out more.

Slow Down To Go Fast

Note to self: when I feel overwhelmed with workload I need to return to the basics. Going fast is a matter first of efficiency. Remove wasted effort.

Under tremendous pressure, there is a very real risk I fixate on the volume of work and, as a result, freeze. How do I resolve the deadlock? Slow down.

Being a knowledge worker that means:
  1. Collect
  2. Plan
  3. Do what I can't delegate
Now, back to work.

January 9, 2011

Following My Own Advice

As I've recently transitioned from my consulting life to managing a software-as-a-service (SaaS) team as an employee I find myself working hard to follow my own advice. As a consultant I had the opportunity to observe and advise. The implementation typically fell to my clients.

Now I am my own client, in a way, and the advice I gave in the past still applies.

Two principles come to mind after a week on my new job: 1) leaders drive cultural norms and 2) improvements are best made as small, incremental changes.

Cultural norms reflect the reality of what life looks like on your development team. Would a developer hack a file in production and leave it there? How long does it take to notice a broken build? Is untested code OK? Your team communicates the answers to these questions every day they work. The leader in the team implicitly approves and disapproves of individual behaviors by his/her responses. A capable leader explicitly trains, gives feedback, encourages and makes room for the team members to do the right thing. The leader shapes the cultural norms. I ask myself, "what cultural norms am I driving in my team?"

Balancing the training, feedback, encouragement and overall change is the need to perform all these activities without alienating people. These are people, after all. Rapid, forceful, massive change has it's place but it's disruptive, destructive even, at times. I want gradual, sustainable, incremental change so that I can guide my team towards more effectiveness without alienating my teammates in the process. I ask myself, "what change would help my team gain the most effectiveness and what is the next step toward effecting that change?"

So now I give myself a new principle to apply: integrity is following your own advice.