Drinking on the Job and Other Vices

Yaacov Apelbaum-Drinking on the job

Working in an early stage startup can be a blast. For me, it is a most rewarding personal and professional experience. There is minimal bureaucracy to get in the way and you have the opportunity to build the product of your dreams.

True, at times a few dark clouds (like the possibility of not making payroll) may gather on the horizon, but with some ingenuity you can handle it. If you are preparing to ship version 1 of your product, the pre-launch phase or the final sprint can be an ultimate adrenaline\caffeine rush, and the chronic lack of sleep will just enhance the experience.

Working in this environment may not be for everyone. The rapid pace of change, the seemingly never ending To-Do list, and the constant improvisational nature of the work often frustrate individuals who are used to more structured development. Financial stability can be another turn-off. Most early stage startups operate on a shoe string budget using seed\angel money that has to be stretched to the limit in order to build a viable proof of concept. Once in place, the funding and development cycles are repeated in the hopes of surviving long enough to attain commercial viability. These repeating cycles, if not executed properly, can become a tiresome soap opera.

To use an equestrian metaphor to illustrate the development effort in a large organization is somewhat similar to English-style show jumping competitions. A smartly dressed rider moves elegantly between the stations (projects), always maintaining aristocratic poise and composure (an eye on features, schedule, and budget). The same event in a startup looks more like a rodeo, where the inexperienced rider jumps on the back of a wild mustang with neither saddle nor reins and spends the duration of the ride screaming, swearing, and holding on for dear life (dwindling budget and product immaturity) while the horse (the competition) simultaneously kicks, bites and tries to throw him off. Net-net, a tour of duty in a startup can resemble the life of a Caribbean buccaneer. The risks are plentiful but the rewards of a buyout or an IPO can be glorious.

In addition to operational differences, startups also tend to have a more casual and festive corporate culture. To help recruit and retain talent it is not uncommon to offer employees various soft perks like no dress code, the freedom to play interior decorator, and access to amenities such as the latest video games, quality coffee, soft drinks, snacks, and other tech toys.  Some companies, in an attempt to even further sweeten the sub-par monetary compensation will go as far as to abstain from creating work policies regarding vacation, work hours, and employee conduct.

If you are on the management team of a startup, it is tempting to convince yourself that you can make up for low base pay and a high stress work environment with theme park playfulness (a approach not dissimilar from paying for prime real estate with firewater and glass beads). But in reality, trying to convince highly intelligent people that the privilege of working in a glorified techno-utopian commune is an adequate substitute for decent wages amounts to little more than Svengali’s operatic hypnotism, it may work for a while, but sooner than later the effects wear off, leaving you with consequences like high attrition rates and chronically missed deadlines.

Firewater and Glass Beads

In one of my engagements, I had the opportunity to work with a late stage startup. The company desperately needed to mature and commercialize its product and swing to profitability. This had to be done rapidly in order to secure bridge funding.  When I first took over the technology and engineering organization, I discovered that the team had an almost 50% turnover rate and that my two predecessors had left on very disagreeable terms. Initially, I was surprised that the subject of almost every staff meeting revolved around compensation, but that matter quickly came into focus. The developers were disgruntled because, in addition to being significantly underpaid, they hadn’t received their promised bonuses (which accounted for almost 40% of their salary) yet they were still being asked to work 70 hour weeks. It was evident that all the soft perks they were getting didn’t succeed in dulling their memory of the promise.

In another engagements, the CEO refused to budge on the question of base salary and missed bonuses and argued instead that work conditions (flex hours, free sporting event passes, telecommuting, and free alcohol) were more than sufficient  compensation. On the eve of the “Mother-of-all-Sprints,” (a hellish 320 hour coding month), some team members started exhibiting disturbing behavior that included sending inflammatory emails to the entire company (see excerpt below), rowdy conduct in staff meetings, and calling in sick.


