Archive for the ‘Uncategorized’ Category

Which mode does your technology organization operate: yesterday, today, or tomorrow?

April 8, 2012 1 comment

Long flights can have unexpected benefits:  the person sitting next to you and how much you can learn from this person.

While in transit over the Atlantic some time ago, my neighbor was a CEO of a high technology company.   Twenty minutes into our conversation, he asked me, “as a CTO, what is the single most important concern that keeps me up at night”.

I paused for a moment and answered,

… whether my technology organization operates in yesterday, today, or tomorrow mode.

He smiled, signaling that he understood exactly what it meant.

The question of operating in yesterday, today, or tomorrow is everywhere – not just in software or high technology market alone.   Everyone heard of the expression, “do not delay until tomorrow what can be done today”.

I will illustrate several helpful examples – very familiar to all CTOs:

– The competitor unexpectedly launches a new product which instantly places your own product about 9 months behind
– Your technology organization does not have the skills to refactor the product prior to accelerating the delivery of new features
– Your budget has been set 10 months ago and the conversation about incremental funding is moving too slowly
– The team is clearly stressed and very reluctant to work even harder, despite working at a breaking point for quite some time

By this point, it is clear that something is wrong.   If the CTO does not respond to these alarms, the technology organization will fail to execute – reasons no longer being important after the failure – and equally fail to support the change needed to reposition the business towards a position of competitive parity or – better yet – a clear position of strength.

In my experience, a small percentage of technology organizations operate in ‘tomorrow’ mode:  for some reason, everything that needs to happen today, happens tomorrow.   The product management organization produces requirements late.  Designs are not completed on time, or worse – poor designs still become the norm in subsequent releases creating or expanding technical debt.   Critical releases miss dates.   These organizations do not survive for too long and the right change in leadership will move the organization to operate in ‘today’ mode.

The vast majority of technology organizations operate in ‘today’ mode and spend too much time celebrating the fact that a release planned 6 months ago has been delivered on time.   What if a competitor launches a market-breaking, disruptive solution offering and the technology organization now has to deliver the current release 3 months earlier and deliver a new product at the same time?   Suddenly, being very good at tactical execution of a release planned 6 months ago is no longer the reason to celebrate.

High performance technology organization always – always – operate in ‘yesterday’ mode.   These organizations deliberately plan and execute critical initiatives many months ago in order to get ahead of the competition.


– Planning a complex refactoring effort well in advance in order to create more flexibility in the architecture or component model and be well positioned to accelerate the delivery of important features.
– Creating a succession plan for critical skills and proactively hiring ahead.   It takes at least 12 months of deliberate organizational transformation focus to upgrade the skill profile of a technology organization, while managing the natural disruption of under performers leaving and new stars arriving.
– Creating a global development organization with 4 teams working in 4 global locations and accelerating product development velocity by at least 60%.    This typically takes 18-24 months.

So what did I learn from the CEO sitting next to me on a long flight?

“Today is meaningless because today is mainly influenced by what happened yesterday.   If we are lucky, we may spend some time today to plan a better tomorrow”

“Yesterday is therefore the most important day.   If we do the right things yesterday, today and tomorrow will automatically benefit”

There is a lot of truth in what I learned from this CEO.

High performance technology organizations are fanatical about operating in an anticipatory mode (yesterday) and are better than their closest competitor in responding quickly to changes in business  climate.

Which mode does your technology organization operate?

Categories: Uncategorized

5 mistakes growing companies make when hiring a CTO (the results could be fatal)

The examples of hiring the right person for the job – outside of the software business – are everywhere.

– Passengers on a Boeing 737-800 know that the pilot in command has been properly trained to fly this aircraft
– Passengers on an Airbus A320 know the same
– The country or state where you reside asked you to pass a driver license exam in order to drive

Yet growing technology companies make mistakes – often fatal mistakes – when hiring a CTO, in this case someone who will play a leading, critical role in formulating a technology strategy (with a plan to deliver of course) in growing the business.

Mistake 1:  Failure to ask the right questions and assess how you – as a company – arrived at the present moment in time

“There is a reason why today is meaningless and meaningful at the same time.  Meaningless – because today is simply an outcome of everything we have done yesterday.   Meaningful – because everything we do today will influence tomorrow.”

– Are you a company that has evolved via acquisitions or organic growth?   How would you rate yourself against the industry and closest competitors?
– Who is your competition?  How well do you know your competitors and their technology leadership team?    Will your new CTO be as capable as their CTOs?
– What is your growth strategy?  Is there an organizational strategy to support the growth strategy?
– What is the true state of the product?  Zero technical debt or lots of technical debt?
– Is there tension between members of the executive team?   There is always some healthy tension.  But – is there a fundamental misalignment between the strategic agenda and the ability to execute?  Would the new CTO simply add to the tension and – despite their best efforts – fail early?

