Enter your email address:

Delivered by FeedBurner

How does an Architect pack?

Today we are packing for the big move. Quick Solutions is moving to some new swanky office space, with an awesome new delivery center. The new center has wall to wall whiteboards, network projectors for group programming (pair programming is so 20th century), a game room, new open seating (shared workspace is the key to productivity), and lots of other new goodies. It is an amazing investment by the company, and shows their commitment to building the best team on the block.

As we are packing, we started joking around (not that joking around is rare, and would have occurred regardless of the packing state). How does and architect pack? An architect doesn't pack anymore. He did that ten years ago. He goes to plenty of packing conferences, and has read a lot of books on packing. An architect will map out how the whole enterprise should pack, and even dictate what (clearly out of date) packing supplies and processes should be used. These processes will be the perfect match for some scenarios, but not all, but will ruthlessly be applied to all anyway. The architect will require team reviews of the packed boxes, and find ways you could have done it better (without regard to time or resources). He will spend months developing gigantic packing diagrams, and box flow-steams using the latest UML tools. All of which will be out of date before they are ever published.

All in jest of course.

Link back here with your response:

  • Alexei, how does a TFS geek pack?
  • Jim Holmes, how does a tools nerd pack?
  • Bruce, how does a data architect pack?
  • Monish/Arnulfo, how does a BizTalk guy pack?
  • Wingfield, how does an ajax guy pack?
  • Jeff, how does a siliverlight guy pack?
  • Phil, how does a MOSS guy pack?
  • Randall Drum, how does a PM pack?
  • Steve Harman, how does a framework guy pack?
  • How does an open source guy pack?
  • Josh, how does a Web 2.0 guy pack?
  • Bender, how does a WCF'er pack?


I don't often explicitly state that I work for Quick Solutions when I post to my blog. Others that work with me talk about QSI all the time. I do this because I want the articles to be what 'I' have to say about technology, not what QSI has to say.

I started working for QSI in June of 2003. I was about to start my own consulting company, and they asked me to come in to help them start their solutions business (having built a high quality technical staffing business). I thought, why not? Getting to build what I want to build on someone else's dime definitely reduces my personal risk, and if it didn't work out, I could just pick back up the 'start my own company' thing.

Nearly five years have passed, and we have built a great team. A team that is considered one of the leading development shops in our region. Each, and EVERY person on this team would be considered a rock star at any company. We have a great culture for the team, and a deep seated ownership culture across the whole company. We really do own the company.

This is the best company I have ever worked for, and I truly love working for Quick. The ownership/business culture, the commitment to the people, and to the community is what sets Quick apart.

But...I have always wanted (since I was 13) to work for Microsoft. I was a boy, sitting in the hallway of my school, waiting for my dad to pick me up. I used to stay after school every day to use THE computer at the school to code (which I started when I was 10). While I waited for my dad, I read the MS-Dos manual (amongst other manuals and books that I could scrounge up). That day I decided I wanted to work for Microsoft. This was before I even knew 'computers' could be your job or career, or that I ever thought of college, or that I would ever even leave my hometown.

Recently I just accepted my dream job, as an Architect Evangelist at Microsoft (for the Heartland District). It was very hard to leave QSI. I love the team, and what we have worked so hard to build over these past years.

This will also be the first time for me that a new job will truly be a new job. All of the jobs in the past have been very similar in nature; leading a dev team or IT department.

Here are some words of wisdom I hope is remembered as I leave:

0 : Starting lists with zero is geek-cool. It confuses humans though.

1 : Don't be a plumber. Leverage frameworks from other smart people.

10 : Do more of what works, and do less of what doesn't.

11 : Focus on helping the user kick ass.

100 : Don't think like an owner. Don't act like an owner. Be an owner.

101 : Perception is reality.

110 : Feel. Felt. Found.

111 : Passion. Learning. Problem Solving.

1000 : Eat like a bird, and poop like an elephant.

1001 : Don't ever let the bozo's grind you down.

1010 : Always tell the truth, so you don't have to remember what you said to whom.

1011 : Invest in the community.

1100 : Architecture is about balance.

1101 : The effort is the effort is the effort.

1111 : Don't play BioShock in the dark.

10000 : Put staff first. Before the company and before clients. When you do this, they will feel empowered to put the client and the company first.

10001 : Humans do have value. You just have to find the right ones, and assign them the right delegate.

10010 : Project management isn't about spreadsheets or plans. It's about communication.

10011 : work together, play together.

Ok, I have a million more. :)

I wish luck to my team at QSI, I know you guys will go further than we have ever dreamed. And I expect to stay in touch.

On to a new adventure!