As part of the “Mother of all Sprints”, we have been asked to go above and beyond our normal dedication. We have been asked to make major sacrifices in our personal schedules. We have been asked to work harder with longer hours. We have been asked to cancel existing plans we may have put in place with our families. We have effectively been asked to put our lives on hold until the end of the sprint. And we have been asked to do this without any advance warning. Furthermore, many of us disagree with the exact product direction.

  • We disagree on the functionality necessary for the company to go forward.
  • We disagree on what the bottlenecks and limits with the current process are.
  • We disagree on the feature focus of current efforts.
  • We disagree with the release date.
  • No one asked the development team what they felt was important to accomplish.
  • No one asked the development team what features they felt were necessary.
  • No one asked the development team what they they could realistically accomplish.
  • No one asked the development team when the release should occur.
  • We have no real equity in the company. We have no guarantee we will ever receive bonus payments. We have no guarantee that bonuses will be distributed fairly, if they are ever paid out.

So I have to ask myself, what is my personal motivation for doing this? What do I get out of it?

Of course, it didn’t help that the company offered its employees a steady supply of beer and hard liquor, and even had gone as far as openly encouraging everyone to drink on the job (at the ever so popular “Tequila Fridays”). HR wouldn’t implement any conduct policies because they feared that doing so would dilute the startup experience. Not surprisingly, some employees in turn responded by drinking just a bit to much and staying home sick.

Workspace structure and policies are as mandatory as social contracts and are designed to protect us from abuse and anarchy. Hobbes observed that life under the rule of the mob is “nasty, brutish, and short.” Similarly, life in a startup modeling its governance to resemble the “Lord of the Flies” is wretched and hardly short enough.

Unfortunately, no one has the exact formula for balancing discipline with productivity. But I have found the following rules of thumb to be an affective guide:

It may be contrary to your anti-establishment philosophy, but it is in your best interest to create and maintain an orderly work place. Unfortunately, the only way to achieve this is by formalizing rules for all employees and enforcing policies like performance reviews, bonus payments, vacation and sick time without favoritism or exceptions. 

Here are my six golden rules for keeping anarchy at bay:

  1. Provide formal policies regarding company usage of licensed software. It may be true that software yearns to be free, but unless it is properly licensed it should be kept off of company computers. This may sound picayune, but using counterfeit or cracked software is a huge legal issue.
  2. Regardless of how hip and progressive it may seem, do not encourage consumption of alcoholic beverages or drugs on company premises. Every garden has its snake and this one will bite you big time. It’s only a question of time before one of your employees under the influence of something he consumed at work will become a legal liability.
  3. Do not tolerate violent or abusive behavior (such as regular use of foul language or extensive absenteeism) from any employee, including leads and management.
  4. Offer your team competitive financial compensation. If you can’t afford to pay market wages, be honest and upfront about your limitations. Don’t try to renegotiate salaries down by arguing that industry wages are inflated.
  5. Be creative about company spirit and culture. Offer your team as many soft perks as you can, but remember, perks are not a substitute for wages.
  6. Don’t exaggerate or misrepresent bonus target amounts, stock option availability, or plans for employee profit sharing. Be forthcoming about the financial state of the company and its stability. My rule is “promise only what you can deliver” and in a timely manner “deliver what you’ve promised.”

Maintaining transparency and a fair work environment are two of the most important pre-requisites for a smoothly operating startup. Once these are in place, you will discover that you are well underway towards achieving your most ambitious development goals as well.

Good luck.

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

It’s Good Enough for Me

Yaacov Apelbaum-Giacamo the Good

I commute frequently, so I tend to have some down time at the airport while sitting at the gate and waiting for my ship to come in. I usually use this window to catch up on my technical reading, but recently I decided to take a break and venture in to one of the book stores in the concourse. After skimming the offerings, I discovered a bookshelf filled with titles of the “How I Became the Best In ___, and How You Too Can By Simply Following My Easy Three-Step Program” genre. These books, mind you, are not cheep paper backs. I was looking at thick hardbacks, generously illustrated and accordingly priced. Apparently, the “How to Become the Best” series industry is booming.

This got me thinking: statistically speaking, the best of any kind takes up only a tiny outlier of the bell curve. So why the hype? Clearly, if this industry is thriving there are enough literate people out there who were willing to buy into the idea that being the “best” is worth their time and money.

Then a few weeks ago, I found myself confronted with this concept again. I was having lunch with a colleague and he raised the argument that the only way to win in today’s lean software economy is to develop the “best” features and functionality. He expressed his strong conviction by recounting his recent experience at a trendy “how to become the best” seminar. “I am a new man,” he said, “This event has changed my entire outlook on product development”. “How’s that?” I asked, curious. He leaned forward, squinted, and in a lower and somewhat more mysterious voice, he summarized his newly acquired philosophy. He said that according to the presenters, Trump, Robbins, and Kiyosaki, success hinges on one’s ability to tap into one’s inner best. Either you’re Napoleon or you’re out of the game.

