So the past 3 years I have had the privilege of leading one of the many great development teams at Innovative Systems. And while leading a team is nothing I originally remotely desired, I have learned much from it and from all those I work with. Left to my own devices, I would be perfectly content working by myself on varying projects. So I did take this challenge seriously and do try to do my best with it. That being said, I am always looking for better and more effective ways to work together as a team. And so far, I realize I have learned the most from the Steves.
And no, I don’t mean Steve Jobs – although Walter Isaacson’s article in Harvard Business Review last month entitled “The Real Leadership Lessons of Steve Jobs” is a terrific read and has some great lessons in it – but Steve Job’s style is certainly pretty much not going to be reproducible by many others 🙂 – this article though is highly worth reading as it was written by the man who spent years writing Steve Jobs official biography.
But no, I actually am referring to Steve McConnell, author of development gems such as Code Complete & Rapid Development – both permanent members of my book shelf.
And Steve Maguire – author of the Microsoft press book “Debugging the Development Process” which I read well over 15+ years ago and still remains highly relevant today.
Some of the Lessons from the Steves that I have learned from their books and their lessons from other places and tried to put into practice:
1) As Team Lead, its my job to remove obstacles – in the most zealous yet productive manner
2) Team Meetings should always be as brief as possible and never without an agenda
3) Action Items should be summarized at the end of the meeting, and the Team Leader needs to make sure the meetings keep moving forward, and not allow topics involving just a few to dominate everyone’s time – instead those should be taken offline
4) Meetings should NEVER be scheduled in the middle of blocks of time (that means 10 AM and 3 PM meetings are totally off limits) – it removes developers ability to devote chunks of focused time on problems they may be tackling – for me, meetings tend to be at 11 or 11:30 and promptly stopped at noon.
5) Personal communication trumps non-personal communication – most times, issues that require compromise or explanation require face-to-face meetings, email/IM just don’t allow for proper tone/attitude decipherment by the recipient of those messages – and too many times, “time saved” by electronic communication is totally wasted by miscommunication, improper assumptions as to imperativeness, or worse yet, mistaking a persons tone in email/or IM as being brusque or uncaring.
I still make many mistakes, and I believe I am still improving ever so slightly, but thanks to the Steves, I am not as helpless as I might have been had I not stumbled across their books.
But for those looking for other sources of inspiration for Project Management, there is always Darth Vader’s project management stylings.