Your First 90 Days on the Job

Yaacov Apelbaum-First 90 Days

You just landed the technology executive job of your dreams, so what do you do next?  Do you concentrate on the dysfunctional engineering/architectural environment? Do you accelerate the delivery schedule on the flagship revenue platform? Do you tackle that daunting platform upgrade that everybody has been steering clear of for the past several years? Well, you should do none of those, and I’ll tell you why.

Your first ninety days on the job are critical to your long term success. This transition period is characterized by great uncertainty and the risk of deadlocks.  As many eventually discover, the inability to make significant headway during this initial period has little to do with technical intelligence or leadership skill. The common cause for the ninety day blues has to do with communication breakdowns, misaligned expectations, and the onset of a psychiatric condition known as the “Hero Syndrome”.

If you have just given notice and are about to take over new technical management responsibility, you may want to consider the following tips and tricks:

1) Committing to unrealistic deliverables and timelines
The number one trap on my list is to promise too much and commit to specific deliverables too early. Creating unrealistic expectations is one of the most common pitfalls for a new manager. It is all too human to endeavor to dazzle your boss and peers by establishing the reputation of a mover and shaker. Fight this urge until you get a good understanding of what it is exactly that you are about to move and shake.

One great example to illustrate this is the story taken from the Mahābhārata about king Santanu, who commits to a deadly relationship with Ganga without first understanding the repercussions of his decision. It cost him 7 of his 8 children.

2) Pretending you know it all
The second pitfall is believing that you have been there and done that. Regardless of your pedigree and illustrious career, no two projects are ever the same.  You must come to terms with the fact that you can’t possibly have all the answers. My favorite tactic for addressing this is to schedule a day long summit that is dedicated to one core problem.  During the summit, the stake holders present and openly discuss their concerns and views. Spend the time listening to all the domain experts. Don’t be shy, if you don’t understand the issues discussed, ask for a simplified explanation.  In all likelihood, when the fog eventually lifts, you will find that the problem is more complex than you had initially thought.

Another variation on the knowing-it-all syndrome is jumping to conclusions. Quickly embracing a substandard solution as a simple fix to a complex problem can alienate your organization. Team members who believe their leaders’ minds are made up about a problem are usually reluctant to share information or ideas, and this can further impede your ability to learn the true nature of the issue.

3) The good ol’ days and clinging to your old persona
Sometimes without even realizing it, you may discuss your former company or your past success too frequently. The psychology behind this behavior is to use past achievements (real or imaginary) to shore up an argument. This may work some of the time, but it is a double edged sword because doing it habitually can disenfranchise your new team and create the impression that your former company was so much better than your current one, at least in your mind. People may also wonder why—if you loved your old company so much—you didn’t marry it and stay there.

4) Suppressing bad news and dissent
Managers who quash disagreements, bad news, and dissent remove themselves from the real feedback loop and lose the ability to identify and correct problems. It’s easy to create a top to bottom environment that is based on fear. This, however, is guaranteed to drive your brightest team members out the door. The highways are full of smart employees who were given draconian decrees in the style of "it’s my way or the highway." The only ones left in your company parking lot will likely be the mediocre talent who have difficulty driving to their next gig.

5) Chronic Hero Syndrome
Trying to go at it solo is romantic but foolish. If you operate as a lone wolf who insists on forging his/her own way and doing all the work yourself (design, coding, architecture, etc.), you will cut yourself off from valuable sources of domain expertise. Even if you are on the right track, you will eventually burn out or alienate your team.

6) Failing to identify the true sources of corporate power
One important quality you should work on is reading the unwritten laws of your organization.  Depending on the structure of your new company, (startup v. Fortune 500), you may find that real power and ability to effect change is held by the likes of senior architects, product managers, etc. and not your C-class peers.