At this point, I was done with my burrito and so I seized the opportunity to respond in kind with a rival French maxim. I quoted Voltaire: “Le mieux est l’ennemi du bien” (The Best is the Enemy of the Good). Wellington, I pointed out, was by no means the best, but he certainly outlasted Napoleon in the game.

My companion was startled and said he didn’t understand what I meant. I offered an explanation: “It’s not that I am a proponent of mediocrity; to the contrary,” I said, “I pride myself on my attention to quality. I have absolutely no problem with the concept of pursuing excellence. What prevents me from realizing perfection are mundane details such as looming deadlines, shrinking budgets, and a chronic shortage of resources.”

Of course it’s easy to invoke demagoguery and claim that it’s either “best” or “bust”. Many development managers adapt this mistaken philosophy, assuming that it has a positive motivational value. The average corporate culture doesn’t help dispel this myth either, by creating unattainable criteria for personal performance and compensation plans. Regardless of how fond of the cliché’ you may be, unfortunately preaching the best when it comes to delivering software under time, quality, and budgetary constraints is one thing, actually being able to deliver on such promises is quite another. If we learn anything from human endeavors, it is that “good enough” is more than acceptable. As far as I know, most of us don’t drive the best car on the market, live in the best built house, or exclusively buy the best clothes or appliances. Compromise is the order of the day.

My favorite story that illustrates this concept is the World War II race to develop the radar. Both British and German teams were aware of the tremendous operational and strategic advantage this new technology could offer. The German development team had the more advanced science and superior technology. Their radar was more accurate, had a longer range, and provided fewer false-positives. The German team—true to their cultural heritage—was striving to develop the best apparatus possible. The British team was smaller, less experienced, and had inferior technology. But from the outset, it adopted the motto: “Second Best Tomorrow”. This philosophy eventually allowed them to release an inferior but working radar earlier than the Germans thus winning the race and ultimately tipping the balance of power.

Cheap (often free) and simple software free of stringent SLAs is popping up everywhere. Most of us now get our breaking news from Google and personal blogs, case in point. We make free, long-distance calls on Skype (and don’t mind the low QoS), watch video on tiny iPods screens rather than high definition TVs, and more and more of us are using low-power cell phones that are just good enough to meet our surfing and emailing needs. For many leading companies, the distinction between good enough “beta” versions and commercially “best” products has blurred beyond recognition. (Gmail has finally come out of beta after more than 5 years.)

To be successful in commercial software development, one must fight the urge to gold plate by adding late stage functionality. One must also learn how to be firm regarding ad nauseum pressure for application re-writes, all in the name of making it the best.

Contrary to what the motivational posters profess, when it comes to shipping on-time, the pursuit of perfection can become your worst enemy. The same also applies to excessive QA and testing. In the end, even the most comprehensive white, gray or black box tests can only provide a projection of how your application will perform. The ultimate usefulness gauge are the real users. The earlier you release your product into the wild, the faster you’ll discover if it adequately fills a need.

As I have discovered on many occasions, building a good enough product and releasing it early enough is good enough for most customers—which is good enough for me.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

The Death March

Yaacov Apelbaum-TheDeathMarch

Most software professionals view themselves as the masters of their own destiny, analytical and calculated, wisely exercising free choice in all matters of importance.

This was certainly my mental image of myself as well until several years ago, when I gradually came to realize that given enough time on the job, even the most experienced development manger will eventually have to venture into that dark and irrational world of the death march project.

For those unfamiliar with the term, a death march is not a walk through Ezekiel’s valley of dry bones. Rather, it is a reference to a development project where requirements either exceed the realistic deliverables by at least 50 percent or where critical resources are cut in half without adjusting functionally and schedule delivery accordingly.

Contrary to the common misconception, death march projects are not limited to only naïve and over ambitious startups. To the contrary, they are quite common in large and mature organizations that should know better yet for some poorly understood reason continue to practice every form of anti pattern known to man. How do I know this? Well to confess my sins, over the years I’ve participated in several of these projects.

