Wednesday, January 23, 2013

The Title "Software Architect" is Hooey, and Why I Still Became One

In September 2012, I left my role as a Software Engineer to work in the Architecture group of part of my company. I had my reservations, purely on the title alone. Based on my previous experiences with architects in other companies, I found them to be too far removed from the tactical needs of engineering. As such, they were generally long on vision, quick to make mandates, short on feedback from the development process, and hard to convince on anything. Speaking with friends who have worked in my company for a number of years, they had the same general impressions.

The reason I considered the position at all was mostly in the job description. The primary role is managing the Application Lifecycle Management initiative in a sector of the company. It was looking for someone who was knowledgeable about software development, enthusiastic about best practices, and had very good inter-personal and communication skills. In my development role, I, and a ramshackle group of my colleagues, were trying hard to push management and other teams to adopt some industry best practices. It was difficult, but we made enough headway to not be discouraged. This new role seemed like a golden opportunity to steer things at a much broader level. It also didn't seem like architecture, it was practice and program management, and it was certainly some evangelism role. It was enticing.

After speaking at length with the person I'd be replacing, as well as my future boss and my future colleagues, I found them to be the complete opposite of everything I had in mind. My future boss was very receptive to my ideas (in fact shared a lot of the same concerns I had for the company), and my future colleagues shared tales of trust and empowerment. That's it. I was sold (and if not, and I wanted to stay in the company, it was only a year anyway, not too long ;->).

It's been over four months in now, and it would be hard to say I regret my decision, or expected anything less of the role. I was most worried about not spending a significant portion of my time coding or doing things related to all-around software engineering; those worries came to complete fruition. To be fair, there was also an anticipated side-effect -- I now code and tinker around at home on personal projects far more than I ever did when it was my day-job (like the cobbler with the holes in his shoes). Management of an application and a program has been challenging. Context-switching is always occurring, but even then I'm learning to manage it a little better.

As a consequence of accepting the role, I picked up a number of books on project management, ALM, software development concepts, and a single book on software architecture. I should've read most of the books years ago, but never found the time. The one on being a software architect is all about the soft-skills, and really should be required reading for anyone in our community at any technical level. It's called 12 Essential Skills for Software Architects and I plan on writing a lot more about it over the next few weeks. I'm looking forward to finishing, so I can get more of a habit of writing here, and then maybe start reading some John le Carré.

No comments:

Post a Comment