7) Fighting the wrong battles
As a new leader, you instinctively want to focus on high visibility problem areas and figure out how to solve them. Nothing is more rewarding than to take a leading role in a gunfight at the O.K. Corral. That’s commendable, but not if it comes at the expense of sustaining small gains at GTB (growing the business) while suffering significant losses at RTB (running the business). There is a tendency in the beginning to think that it’s more important to be visible. Fighting too many of these battles can quickly become a huge  black hole that will suck every free moment of your day.

8) "Trashing" your predecessor
My golden rule is to always be respectful and sensitive about my predecessors on the job.  Consider the fact that most of the people you will work with knew the old manager and many are still in touch with him/her and are probably still on friendly terms. Learn as much as you can about your predecessor and the reason for his/her actions. Try to figure out what was done well and what went wrong. If at all possible, insist on getting access to old e-mails and work files. As I have discovered many times, this data can contain pure gold and is probably a good indication of the type of bus that is heading your way.

9) Attempting too much
Whether you like it or not, you are going to be judged on specific deliverables. If you concentrate your focus on too many activities, you may miss the opportunity to allocate a critical mass resources and time to complete high priority projects. To avoid this pitfall, work to prioritize your assignments. My rule is no more than three vital priorities for the first 90 days.

10) Hanging around with the wrong crowd
In life, hanging around with the wrong crowd can get you into trouble. The same thing applies to your new team. If you get inadequate or skewed information, or make all your decisions based on poor advice that comes only from a handful of individuals on your team, you may end up inadvertently politicizing trivial issues. Keep the lines of communication open outside of your organization in order to make sure that you balance inter-team influences.

11) Failing to build a cross-organizational coalition
It’s impossible to get anything done effectively in any size organization without critical mass of support. This is even more important for large corporate initiatives. For you, this means that you very quickly need to identify who the key decision makers are and what they care about, map the organization’s political networks to figure out who influences the influencers, and craft a plan to reach out to build strategic relationships.

Your Recipe for Success
Avoiding the above mentioned traps depends on how well you manage your first ninety days on the job. This means taking the time to evaluate situations, identifying team member strengths/weakness, accelerating learning, negotiating success, building coalitions, and achieving early victories.

Coming into a senior management position from the outside of the organization is tough. You don’t have a reputation to fall back on yet nor an internal Goombah to speak up for you. You must quickly learn about new products, market opportunities, and the mechanics of day-to-day operations – and all this in the context of an unfamiliar political culture.

Yaacov Apelbaum - Werewolf Killing KitTo execute your vision successfully, avoid using political clout and authority. Instead,  leverage your team members to get the job done. I use the “clip with 3 silver bullets” metaphor. You can use management directives 3 times, but each time you do, you spend one of your silver bullets. After your last management directive, you are effectively out of ammunition and it’s only a question of time before the werewolves will get you.

This means building a good relationship with team members from other business units who have their own agendas. It means creating supportive relationships with your manager and peers who have different styles and objectives. It means motivating a wide range of employees who probably feel threatened by you. So how do you put this hundred ton flywheel in motion and secure support? You do it by following these battle proven directives:

1) Manage your management team
What makes companies like Intel, Google, and Apple successful is their talented and high-performing employees. Creativity, product innovation, and development efficiency are largely based on good technology management practices.  Whether you are coming in as CTO to resuscitate a fallen giant, or as a VP of engineering in a startup to get their product to market, the primary lesson is that you can’t do it alone.  You need to build a dependable management team that should be able to survive the loss of any of its key members (including you) and still continue to function.  For you, that means working out individual secession plans and career paths.

Neff and Citrin, in their book, You’re in Charge-Now What? argue that the difference between short term success and great enduring success is how you practice leadership and shape your management team in the early days, and then motivate and develop them over a longer period of time.

2) Develop and articulate your strategic plan
In the fog of battle, it may seem as if there is no time to think, but that’s not the case. Take your time and work out your plans. As a new executive, you are not expected to produce a fully functional strategic plan in the first ninety days. You should instead try to strike a balance between developing a comprehensive map of where you want to take the organization without immediately becoming prematurely bound to it.