Perhaps you are wondering why any rational person would choose to participate in or initiate a project that from its onset is clearly doomed to fail. The answer has to do with the adaptive strategies we use in order to survive in highly competitive and schedule driven corporate environments.

When performing a post mortem, most death march software projects typically exhibit the same pathology. The prominent finding is that the team has worked twice as hard and/or twice as long as would be expected in a “normal” project. So for example, if a normal work week is 45 hours, then a death march project team works 15-hour days, six days a week for a 80 hour week. Of course, thanks to a steady diet of caffeine and management coercion, the pressure within the team eventually escalates beyond control and leads to project meltdown.

The psychological drivers behind the willingness of individuals to join what is clearly a long and drawn out sadomasochistic exercise stems from the strong disdain that many of us have for organizational politics and our refusal to take any part in it. Unfortunately, by not participating in the political horse trading, we sacrifice our ability to effectively influence these irrational projects and leave all the decisions to corporate politicians who have little stake in the actual development effort.

Scott Adams, commented on this form of irrational behavior:

“Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs. This is the principle behind lotteries and dating…”

Having reached this realization myself, I eventually started wondering if there were any early signs or warnings that could help identify an imminent death march. After some introspection and reexamination of previous projects, I have come to conclude that any of the following three (individual or combined) project scenarios will almost guarantee the formation of a death march:

  1. Naivety of Youth—The schedule has been compressed to less than half the amount estimated based on previous delivery; so for example a project that would normally be expected to take six months will be set to be delivered in three months or less. This form of a death march is most common in ra-ra speech environments and “Internet time” startups that naively believe that when it comes to their ability to deliver the “sky is the limit”.
  2. The Senility of Old Age—The development team has been reduced to operate at half the capacity. This may have come about as a result of management’s belief that a new development language, framework or technologies will double the team’s productivity. This is often seen in older companies that are downsizing while at the same time transitioning from one technology to another.
  3. Offshoring Hell—The budget for the project has been cut in half because the business believes that offshoring it is a cheaper alternative. In this scenario, the project manager is informed by the business unit sponsoring the project that it’s a “take it or leave it deal” and if the development manager doesn’t accept the budgetary constraints the business unit will offshore the entire project for less. Thus, in an attempt to save his team from the chopping block, the development manager accepts an impossible challenge.

    Another interesting side effect of this type of project is that as soon as management finally realizes that the project is going nowhere fast, they try to salvage it by throwing additional offshore resources at it, which leads to further delays (Brooks’s law).

It is true that many of the contributing factors to a death march may be beyond your control, but if you find yourself involved in one of these coveted assignments don’t panic, take notice. Contrary to the advice dispensed by some purists (i.e. transfer to another team), being assigned to such a project doesn’t mean that you should abandon it or quit your job. My advice is to keep your ethics and personal priorities separate from the politics of the project. Do your best to contribute to the success of the development, but in so doing be sure to set your manager’s expectations to realistic levels.

State your concerns in a non-argumentative and level headed manner and clearly communicate your conditions for participating in the project in terms of exactly how much overtime you will agree to and your willingness to work weekends and holidays.

Without advocating or orchestrating a mutiny, encourage your team members to speak their minds as well. In these ways, although you may not be able to cancel the project, you will likely succeed in regaining some control over it and reduce the amount of stress everyone on your team incurs.

Happy coding!

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

Playing Telephone

Yaacov Apelbaum-Playing Telephone

To those not familiar with the game of Telephone (also known as “Chinese Whispers” or “Russian Scandal”), it involves transferring a message amongst several individuals. The first in line whispers something to the person next to him who in turn passes the message on to the next person and so on. The game ends when the last person in line repeats the message out load. The entertainment value comes in when corruptions are introduced to the original message as it makes its way down stream. If you are wondering how playing Telephone is relevant to software development, read on.

One of the biggest challenges of developing software for new business models is that you only get a short window of opportunity to launch before your competitors join the race. This is contrary to an evolutionary product development where we use a clearly defined road map and feature list. During the early stages of new product design, no one really knows exactly what is needed or how to go about building it (that’s where the cone of uncertainty is the largest). At this early phase, the business has not yet fleshed out their model, the customer base, distribution, and pricing and the development team hasn’t yet picked the tools, platforms or frameworks.

