Management Theory

This category contains 17 posts

Hard Lessons Learned as a Senior Manager – The Monsanto Challenge

The following is a series of personal thoughts and reflections on eight or so years of learning my way around what it means to be a senior quality assurance  or engineering manager. As some of you know I have recently found myself once again looking at the future of my professional career and wondering what it holds. The man who made the decision to change the entire organization of my department this week gave me some great advice. In our long and unofficial exit interview he challenged me to write down my thoughts on things I can personally take away from my successes and failures over a decade of different management roles.

Since I over share (according to everyone who loves me) this is the medium I’ve chosen to use. No names will be changed since I have no desire to name names or otherwise talk about specific instances, people, or companies.

Entry the First: The Monsanto Challenge

In which our hero finds himself experiencing blowback for not recognizing his full customer chain

A while back I worked for a company that was purchased by Monsanto. Monsanto meant business when they purchased our admittedly small little outfit in downtown San Francisco. They wanted everyone to feel like they were special and to know they purchased us because they had no idea how to do what we did and thus had no interest in telling us how to do what we do or interfere in any other manner. They purchased us because they wanted us and our data and our data models all to themselves. They spared no expense instilling the impression that both we were still going to be us but that we were also now in the “big boy pants” leagues. They chartered a jet and flew all of us out to three different facilities throughout the middle parts of the United States. We were given access to top research scientists, laboratories, executives, and even had an intimate dinner with the C-level executives and several board members. I got to meet men and women in one day who did everything from build Maker Faire sort of wild machines designed to strip genetic information from seeds without destroying them to people who advised Presidents and Prime Ministers on issues of national importance. Everyone I met on this magical mystery tour was very nice. They were to a person cheerful and helpful but most of all every single person from the assistants to the front desk personnel to the geneticists were all passionately committed to the idea of solving the world’s current and looming hunger crises. These were not Jurassic Park scientists playing with expensive toys. These were dedicated botanists, geneticists, engineers, and explorers who sought out, cataloged, studied, and genomed every single variety of crops like corn and wheat in existence looking for answers to complicated problems. When they couldn’t find answers in the species they realized they had to look outside the species. That’s when GMOs came on the scene.

Since I had what was essentially a captive audience who claimed to be willing to talk about anything, I asked the President of Monsanto directly why he thought his company’s public image was so wildly divergent with what I personally experienced just chatting with everyone. He told me it was one thing they completely screwed up a long time ago and didn’t even try to correct until lately. They didn’t look into anyone except the farmer’s buying their seeds and herbicides. The stopped at the primary connection in their value chain.

You see as much as a lot of people hate Monsanto, farmers around the world love love love them. Monsanto has done an amazing job of working with farmers, listening to their problems, and rapidly (in terms of seed) changed course several times to address their pain points. In most ways their movement into GMOs was a direct request from farmer’s who’s crops were being destroyed by climate change, water contamination, rapidly evolving pests & diseases, and the regulation of most herbicides out of existence. For decades Monsanto thought that was enough. When the suddenly felt the pain of people reacting emotionally to the idea of consuming what to them felt like “Franken-food” Monsanto reacted like the scientists and engineers they are by simply telling people to look at the science and research. To which what seemed like an entire planet replied with the phrase “Nuts.” Monsanto got hammered and is still being hammered. They’ve become the symbol of everything people don’t like about our current society and a repository for all the fears we have for what seems to be looking more and more like a bleak future. They ended up trying to enter a very pernicious and embedded opinion based on a decade or more of rumor armed only with facts.

Looking back at his now I wish I’d learned it years ago and had remembered it recently.

When you’re a manager (and especially a senior manager) you are responsible for a lot of things. Your team can feel like the most important thing that need concern you. You have reports and meetings with your direct manager who may be a director, vice president, or even chief officer of some sort. You have customers you need to keep happy be they external to your organization or internal to it. You can fall into the trap of making sure you do the best job possible, your team is chugging along fantastically, and your customers think you’re amazing. You want to believe that is more than enough to secure your reputation. Every company says it’s a “no drama zone” or something like it. Technology companies in particular like to say they’re data driven and that the rely on things they can measure. The reality is while you’re intensely focused on your primary relationships you are neglecting your secondary and tertiary relationships. These relationships are vitally important for the long term health and opinion of you and your team.

There is a tool consultants use called an influencer map. They use it to rapidly assess everyone on a project who has some sort of influence over the success or failure of that project and how they perceive it. People with direct influence are given priority but importantly people with indirect or even outlier influence are also mapped. The different people are mapped around who they can influence rather than where they occur in an org chart. Your job as a consultant is to be aware of people with influence who can have an effect on your outcome. You then turn around the ones you can to be supporters or even interested in your work. If you can’t change their stance you try and isolate them so they can’t scuttle your work through their attitude. As a manager you need to be aware of everyone in your organization in the same manner. it’s not something you need to address all the time but you don’t do it at the risk of how people perceive your work.

You see perception is often completely at odds with facts. People don’t trust facts or they selectively pick the ones that will support their perception. If a manager or director or a vice president forms a negative or even questionable perception/opinion of you or your team they will start to notice things supporting that viewpoint. You can present them with lots of Key Process Indicators (KPIs) showing you are doing great but they’ll come away remembering the one thing that may not have been awesome. At that point you are fighting a losing battle since you are actively working against an opinion formed from nothing. If you have enough time you can mitigate this issue with personal intervention and salesmanship but it’s a holding action until the opinion changes. If something like a re-organization or change in management happens before you’re turned that around you will find yourself on the list to be changed.

The best way to avoid The Monsanto Challenge is to never find yourself in it. Your first month as a manager should be spent personally meeting every other manager in your organization and every upper level manager in the company. You need to meet with them regularly and let them form their own impression of you, an impression you can hopefully control. Take the time to talk about the great things your team is doing and showcase their success. Ask them for advice or go to them with intelligent questions they can answer. Controlling your image in this manner provides some inoculation against other influencers who may be spreading a message you don’t want spread. It won’t prevent you from having your budget cut or being laid off or having your project shut down. These things happen all the time even in large companies.

It will remove one of the ways things like lay offs can happen in spite of success.

It’s a lesson I’ve paid the price for not following now at least twice and perhaps three times. I did not get on a plane and go meet with people face to face (the value of which I will talk about in another blog post). I didn’t control the message about myself and my team. In all of these occasions there was a price to pay; sometimes it was a very dear price indeed.