Mistake 2:  Failure to create a clinical competency matrix which clearly defines who we want as the new CTO

Yes – the competency matrix has to be clinical (or “binary clear”).

Imagine the following scenario.   The new CTO joins the company and quickly notices that the sales team is actually very average.   What’s the point of building a fantastic product if the sales team cannot sell it?   Removing the constraints of organizational boundaries, what is the right thing to do?   Will the new CTO have the organizational courage and maturity to engage and help the sales team sell?  And if this approach does not work, approach the CEO and explain the problem?

That’s why Mistake 1 above is the one that almost always leads to a fatal outcome.   Growing companies that do not know themselves – or fail to learn about themselves – have very little chance of successfully hiring the right CTO.   Unless the company knows itself, it cannot create the very matrix which will define the right CTO against which the candidates will be compared during the search efforts.

Mistake 3:   Failure to hire the right candidate vs seeking “safe” candidate

“Safe” candidates are very attractive:  do not have to relocate anyone, may be coming from the competitor (but are they capable of quantum innovation or simply able to avoid mistakes that the competitive circles already know).

The right candidate are much more difficult to identify unless the competency matrix is “binary clear”.   Once identified however, open all doors to get this person onboard.

Mistake 4:   Failure to accommodate the friction which is always associated with progress

The right candidate will cause friction.  It’s inevitable.  Progress is impossible with friction.

Does the executive team understand the strategic direction and how the newly hired CTO will help achieve the desired business outcome?  Change will be inevitable and with progress friction will arrive.   Is everyone truly ready for change and some healthy incremental friction?

Mistake 5:   Failure to support the newly hired CTO

Newly hired CTOs fail for many reasons.   One of the major reasons is failure to understand and engage their team.  I always suggest that any new CTO should spend the first 30-45 days in the trenches to understand everyone’s challenges and needs.  Only then the new CTO will have enough organizational capital to  describe the mission and inspire everyone to follow.   The second major reason why a new CTO fails is lack of support from the executive team that invested an incredible amount of time (and sometimes money) to find the right person and not the “safest” candidate for the job.  As an agent of change and progress, the new CTO will be a messenger of disappointing news in the beginning.   One of their early goals is to understand what works and does not work before suggesting a specific course of action.   Do not shoot the messenger.   If the new CTO fails, you will fail with him or her.

Data driven testing: the last mile in the journey towards automated testing

May 30, 2010 1 comment

The promise of automated testing benefits remains just a promise unless there is commitment to implement data driven testing.

Instead of defining data driven testing (there are many good books and articles written on the subject), let’s simply take a look at the problem from two perspectives:  “I am a customer and I have a problem” and “I am a software vendor and I can’t believe this customer keeps encountering the same problem”.

“I am a customer and I have a problem”; in every instance – the only perspective that matters:

– The new software release has done nothing to solve the problem that has been open for many months
– This error happens frequently enough.  Why can’t someone fix it?
– Other customers we spoke to do not seem to have the same problem (one of the indicators that the customer’s unique data may be a contributing factor)

“I am a software vendor and I can’t believe this customer keeps encountering the same problem”:

– We tested everything and this problem still affects only this specific customer

It’s important to recognize that companies in the same industry will use the software differently.   To illustrate, companies in the retail industry (customers of your software products) can sell …

– Apparel
– Consumer electronics
– Office supplies
– Pharmaceuticals
– Footwear
– Home improvement supplies
– Jewelry
– Luxury leather goods

In addition to performing the usual testing activities, each software release should be tested with one or more test data environments (I call these environments TDEs), where each TDE represents a certain data bias for very good reasons:

– Customer segment:  apparel, office supplies, footwear
– Customer size:  large, medium, small
– Customer satisfaction index:  ideally – actual customers with the most defects or unusual problems can be encouraged to provide a copy of their data (scrubbed and cleansed of course).    In the past, I was responsible for a software product which could not be shipped until the ‘gold image’ was tested with real data from one specific customer.  This approach can save a lot of time and money, especially for the customer waiting for the new software release.

So – how does all of this work?

Part 1 – Create unique QA environments (usually one for each TDE, or test data environment with a certain bias)

– Create automated procedures to deploy software release candidate to each TDE
– Deploy on demand or – even better – automatically after each nightly software build
– Ask your customers to provide copies of data required for testing (one customer – for each data bias)
– Scrub the data / mask all confidential or personally identifiable information
– Enjoy the comfort of pressing a button and automatically generating a test data environment which has required bias:  home improvement retailer, 2 years of sales data, 40 stores, etc.

Part 2 – Create a portfolio of end-to-end scenarios which are based on real experience working with customers