Because of this, the design process defies common sense. If you follow the tried and true PM and SDLC practices (i.e. detailed requirements gathering and formalization phases), you are guaranteed to end up with an outdated design that does not reflect the real business needs. This can be a bit unsettling, when considering that the business requirements document you’ve worked on so hard become obsolete as soon as you send it to the printer.

Yaacov Apelbaum-PDLC Poster

The causes of this paradox stem from the difficulty in articulating and converting new business requirements to a functional product.  Just like in the game of Telephone, the original message tends to get comically distorted as it traverses the line so do the business requirements and the final software solution. Playing telephone can be fun, but it’s not if you are trying to accurately convert business requirements to a software solution in a timely and cost efficient manner.  

How do we address these challenges?  Luckily, over the years several effective methods have been devised. The following are my six favorite cures for playing software requirements telephone:

  1. Shorten the feedback loop for all development activities and streamline your design. Develop less functionality and deliver it early. This approach is based on the OODA Loop originally developed by John Boyd. One of its key requirements is that all stakeholders meet frequently (daily) and promptly iron out all newly discovered problems.
  2. Leverage RAD methods to quickly convert raw business requirements to proof of concepts and prototypes that closely resemble the real business objectives, especially as they apply to the product’s functionality and look and feel. 
  3. Keep project deliverables and key milestones to a weekly time-frame. This will help prevent problems from popping up a month or more later or going undetected until the product is in its downstream phases.
  4. Utilize SCRUM methods to quickly convert business requirements to functional features and smoke test and build daily, so at the end of the weekly cycle you will always have functional code.
  5. Put in place an effective collaborative infrastructure (document depositories, real-time progress dashboards, build automation, accurate bug tracking, etc.). There is no better way to secure trust and cooperation with the business than to maintain transparency. 
  6. Involve all team members in the decision making process, especially the architects and developers actually responsible for designing and coding the product.  Immediately bubble upwards bad news regarding show stoppers like instability, scalability, system performance, and security.

Another important factor to consider is that unfortunate truth that many development team members consider the horse trading side of software development to be tiresome. Naturally they’d rather spend their productive time coding.

Unfortunately, this isolationist mentality only exacerbates the Telephone game. As a development manager, you should work diligently to eliminate it and bring the business as close as possible to the technology. Instead of relying on outside resources to explain a business case or strategy to your team, have your team develop domain expertise in every aspect of your business, including sales, marketing, customer boarding and support. 

I have found the following two approaches to be most effective in achieving this:

  1. If your company has a sales training academy (typically a several day orientation for new salespeople), have your team members attend it. Learning the business from the point of view of a sales rep will help you design more effective and streamlined products.
  2. Actively participate in business strategy meetings and regularly brief your team on upcoming business ventures. Provide technology leadership beyond the current ongoing projects by volunteering to present new technology trends to your business units and show how these trends can benefit the business. Be proactive in putting forward new solutions that can make the business more agile and improve sales and revenue. 

Learning and mastering your company’s business model and gaining a thorough understanding of the market forces where your product will live and compete will go a long way towards being able to navigate the high seas of ambiguous requirements. It will also help you build better and financially successful software.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

What’s with the Chicken?

Yaacov Apelbaum-Chicken

Over the past 50 years, quality and optimization have bloomed into a mature set of practices that are now leveraged in almost every industrial and manufacturing environment. Six Sigma and TQM are just two good examples for such practices. In manufacturing, unlike software development, the relationships between project schedule, component quality, and order of assembly are clearly defined and optimized (i.e. unnecessary motion is reduced.).

For a team working on an automotive assembly line, the practice of stretching deliverables to the extent possible (so long as the assembly line continues to move) is legitimate. Unfortunately, this is not the case in software development.

As product development evolved from mechanical devices to complex software packages, some previously benign scheduling habits have become vices. One such transgression is the practices of the “Schedule Chicken”. And no, this does not refer to the cafeteria’s daily practice of serving charred poultry. The origin of the term comes from 1950’s and has been documented in the movie Rebel Without a Cause. In it, two drivers are racing their hot-rods and are supposed to jump out just before their cars go over the cliff.

The first one to jump out of the car is labeled a “chicken” while the one closest to the cliff’s edge wins bragging rights. From the psychological point of view, it is interesting to note, that the rational for the “Schedule Chicken” behavior is related to the Hawk-Dove method of conflict used by players in game theory. The software development equivalent of this occurs when two or more areas of a product team claim they can deliver their features at an unrealistically early date because each assumes the other team is stretching the predictions even more then they are.