The first ninety days are your honeymoon period and as a new manager, you are allowed to walk a fine line. You must develop credibility through action but at the same time,  if you act too quickly before gaining a complete understanding of the situation, you may risk making the wrong choices.

3) Communicate
Communication is probably the most important aspect of good leadership. Effective communication has a disproportionate effect on your success during the early period.

Don’t miss the opportunity to communicate daily and to communicate well.  Listen carefully during meetings, take careful notes (write down and learn every acronym), follow-up on conversations to get in-depth explanations for issues that you didn’t grasp initially, be punctual showing up to meetings and returning e-mails and phone calls, and provide constructive non-polemic feedback.

4) Transform the culture, but do it slowly…
Every organization has a different ecosystem and operational nuances. Before you start transforming the organization, learn about the culture of the company and identify its bureaucratic and operational bottlenecks. It is critical to first learn "how they do things around here" and to identify the knowledge network, secret handshakes, chief influencers, decision-protocols, and unwritten conventions that form the nervous system of your new organization.

A few good areas for investigation are procurement, recruitment, release management, and quality tracking. My two personal favorites are to go through the actual steps of composing and submitting a request for a piece of software or hardware and a new headcount justification request. You will be amazed how much you can learn about the company by completing these two tasks. Once you get your finger on the pulse, you can begin to intelligently effect change and take the right transformational steps. This would include: instituting new operating procedures, choosing a new management team, setting up governance boards, identifying change leaders, and leading by example.

Finally, change is unavoidable, but it is important to remember that rapid and excessive change can destroy the work culture and the change agent (i.e., you). So, instead of adapting a deeply disruptive strategy such as reinventing everything or replacing key people, try the following long terms initiatives:

  • Set up pilot and POC projects
  • Change the way performance is measured and tracked (digital dashboards)
  • Educate and train your team (gain expertise in your entire technology stack)
  • Build up islands of excellence (tiger team, high performance SCRUM teams, etc.)
  • Document how the technology organization operates (process and roadmaps)
  • Collectively envision new ways to operate (what to sunset, upgrade, etc.)

5) Get to know your boss, your greatest ally
A key success factor in your new job is to establish a productive working relationship with your new boss. It is important that you spend some time together on daily basis. This includes keeping him/her informed of your thoughts and actions, discussing proposed changes, and updating him/her on your deliverables.

It is also imperative that you quickly size up your boss, including high priority goals, pain points, strengths, weaknesses, blind spots, and preferred work style.

Remember, your boss is your greatest ally, because he/she can link you to all the right individuals in the rest of the organization, help you set priorities, and secure the resources you need to get your job done.  All of this is free and comes without you having to spend any political capital at all.

 

For a more detailed treatment on how to max the first 90 days on the job, check out: The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael Watkins

 

© Copyright 2011 Yaacov Apelbaum All Rights Reserved.

Advertisements

Ode to The Code Monkey

 Yaacov Apelbaum-Code Monkey  
The Code Monkey (inspired by A Dream Within A Dream by Edgar Allan Poe)

Take another slap upon the cheek,
While slaving on this project, week by week. 
You have been wrong to work so hard,
Expecting riches and managerial regard.
Grinding out functions awake and in a dream,
Will not fetch rewards or professional esteem.

What you lack are not more lines of code, 
Rather it’s architecture and a road.
To substitute quality with speed,
Is the motto of the code monkey creed. 
You who seek salvation in RAD extreme
Will find, alas, a dream within a dream.

If you examine your latest stable build,
You will notice many bugs that haven’t been killed.
Strangely, they seem to grow in relation,
To your oversized code base inflation.
So many new features! How did they creep? 
Through scope expansion, they trickle deep.