– Example A:  footwear customers may experience more problems processing merchandise returns.  Develop automated test scenarios which will exercise anticipated trouble spots
– Example B:  luxury leather goods customers may experience more problems while running reports.   Again – develop automated  test scenarios to target this area of product functionality

Part 3 – Make it work

– After the nightly build, deploy the release candidate to one or more test data environments
– Trigger automated data generation programs and generate TDEs with desired data bias profiles
– Run test scenarios as needed against target test data environments
– Automate collection of test results / email test results to everyone that needs to see them

Part 4 – Arrive the morning and enjoy the benefits of automated testing implemented to the fullest extent

– Inbox should contain messages with test results from functional, regression, and now data driven tests

Some software products are not as sensitive to variability in customer data.   But most software products are.  Data-driven testing is the last mile in the journey towards getting the maximum value from automated testing.

Categories: Uncategorized

How to guarantee failure of a global software development project

March 6, 2010 3 comments

No one wants to witness a failure of a critical software development project.  The failure becomes even more painful if the project has been sponsored at the highest levels in organization to achieve critical business results, for example:  provide 360 degree view of the customer relationship, enable multi channel customer marketing campaigns.

Yet global, critical, “failure is not an option” software development projects fail all the time.

Before getting to the heart of the matter, it’s good to start with a small grain of truth.  History has a way of repeating itself.

Peter Drucker said, “The purpose of the customer is to create customers (implied in his words:  nurture and grow existing customers)”.   Considering that new customers may not profitable until Year 2 or even later, it becomes critical to give some thought to Customer Relationship Management, or CRM.

There are plenty of lessons learned from failed enterprise CRM implementation projects:

– CRM is :  first – a clear strategy, second – an approach to implement the chosen strategy, and third – technology (may be but most likely)
– CRM is comprehensive and requires participation from all functional areas:  sales, marketing, customer service, fulfillment, finance to name a few

The biggest lesson learned from failed enterprise CRM implementation projects:  strategy is not equal technology.   If business goals are not aligned with how technology may support and enable these goals, it’s rather obvious that any global software development projects will experience a guaranteed failure.

It’s essential to first develop a strategy how to structure the project and align the structure with a) what (milestones), b) who (people), c) where (locations), and d) every dependency which will either inhibit or enable your project.

For the moment, let’s assume that the goals are aligned and technology roadmap to success is clear.

What could one do to ensure that a global software development project would experience an almost guaranteed failure?

The top reasons are (I will focus on execution related topics as they relate to building great software):

– Do not spend any time thinking about a solution approach (or strategy) which will recognize all major drivers of complexity:  process changes, architecture changes (many hidden requirements here), competing projects, functional migration efforts, new development efforts, technology platform changes.

– Make every team across the globe operate in the same manner, whether they are migrating existing functionality or developing new features

– Ignore timezone differences

– Declare that one approach will work for every problem (instead of matching one or more approaches to the specific problem)

– Spend no time on thinking about how to componentize major software deliverables

– Discount the value of “design by contract” approach

– Spend very little time on creating the build / test infrastructure which will help teams to integrate code developed in multiple locations

– Spend equally little time on planning rigorous automated testing procedures

– Underestimate how much time may be needed to clarify requirements

– Discount the value of an integrated program plan where all stakeholders understand dependencies and critical milestones

– Discount increasing concerns from business owners, such as “I don’t understand when my customer support representatives will be trained”

Global software development projects do not need to fail.   Simply reverse above ‘suggestions’ to increase your chances of success.

Advice for a new CTO in 2010

December 23, 2009 1 comment

Three weeks ago, I was very happy to provide a professional reference for my former colleague.    “N” called me last night and shared the good news.   He accepted an offer to join as a CTO in a software company that just crossed a very important milestone: for the first time, the annual revenues will exceed $10M.

Although “N” has been clearly the best candidate for the position, a lingering concern remained in his mind.  “What if I don’t succeed?”

“N” is one of the smartest people I know.   But being smart is just one essential ingredient of success.  “N” asked for my advice and I was very happy to offer my thoughts.   This blog entry is much more than just a recollection of our conversation. I want “N” to succeed as well as every other CTO who will be asked to create market-leading products and fuel revenue growth in 2010.

First – take a deep breath and commit to ‘observe only’ plan for the first 30 days:

1.  Where are the products vs competition:  behind, competitive, or ahead?

– If behind:  you will most likely deal with a backlog of delayed functionality, sales team wanting to see more frequent product releases, and potentially growing backlog of defects.  Your team will be under stress.

Items to consider:

– Build good working relationships with leaders of Sales, Marketing, Customer Support, and Professionals Services organizations.  Acknowledge the problem.   They will understand – that’s why you have been hired.   Prioritize most important functionality / releases and develop a plan – with dates cast in stone – to deliver.  Your team will be under even more stress but do not be concerned.  This is your chance to learn what every team member is capable of under the pressure.  Many will disagree with you.  Ignore the noise.

