Manager in Doubt: Help or Hinder?

"Successful technical leaders employ a general style that we call problem-solving leadership. They focus on the process of innovation and they do soin three major ways:
* understanding the problem
* managing the flow of ideas
* maintaining quality
...leaders may use motivational, organizational, and informational means to accomplish, in the end, a better way of solving the problem"
...............Gerrald M. Weinberg

Major release is around the corner. I want to be on a front line. I am eager to execute my technical leadership. The question is, however: do I help or do I hinder?

I ask what the problems are. I run between product managers, testers, and developers and ask what the problems are. I carry information faster then light (at leat email), and I make people see each other and communicate. I participate in discussions, brainstormings and arguments as a facilitator. I contribute with my ideas, but I easily withdraw them then someone offer better solutions (and it happens all the time). I am immediately available to take responsibility and make a final decision when required, without delay. If they decided to burn some midnight oil, I stay with them and share the tough part and show that I really care. I charge the team with my energy, enthusiasm and passion. So I help.

Or: I run as a chicken with my head cut off, interrupt developers, and increase everyone nervousness to the level of panic. I call them off for all these little meetings and short coordinating meetings all the time, and bring more managers and testers with their opinions for endless arguments. I stick my nose into their work, into technical details as if I can understand it, and then I throw stupid irrelevant ideas that they have to listen. I jump in and make sporadic autocrative decisions without understanding a problem. I stick around in the office so when the night comes I make them feel bad when they go home. And all the time I run, rant and ramble loudly with idiotic smile on the face. So I hinder.

Whether I help or hinder, to me it looks identical. Which one is real? How can I possibly know?

Questioning SCRUM

I came across my notes from the SCRUM Training I took last year. Here is one, as it came along ten months ago, as I challenged SCRUM concept of self-managing teams:

Self Managing Teams is a key SCRUM concept, but just mention it to your customer, and she'll shit her pants scared. Or mention it to your old-school hard-nose CEO, and the scared pants will be yours. He says "Go play democracy if you think it's good for team moral. But at the end of the day I want to see a name written down against a task. Who is the individual I hold responsible for its success, or it's failure? Whom do I go and shake the hand? Or whom do I go and kick the ass?"

Can a Self Managing Team manage their own compensation? Throw you annual budget, one million dollars in cache, on the table and watch them self-organizing as they are grabbing their shares. Is your team ready for this self-managing exercise?

How about another management responsibility, the authority to fire someone who does not perform well? This is a shitty part, but sometimes it has to be done. Does your team get guts to execute on this?

I am autocratic. I believe in the self-managing team. However I realize its limits, and see the need for one single place where the buck stops.

I like geese analogy. Geese formed a team, bought into a shared goal, they are proactivly working on it, going south. Look at the picture, they naturally emerged a leader! They're a great self managing team. To complete the image, see a man with a rifle on the top of a hill.

As I am reviewing my notes, I see more minor disagreements, more things I don't totally buy, more questions and more food for thought. This is a sign of a good training, and indeed I liked it! I credit it's success to Mishkin Bertraig, our SCRUM Instructor, and to a great audience of skillful and experienced professionals. We had diverse backgrounds, but we shared same challenges. We did a great team work together. Heck, we were the bunch of real geeks out there: who else spends 2 days between Christmas and the New Year questioning SCRUM?

More Software Professional Groups in Toronto

My review of Software Professional Groups in Toronto fetched contributions! Here are more professional groups to explore:

* Toronto Perl Mongers
* CIPS Toronto
* Mississauga Technology Association
* BitNet
* Information Technology Association of Canada for Ontario
* York Technology Association
(All courtesy to Michael Bolton)

* Toronto .NET Users Group (courtesy to Pablo Carbajal)

* Toronto Java User Group (JUG) (courtesy to Gerry Power)

To make a consolidated list, here go the groups reviewed in my earlier post:

* XP/Agile Toronto
* SCRUM Toronto
* TPMA - Toronto Product Management Association
* Toronto SPIN
* TASSQ, the Toronto Association of System and Software Quality
* DPSG, Design Patters Study Group Toronto

PS. More groups keep on showing up. I will be expanding the list below until the list is complete:

Toronto Python User Group, PyGTA:The group meets on the third Tuesday of the month at the Linux Caffe under the leadership of Mike Fletcher. Reported by the cofounder, Ian Garmaise.

Svetlana Korobov shared her great collection of Microsoft backed groups:
* Canada Technology Triangle .Net UG : www.cttdnug.org
* Toronto Visual Basic User Group: www.tvbug.com
* Metro Toronto .Net User Group: www.metrotorontoug.com
* East of Toronto .Net User Group: gtaeast.torontoug.net
* Toronto SharePoint User Group: www.tspug.com
* Toronto SQL Server User Group: www.tssug.com
* Toronto Windows Server User Group: www.twsug.com
* BizTalk User Group: www.btug.biz

Hey, we can brag with a great professional community here in Toronto

Software Professional Groups in Toronto

I was driving to our Desing Patterns Study group the other day, and that's what I though with a smile: one of Toronto natural beauties is great software professional community. We got so many smart and nice people who self-organize into various professional interest groups. Let me share with you my personal "keyhole" view to what groups do we have around.

