Thursday, July 31, 2014

Applied Architecture Patterns on the Microsoft Platform, Second Edition


The book that I have been working on for the last year, with Andre Dovgal and Dmitri Olechko, has been published and is now available for purchase on Amazon Applied Architecture Patterns on the Microsoft Platform, Second Edition, published by Packt Publishing, builds upon the framework that was presented in the first edition and includes new chapters on recent Microsoft technologies, including .NET 4.5, SQL Server and SharePoint.

The book is aimed at software architects, developers and consultants working with the Microsoft Platform, who want to extend their knowledge of the technologies that make up said platform, and learn how those technologies can be composed into complex systems.

I decided to contribute to this book because of how useful I found the first edition. Hopefully this updated version will be as useful to those who read it.

Thursday, July 10, 2014

Everyone Jumps, Everyone Fights

I have been in a lot of interviews recently and the topic of my leadership style has come up in many of them. My 20-year career has given me numerous opportunities to observe a wide spectrum of leadership styles, some very effective, and others not so much. My own leadership style has percolated from the styles of the aforementioned leaders, and more specifically from the philosophies, practices and techniques that I have seen be consistently successful. Though most are self-evident I think they are worth writing about, and I will do so in a number of posts.

My informal study of leadership began while I was serving in the South African Defense Force with 1 Parachute Battalion, then part of the 44 Parachute Brigade. In airborne units typically everyone jumps, and everyone fights; everyone from the private working in the mess to the commanding officer is jump-qualified and is trained for active combat. The commanding officer while I was at 1 Parachute Battalion was Colonel J.R. Hills. Colonel Hills was a seasoned and decorated veteran of the Angolan Bush War, and was easily one of the most capable soldiers in a unit of highly capable warriors. He without exception commanded the respect and loyalty of every member of the unit, by demonstrating time and again that he was a leader who not only could jump and fight, but who would lead from the front.

Being in the Infantry, airborne or otherwise, means that your skill as a soldier is primarily predicated on your endurance. An infantryman needs to be able to march or run a significant distance burdened with equipment and weaponry and arrive at the objective with enough reserves to be able to fight immediately. And the physical and emotional endurance that is then required for combat is staggering.

One of the ways that Colonel Hills demonstrated his willingness to lead from the front was his annual running of the Comrades and Washie ultra-marathons, and his challenge to the entire unit to beat him in the former marathon, and simply finish the latter. The reward offered was always a much sought-after weekend furlough. Though I do recall some members of the unit beating his Comrades time, I can’t recall a single soldier taking the Washie challenge. The Colonel demonstrated time and again that he had more raw endurance than anyone in the unit.

By the time I served in the unit South Africa was not involved in any active conflicts, but if there was anyone I would have wanted as my commanding officer in active combat it would have been Colonel Hills. I would have followed him into Hell had it been required.

Lead from the front is probably my most core leadership principle. Software engineering teams are meritocracies, so effective leadership of these teams requires that every member of the team respects the leader’s technical knowledge and skill. Leading from the front also means that a leader should not expect anything from their team members that they are not prepared to do themselves. This does not imply that the leader needs to master every discipline of every role in the team they lead, but they should at least be able to roll up their sleeves and make a contribution in every role if necessary, and certainly understand the day-to-day requirements and challenges of each role.

I am lucky that I have had opportunities to work in most sub-disciplines within the broader Software Engineering discipline, including Product Management, Program Management, Project Management, Architecture, Development, User Interface\Experience Design, Quality Assurance, Release\Configuration Management, and even Support and Operations to a lesser degree; so I have a good understanding of the minutia of most of these. I also endeavour to write code every day; partly because I just love to write code, but also because it means I never lose touch with the reality of being a software engineer. In my last role I made sure that I was actively contributing to the product, by taking Architecture, Development and QA work items in every sprint. I believe that this made me a much more effective leader, earned me the technical respect of my team, and gave me some of the context necessary to build rapport with everyone on that team.

I should note that not all the leadership practices I observed being successful in the military translate to leading software engineering teams. Military organizations employ a Command and Control management style by necessity, which is almost always a disaster if used with modern software engineers. I favour a Facilitation management style, which I will elaborate on in a follow-up post.