Building good software is hard to manifest,
If you fail the requirements to first digest.
The lesson to learn from this development ditty,
Is that no matter how clever you are or witty,
If you fudge the schedule and estimation phase,
There is but one reward for you. The death march malaise!

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Designed for Humans

Yaacov Apelbaum-Designed for Humans

In my previous life, I was a civil engineer. I worked for a large power marine construction company doing structural design and field engineering. The work assignments were pretty interesting. I got to blow up a bridge, salvage a sunken vessels, and build a lot of interesting marine structures.  On one of my projects, I was given the responsibility to design a set of beds for pre-stressed concrete piles.  The design challenges in this project were significant. We had limited real-estate and the loads involved were higher than any previously attempted.

Yaacov Apelbaum-Prestressed Concrete Piles Beds for pre-stressed concrete have massive anchors on each end. Between them steel forms are placed and steel cables are strung.  The cables are first tensioned, then the concrete is poured into the form.  When the concrete hardens, you cap the cables and cut them.  The result is a pile or a girder that is significantly resistant to various loads.

Following best engineering practices, I completed a structural load analysis document, a set of production blueprints with full dimensional drawings, welding, coating and assembly instructions, a bill of materials, and even a balsa scale model to help the manufacturing facility to visualize my design. Yaacov Apelbaum-Prestress Bed Scale Model

I was proud of my hard work and I felt that it was a great achievement.  The day before the presentation, I went over all the calculations again and rehearsed my slides.  After one last sleepless night, I arrived to the conference room to find several structural engineers, the yard superintendent, a number of field engineers from several divisions, and the chief engineer from corporate, an elderly white haired gentleman in his mid-sixties.  I remember feeling confident in my ability to sell my design to them.

The entire presentation went off without a glitch.  There were some stylistic comments but the overall feedback was good.  After the presentation, the chief engineer stopped by, shook my hand, and said that he liked my design very much.  Then with a straight face, he told me that he expected to see two additional alternative designs before we finalize our decision.

I was speechless.  “I’m not sure I understand, sir” I said. “Didn’t you just say that you liked the design?” I pointed out that none of the participants had found any flaws in my proposal.  “Why", I asked, “did you think we need to develop two additional designs?”

He paused for a moment, and then said, "You never know what the best idea is unless you compare several good ones side by side." I nodded politely, but I was disappointed. I felt like this was probably some form of engineering hazing. Was it truly the case that it’s impossible to achieve reasonable quality on a first try? I didn’t really understand how valuable his advice was until years later.

Yaacov Apelbaum-Pre-Stressed Concrete Bed

Completed pre-stressed concrete beds

Fast forward several years. I switched from civil engineering to software development.  At the time I was working as a lead front-end designer.  One of our key customers hired us to migrate a large VC++ client to a browser application.  In the mid-nineties, rich browser based clients were relatively unheard of.  We were stumped. Problems like session security, persistence, and lack of basic GUI controls seemed Insurmountable.

During meetings, I would regularly sketch various GUI solutions.  But I often found that as soon as I came up with a solution, a new set of problems would be exposed and a redesign would be necessary. In retrospect, most of the ideas I came up with at the time were sub-par. But with each design, no matter how bad, another potential solution was discovered.  Each new design I sketched out was closer to the solution than its predecessor. Even the poor designs peeled away some layers that obstructed the problem that I didn’t initially see.

After dozens of attempts, I had an epiphany and came up with one design that it was possible to implement in several ways. Sketching and contemplating the various designs helped me tremendously, but when the time came to present my solution, I made a tactical mistake. I deliberately neglected to show all of the other working ideas for fear that they would think that I was a mediocre designer; why else did I need to work so hard on so many designs just to yield one single decent one.

I realized in retrospect that there would have been any number of acceptable designs and by not presenting some other ideas I considered before arriving at the one I chose, I short changed myself. If anybody had suggested one of the other options I had discarded but not mentioned, I would have had to explain that I had already discarded that idea. But at that point , it would jeopardize my credibility because it would look as if I was only trying to brush them off.

 

 Yaacov Apelbaum-Poor Design   Yaacov Apelbaum-Quality Design M1917