This pretense continually moves forward past one project checkpoint to the next until just before the functionality is actually due. The more mature “Schedule Chicken” practitioner will often delay addressing the obvious for as long as possible, hoping that someone else will hit the breaks and stop their car first. The ceremony in which the team lead finally admits that he can’t deliver the features on time climaxes in a primeval ritual that is reminiscent of ancient Aztec human sacrifices, albeit it’s somewhat more painful.

In the end, it is very difficult for the failed team to recover from being behind schedule, because once the truth is out, all other teams will blame them for the delay. Even if they actually do end up beating the deadline (which is highly unlikely), it will be forever impossible for them to remove the associated stigma of having been “chickens”

So how do you combat the chicken? Here are my top indications that your project has possibly been infected with an avian flu:

  1. While discussing the production schedule people use terms like guesstimating and SWAG
  2. The proposed schedule is not based on a documented matrix of previously developed products
  3. In private conversations, cross team members challenge the validity of their own schedules
  4. The team hopes to make up for lost time by adopting silver bullet tools or technologies
  5. The amount of code necessary and it’s complexity do not match available development resources
  6. Failed smoke tests, quality of builds, and bug bounces do not match the published  status reports
  7. The team is opting to build low level functionality rather than buying it and is insisting that this will actually help accelerate their delivery
  8. Development teams are regularly burning the midnight oil, are putting an exceptional amount of overtime and appear to be worn-out
  9. Project stake holders are starting to use e-mail for the creation of a “legal trail”
  10. Team leads are showing compartmentalized understanding of the project and are unable to walk through all of its dependencies (for example, they may be insisting that it’s not necessary for them to thoroughly understand other team’s implementation details or how the entire solution is going to work)
  11. Project leadership continues to commit itself to unrealistic deliverables like “zero critical bugs” or significant performance improvements, despite having priority bugs and stability issues.

The practice of Schedule Chicken may seem harmless and in some cases may even be encouraged because it promotes survivalist behavior, but in fact, if left unchecked it can have long term devastating psychological effects on the entire team and its ability to develop efficiently.

From my experience, the best mechanisms for combating the chicken are to demand open and honest communications, insisting on peer reviews, and maintaining deep visibility into all project activities.

This is not a simple task as it may goes against the grain of the entire organization but in the end, it beats the alternatives of failure and the blame game.

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

The Überteam

The Uber Team

It’s tempting to view all development teams as homogeneous masses that operate with the same efficiency. When looking for ways to improve productivity, we tend to overlook the human factor and rush to either embrace new management methodologies or focus on incrementally improving some existing processes like requirements management or bug tracking.

Certainly, there is always room for process optimization, but ultimately, these enhancements will only translate to small gains in the team’s overall performance.

In order to realize an order of magnitude improvement, we need to focus on the ‘individual’, who in my opinion is the cornerstone of the software and hardware development process. It has been shown in numerous studies such as Steve McConnell’s Rapid Development that different teams within the same organization can have significantly varying delivery efficiencies.

So how do we explain the formation of islands of excellence within the same organization? After all, don’t all teams within the company share the same HR resources, training, tools and culture?

The short answer is that excellence in operational has a lot to do with management style, team structure, and makeup.

Building and managing strong development teams goes beyond the simple management of developers to quarterly objectives and delivering functional products. What sets apart a high performance team from the garden variety one is that in addition to delivering acceptable products, the high performance team tends to exhibit more loyalty and less splintering. It works smarter, it is more creative, more cohesive and its members are more independent. A high performance team has certain qualities and a distinct spirit which emanates from the individuals in the team.

A high performance team’s esprit de corps is derived from a strong sense of individual belonging, common culture and shared vision. Building and managing this type of a team requires a clear definition of the team’s identity, documented history of success (and failure!), the cultivation of elitism (i.e. an aggressive selection process which makes team membership a coveted privilege), stoking the competitive fire (identifying the competition and targeting it), striving to being different than others and having a reputation for taking on and delivering difficult assignments. Above all, it should be a fun and intellectually rewarding environment.