Simple Questions to Ask when being Interviewed

My fiend Johonna (aka Josie) Nutter turned me on to the following blog post written by Katie Thomas at the Hackbright Academy. The titular focus of the article is suggesting questions to ask of people interviewing you in order to determine if the overall culture is more or less female-friendly. It’s a great post and you should read it now.

I’ll wait.

I hope you actually read it as I’m not going to summarize Katie’s excellent advice.  Instead I’m going to comment on it since these questions struck me as some of the exact questions I should have asked at my last startup, the one that ended up being a sick cliché of almost everything wrong with SF startup culture.  My concern over the initiate or inexperienced candidate asking these questions, and the reason for this post, is to explain why I think these are excellent for ANY person and how people interviewing you can lie to themselves about what’s really going on around them.

“How often do people ask questions? How do people ask questions?”

I love these questions.  As a new employee your job is to ask questions.  All the questions.  As a manager if I found a new hire asking only a few questions within at least the first 90 days I would be concerned about their long term success.  As you move upward either technically or management wise this rule becomes more and more important and the time period should be extended further and further.  Software testers are especially good at this since one of our primary duties is asking the questions no one else wants to ask or didn’t think to ask.  We’re a curious and insatiable bunch that way.

Most interviewers if asked this question will reply with some sort of pat answer about it being a collaborative environment where new ideas and opinions are welcomed.  That’s generally a fib in most companies.  It’s a well-intentioned fib but it’s still a fib.  What you’re looking for here is a reaction to people raising basic questions or asking about things that “aren’t their job” or even things that are tribal knowledge.  As an example, within my first 90 days at my last position as a manager I was called into the VP of Engineering’s office and taken to task for asking who should be on an interview panel and which team was supporting which product.  None of that was written down on a central repository, if it was written down at all.  The issue was most management had been with the company for several years and so knew all those questions before they were moved into team management.  My asking questions about this sort of thing was taken as a sign of possible (sure) incompetence as a manager since everyone else knew it.

As a new employee you run the same risk.  Unless the company, department, and team are open and accepting of what seem like basic or redundant or even “semantic” questions then you will be facing a wall of expected omniscience you will more than likely fail to overcome.

“What practices do you have in place to ensure high quality code and continued learning?”

Code reviews are awesome.  Everyone does code reviews in this day and age, mostly because they’ve been told how awesome code reviews are by a blog entry or expert on some sort of topic.  When done correctly code reviews are great as one method for defect prevention while also sparking debate that can raise the level of code quality for all participants.  The same is true for style enforcement tools, unit tests, or [insert thing here].  My only complaint with this question is you need to dig deeper.  How are these practices and tools used?  How are they enforced?  Are there different rules for some people?  If I check in some code for review how long do I usually have to wait for comments or approval?  What is the general nature of those comments?  Who can block my checkin and for what reasons?  The same questions should be asked of all tools, especially style guides.  Who set up the guide?  Why did  they choose one pattern over another?  How often is the guide updated?

As another personal example, I once had a high priority fix delayed by a week as I sorted through several days worth of blocking comments.  30% of the feedback dealt with style issues such as how to format comments or spacing of wrap arounds.  60% of the remaining comments were attempts by various senior codes to make my code conform to their patterns, even if two or more of the patterns directly conflicted with each other.  10% of the comments were issues I missed and helpful feedback around how to do it better next time.  All of these comments were marked as blockers to submitting my changes.  All of these comments were entered in different days as each person found time to look at my checkin and tell me what to do.

A situation like the one I mention above is a giant red flag for a lack of discipline and coordination between people and teams in your organization.  As testers we often span groups when we move beyond the mind-numbing verification & validation activities best done by developers in any event.  If two or three interviewers cannot agree on how code is ensured then you can expect a lot of tension when attempting to test across functionality to where 75% of all bugs live.

“Are there any women on the team? If so, what positions do they hold?”

I’ve been to and spoken at a lot of conferences and smaller events.  I may have a unique perspective since I don’t just go to testing events.  Based on that perspective I can be reasonable sure the software testing and software quality assurance profession is one of the most diverse professions in the larger tech industry.  We can do a lot better, but we are by no means atrocious.  Development engineering events, on the other hand, are still giant sausage festivals.  Most of the diversity numbers you see coming out of the large tech companies this days are completely crap for that reason.  All the ones I’ve seen lump development engineers in with testers, marketing, project management, and design.  Unfortunately for them even when they play fast and loose with statistics they STILL end up with only 20% females and even worse in the numbers of ethnic and racial minorities or self-identified members of the LGBT community.

The sad truth is this question will help you determine the likelihood of your promotion and salary parity should you join the company as a software tester.  If women there are a lot of women in development engineering positions it’s a good sign the company is willing to treat difference with respect.  Software testers are different.  We think different and we focus on different things than a development engineer.  At some companies difference is assigned a value judgement and it’s usually more negative.  Managers hire people like them because managing these people is the video game tutorial of people management.  Since a startlingly high number of companies don’t care much about people management they promote awesome technicians to positions of authority.  As a tester this means there is a ceiling you will hit at some point even if you are a rock star.  Unless you change careers you will never move above that level at said company since you are different.

I feel I should also clarify something here.  I don’t believe women software engineers are inherently and inevitably all that different from male software engineers.  The paradigms and skills making a male an awesome developer are the same one making a female an awesome developer.  The same holds true for members of the First Nations, African Americans, Latinos, trans-gendered, or anyone else.  I did a talk at Electronic Arts on this very subject and did a thought experiment.  It was pretty cool.  You should ask me for it since I can’t post it anywhere.  Freaking Ted Talks agreement.  Anyway … what I’m talking about here is perceived difference which is actually worse since there is little you can do when trying to combat it.  The people deciding on your career perceive you as being inherently different (ie: inferior) so that’s what happens.  Unless you want to battle that it’s best not to join the playing field in the first place.

Vivre la difference.

“What kinds of things do team members do together besides work? How central is drinking to social events?”


Katie mentions this question as catching “brogrammer” culture but my experience is something different.  A distressing number of software companies have fetishized youth culture as the secret to creating a great company.  The culture then reflects this fascination.  The perfect employee at these places will be under thirty, moderately attractive, and residing within a small radius of the company.  Company social events will revolve around evenings spent drinking or hanging out in bars/nightclubs.  Even company offsite team building events in the woods will include an open bar and events that do things like rock climbing or wake boarding.

