Let's not indulge in self-delusion, companies are no different than people in this respect. They are the sum total of the people that comprise them but like individuals, they range in effectiveness and many other dimensions. Sometimes large groups of people, in lemming-like fashion, willingly plunge headlong off of one figurative cliff or another. There can be severe dangers inherent in corporate inbreeding, believing one's own press and in drinking the kool-aid.
I once came across a plausible analogy for a corporation as "limited autocracy." Think about it, there is secrecy, absolute power over continuation of individual participation, inability to challenge a wide swath of inappropriate behavior or low business practices and a resulting ability to plant the flag of success in the jaws of defeat. And if you don't like it you can hit the road, Jack.
OK, a little harsh but I'm not saying corporations are all bad. There are some great ones and I've worked for many of them. It's just that there are challenges, many of which result from the collision between what we all hope for from gainful employment; promotion, compensation, advancement; and the goals of the corporation itself which are normally ROI, growth and the other accoutrements of success.
Examples are in order, just to be clear.
During the 70's and 80's IBM distributed software upgrades on magnetic tape. There was extreme deadline pressure, As today, to roll out new releases. Management figured that things would go smoother if they gave managers bonuses for meeting release deadlines. Then we started receiving tapes that would either not install or which contained buggy software. However, we learned to wait for the second or third tape for the same software.
There are analogs within corporations of almost every conceivable human foible and personality disorder. I'm still waiting to see a corporate DSM-5. There is the proverbial elephant in the corporate living room, more likely to happen when challenging ideas, even bad ones, is assured to be career-limiting. If it is easy for individuals to hide the results of their initiatives by sweeping them under the proverbial carpet that carpet can grow lumpy over time. Then the "stuff" can hit the fan and launch the next crusade to remedy the problems. That crusade can even be led by the one who caused the problem in the first place in the same way the arsonist lingers to watch the results of their handiwork and even help the fireman. There are opportunities for key individuals in crisis management when the fix might be remembered much longer than the cause... even when the fix is nothing more than stopping what you were doing.
We can gaze off into the not so distant past for other examples such as those taped internal phone conversations of Enron employees joking about how they were going to screw grandmothers in CA on their power bills. The worst, in that case, bordered on psychopathy.
The IBM and Enron anecdotes are the worst examples of corporate dysfunction and I'm only stating the extreme case for illustrative purposes and somewhat humorously, I hope. Sort of. There has to be some way to define what the corporate challenges might be and for an individual to navigate the straits (s)he might find (her || him)self in. There is a point in all this and if you're still following the thread we'll arrive at it soon, I promise.
I once worked for a Japanese company which, by its own admission, recognized the pitfalls of their cultural tendency to all too willingly and quickly form consensus...thus the reason for intentionally manufacturing some tension resulting from somewhat autonomous US development groups. During my tenure there in an effort to better understand cultural differences I purchased a great book titled Kiss, Bow, or Shake Hands, touted as a "Bestselling Guide to Doing Business in More than 60 Countries." Particularly memorable was the author's description of a culturally instilled trait "asal bapak senari " which translates to "keeping father happy." Apparently upper management in Indonesian companies have a difficult time getting accurate assessments of problems because of employee reluctance to send any messages other than "happy news" upwards.
That's no slam on Japanese culture either. I departed with a deep respect for how the Japanese go about business. At the other extreme are culturally American companies which more resemble a bickering family with little harmony. In a nutshell, the challenges seem to be both manufacturing a healthy tension which allows vigorous debate and ideas to be challenged while, at the same time, not letting it tear the company apart, devolve into a destructive form of competition or result in lingering resent.
There are also challenges in cultivating the precise balance in a company's culture but there are ways to do this among them some element of peer technical review which formalizes the idea of bringing all ideas to the table no matter how conflicting they might be. Observing the introduction of this approach in one company it was noteworthy that the ones having the most difficulties with it were typically the grizzled veterans who we not accustomed to having their ideas challenged. But when done correctly the civility that the process requires can become ingrained and reap great rewards. When the prime objective is not to review the vast majority of code and design even the smallest dose of review has a way of breaking down the walls that prevent essential collaboration.
As a junior developer years ago I'd thought that all companies were created equal. We all interview and rejection, aside from the source of the rejection, can hurt. That was my experience but it might be self-inflicted because of what author Pat Conroy so eloquently described as "that southern boy thing about needing to be liked."
To distill a bit more -- in order to better navigate the organizational straits that might present themselves it helps to understand the challenges that companies face and what the ways they rise to those challenges mean for you as a prospective employee.
There are ways to assess and questions to ask during interviews. The answers to those questions can provide the insights you need. However covertly it might need to be done, you are interviewing the company as much as they are interviewing you.
On the technical side great guidance can be had from the Joel on Software evaluation, devised by Joel Spolsky, formerly of Microsoft. That's a succinct list which he elaborates on further in his book Joel on Software. The number of "YES" answers are a good measure of any software development organization's effectiveness. It's something to consider because "a rising tide lifts all boats" and "you can't fight city hall", as it were. Your personal growth and success can be severely limited by the perspective of the company in which you work. No single individual can move a company from a 2-3 rating to 10+. That's even a challenge for someone near the top, that is if they have deep experience.
The Joel test is also an accurate predictor of whether you'll be building software with the equivalent of rocks and sticks, whether your time on the job doing what you like best (design and implementation?) will be maximized or whether you'll spend most of your time fighting fires and, in a sense, chasing your tail. We are all malleable and not only add to the environment we're pickling in but draw from it as well. It is guaranteed that after years at a company that rates 2 of 12 you won't emerge as the same developer you might if you worked at a company rating 10+ out of 12.
As an aside, I loved question number 8 after having worked in environments in which there were insufficient meeting rooms to support the software development process which necessitates extended periods of heads-down interspersed with flurries of collaboration, brainstorming and information sharing. Sometimes, if the environment or methodology, as practices, does not support this it will not happen as needed.
These things must be taken into account in plotting one's career trajectory and one can't focus on this early enough in his || her career.
You have to be clever in ferreting out the information you want to know about a company. Companies can be as sensitive as a first date, despite being ultimate arbiters of the hire/pass decision. They should be approached with the care and calm one might have trying to hand feed a scared animal in which one sudden move will certainly result in flight.
For example, I once asked "How does your process encourage developers to "plug in" and collaborate as opposed to "going dark" and working in self-imposed confinement avoiding collaboration. That's a mouthful but the issues are very real. We all know that. As it turned out, the company claimed to be "agile" but that term can be used to loosely describe chaotic and "catch as catch can" or it can be being used precisely in the formal sense as a tried an true development methodology addressing the nature of a business in which requirements change rapidly so that locking in on a set of requirements cannot be cast in stone, necessitating shorter iterations and concurrency between prior iteration implementation and the next iteration's requirements gathering. If the interviewer is the least bit sensitive about their methodology being referred to in the former sense then such a question might be perceived as inflexibility or an indictment. So be clever in the way you ask questions.
It not only helps to get the lay of the land in both in terms of technology, apps, business, methodology and infrastructure but also the roles in which you'd be interacting. Asking the general question, which is certainly legitimate, can lead to a motherlode of useful information such as whether there are testers, business analysts, on-site users and project managers. Again, be careful. I once declared that I have come to appreciate the role of business analyst as a user proxy and got a snippy, rather caustic reply of "...maybe, if they're any good!" LOL! I was hardly any better off for having stated it that way as opposed to asking a more general question then reflecting over the response.
Finally, software methodology and development lifecycle are very important predictors of how productive you can be. There is never one-size-fits-all but anything that can provide:
- Accepted, repeatable and generally recognized junctures for collaboration (as is common with most development methodologies) with endorsement at the highest level of management.
- Process rules or guidelines that apply equally to all team members which ensure that leading will be by example rather than from the rear (which can engender resent)
- Widely accepted steps for resolving fundamentally healthy technical disagreement and "moving on"
- Ways to measure performance, defects and velocity and to amend approaches "in stride" using these metrics
- A solid, fundamental; perhaps documented; understanding of build and release steps by all team members
Have fun out there !!!
No comments:
Post a Comment