Multiple product designs


After participating in and leading many painful design meetings, I have come to the realization that the best way to sell the top design idea is to first share some of the alternative and inferior designs.

If you are responsible for usability or user interface design, you have to develop at least several alternative options for credibility purposes. By that I don’t mean that you should become a cynic and create duds just for the sake of generating volume. The alternate ideas have to represent meaningful and functional choices.

Once you have your alternates worked out, walk through the various options during your design meeting and call out what the pros and cons are for each and what the overall solution trade-offs would be. When discussing designs, place emphasis on both the positive and negative qualities of each alternative.  This will help your peers view you as an unbiased and professional presenter.  Also, you may find that when you present your top candidates, your team will come up with some hybrid solutions that otherwise would have been impossible to generate if you had only presented a single one.

Nowadays, I am often tasked with working on problems that are exceptionally difficult to overcome (with respect to both technology and schedule) and the typical, off the shelf solution is just not sufficient. But there is hope. Usually after a few days of intense interterm deliberations complete with often heated exchanges of alternate designs, magic happens.

My secret sauce for breaking down the most difficult design problems consists of the following steps:

1. Get your entire team into a conference room, order plenty of pizza and write down all possible solutions on the whiteboard. Make sure that everyone offers an opinion. Don’t make any go-no-go decisions during your first meeting; rather leave the information on the board for several days (don’t forget to mark it as ‘do not delete’)  and schedule a follow-up meeting. Tell everyone to document the pros an cons list for each option and provide specific use cases.

2. Get your team into a conference room a second time, order plenty of pizza and write down the pros and cons list for each choice.  Boil down your choices to the top three candidates.

3. Work out the feasibility of each of the top three candidates and cast a vote for the best one.  This is the time to establish consensus and a team buy-in.

    Way back when the chief engineer asked me to come up with two additional alternate designs, he was in fact telling me that no matter how talented a person is, there is tremendous value in variety.  He was also saying, that in order to come up with a ‘good’ design there must first be several inferior ones. If you are responsible for the design of any product futures, you will want to encourage your team to flesh out the bad designs on the whiteboard or as POC, not in your final product.  Unfortunately, the only way to achieve this is by expending resources and time exploring several possible solutions, up to and including some unattractive ones.

    A common development folly (see It’s Good Enough for me) is the notion that there is in fact a ‘best’ solution or one right answer to a given problem.  Actually, the opposite is true. Considering time and resources, in most cases, the ‘best’ possible solution isn’t worth the effort and a ‘good’ solution would more than suffice.

    If you are curious abut which design I ended up using for the prestress pile beds, it was the third one.  It turns out that unexpectedly, after I reconsidered the problem again, I realized that due to the yard’s location at sea level, the water table was too high to accommodate my initial proposal. As a result, my updated design required various modifications in order to solve this problem.

Live, design and prosper.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Crafting Great Software Features Part-1

Yaacov Apelbaum-Useless Technology  
Latest Features: Driver’s Entertainment System and Password Protected Gear Shifter

Trying to do anything well is difficult. Developing useful features is no different. It takes more effort to create useful functionality than to produce eye candy.

Good feature design comes from a reliable and repeatable process (not dissimilar from CMM). Unfortunately, many organizations still have not figured this out and instead of investing in usability engineering, they slug it out in isolation and tragically, like Sisyphus , doom themselves to getting the wrong functionality and spend eternity (or until the project is canceled or runs out of money) patching their mistakes, version after version.

If your goal is to build a useful product, you should schedule your project so you can develop the needed functionality. Habitually excusing yourself by claiming that you "just don’t have the time" to develop quality is a cop-out. If you find that your team is spending a significant amount of time on feature seesaws (taking them out-putting them back), it means that you’re not planning well, and that the technical goals are not aligned with the product objectives.