This is an issue because a lot of companies these days put great weight on “cultural fit.”  Not attending these events because you have a family or will need to drive 40 minutes home afterwards will be noticed.  Eventually you’ll be pegged as a “poor fit” or even a dreaded “nine-t0-fiver.”  Companies that truly care about their employees’ happiness and productivity and commitment will have a great mix of events.  One company I worked at had evening keggers where the young could congregate and pretend not to be flirting.  They also had family-focused barbecues and outings to sporting events such as baseball and soccer.  My oldest daughter got to pet a real zebra at one of these events.

Finding a company that caters to people in multiple points and times in their lives is generally a sign that same company is looking at the long term viability of both their business and their employees.

In Defense of a Software Testing Manager

Hey there, reprobates and iconoclasts!  Sorry I’ve been away for a while but I’ve been busy with work and playing a very interesting video game, Elder Scrolls V: Skyrim.  The video game itself is interesting after a fashion and I logged more than a few hours inside it when it first came out on PC.  I went back to it because the PC version has this amazing symbiotic relationship with their customers.  Bethesda Games released a creation engine (basically a rich set of level design tools) for free.  These tools were released for several very important reasons.  Allowing gamers access to design their own experiences and (more importantly) share them with their peers creates a rich set of downloadable content at zero cost to the production studio.  This “DLC” greatly extends the life of a game oftentimes by years.  The peer review nature of these downloads generates a lot of really valuable user data for the production company.  By watching what’s popular, what’s being discussed, and what’s being downloaded they can more easily design a richer and more rewarding gaming experience the next time they want to release another installment or even a brand new intellectual property.  The final things they gain are an instant hiring pool from which to draw and a free set of dedicated and very intense testers.  Some of the first DLCs produced by the people using these tools are usually what are called “unofficial patches,” which means they went through and fixed all the bugs and weirdness and outright insanity left in the game by the studio.  Of course after those you’ll start to see the usual nudity and chicken guns (this is the internet after all) but soon enough a lot of visual enhancements, physics tweaks, skeleton models, and even entire side quest worlds are submitted and essentially voted on by your customers.  The most successful of these designers are now working at Bethesda or were at least offered a high paying job if they wanted it.  So that’s why I’m back playing this game after a three year(ish) hiatus.  The mods and DLC I can now download have made it into a gorgeous, rich, engaging, and altogether brand new experience … and it only cost me the time it took to download the content and tweak out the conflicts.

So what does this have to do with test managers, you may well ask?  Ha ha … you must be new.

Video game companies are notorious for treating testers poorly.  Thankfully that has been changing for a lot of the new kids on the block, but at the old guard it’s still very much a job reserved for teenage monkeys who would rather follow a written script in a dimly lit room than work at the Hot Topic again this summer.  The other thing they have not usually done all that well is design games for someone else since “the customer” is some vague notion of a blob that sort of resembles them since they like to play games.  This is one of the reasons girls didn’t start gaming until relatively recently.  A giant majority of the people making games were boys and man-boys and they liked to design games they’d want to play.  This is why most video games have giant men with bulging muscles and strange satires on women who could never exist in nature even with surgical help and a team of assistants helping them get dressed.  To combat this problem of myopia, video game companies began creating open spaces for anyone who wanted to join.  These were originally places where people could post their game hacks but some smart people decided to nurture them by assisting them to make things.  They essentially backed off and admitted they might not know everything there was to know about gaming and gamers.  Rather than forcing their market into conformity with their assumptions, they stepped back and let their market tell them what to do.

This is why you need a software manager even if you are one of those full stack team organizations companies seem to love these days since everyone wants to be sexy and lean startups are sexy.  The almost universal hierarchy of a software development company has developers and architects at the top with everyone else following behind them.  If you want to get seed funding for your startup, you’d best be a developer or be partnered with a developer.  If you want to rise above a management role you’d best have the last few stints as a developer in your CV if you started out in a different profession or discipline.  Usually this is not a bad thing, but it does cause conflicts when this person attempts to manage other professions … by which I mean testers.  The average software developer/coder does not really know anything about software testing.  It’s not their fault.  Software testing does not excite them.  They don’t read articles on software testing unless they feel they have to since they’re now managing testers.  They don’t attend software testing conferences.  They don’t follow software testers on Twitter.  They don’t attend software testing meetups or participate in weekend testing events.  In short, they have zero qualifications when it comes to helping drive the direction and practices of the testers working under them.  They are also horribly unqualified to advise these people on their long term  professional growth should they want to stay in software testing.  In places with this sort of setup and expectation the testers will usually find themselves either managed and directed as if they were software developers or worse, ignored and simply told what to do when the time comes to tell them.

There is a different way and it’s the same way some video game houses have followed.  The software Sr Director/VP/Major Domo can simply let go and admit they don’t know everything there is to know about all things software related.  They can find the person or people in their company who are deeply engaged in the professional knowledge they lack and let them pursue their passion as they see fit.  Even in a self-sustaining team there is a lot of cross team interplay at healthy companies.  Someone needs to nurture that interaction and keep the momentum going when people stumble onto something awesome.  That person is usually called a “manager.”  It’s their primary job.  They make sure the people they’re nurturing have the tools, resources, and backing to pursue the things their experience and passion say are worth pursuing.  They help get people to understand when something is just a little failing and when it’s a flaming disaster.  They make sure people feels safe to do so.  You cannot accomplish this if you lack the authenticity of actual interest.

Let me say that again.  You cannot inspire passion in people if you do not feel passionate yourself.  Period.  Mike drop.

If testing is important to you and you want passionate testers, you need someone with just as much or more passion leading them.  When you get that you’ll soon see a massive return on your investment, just like the makers of Skyrim found out when they went against industry canon and helped people hack their game.

That’s a software testing manager and that’s why you need one.

5 Warning Signs for a Person Interviewing a Candidate