– If competitive:  in the community of equal products, how products are positioned and sold is the key to success.   Learn the products.  When there is a chance – get on the road.  Sell, sell, sell – and learn first hand what the market and customers want.

– If ahead:  what a great position to be in …

Second – evaluate your team and how everyone works:

– Within the first week, sit down with every direct report and clearly describe your expectations.  Do not leave anything to chance.  This includes “I expect every meeting to start on time.   10:00am means you are in the room, ready to talk, with all supporting materials and presentations ready to be shared.  It does not mean arriving at 10:00am and then proceeding to get a cup of coffee”.

– Schedule one-on-one meetings with every team member.   Show your personal side.

– Assess talent, skills, promotional potential.

– Evaluate how the team conducts design activities, prepares engineering estimates, runs release management activities.   This is obviously not an exhaustive list.  Look for absence of rigor and quality.  Also look for evidence of “just enough to get the job done”.  These are danger signs that will very quickly lead you to the root cause.

Third – ask a question, “can I deliver what’s needed with what I have”

– Confirm quarterly and any other, additional product development goals

– Evaluate engineering capacity and historical product development velocity

– Get a good handle on the budget, open requisitions, recruiting process

– If you need a different budget to succeed, this is the time to ask for it

Finally – make changes:

– It’s important for you to be respected as a leader of the product development organization.  Everyone knows new leadership will bring changes.

– This is your chance to make the necessary changes based on what you learned.  Some changes may not be popular.  Other changes may mean more work.  Again – ignore the noise.

– Carefully monitor how the organization responds.  This will always be true: many people will see you and your leadership as a breath of fresh air.  Others will see you as a threat.   Give them a chance to adjust.  But at the same time, allow everyone to have a voice, even if they don’t agree.  The decision may still be yours to make.  After the arguments have been heard and a balanced decision has been made, everyone – and I mean everyone – should be working hard to support the decision.    Do not allow the few to derail hard work of many.   Prepare a transition plan and gracefully ask them to leave.   Your trusted recruiter should already be already working for you.

Best wishes for success in 2010!

Categories: Uncategorized

You just arrived as a new CTO; step one – get on the road

December 8, 2009 2 comments

After a long and diligent recruiting cycle, you just arrived as a new CTO in an enterprise software company to lead both product management and software engineering activities.   What you will do in the first 2 weeks will be critical to your success.

Not all is well.  Revenues are flat.  Some large customers are at risk of not renewing their maintenance (or subscription) contracts.   The latest and long-awaited major release has been delayed.   The sales team also lost some sales superstars to competitors.

Try to make the first day a Friday.   You will need the entire next and your first week for a very specific purpose.


– In the morning, meet with your direct reports, take them out to lunch, and apologize for not having any time for anyone during the first 2 weeks

– In the afternoon, meet with VP of Sales & Marketing and learn everything about revenues and customers

– Identify critical customers and ask VP of Sales & Marketing to make phone introductions.  Resist every attempt to have the sales person accompany you.  You want to send a polite message that your purpose is to listen, not sell.


– Get on the plane and travel to the first customer on your list

Monday – Friday, while meeting with selected customers:

– Learn everything about how the customers use the company’s products in their environment

– Get a list of critical bugs and defects

– Measure the flight risk – whether the customer may defect to a competitor

– Ask how the entire company – not just engineering team – serves the customer:   sales, professional services, customer support, training.  That’s the reason why you want to be alone while listening.    As a CTO you may build a great product but the professional services organization may not deploy the software correctly, creating an opportunity for competition.   Start collecting insights and real, unabridged feedback from the customer.

Monday (your second week):

– Meet with VP of Sales & Marketing to review the sales pipeline.   Get ahead of the business and critical ‘must close’ deals.


– Meet with the owner of customer support organization.  This organization should have the same sense of urgency that you gained when meeting with customers last week.


– Meet with the owner of professional services organization.   Again – the product deployment process should delight the customer.  Anything less?  Take notes.


– Meet with the CFO.   Learn the budget history and current budget metrics.


– You are now well equipped to meet with your direct reports.

There is a reason why the new CTO should meet with his / her organization last.   You want to know as soon as possible if the organization is capable of meeting the demands of the business.   That’s why you spent the first 2 weeks:

– Getting the unabridged version of state of the business from real customers

– Learning how other organizations (customer support, professional services) serve the customer;  you cannot succeed alone

– Learning how much financial flexibility you have to address any problem

Finally, you are ready to learn if your organization can embark on the journey together with you.

Categories: Uncategorized

Switched to WordPress

October 29, 2009 Leave a comment

Since Google acquired Blogger, I simply cannot reliably manage my blog.   WordPress – thank you for the welcome e-mail message.

Categories: Blogging, Hiring, Uncategorized