Even though high performance teams are independent of project type and technology (they are certainly not limited to early stage startups), they all share certain characteristics. I call these the Seven Golden Habits, they are:

  1. Preach and Practice Honesty and Integrity – Always insist that all team dealings and communications (internal and external) be honest and open. The primary building block of all human relationships and the cornerstone of good leadership is integrity (both professional and personal), so you must show personal integrity (in moral decisions always follow the “Et si omnes ego non” principal) and instill its importance in your directs and their team members. You can always explain incompetence and overcome it. Not so with dishonesty and poor integrity.
  2. Promote High Technical, Operational, and Personal Standards – Place strong emphasis on recruiting bright and talented individuals who are passionate about their work and are domain experts. Demand that each team member provides leadership in one or more areas. Work with each team member to develop customized training and professional growth plans and make sure that each has a clearly defined career path that goes beyond basic corporate training (plans for an advanced degree, leadership opportunities, professional certifications, etc.). Inspire them to continually learn so as to further excel. Organize training in emerging technologies, standards and best practices. Promote industry visibility for team members by encouraging them to present papers at conferences and to publish. Public visibility for individual members = visibility for you and the entire team.
  3. Emphasize Accountability and Responsibility – Carefully delegate responsibility and provide your directs and team members with ample opportunities for exposure and high visibility success. Never micro manage! At the same time, expect all assignments to be completed promptly and with a high level of quality. Do not tolerate procrastination and repeated failure to deliver projects on time, over budget or with inferior quality. Provide talented team members with frequent leadership opportunities. Generously give credit where it is due and swiftly sanction habitual underperformers.
  4. Promote Cultural Diversity, Sociability and Friendliness – Recruit heterogeneous individuals (promote cultural, racial and gender diversity). Consider the stimulating exchange of ideas between team members critical for team success as well as for your own personal growth as a manager. As such, encourage the establishment of forums and strategies to build strong collaborative teamwork, some of which may include: inner team mentoring and tutoring, brown bag technical luncheons and sponsorship of after work activities. Do not tolerate any abusive behavior within your team. Get to know each team member personally. Learn about their hobbies, their family and their personal concerns.
  5. Stop the Buck and Delegate – Serve as a single executive focal-point for your management and directs (handling both inbound and outbound escalations). Build, motivate and promote inner team leadership and a successful culture that is based on mutual benefits. Empower direct reports to contribute to the development strategy, while insuring that their action plans and implementations are based on the official strategic goals and well defined market opportunities.
  6. Develop a Competitive and Rewarding Workplace – Institute spot cash bonus programs and prizes (gift cards are a favorite), permit a certain amount of telecommuting when possible, subsidize technical books, on-line education, and hardware and software for personal use, place strong emphasis on social bonding (including after work hours activities and membership in online social networks).
  7. Deal with Ambiguity Effectively – Due to their intangible nature, ambiguity and uncertainty can have devastating effects on any development team. Ambiguity tends to increase with project size and complexity and can stem from many sources that may not be under your team’s control (i.e. budget, schedule, requirements, technology, strategy, etc,). You should expect ambiguity as a given and develop approaches to elevate and counter its effect on your team’s ability to shift gears quickly without having all the facts.

Some of the coping techniques I have used to deal with ambiguity include:

  • Avoid “analysis paralysis” and “deadlocks” – Even though most of us subscribe to a structured, orderly and predictable management methodology, in the absence of more information, you should feel comfortable relying on your team’s advice as well as your personal experience and intuition to reach a decision without endlessly pondering all of the options.
  • Keep clear from the tried-and-true trap – Under conditions where the work threatened by various conditions of uncertainty, traditional solutions may not be feasible, you should push the team to innovate, think out the box, and take calculated risks to insure that business objectives are met.
  • Manage the effects of ambiguity on the team – Understanding the relationship between anxiety, impatience and uncertainty, you should work to develop an effective communication plan and control the effects of uncertainty on the team by: providing daily communication (meetings, e-mails, briefings, etc.), fighting rumors, requiring every team member to provide constructive suggestions, eliminating team splintering and factioning, speaking externally with a single voice, and avoiding finger pointing and blame.

These rules work well whether you are first forming a new team or transitioning forward a mature (and perhaps stubborn) one. Whatever the constellation of your corporate environment and culture is, these are tried and true methods that will yield significant improvements in operational efficiency and product quality.

Contrary to the old adage, you certainly can (and should!) teach an old pooch new tricks.

Good luck!

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.