Over the years I’ve had more than a few chances to chat with consultants, candidates, and contractors in circumstances that can best be described as “exploratory.”  The specifics leading up to the events are usually as varied as the events themselves.  The one constant is the actual conversation itself.  By that I mean it’s just that, a conversation.  The meeting is a chance for me to get to know this person a little better in order to take a wild guess about whether they’d be useful, compatible, or even “not crazy” if we were to invite them into our cozy little corner of the professional world.  I’ve often joked that it feels like a first date and it seems like that specific piece of humor resonates with people.  There are points of overlap between a “first date” and an “interview” even though the two are actually quite different.  Taking that viewpoint I’d like to see if I can help people who find themselves in the position of talking to a possible new presence in their work life.  I know there are several hundred (thousand) blog posts, articles, and even books on “effective interviewing” but this will not be another of those.  I’m not going to give you tips on how Microsoft, Google, or Amazon recruit and interview people successfully.  The best interview technique is one that feels natural to you.  Reading interview questions off a printed out sheet is an awesome way to kill the enthusiasm of a talented and sought after interviewee.  They’re looking for clues about you, remember, so it’s best to give them a taste of the real you … unless the “real you” is pretty dreadful.  In that case please have someone else do the interviews or read from a script of prepared topic points without deviation.

So what are some of the things you should watch for when chatting in these circumstances?  I’m glad I asked.  Here’s a quick list of five things I try and suss out while having the sort of informal and free flowing conversation I find works best for me in an interview.

Does this person know anything about your company or team?

Years ago, when I first started in the software industry, the internet was still a relatively new thing.  Companies bad websites and were all scrambling for a “web presence” but it was by no means common.  Certain companies had brand visibility but most companies still used printed out materials for company communications and advertisements.  At that time the only way to get any information about the average company, much less the specific teams, was to know someone on the inside already who was willing to talk candidly.  That is no longer the case.  In today’s world almost every company out there has a public facing website.  Most search engines can easily return nearly too much information on the financials, operations, and news stories of a specific company.  Social media sites allow you to quickly poll information on the people working at specific teams and departments with differing levels of anonymity.

To put it bluntly, the only reason a person would come into this sort of meeting with you unprepared is either a lack of access to technology bordering on Luddism or apathy about the position itself.  Simply asking a person what they know about the company will probably get you a rehearsed response unless you’re dealing with a talented salesman.  Reserve judgement on this topic until you’ve had a chance to talk for a while.  If the person seems to be going off on unrelated tangents or leaping on topics that aren’t at all relevant, then perhaps you should dig into what they actually know about you and why they want the position.

Does this person use a lot of “buzz words?”

As I mentioned before, buzz words are an excellent tool for obfuscating an actual lack of practical knowledge or benefit.  Buzz words are different from jargon in that jargon has an actual practical application for the realm in which it is used.  It’s easier to say “sproc” that to say “stored procedure” just like it’s easier to say “cloud computing” than it is to say “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”  Buzz words are an attempt to make the easily understood sound arcane … and therefore valuable.  This is the difference between “cloud computing” and “The Cloud.”  It’s the difference between “agile software development” and “Agile Software Development.”  A good rule of thumb is if you can read or hear words being capitalized and they are not proper nouns or acronyms, you’re probably reading or hearing a buzz word.

Does this person seem rehearsed or fake?

A person who sounds rehearsed, false, or otherwise disingenuous is a pet peeve of mine.  The meeting we’re currently having is usually to determine whether or not we can work together as colleagues or in some other professional role.  It’s best if we’re both honest and true to our natures or there will be some unfortunate surprises later.  The “surprise” part is the one that particularly puzzles me.  I know people who spend time reciting “best” answers to practice interview questions.  I also know people who spend a lot of time and effort researching ever more intricate and elegant interview questions to toss out at everyone who meets them.  What is the success criteria for this strategy?  Unless you are a brilliant performer attempting a new art piece, the task of being this foreign person forty plus hours a day is going to prove impossible.  Eventually the “real you” will surface.  This is going to cause problems because the people around you agreed to work with the other guy, not you.  Over the years I’ve learned to watch for people who think they can trick themselves into a job.  If they can’t or won’t leave their script on the table then you’ll need to be concerned about who and what you’re inviting into your team environment.

Is this person interesting?

Usually when we’re looking to bring on a new person it’s because either we need to replace someone who left or we need to augment what we’re already doing.  Unless you’re in an unfortunate situation this is an excellent opportunity to breathe some new ideas and life into your community.  I’ve found the best way to do this is to look for interesting people.  People I find interesting are ones who have no problems discussing things that are new to me or who cause me to look at something from a new perspective.  Because I like learning new things, I will immediately perk up.  I love “interviewing” people who end up feeling more like we’re having a really interesting chat over chai somewhere.  I detest “interviewing” people who reference the same old ideas and concepts in the accepted manner that have been agreed upon by the usual governing body.  I’ll hire the best reciter if that’s all there is available, but I’ll overlook at lot if I feel a candidate is going to take me and the rest of the group in new directions that might yield amazing things.

Do you feel passion when they talk?

The final one is the one that trumps them all when you come right down to it.  If I’m chatting to someone about coming on board to help us do a security audit, I’m going to want to hear the energy in their voice when they talk about things like DDoS attack detection and encryption algorithms.  I’ll want to hear if they’ve read books, attended conferences, or listened to speakers at a local Meet-Up on their subject.  This is a specific point of error for me as even today I still find myself talking to a lot of people who treat software test engineering as a stage in their longer computer software career.  All to often it’s not just a stage, it’s the initial stage.  I’ll be chatting with someone about a test engineering position only to hear them become passionate as we casually chat about the mobile app they’re developing with a friend in their spare time.  It’s awesome that you’re passionate about mobile application development and it’s definitely something you should pursue.  I, however, am hiring for software testers today but I’ll definitely pass your resume on to our HR department.  The danger in missing this clue is passion breeds excellence faster than any morale event or annual stock bonus.  If you look for and hire passion you’re job as a manager is pretty much done.  The only thing you then have to do is herd the puppies and keep them sort of going in the same general direction.

And honestly, who wouldn’t want to work with a puppy herd?

Diversity Isn’t a Question of Biology

I keep hearing the topic of diversity raised at regular intervals since moving to the SF Bay area.  Having moved to what is unarguably still the center of cutting edge innovation in software development, it’s impossible to avoid references to “this thing we do.”  I imagine this must be what it’s like to live in Los Angeles or Mumbai and work in the film industry.  There are other industries around and plenty of people making money in other ways … but  what you do is so vitally important to the local economy that industry insiders are local celebrities.  All that was by way of giving context for why I can’t drive into work or watch television or attend an evening lecture without standing a better than average chance of being subjected to a talk on why there are so few [fill in blank] in the software industry.  It’s gone from interesting to amusing to noise.  Mainly because I think the entire premise is wrong.