Feature Framework

In a functional development organization, everyone should fully understands how their individual contributions will impact the end user. To help achieve this, there should be a feature framework in place.  The feature framework  must cross organizational lines and bridge development, PM, product planning, sales, and marketing.  The chief purpose of the framework is to determine what challenges end-users have and how a proposed feature, functionality, or technology will solve those problems. Without utilizing some degree of Feature Driven Development, you stand the risk of creating features that may look great (like password protected gear shifter) but solve no real problems.

Management Knows Best, Well, not Always…

In order for you to master the product usability question, you have to conduct real life tests with real would-be users. Talk to your customers about their pain points and ask them what they love (and hate) about your product.  The earlier you get the bad news, the better you’ll be in the long run.

Keep in mind that most failures in software usability can be attributed to poor decisions at the executive level, which are promulgated due to a culture of silence. Developers and designers should be encouraged to think critically about their work and be provided with official channels for expressing their opinions (in a non polemic manner).

Make sure they talk to the the other members of your team to broaden their horizons.  Invite their participation in every feature conversation. When considering new or revolutionary UI changes, solicit input from your customers and your organization.  Without sufficient end-user, business justification, and sales input, its easy to develop functionality that universally disliked (like the notorious Microsoft Clippy feature).

One of the most common development failures (after underestimating feature complexity and the cost and time to develop it) is the inability to correctly define the problem space and instead to develop solutions that are looking for a problem.  If the project objective is vague and not granular enough, it’s impossible to know whether it has been solved or not. Furthermore, even if the objective is well defined, you may still be working with the wrong assumptions about what the customer really needs.

A video screen built into a steering wheel that plays looped safety movies won’t help your user drive any safer. These two types of problems—vague objectives and the wrong assumptions—have nothing to do with your team’s technical ability. If you can’t side step these kinds of issues, even the best software engineers and designers are bound to fail. You may write great functionality and create whooping UI, but if you can’t solve the right user problem, all of your hard work will be wasted.

Do you have a Problem with That?
The first step towards critical feature analysis is to take an objective view on the nature of the problem. As a developer, you are inherently biased towards the value of your features and suffer from a certain degree myopathy. You’re inside the tech bubble looking out and so you cannot possibly see your creations the way your users do.

Yaacov Apelbaum-Team Structure To improve visibility, you need to supplement your view with external sources. These should include: UI team, technical developers, product business champion, actual customers, sales, training, and marketing.  Get as many alternative views as you can. Again, make sure to talk directly with the users effected by the design, Don’t take single  camp’s word for what the problems are. Think of yourself as a newly elected congressman trying to keep your constituents happy. Don’t only consider the opinions of the power lobbyists.

Another challenge is that the way approach your customers for feedback will impact the type of information you get from them. If you unintentionally bias your questions, you’ll get skewed data. The art of observing and understanding customers needs is an acquired skill and it may take several trial runs before it’s honed.

When researching the problem, keep the following key questions in mind:

  1.  Who are your user’s, what are their skills and job functions?
  2.  What is your user’s workflow and how does your product enhance it?
  3.  Do your users use other products to supplement your app?
  4.  What business assumptions are you making about your users and their environment?
  5.  What are your user’s specific deliverables (spreadsheets, reports, presentations, etc.)?
  6.  How do your competitors solve the same problems you are working on?
  7.  What is your user’s strategic information roadmap and how does your app fit into it?

If you don’t have complete responses to these questions, you cannot start to design or develop any features or functionality. a solid understanding of your customers and the answers to these questions form the foundation of your application.


You Only Get One Chance, So Chose Wisely
As you are preparing to work on your next version, you will discover that there is an infinite number of issues that need solutions and a mile long list of most have features. But just having a raw list of bugs and features isn’t enough to build a product.  As it goes in life, some problems are not worth solving once you consider their poor return on investment and time.