XP/Agile Toronto - I've been enjoying active participation in this group since 2003. Over this time the group changed few skins and meeting locations, but it remains vital and passionate. The group feature presentation and discussion with thought leaders in the industry, like Craig Larman, Joshua Kerievsky, Ken Schwaber, as well as many local Agile talents. It is currently Lawrence Ludlow who keeps the group moving. Discussion meetings are held on the third Tuesday of the month. Current location is George Vari Engineering and Computing Centre at Ryerson University.

SCRUM Toronto - I think of it as a subset of XpToronto. It mostly comprises Certified Scrum Masters in GTA who throw eventual posts on Yahoo group mail list and get together for a dinner before XpToronto meetings, where you can meet most of them.

TPMA - Toronto Product Management Association. Clear from the name, this group is more inclined to Project Management and Marketing. The crowd is strong and diverse. Meetings are regular on last Tuesday each month at Metro Hall (55 John Street). Meetings are $20 at the door and free for members; membership is $100/year.

Toronto SPIN - Software Process Improvements Network. I visited one of their event on RUP and it was good, featuring two seasoned consultants from IBM Rational. But when I checked their web site recently, they appeared to go belly up. It's a pity.

TASSQ, the Toronto Association of System and Software Quality, is of more interest to software testers and QA. I never visited it, but rumors are it is more "planned school" participants, however they have very progressive speakers, thanks and credits to Michael Bolton http://www.developsense.com/blog.html who is a Program Chair there. The group meets for dinner on the last Tuesday of every month (except December, July, and August) Sheraton Centre Toronto Hotel, 123 Queen Street West, across from New City Hall. The price for attending a meeting is $35 for members and $50 for non-members, the membership is $85/year (do your math).

DPSG, Design Patters Study Group Toronto, is initiated by my friend Fernando Cuenca as a book study group. A small team of programmers and architects collectively storm fundamental books on software development. They gather every second Thursday, in the meeting room of the World's Biggest Bookstore (20 Edward Str., near Yonge & Dundas.) This season is going to be exciting at DPSG: we are reading Refactoring to Patterns by Joshua Kerievsky.

I am absolutely certain there are much more interesting groups around in GTA that worth mentioning in this list. I would appreciate your contributing with the info about such groups in the comments to this post or by emailing me at dz at softarefrontier.com

Mastering Manager's Tools

One thing I learned in my years of experience in Software Development is to master the tools. You may be smart and intelligent, but it hurts to see a programmer who slowly dragging mouse from one dump menu to another and it takes him forever. But watching someone artisticly playing on keyboard like a jazz musician with blowing performance brings austetic pleasure and a light feeling of jealousy.

As I moved to the management, I got to play with different toys. I use less and less of Visual Studio and vi, and more and more of Microsoft Excel and Internet Explorer. Like them or not, I got to master them. Like with development tools I am looking for the Hot Keys to drug the mouse less and make more. Here come a few keyboard shortcuts I am learning:

Dmitri's Internet Explorer Favorite Keyboard Shortcuts:
Ctrl-O or Ctrl-L - new location
Alt-D - address box
F4 - brings a history of typed addresses
Ctrl-Enter - wraps the address with www. and .com. You type softwarefrontier, Ctrl-Enter, and get www.softwarefrontier.com and go!

Dmitri's Excel Favorite Keyboard Shortcuts:
Ctrl-Blank - selects current column
Shift-Blank - selects current row
Ctrl-Shift-+ Insert. If a full row or column is selected, it inserts row or column. Overwise it brins up Insert menu prompting you of what shift you want.
Ctrl-Y - repeat last action. This kicks buts!
Ctrl-- delete selected cells
Ctrl-PageUp/PageDown - switch Worksheets.

Brainless Strategies

Today I listened Steve Pavlina's podcast "Kick-Start Your Own Business". He landed on the point witch I was molding over for a while. Why we smart intelligent egg-heads are soooooo slow and behind when it comes making business? I think it is because we tend to overcomplicate things. We look for universal solutions, for effective processes, and we spend so much time to do things right that no time is left to actually do anything.

Steve's recipee is to come up with a brainless strategy and execute on it.

Brainless strategies don't live well in software organizations.
I see it over and over in software companies. Too many smart people make too many things too complicatedd. It begins with programmers overengineering their software. It continues with managers who overcomplicate their organization processes.



When organization encounter a problem, the incstinctive question is often "how are we going to resolve such problems in the future". Meetings are called, responcibilities are defined, the process is documented and put in place, resulting in more meetings and more documents, all to ensure that if eventually this problem comes again we are armed to solve it a little more effecively.
Sometimes solving a problem is all what you need. So brainless: just do it, and as soon as it is solved, great! May be it is not the most efficient way of solving it. But it doesn't steal time of a few smart high-paid people for defining and documenting a process. It doesn't leave that process burden that organization is doomed to maintain to the end of the time. Just get the damn problem solved!

I'd think smart people don't need a disclaimer, but practice shows that we love to get things wrong. So here it is, disclaimer. No silver bullets. No absolute statements. Often times process is necessary. Often times they pay off. We all know it. Let's just watch out.

Catch youself next time you'll be asking "how are we going to resolve such problems in the future". Pause and think. The brainless strategy of "just do it" may be all what you need.