To explain what I just said, I’ll refer you to a seminal work authored by Psychologist Howard Gardner back in 1993.  The title of the work is Frames of Mind and Multiple Intelligences and the concepts if not the work itself should be required for any manager working with any team.  The basic theory proposed by the work is that everything you know about intelligence is wrong or at least very narrowly defined.  Dr Gardner first asked the question that had plagued psychologists and behavioral analysts since the adoption of the “intelligence quotient” in 1912 when the German psychologist William Stern first proposed using it.  The problem was namely one of description.  If the intelligence quotient (IQ) was a good descriptor of intelligence and cognitive ability, why did some people who scored high never seem to do well while others who scored lower seemed to excel?  The attempt to reconcile this seeming problem lead people to such ideas as “cognitive maturity,” “fluid intelligence,” and a host of others all premised on the idea that IQ was not a flawed theory in itself but rather had a problem with a lack of tools to help explain it.

Dr Gardner took another approach.  He proposed the whole concept of how we looked at “intelligence” as a hierarchical structure with certain cognitive abilities at the top was essentially wrong.  The problem as he stated it was that there were/are approximately seven distinct types of cognition rather than one.  The intelligence tests and point system were designed to only measure and grade one type, meaning people who excelled in the others were ranked as having low or lower cognitive reasoning ability.

The seven types proposed by Dr Gardner as as follows:

  • Visual-Spatial – think in terms of physical space, as do architects and sailors. Very aware of their environments. They like to draw, do jigsaw puzzles, read maps, daydream.
  • Bodily-kinesthetic – use the body effectively, like a dancer or a surgeon. Keen sense of body awareness. They like movement, making things, touching.
  • Musical – show sensitivity to rhythm and sound. They love music, but they are also sensitive to sounds in their environments. They may study better with music in the background.
  • Interpersonal – understanding, interacting with others. These students learn through interaction. They have many friends, empathy for others, street smarts.
  • Intrapersonal – understanding one’s own interests, goals. These learners tend to shy away from others. They’re in tune with their inner feelings; they have wisdom, intuition and motivation, as well as a strong will, confidence and opinions.
  • Linguistic – using words effectively. These learners have highly developed auditory skills and often think in words. They like reading, playing word games, making up poetry or stories.
  • Logical -Mathematical – reasoning, calculating. Think conceptually, abstractly and are able to see and explore patterns and relationships. They like to experiment, solve puzzles, ask cosmic questions.