Often, a solution to one problem spawns multiple new problems (and bugs). You need to exercise good judgment, which means having the ability to distinguish what should be done from what can be done. After collecting the business requirements, the next step is the development roadmap. You have to synthesize the requirements and create a specific action plan for where to invest your time and resources.

With the data collected from customers and internal sources, distill the information into short one-sentence lists. These sentences should be written from the point of view of your end-user. For example, "Enable password field to accept 11 characters" is not a problem statement. But "Password field must support strong passwords" is. The difference is significant. You rarely want to define the solution and the problem in the same statement: If you do, you’ll miss the real problem.

In this example, there may be many other ways to solve the problem of password strength, including hard coding the logic to accept 11 characters. But if you are too focused, you’ll never see the alternatives (make the password length database driven, integrate it with LDAP, biometrics, etc.). Good feature development is all about understanding your alternatives.

Yaacov Apelbaum-problem to a solution For each problem statement, provide supporting information. Include details about which users have the problem, how it was discovered, and what the potential workarounds are. Determine whether the problem only occurs in certain configurations. Following Feynman’s rule of scientific integrity, provide as much details as you can to allow others to confirm or challenge your assumptions.

If you’re the owner of the usability study or market research data make it available to everyone.  Don’t ask anyone to “trust you”. The more open you are about your feature sources, the less likely it is that people will suspect you.

A solution looking for a problem

Hold your Fire
Only start coding when you see “the whites of their eyes”.  When the goals are set and the problems to be solved have been well defined and understood, you can begin to build the features. Instead of adopting a top to bottom approach (where the development team is told what to do), engineers and UI designers should have free rein to generate the ideas that will solve the problems. Time should be allocated to investigate different alternatives that might provide the necessary functionality, and to run usability studies on prototypes to see if they actually improve the end-user experience. Only once you evaluate all your potential solutions and pick the best one can you engage in full speed development. The rest of your solutions do not have to be disregarded; you can shelve them for future releases.

As long as you are working within a feature framework, you are guaranteed to be marching in the right product direction. There should be a lot of innovative and creative juices flowing in your team, and even if you can’t completely solve all of your feature functionality challenges, a partial solution to the most important problem will still be superior to a perfect solution to the wrong problem.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Developers Just Wanna Have Fun

 Yaacov Apelbaum-The Cinawaffle

The Cinawaffle DX250 Waffle Maker\DVD\MP3 Player is Remote Controlled and Bluetooth Enabled.  It Comes Standard with an SDK and a Built-in Web Server.

One of the greatest fallacies in software development circles is that great products must be made with cutting edge technologies.

This belief is not coincidental, as most of the people who work in high tech maintain a passionate love affair with technology. If you ask most of us about our willingness to work long hours on risky and challenging projects, the answer is likely to sound something like: “I love technology, it’s fun,” or “I enjoy playing with technology; I can’t believe that someone is actually willing to pay me to do this job.”

Hardcore techies aren’t the only ones who are enamored, It seems that since the ushering in of the industrial revolution, we all have come to embrace the utopian belief that technology will one day solve all of humanity’s problems.

Believing this, many seasoned business and dev managers fall into a trap and tend to package unnecessary technology into their applications. Unfortunately, this is most often done to the detriment of the product and its users who fail to leverage or appreciate the complexity it brings.

I have witnessed numerous product launches where the entire company stood in awe at the sight of their own technical achievements.  Managers and developers alike were congratulating each other on overcoming what early on seemed to be impossible development roadblocks. All without any regards for the sketchy implementation and clear sight of the purpose that such functionality might serve.

Yaacov Apelbaum-Neo LudditeYaacov Apelbaum-Luddite Reward At the risk of sounding like a Neo luddite, I would argue that our infatuation with technology doesn’t always lead us to develop the products our customers need.

