I'll clarify that last point and do a bit of self-promotion by stating my belief that I'm already promotion worthy. I have good tech skills, an understanding of my field (tech, otherwise), an ongoing interest in my field, and what seem to be solid interpersonal habits (despite being a bit forward/confrontational at times - but that's a skill). I've had direct reports - seven at one time - done raises, done reviews, complained about the review skills of others, and run a project as both tech lead and team lead, on more than one occassion. My new position has been important to me as I picked it precisely because it would put me in front of aspects/groups in the company I did not previously interact with (the main product line, international groups, enterprise layers) and in front of job types I didn't previously interact extensively with: managers, directors, architects, project managers, business analysts, content experts. Given that I've spent an inordinate amount of time making sure I have experience (if not an understanding of) with all aspects of the company, if I don't feel like going back to school is the right decision, at least on a viceral level, why do it?
Ming said that you do it to meet people, particularly other MBAs - the people you forge connections with so that you can garner best practices (he didn't phrase it exactly that way - but he meant it). I asked him if he felt the other people in the room with us at Hamline were the sort of MBAs he wanted to meet and with whom he wanted to form lifelong professional friendships. He sheepishly admitted they were not.
So, in the interest of being able to talk and think like management, and in the interest of acquiring all the skills of a manager, even if I know that not all of them in my company have been through professional training (like an MBA/etc), I've decided to embark upon a self-directed study course, courtesy of The Personal MBA and a few add ons I feel are important, like a firm grounding in Agile and alternatives (yes...alternatives), tech, offshoring, ITIL, and whatever I find on the shelves of Directors and VPs. In order for me to retain something of what I learn out that huge mass of books (must read accounting, must read accounting), I'm going to be posting a few reviews now and then to help me clarify what I've been reading, relate it back to the other books I've read, and provide my insights for one or two others at my company who are pondering a similar course. Mac, already MBA-ed, and apparently in agreement about my decision not to use an MBA as a way to a promotion, can also chime in and correct my erroneous assumptions.
By the way, Mac. I am incredibly jealous that you're even hinting at getting published. I have a great big notebook full of about 50 short stories and 6 book ideas from the past year. You have inspired me to do something about those ideas other than leave them stubbed out for posterity.
Onward...the plan. I'll review a few of the books, generally in twos and threes so I can draw parallels. But I'm going to add the odd quote broken out here and there, not to draw attention to a particularly pithy observation, but to point out something I think is stupid or humorous. If you feel you're an expert on something business related, then at some point during your observations, you're going to say something horrible. It's just a given. I feel that you can't self-educate without maintaining your sense of humor - you've got to be watching for the surreal so that you're not taking everything you read too seriously.
"If I had learned what your book taught me sooner, I wouldn't be stuck inside
these walls today." - from an women's correctional facility inmate.
The first two books I read were self-discovery books, courtesy of the inter-library loan program. That means, I couldn't take the tests, because the goal is to make everyone buy a book and take the test. But I found that to be helpful. I really had to focus on how I felt about dropping myself into various personality buckets. The Personality Code focused on DISC, a yes/no examination of whether you were Dominant or Steady, and Interpersonal or Conscientious. The goal is to determine if your focus is on people or tasks, and active or reactive. Your preferences drop you into one of fourteen categories which are then expounded upon, for their own merits, as well as for how they interact with their anti-type. I have issues with a book that posits there are four dimensions to personality in the beginning, and then self-references within the rest of the book as though the original hypothesis is fact. Particularly given that Bradberry admits there are 123,000 possible configurations (p. 151) and he narrows it down to fourteen broad types. It doesn't seem like the issue is pinpointing your personality, but putting yourself in a generalized bucket so that you know how to react consistently in a situation, and given a particular type of foil. There's this unwritten (in the book) idea that leadership isn't bucketing yourself or others, but brushing yourself with broad strokes so that your reactions can be interpreted correctly and consistently, by you and by others. I find some value in that idea. If your motives and actions aren't transparent to subordinates and management, no matter how valid or altruistic, that can be an issue.
"Never threaten this person unless you are 100% ready to follow through." -
Strengthsfinder 2.0, p. 64
I found the appendix to The Personality Code to be much more interesting. It spelled out 26 emotional quotient (EQ) values and provided some research and ranking behind them. These are the things that, unlike basic personality traits, you can learn, change, and improve. Self-awareness, self-managment, social awareness, relationship management, credibility, courage, et al. Strengthsfinder 2.0 tackled these same EQ values, but with different names. I found less value in trying to peg myself to any one, or more, bucket (I believe I'm ideation, input or intellection, and responsbility, coupled with opportunist/expert) than in considering the themes and the value in recognizing all the EQ themes are abilities you should be able to access in an appropriate context. Which means, in the end, I walk away with, in addition to an annoyance about the focus on Rudy in Strengthsfinder 2.0, a very limited list of items that I feel were essential and common to both books:
1.) Know yourself. Know yourself well enough to act consistently and transparently.
2.) Know the personal and emotional tools at your disposal well enough to apply them situationally.
That last one. I think it almost spelled the end of a manager I know. That manager focused on the hard manager skills (tech, etc) to the exclusion of the people who were implementing the project. The rats-abandoning-the-ship that followed (not an accurate metaphor - perhaps, rats discovering nearby cheese with fewer traps is more accurate?) nearly shut that manager down.
"...cradle to cubicle..." - Strengthsfinder 2.0 (seriously, is there a more
horrifying phrase?)
Whoof. Were you expecting that much typing? I'm going to go one step further. Between these two books, my recent MBTI course, and a pile of developer/agile reading lately, I've been pondering a particular correspondence. Given Clay Shirkey's discussion about developers, software, and Bion, I wouldn't be the first to draw connections between psychology and software. What I've been pondering is whether what's considered great about agile development might not just be personality in the macro. What? I'll step back. I don't consider anything I've read about personality, or any class I've taken, to be useful in picking a team. You pick a team by interviewing and hiring good programmers and getting to know the people you hired and how to smooth out the bumps in making them work well together. Sounds like personality, but it's not an issue of looking at fourteen types and three dozen EQ themes. It's an issue of looking at all 123,000 possible permutations. Microanalyzing is no good. You have to look at MBTI in the large, situational leadership, and within your own judgement to create a matrix...a matrix that's no good unless you talk to your team and understand each of them as individual people (or hiring someone who's capable of fulfilling that role for you).
But in the macro, in a Hari Seldon fashion, I think there's something to be gained. Posit your business unit as a person. Posit your development group, as a whole, as a person. Developers seem to be intuitive rather than sensing. While it might seem like they should be sense-centric, all the facts ma'am, tell me all the discrete steps, I find that better developers, exactly the kind agile says are necessary for their process, are more intuition. They're focused on patterns, the future, and a big picture. They read books about patterns and objects and consider grandiose new ways to work with, and present data. A business unit, on the other hand, while professing to be about the big picture, is very sense-focused when scoped at a project level. Developer assurances about a new technology: css, themes, AJAX, agile itself, silverlight/flex - those don't mean much. It's too much. But a concrete, touchable, clickable prototype. That's gold. Those are the trees in the forest. And if you look at the groups that way, agile seems to be solidly entrenched in MBTI and information processing. We (and here I set myself as a developer, although the start of this post noted I want to be the business unit/management) get to tell stories. We pander to what could be and revel in inspiration. Inspiration. No one tells an agile story with an unhappy ending. That's fucked. It's not done. If you can't see the utopia at the end of your code: the Shangri-la or Keanu-resolved matrix - if you can't revel in the inspiration you feel your sprints and spikes will force upon people who don't even understand the underlying code - if you can't throw away that nasty technical documentation becuase it only fits one personality type, not the other thirteen, and certainly not your business unit - if you can't give your business unit the sensual information that best first their perceptual preference - than what the hell are you coding for. They're not the storytellers. You are. They're the readers. Real developers, agile developers, focus on what could be, and their business unit focuses on the touch and the taste. If they can touch it, sense it, feel it, then they can have a reaction to it and explain that reaction to the developers. A mutual need is fulfilled. And that's the focus of almost every personality exploration out there. At some point you and your foil have to meet on common ground. In the micro, that's a matter of two people talking it out, because there are so many personality points to consider. In the macro...in the macro maybe you can make some assumptions.
2 comments:
They have a "porn" degree at the U? I underestimated them. Just read Guy Kawasaki's blog from time to time, check out what he's reading and call it a dang ole' day.
Post a Comment