(Source: http://www.tecweb.org/styles/gardner.html)

Those of you who work in software development or IT in general can probably see where I am going with this article now.  Those of you who don’t or can’t, let me spell it out clearly.

The software industry is almost completely dominated by people with deeply evolved logical-mathematical cognitive abilities.  It is nearly impossible for anyone else to even enter this work force, much less rise to a position of authority.  Over the past few decades I’ve seen a lot more people with highly evolved cognitive abilities in linguistic cognition start to make inroads, but they are still a deep minority.

And to the people who correctly for some reasons want to see more [fill in the blank] represented in the software industry, I say go for it but stop saying hiring more of said person will result in “diversity of thought.”  If your entire culture is geared toward training, recruiting, promoting, and rewarding only one sort of intelligence then the only solutions or innovations you will generate are the ones available to that sort of intelligence.

It’s also an issue when you start looking at who you can make a team lead or a manager.  You can’t train someone to have high levels of interpersonal cognition with a few weekend seminars anymore than you can teach them to be a mathematician with the same … and yet that is exactly what we do in the software industry because we cannot conceive of anyone except a logical or possibly linguistic thinker being of any worth.

So if you want our industry to move into the 20th century you should stop trying to make everyone just like you and start looking for people who are not like you at all, but still have something to offer.

And in closing, here is the Ted talk by Temple Grandin that started congealing these ideas in my head back in 2010.


Your Review Process is Hurting Performance

“Q: What are the three signs[ of a Miserable Job]?

  • The first is anonymity, which is the feeling that employees get when they realize that their manager has little interest in them a human being and that they know little about their lives, their aspirations and their interests.
  • The second sign is irrelevance, which takes root when employees cannot see how their job makes a difference in the lives of others. Every employee needs to know that the work they do impacts someone’s life–a customer, a co-worker, even a supervisor–in one way or another.
  • The third sign is something I call “immeasurement,” which is the inability of employees to assess for themselves their contribution or success. Employees who have no means of measuring how well they are doing on a given day or in a given week, must rely on the subjective opinions of others, usually their managers’, to gauge their progress or contribution.”

from an interview with Patrick Lencioni

So what does the above quote have to do with our performance review, you might be asking.  Well hopefully that’s what you’re asking.  You might be asking yourself what an essentially useless activity you and your team are forced to conduct semi or annually solely for the purpose of arguing about who should get more, less, or the same amount of money has to do with performance.  If you are, please stop reading.  You’ve just answered the question for yourself.  In your case performance is harmed because you and your team are being asked to stop all productive work just so you can devote a week to two weeks (or possibly more) filling out forms and completing online surveys about why you aren’t more productive and why the guy sitting next to you is driving you insane because he keeps popping his knuckles.

In your case just stop doing the performance reviews all together and move on with your life.  Base any bonuses or promotions on what you’ve actually done for the company and call it a day.  If the team has a kick ass year, hand out a few checks.  Or better yet, have a kick ass party somewhere to thank everyone.  At one company we did an amazing job with our launched product.  It was more successful than anyone had ever imagined.  That year upper management used some of the extra money to rent an entire private beach front hotel in Mexico and stock it with all the food and drink we could consume for a week.  Was that a good bonus in comparison to a check?  Let me put it this way, that happened about a decade ago and I still talk about it.  The bonus checks and stock awards are soon out of mind and out of sight nearly as soon as they’re awarded.

Yeah … lying on a beach in Mexico with a whole passel of computer geeks just as hung over, flabby, and sun-burned as me.  Good times.

So for everyone else, what’s wrong?  You are supposed to be doing this activity which helps people become better and move forward in their careers.  You honestly want to do this because you care.  It also helps retain employees who know they’ve got somewhere to go.  You’ve purchased the software.  You’ve read the books.  You’ve attended the training about “SMART goals” and “360 reviews” and “stack ranking” but it still feels like a chore to you.  It seems like every year you pull up the documents you painstakingly wrote the year before only to feel that sinking realization we all feel.  Most of what’s listed there is either out of date, unrelated to the work now, or makes absolutely no sense to you now.  So now you have to map out the things your team did this year that “rocked” and the things that were “lame” (you can take the boy out of the Seattle grunge scene, but you can’t take the grunge scene out of the boy it would appear) and somehow map them to what you promised.  That sinking feeling you experience is partly the knowledge of this task ahead, but also the absolute certainty you are going to run smack into the Dunning-Kruger effect or the self-serving attributional bias even if you are not a manager or lead.  If you’re even mildly empathetic you’ll probably also be aware of how seemingly purposeless this whole exercise seems.  The only thing people argue with passion seems to be whether or not they deserve a 5% or an 8% bonus or raise.  It will often feel like this is an excuse for the employee to demand more money and the employer to demand less money.  In short it feels like the initial salary negotiation has been converted into an annual event, sort of a masochistic bank holiday.

Why is this?  Does it have to be this way?

No.  No it doesn’t.  However the alternative is very very hard.  I’m not kidding.  It’s hard because it involves a radical shift in how you view your work and your employees.  Most people and companies don’t want to make this shift because … well … not to put too much emphasis on this, but it’s hard.  The answer directly addresses the three states of being listed by Lencioni in the quote I listed above and in his excellent book, The Three Signs of a Miserable Job: A Fable for Managers (And Their Employees) which I also linked above.

I’m bringing this up because of this blog post by Mario Moreira.  I really hate to pick on him but I can’t help it.  He just makes it too easy.  He seems to recognize there is a problem with trying to define someone as a role and base their performance goals on that alone.  He wants to somehow personalize the process.  Unfortunately he appears both in his article and in our subsequent chats on LinkedIn to fall short because … it’s hard to do it the right way.

So in honor of Mario and his compatriots who want to do more of the same because what they’re doing now isn’t working, get ready for another multi-part entry from yours’ truly.


How exactly do you make people happy with your work?

My manager and his manager have been in something of a pickle lately while they board of directors has them under the gun.  In other words they are currently faced with the dreaded pickle gun.  They’re not the only ones.  One of my colleagues is currently staring down the briny barrel of tartness from the leader of the “Center of Excellence” dictating policy and best practices for her entire company.  Yet a third friend can literally smell the dill as the green projectile whizzes past him after being fired by his  remote client.  What do all these people have in common?  What sort of issue is causing them pain?  When will I stop stretching this pickle metaphor?

The problem all these people are attempting to resolve is simple to state but hard to analyze.  So simply stated, some one acting as their customer/audience/manager is dissatisfied with their work.  Usually dissatisfaction is easily identified and corrected.  The problem is probably your’s.  You’re not doing what someone is paying you money to do.  This naturally makes them a little unhappy at handing over or at having handed over their money.  If I pay a mechanic to rotate and balance my tires I will be somewhat dissatisfied with our transaction if they flush my radiator instead.  It won’t matter one whit to me if the radiator is well flushed and feeling like new with shiny hoses and non-toxic coolants made from unicorn sweat.  I paid someone to attend to my tires, not my radiator.  The problem is then one of simply doing what the person paying you or directing you asked you to do, and doing it well.  Complexity rears it’s briny green head (again with the pickles)  if you do what they ask but they are still dissatisfied.  So why are people dissatisfied with your work if you do a good job, do what you were asked to do, and do it within the time you both agreed?

First off, let’s just assume you actually are doing what is being asked and not what you think is being asked.  Assumptions are the most common source of dissatisfaction in any relationship.  The power dynamic in a working relationship, however, is completely skewed against you.  It does not matter if your customer/manager/director is at fault for incomplete or misleading requests.  Their continued dissatisfaction means you will be out of work.  You can soften this blow with the knowledge you were in the right all along, but ethical certainties will not pay your rent.  Your job then is to partially determine if what you think is being asked of you is actually what the person doing the asking wants.  That’s a pretty confusing way of saying, “Make sure you’re following the spirit as well as the letter of the request.”  Customer satisfaction often means doing what the customer doesn’t themselves know they want you to do.

Okay you’re doing all that because you’re a seasoned professional who knows language is a fickle thing full of homonyms, synonyms, acronyms, jargon, idioms, and misunderstandings.  The customer is still dissatisfied.  What do they want from me that I’m not getting?  They want the following.  They want you to demonstrate to them you are improving their lives somehow.  They want you to show them how your work is a good return on their investment.  They would like to see a general improvement in your deliveries over time in a longer relationship.  They want you to prove they can trust you.  That’s it.  They want value addition, ROI, continual improvement, and trust.  Nothing to complicated, eh?

I’ll go ahead and let you all chew on that for a little while.  All this talk of pickle guns has made me a little hungry.  Tune in later for explanations and strategies for actually implementing what I’m suggesting.

Mmmm … potato salad.

The Primary Aspects of a “Startup Culture”

Those of you who know me or who simply follow my various ramblings and musings through this blog will probably know I’ve been out there in the trenches for a while now.  I first started back in 1998 as a “temporary” contractor with a new product division of Microsoft.  The product was a giant beast of a creature we’d now call an “ecosystem” in today’s project speak parlance.  It was aimed at small to medium sized businesses and incorporated elements of a new product called “Exchange” as well as elements of a soon to be deeply integrated MS Office suite.  The product ended up shipping as Windows Small Business Server, but I bring it up because now because that was the first time I began hearing the phrase, “we’re really more like a startup.  Of course it was all poppycock, and you can bet it will be poppycock as well when you hear some one else make the statement about any other company or group.  The reason I can make this claim is companies or groups operating in a startup mode or state do not have to self-identify as a startup.  The fact they have no money, customers, equipment, or support sort of does the talking for them.  Working with a fixed budget on a project with no guarantee of success does not immediately equate your work to a startup.  It simply means you’re working on an interesting project that could blow up in your face, but probably not.  So why do so many companies, departments, and people self-identify with the “startup” some of us have actually done time with?

Unfortunately the startup company has a particular place of honor in the mythology of the software development and information technology industries.  The startup ranks up there with the coder who’s arcane understanding of mathematical systems and processes departs a special knowledge rendering them superior to other humans.  It’s actually only slightly below the conceit of computers (and software) running or controlling the world (see “brothers, Wachowski” for more on this).  The myth of the startup is something along the lines of a small group of dedicated enthusiasts joining together in a quest to create something innovative and world changing.  The enthusiasts are generally credited with enough foresight and altruism to justify little to no immediate financial security while pursuing their dreams.  Certain versions of this myth have the enthusiasts eventually becoming rich(ish) but treating the monetary rewards as trivial, even losing them all with a smile on other companies and products.

So the primary aspects of a startup according to the myth are frugality, innovation, enthusiasm, egalitarianism, and camaraderie.

These are all laudable traits,  but unfortunately they are nowhere near the ones truly defining a startup and its culture.  The really unfortunate part of this problem is rooted in the general positive value assignments of all the traits.  Because they’re essentially positive, a lot of groups,  companies, departments, or teams like to call themselves “basically a startup” or “following a startup model.”  I’ve actually talked to groups with multi-million dollar budgets, hundreds of active customer accounts, and offices in three continents who referred to themselves with all seriousness as “still essentially a startup company.”  Of course no one who was actually at the company when it was in startup mode was still around to laugh in these people’s faces, so there was no one to correct them.  That’s why I don’t really blame them for their mistaken belief in an archaic system.  All I can do is educate and see if it sticks.  I have to admit to a certain amount off self-interest in spreading this message.  I’m getting tired of meeting with clients who think they’re a hare but are really a tortoise.  It’s not a value judgement but it does make working them a tad easier if I don’t have to rub their tortoise feet for luck and continually admire their “fluffy” tortoise tails and “long” tortoise ears.

So what are the actual traits of a startup, or rather what are the traits of a startup that eventually succeeds?  I’ve actually done a lot of research into this topic and I have some definite opinions … of course.  I mean why else would I be writing a blog entry?

The actual traits of a startup are as follows:

  • You have no customer base for your product(s)
  • You have no defined process or workflow to improve
  • You are always strapped for cash and equipment
  • You may not have a company in six months

Out of these traits come a lot of the things normally lauded by the industry.  Since startups have no real customer base, they must be flexible and agile enough to chase down markets as they evolve.  This means today’s dominant technology or tool is tomorrow’s unused site license.  This requirement for being able to quickly become an expert on technologies and frameworks is why startups are usually staffed with talented generalists rather than world renowned specialists.   Successful startups won’t usually refuse to interview a candidate because they don’t have experience with “X” tool or “Y” platform.  Instead they look for a pattern of rapid competence coupled with an intense desire for learning.

In order to survive past the next six months, a startup has to either take business away from an established company, create new opportunities, or attack opportunities the established companies are ignoring.  This means they need to innovate beyond subtle improvements to what’s already being done.  For a startup to be successful, they need to become dominant in their market which is why most of them attach small markets being ignored by “the big guys.”  Because a startup will have little to no advance knowledge of their market, customers, or their needs the successful startup has to keep their processes and workflows as light as possible.  Once the market starts to coalesce, the measurement and improvement can start as there will be an oracle against which you can measure success.  Until then the startup runs the risk of entrenching behaviors counter to their actual market needs.

While startups always have seed money and angel investors and venture capital, the successful ones are invariably lean and hungry.  Every minute spent working is another minute where money was siphoned out of the company funds, to greater or lesser degrees.  Until the company achieves profitability (ie: customers paying you more money than you spend on a regular basis) the only thing a startup can do to keep running is attract more capital or stop spending money.  There is no money for large development and test environments that must be maintained.  The company cannot afford expensive tools and third party systems that already solved a few of the problems.  Debts in quality and design cannot be paid by off-shoring work to someone else.  Designs and solutions have to be determined, developed, and deployed as rapidly as possible to get money coming in as soon as possible.  The constant drip of the money faucet naturally results in lean solutions with the bare minimum of design and coding that work on laughably under-powered systems.  Because they cannot afford to spend months working out the “correct” solution, the startup comes up with “a” solution and lets the customer tell them if its correct or not.

Finally, and I can’t stress this enough, there is the constant fear everyone at your company won’t be around in a few months if you can’t get the money flow turned around from outward to inward.  This fear of failure brings out a desire for daily excellence in a lot of people while bringing them together in a sense of common struggle.  Since everyone is effected, the test analyst will usually be on a first name basis with the CFO after leading them through a bug bash session with beer and pizza.  Every small victory is celebrated and every small setback is shared.  No one can be suffered to simply come in, do their job, and leave because there are simply too few people around and too little time and money to allow luxuries otherwise.

It’s my assertion that if you’re missing any of those four items, you aren’t really “just like a startup.”  You can be a small company where the CEO sits in an open cube like everyone else; but unless you’re scared spitless about next quarter’s earnings, chances are good the “open cube” policy is more of a PR exercise than a reality.  You can talk about being “agile” and “innovative” but take a look at your hiring and interview process.  Chances are very good its currently geared to attract world class specialists as your ideal candidates.   These people are usually writing papers and speaking at conferences about their subjects, but are also usually about as agile in changing direction radically as an aircraft carrier.

But hey, its okay.  It’s great to be a successful company with a dominant market position.  I can guarantee you every startup out there wants to either become you or be noticed and acquired by you some day.  The original staff may leave when that happens, but that’s okay too.  They’ll usually have a larger bank account and bragging rights about what they built.  You then have the hard task of building on success and creating innovation one small step at a time in a market now populated by a sea of wannabe imitators and conservative purchasing agents.  You have hour own unique challenges and triumphs that should be celebrated.

So stop attempting to be something you ain’t and just be happy with yourself as who you are.

The Journey of the Hero Tester

Selena Delesie recently posted a couple of blog entries about her experiences with something called “the hero culture” and its pervasiveness within the IT and Software industry.  You can read her posts here and here, and I suggest you do because they are really interesting.  Out of that discussion marched several great comments from some of the usual Mötley Crüe.  An interesting theme was advanced in offline conversations between James Bach, Matt Heusser, Selena, and myself.  Okay, it was mostly me and James.  So moving along … the theme was the general transformation or degradation of the term “hero” since the advent of the modern entertainment age.  If you are a student of history, mythology, psychology, and/or anthropology you’ll know the term “hero” is nearly universal in its presence but not specific meaning.  Scholars such as Claud Levi Strauss have posited these similarities represent the possibility of a common thought structure or pattern.  Karl Jung debated them as universal archetypes representational of a common experience and share human nature.  Probably the most famous scholar on the subject in the United States, Joseph Campbell, described these common structures as an attempt to describe and share common beliefs or experiences in the language of metaphor and poetry.  In short, he stated the mythical archetype is an attempt to hack our conscious thought and wire it directly into the unconscious suggested by Levi Strauss and Jung.

So what is the “historical” definition of a hero and how is it different to the pop culture definition advanced by the literature, movies, comic books, and television shows of today?  The biggest difference is a the nature of the hero his or her self.  In modern interpretations a hero(or heroine) is someone who overcomes adversity or seemingly impossible challenges.  The young soldier who lost both legs in combat but still dances at his wedding is considered “heroic” in his ability to overcome his disability.  The comic book protagonist who battles through ever more dangerous and omnipotent threats is called a “hero” for defeating them at the possible cost of their own life.

Contrast this with the pivotal moments of the historical hero cycle as defined The Hero With a Thousand Faces.  In Campbell’s monomyth the hero is called to adventure where they overcome ever increasing challenges or perils with assistance from a divine agent or a companion or both.  These seem to line up with the modern interpretation quire well.  Unfortunately that’s just the beginning for Campbell’s hero while it is the full definition for the modern one.

Campbell’s hero eventually fails, dramatically and spectacularly.  The failure either causes the death of the companion or divine agent, or the death itself is the failure if the hero kills the divine agent or companion personally.  The hero then feels epic remorse and travels to the realm of death to retrieve the lost one.  In this they also fail.  These failures are the pivotal moment in the monomyth, triggering the second part of the heroic cycle.  In the second part, the hero must come to terms with their mortality, foibles, and limitations when they had previously thought themselves nearly immortal, infallible, and omnipotent.  The period off reconciliation and atonement for their past actions raises the person of action into the realm of the hero.  Eventually they are welcomed back into their village/tribe/city after they have achieved wisdom and humility to temper their might and valor.

So the historical hero is not one who overcomes insurmountable odds.  The historical hero is one who fails to overcome insurmountable odds, and in doing so has to face their own death … the ultimate limitation we all must face.  The hero is the one who faces their limitations, and becomes wiser for them.

So perhaps we don’t need to abandon hero culture in software development.  From where I stand, we actually need to embrace it rather than simply remaining trapped in the adolescent or nascent part.  Until we’ve embedded the entire hero, talk of abandoning him or her is a tad premature.  I think we can learn a lot from them.

Attracting and Retaining Good People

During my “sabbatical” I’ve had a lot of time to read and chat with a lot of people from different walks of life, or at least a lot of people who are team managers, recruiters, product managers, and generally high level muckety-mucks.  The rabble have tended to remain quiet, which is good for rabble.

In any event, there is a common refrain amongst these otherwise perspicacious group (look it up … rabble) that I find either surprising or funny, depending on my mood.  The common refrain is more of a complaint, really.  The complaint has to do with the fact these people all seem to be having a devil of a time attracting, recruiting, and retaining the sort of employees you normally want as a manager.  The people they (and the rest of us) dream of attracting and managing are intellectually curious, skilled, experienced, passionate about their career, and self-motivated.  In other words, the people you don’t actually need to manage except in acting as a conductor who directs and helps enliven the work.

As some one who’s had a small amount of success building out teams apparently made up of these sorts of people, I sometimes am asked about my “secrets” or “techniques” as such.  I’ve been hesitant to divulge my secrets for recruiting really good people, until now.  I will now give you my primary secret/principle for attracting and recruiting top notch talent.

I try and be someone for whom I would want to work every day I’m at work.  The rest of the stuff like training budget, high salaries, beer parties, and the like are largely either out of my control or somewhat superfluous.  Here are the actual things you need to implement and practice if you want to bring talented people to you like ants to spilled ice cream.

Respect – Assume everyone on your team and on other teams (often more difficult) are reasonable, talented adults who can be trusted to do their work efficiently and capably.  If you have reason to believe to the contrary, first check your beliefs.  It’s more likely you are just using a different definition of “efficiently” and “capably” than they.

Openness – This one comes in two parts.  You need to be somewhat explicit in your success expectations.  You also need to be somewhat current and explicit your expectations are not met.  Since we can assume we’re all adults (see above) we can also assume most adults really do want to do a good job.  If you are open to them about how they can do better, they’ll usually surprise you by exceeding your expectations.

Honesty – Being honest usually goes hand in glove with being open, but it also implies consistency.  No one likes aiming at a moving target or being told they messed up sometime in the past, when they’re no chance to correct it.  Honesty is about communicating successes to be celebrated and failures to be corrected.  It’s about engendering a reputation of trust so people feel confident enough to come to you with any problems or victories.

Interest – Everyone likes to think they matter to someone or something.  For most people, this translates to the workplace even if only due to the amount of time we spend there.  A good manager shows interest in their employees’ lives, professional ambitions, and daily toil.  They also show interest in their own role and industry.  Nothing attracts talented people in a certain industry more than the chance to work with others who share their interests.  Nothing keeps talented people around more than knowing they’re valued and appreciated on a daily basis.

Availability – Finally you need to be available to your team as much as humanly possible.  You never know when someone will need help resolving a thorny issue, overcoming a seemingly meaningless bureaucratic hurdle, or just want to kvetch in general about the injustice of it all.  You also never know when someone will want to show off a brilliant solution to a problem or run a new idea by you to see what you think.  You need to do paperwork and attend meetings, but your primary job is to manage a team of people … not resources.  People (even adults) will stop coming to you if they feel they can’t count on you being available.

The other thing to remember is you often don’t have to spend a lot of time recruiting talented people.  You can encourage your current staff to become talented.  In order to do that, you may have to fire or transfer away anyone not willing to themselves practice the rules of respect, openness, honesty, interest, and availability.  That’s the downside of building an excellent team, but there’s no way I can see around it.  Some people do not have the personality or desire to be excellent.  Aptitude is something you can work with.  Personality is not.  You can’t make some one excellent in spite of themself, but you can bring some one down.

In the end, I suppose that’s the one over-arching rule for success as a manager.  Create an environment where people know they are expected to exceed and will be given every tool they need to get there.  If you let them take charge of their own path to excellence, they will always surprise you with their capabilities and growth.  If you force them down your path, they will always disappoint.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,077 other followers