When you were interviewing for your last gig, you likely stated that the ability to work with new technology and learn new tricks was a significant factor in your decision to apply for the position. You may have also been told by your interviewer that his company prides itself on maintaining a fun work environment and that you would get the opportunity to work on some very cool and cutting edge projects.

I believe that personal and company success hinges on establishing a creative, unpretentious, and challenging work environment.  But that’s not the whole recipe for success.  Any organization that hires expensive technical staff cannot afford to do it for fun’s sake only.  A company can only sustain a playful atmosphere if an increasing number of paying customers embrace and consider its product useful.

The reason for this is simple. Contrary to the common misconception, it’s not angel funding, seed money, or bridge loans that pay for your operation. Rather, your end users end up picking up the tab for all of your company’s salaries as well as for the espresso machine, the new Wii\Xbox station, and the billiards table.   In light of this, every activity you engage in (e.g. design, coding, or testing) must directly benefit your costumers and end user.

How granular are the effects of product usability on your daily work?  Each line of code you write, every bug you find, every new feature you consider must help the user improve his productivity in some quantifiable way. No matter how obscure or indirect your current project is, streamlining the user interface, improving application stability, or optimizing performance, all must directly benefit your customer. If you can’t clearly see how your work improves the user experience, consider investing your time on some other activity. The more frequently you think about your work in terms of end-user productivity, the more impact you will have on creating a profitable product.

Beauty of Simplicity

The greatest engineering feats are the ones we don’t notice. The hallmark of a great designer is his ability to translate complexity into simplicity. The automatic transmission in a car represents significantly more engineering effort than a manual transmission, but it dramatically transforms the average user experience. The best engineering, architectural, and consumer products always focus on improving user experience and hiding complexity, not showcasing it.

The most effective approach to adding value to products is to add power and ease of use while reducing the learning curve. When you are developing a new feature, ask yourself, is there some way to add it without changing the user interface? (users hate learning new interfaces)  Can we solve a problem by re-designing workflow or consolidating instead of adding more screens and menus?  Or is there some other feature we can modify to include new and improved functionality? Think of car manufactures and how they add major new features with minimal user impact. The dashboard almost never changes, rear anti-collision video monitoring is integrated into the GPS display, anti-lock brakes are added to the standard brake pedal UI, and power steering is added to the steering wheel UI. Minimal training is required on the part of the user to reap the benefits of these new features. This kind of design approach—where complex functionality appears simple to the user—helps create great products.

There are countless opportunities throughout your application to provide a great user experience. Watch your customers usage of your top features and ask yourself how they compares to the level of service you’d get in a 5 star establishment.  Is the product fast, intuitive and easy to use?  Is efficient help always available promptly? Is it easy to get information out of it? And most importantly, does your product enhance the user’s productivity and business process flow?

Regardless of the technology you adopt, the closer your application’s usability matches the levels of service people get in their daily physical experiences, the closer you’ll be to having a great and useful product.

 

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

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 toys like Kindles.  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.

Yaacov Apelbaum-Firewater and Glass BeadsIf 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 reenacting 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.

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 Flame Mail excerpt below), rowdy conduct in staff meetings, and calling in sick.

Gentlemen,

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.

  1. We disagree on the functionality necessary for the company to go forward.
  2. We disagree on what the bottlenecks and limits with the current process are.
  3. We disagree on the feature focus of current efforts.
  4. We disagree with the release date.
  5. No one asked the development team what they felt was important to accomplish.
  6. No one asked the development team what features they felt were necessary.
  7. No one asked the development team what they they could realistically accomplish.
  8. No one asked the development team when the release should occur.
  9. 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?

Flame Mail

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, staying home sick, and reducing their productivity.

Workspace structure and policies are as mandatory as social contracts are 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.
  • 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.
  • 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.
  • Do not tolerate violent or abusive behavior (such as regular use of foul language or extensive absenteeism) from any employee, including leads and management.
  • 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.
  • 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.
  • 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 golden 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

Fighting the Best Defending 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.