Take Back Control of Your Signature

don't be that guyDevice manufacturers have found a great way to brand your emails and even text messages.  I’ve lost count of how many times I’ve seen a note sent by a specific type of phone.  Just this morning I received an SMS telling me it was sent by a specific make of car!  Remember when people used to send messages?  I digress.

I can’t help but think of the creepy dude in the late 1980’s who had to tell you he was calling from his cellular phone (or “car phone” in those days).  Are these “new” device signatures really that different?  Sure: they’re much less personal, for whatever that’s worth.

Some people treat them as an excuse for poor spelling and grammar.  Of course any modern device will both spell check and auto-correct – and heck, if that doesn’t work, you can still resurrect those basic skills you learned in grade school to help!  So really, there’s no excuse, whether hand written, typed, or dictated.

Others may not even be aware their device is doing this.  If that’s the case, please check your settings – own your signature, don’t let vendors use it as creepy advertising every time you communicate!

Your signature is yours, not your mobile device’s nor vehicle’s.  No one is impressed that you dictated a text message into a hands free microphone – that’s par for the course these days.  What matters is the content above the signature – and yes, you should still check it before sending it.  Even if your car sends it, there’s no reason why it shouldn’t make sense or be unintentionally offensive.  If you find that difficult to do while driving, then do the unthinkable and place a voice call instead!  That’s right – most devices still support that function, thankfully.

So now you’ve taken control of your signature by opening your device settings to change it.  Excellent!  Wondering what it should be?  How about this: leave it blank.  That’s right.  Let the content speak for itself, and the sender’s name tell the recipient who it’s from.  Because guess what?  On the other end, someone is also using a mobile device or even vehicle hands free system to read your note.  And that person sure doesn’t want to hear “sent by my Dodge” at the end.  That person expects you to be sending the message, regardless of what you dictated it into.  So go ahead and own your signature, or just leave it blank.  You’ll project much less creepiness each time you send someone a message!

Posted in Life | 4 Comments

Enterprise Software Sales and the Role of the Startup CTO

Enterprise software sales

Selling major Enterprise software is very different to selling “off the shelf” products.  Beyond the technical challenges, the startup CTO can make a major difference in winning these critical accounts.

From the startup CTO’s perspective, Enterprise software sales are really about 3 things…

Enterprise Software Scale

Enterprise software tends to have a much larger footprint than other types of software once deployed.  This has to do both with the size of the deployment itself, as well as the number of other systems it touches.  A deep understanding of both market trends and specific customer challenges when it comes to integrating infrastructure are key to ensuring successful engagements.  What you learn about customer architecture should also influence future technology strategy. This is different than features and functions, it’s more about usage patterns and trends.  Think about what problems the architecture is solving, at ultimate deployment scale, rather than the immediate integration challenges themselves.  If you are the CTO/chief architect of a startup, you are best suited to understand and articulate this.


Building and maintaining relationships when selling Enterprise software is vital.  Startup CTOs should aim to establish 2 key relationships: the technical decision maker, and the technical influencer.  When engaging enterprise accounts, your sales team and/or fellow executives (depending on how you are working the account) should be able to make warm introductions to these individuals.  A relationship with the business decision maker is also valuable if you can have it, but be prepared to focus mostly on ROI with this person.

Naturally you want to meet and make yourself available to as many members of the customer team as you can, but the technical decision maker (e.g. the CIO, VP of IT, etc.) and the technical influencer (e.g. IT Manager, etc.) are key to maintain a strong cadence with.  In general, enterprise customers buy 2 main things: time-to-value, and peace of mind.  Your role is to convince the technical influencer that purchasing your technology will save them time and effort versus building it themselves or buying from your competition.  As for the technical decision maker, you have to convince this person that your company is technically competent and it’s safe to do business with you in the long run. In effect, your job is to win “hearts and minds”.

There is another very important dimension to relationships besides convincing the individuals themselves.  By Developing trust and rapport helps overcome the customer’s company politics.  Unfortunately, politics play a huge role in most organizations.  The key thing to remember is that no one wants to be on “the wrong side of history”, so they will either support you or they will do everything they can to stop you.  Most of the times it’s passive aggression that you have to watch out for.  If you can convince both the technical decision maker and the technical influencer that they’ll be on “the right side of history” by choosing your technology, they should be able to corral their internal politics.  If they can’t, either you are dealing with the wrong individuals, or the deal is not properly qualified. My advice there: “fail fast”, or risk sinking tremendous effort into something that like won’t bear fruit.


Enterprise software is about longevity and predictability.  It’s a major, ongoing investment in both time and money.  No customer will commit a large amount of resource without understanding your vision for their needs specifically, but also for the market in general.  Because your company is neither Microsoft nor Google, who spend big money to do it publicly, chances are you’ll be the first person to brief them on your vision.  An enterprise software deal is like a partnership, so it’s very important that the customer understands and buys into your long term vision.

Vision is not about features and functions nor “pie in the sky” ideas and missions.  It’s really about 2 things: How your technology strategy can improve your customer’s operations both now and in the future, and how­­ you anticipate market trends that matter to your customer.  If you can convince the customer that you understand their pain points, and your long term technology strategy will alleviate these while freeing them to do better things, you’ve won half the battle.  If you can convince them that you understand what’s coming (and relevant to them) in the next 5-10 years, and how you’ll help ease their adoption of these technologies and processes, you’ve won the other half of the battle.  In short, your vision “future proofs” the deal for the customer.  It’s as big a part of peace of mind as whether or not you’ll be in business in the next 5 years.  In fact, a strong vision that is both market and customer relevant is a good indication that you’ll make it.  While no guarantee, it should be enough to convince the customer you’ll be a worthy technology partner for them.  Remember, when articulating your vision, keep it focused on the customer’s interests, and avoid boring them with detailed feature roadmaps.  Let’s face it, whatever features you see on a slide today are likely to change tomorrow.  What really matters is your technology strategy – where are you headed with all this?  Once that’s clear, the features tend to sort themselves out, and customers know this.

In summary, the CTO is one of the most effective Enterprise software selling tools a startup has.  Be sure to plug in from the beginning on important accounts.  Since building and monetizing product are the only 2 things a startup should be focused on, you as the CTO must be heavily involved in both.

Posted in Leadership, Strategy | Leave a comment

Technical Leadership for Impossible Situations

technical leadership for impossible situations

Getting Apollo 13 home – an Impossible Situation!

We’ve all faced resource limited situations that just didn’t seem possible.  Here’s a story of grace under fire, and how sound technical leadership can make all the difference…

The Setting

This is a true story, but I’m withholding names and dates to protect the innocent (and not so innocent) parties.  It happened in a venture capital-backed startup not long ago.

The Self Inflicted Wound

There are some wounds you just can’t avoid.  Then there are the wounds you inflict upon yourself.  Sometimes you just don’t realize they’re avoidable at the time.  So the next best thing is to clean, fix, and dress these wounds as quickly as you can.  But first you must accept what you’ve done, and deal with the consequences.

Our self-inflicted wound was to threaten to miss a delivery date that we committed to for a product that a large, strategic partner was going to take to market under their own brand.  By large I mean the kind of company that coordinates events far in advance, and has serious issues changing schedules once things are in motion – not to mention it’s fanatical about protecting its reputation.  I say “threaten to” because at least we had the sense to warn them in advance – not far in advance, mind you.  Our product management felt there were higher priorities months before this (after it committed), but did not adequately discuss the possibility of missing the date with the partner until there were about 3 weeks left.  In fact the topic only came up when the partner called for “11th hour” status.  As you can see, this was a .50 caliber shot to our own proverbial foot.

The Horse’s Mouth

One afternoon about 3 weeks before delivery, I was busy working on technology strategy and vision.  I had begun to transition more into a traditional CTO role than the technical leadership one I had in earlier stages of the company, and had thus not been working closely with the engineering team for a while.  I still advised them regularly given that I had written most of the code, but my role was evolving along with the company as it grew.

I received a call from the CEO to meet him in his office, and walked over right away.  When I entered, I saw that things were not pretty.  This large partner of ours sent an entire product team delegation.  Our VP’s of Product Management and Engineering looked bewildered.  I sat down in an empty chair directly in front of the CEO’s desk, and asked how I could help.  He explained to me that our partners were “in a world of hurt” now that they’d realized we were going to miss our date.  They would have no choice but to pull the product, fire some of their staff for dealing with us, revoke most of our business agreements, and likely even pursue legal action to recover damages.  If you read between the lines, it was obvious that our company would not survive such consequences.  He then asked me directly, “can we do this?”  He wanted our partners to hear from the “horse’s mouth”, from the “father” of the product and the spiritual leader of technology in our company, be it strategy or execution, that we could do this as promised.  The horse said yes, without hesitation.  Self-inflicted wound?  Perhaps – the type where you cut off your arm in order to free yourself from the boulder you’ve been trapped under for the last few days, after exhausting all other options.

Entrepreneurial chutzpa aside, I immediately (politely) started negotiating deliverables with our partners.  It turns out that we had committed to a handful of very specific things, and I knew that if we focused on solution rather than implementation, we could deliver.  In other words, we didn’t need to build iPod-like user experience for each promised function.  I knew right away that we could get away with delivering functionality with lots of known issues.  I also realized that the delivery date was awfully close to the holiday season, and that we would probably have time for a “service pack” before the product really penetrated the market a few weeks later.  This was as much about saving face for our partner as it was about selling product.  For me it was about one thing alone – doing the right thing – that thing that we had promised to do.

Technical Leadership in its Finest Hour

It began in the CEO’s office as soon as our partners left the building, cautiously optimistic that we would deliver the goods as promised.  The product manager just about had a stroke and could not believe that we would commit to such a thing.  Even when we pointed out there was no real alternative here, it was still not possible for him to grasp.  The engineering lead, who had only been with the company for a few weeks, simply trusted that we would get it done.  In his case, ignorance was bliss, so to speak – especially since I took personal responsibility for the commitment.  I just told him to try to keep up, and that I would get it done.  This arrangement worked well from that point forward.

The very next thing to do was of course to get to work.  This began with me addressing the team directly.  In situations like these, I can’t help but think of Ed Harris in the movie Apollo 13 (obviously a dramatic reenactment of real events) stating with conviction that “this will be our finest hour” in response to naysaying about the challenge ahead:

I’m in no way trying to compare situations, because what those men did (in real life) was truly impossible, but it worked well in this context.  I told the team very clearly what the situation was, what was at stake (in slightly more abstract terms than what the CEO told me), and that I believed this would be our finest hour.  The key was for them to believe that I believed, and they did.  “Grace under fire” is what I kept repeating in my head.  I then outlined a very simple process (in place of the Waterfall-like system the team had been using at that time) – basically a 3 week sprint with daily standups and real-time triage in a “fail fast” approach.  I explained what functionality was mandatory, and that everything else did not matter.  I gave them a very good sense of technical leadership by example, as I next rolled up my sleeves and hit the code, with them.

I will never forget the effort the team put in over the next 3 weeks.  Everyone believed this could be done.  We hid any non-critical functionality that wasn’t working reliably.  We made tough tradeoffs (but with open eyes) in terms of short term delivery and long term viability.  We opened refactoring tasks in the backlog for technical debt we knew we had to incur.  I personally logged dozens of known issues, sending our technical writer large amounts of data each day to note.  My office resembled a forward battlefield hospital tent, except we were operating on the product rather than soldiers.  We amputated.  We cleaned.  We dressed.  But most importantly, we delivered.

Take Aways

It’s easy to argue that my efforts went beyond technical leadership itself.  But when working with highly experienced developers, I don’t think there is any more effective range of leadership than being able to both get your hands dirty and stay focused on the highest level business objectives at the same time.  It helped my credibility tremendously that I was already so close to the code – I did not have to sell the belief to the team, they just knew it.  I’m not a fan of anything but hands on leadership in technical teams, especially in startups, but even if you’re not hands-on, I think there are some important lessons to take away and implement in situations like these:

  1. Believe.  If you don’t believe, neither will your team.  There is always a way to achieve the seemingly impossible.  Identify the hard constraints early, and negotiate everything else.  Find the right balance and compromise between short term delivery and long term sustainability.  This is your job as a leader.  The first and most important part of winning is to believe you are going to win.  Everything else depends on that.  Visualize winning.  Then do it.
  2. Lead by example.  This is always mandatory, but never more than when you are asking a team for extraordinary effort.  If you don’t code, figure out some way to get into the product itself.  Maybe it’s documentation (reviewing manuals, reporting known issues, etc.), maybe it’s testing, maybe something else – but find *something*.  It doesn’t matter if your title is CTO, VP of Engineering, Supervisor, or Software Engineer.  If you are in charge of a development effort, be it full time or temporary, you are practicing technical leadership in this day and age, especially in startup environments.
  3. Avoid administrative overhead of any sort.  Don’t even think about mandatory overtime.  Do not micromanage, even though you will be very close to the action.  If your team cannot be accountable to deliver in whatever time they need, you have the wrong team.  Remember, you already chose to believe.
  4. Stay cool under pressure.  Pressure will be there whether you accept it calmly or not.  I believe this quality is key to startup “DNA”, but it can apply in any size company.  Grace under fire is one of the most important traits you can have as a manager – and it’s infectious.

I must add one more thing.  If you are not empowered to tackle a situation like this and make the necessary adjustments and sacrifices, do not accept the challenge.  I was empowered to do anything and everything except fail – and not because it was presented that way, but because I demanded it.  Don’t confuse this as a promotion or change in responsibilities long term (it may or may not be), but part of accepting a seemingly impossible task is to make clear that you are empowered to fully execute it.  During this effort, none of the engineers reported directly to on the organizational chart.  But they took direction solely from me, and if I had had to make personnel changes, I would have.


Posted in Development, Leadership, Strategy | Leave a comment

OpenStack – Between a Rock and a Hard Place

OpenStack between a rock and a hard placeFirst and foremost, I want to be very clear.  In no way is this any sort of indictment of OpenStack from a technology or community perspective.  Clearly the technology has value, and the community has shown an ability to organize, govern, and rapidly evolve a large platform over the past few years.  This should not be overlooked nor understated for a project of this scale.  With that behind us, let’s look purely at the macro market opportunity for OpenStack, and more importantly, the vendors trying to monetize it.

Perception Versus Reality for OpenStack

If you listen to many, you would think that OpenStack has or will very soon dominate the world.  Pundits will point to the year over year growth of summit attendees, major companies with OpenStack projects in flight, and ever expanding developer and vendor support base.  No doubt these are important elements for the long term viability of the technology.  Many even consider it a “movement”.

In many ways, however, there is a “if we build it, they will come” attitude about the project, with relatively little revenue to show for it.  You can argue the project is in its early stages, but as the OpenStack community itself will remind you, the speed of its evolution has been unprecedented.  451 Research claims OpenStack-related revenue will exceed $1 billion by 2015.  While impressive, let’s look closely at the numbers.  Most of the revenue is services, with product sales a distant second – $680m and $82m by end of 2014, respectively.  Predicted growth rates are impressive, but compared to VMware’s revenue alone, at over $5b for 2013 and growing fast, it’s a small piece of the pie for the 200+ companies sharing the $1b in sales for OpenStack-related products and services.  Why compare to VMware?  Because VMware’s Software Defined Data Center is what OpenStack needs to unseat in order to grow revenue in existing Enterprise accounts.  Greenfield opportunities of course are a different matter, but then again, public cloud is coming…

OpenStack Versus the Cloud

Wait.. isn’t OpenStack actually cloud?  Well, no, it’s infrastructure that can be used to power clouds, private or public.  It’s basically a set of tools that you can install to create a cloud.  So if we think about “the cloud”, as we hear about in popular lingo, what’s generally meant is public cloud services.  Obviously there is a software infrastructure component to this, but most consumers neither see nor care about it.  There’s good reason why OpenStack’s growth opportunity is mainly limited to the private cloud.  There are actually 3 good reasons, 2 of which are giants, and one very famous up and comer.  To spell it out, there’s Amazon Web Services (AWS), Google, and Microsoft.  AWS is the overwhelming market leader by far, not only providing infrastructure directly to consumers, but also to other companies which in turn deliver “higher stack” services to their customers.  And its influence and scale grows seemingly by the minute.  Google of course runs most of the web applications we consume as end users on a daily basis, and is now expanding into head to head competition with Amazon with its GCE.  And let’s not forget Microsoft, the juggernaut who now sees cloud (public and private) as its ticket to long term viability.  While vastly different in approaches, the 3 players have one thing in common: none of them offer OpenStack based services.  Given their entrenched positions and existing investment, it’s unlikely they will.  So any real challenger or challengers who intend to offer OpenStack based services face not 1, but 3 behemoths to compete against.  With AWS revenue estimates alone at over $5b for 2014 and growing at least 30% per year for the foreseeable future, it’s hard to imagine unseating that any time soon.

And let’s not forget, at the end of the day, the public cloud consumer (be it individual or business), doesn’t care what the infrastructure underneath is, as long as it works and provides value.  They are certainly not interested in “movements” nor the communities behind them, as this is all completely abstracted from their services.  Sure, you will always have conscious buyers who refuse to do business with companies who don’t use technologies they like, but this is not the same as boycotting clothing manufacturers for using slave labor in developing countries.  No children are being exploited – it’s simply a matter of preference, and the amount of people who actually care are in an extreme minority.  Quality of service and business continuity are far greater concerns to most public cloud consumers.

Why is public cloud so important?  Simple: its growth rates are astronomical, with megatrends such as Big Data driving it.  And you can bet that much of the spending is from businesses and enterprises, likely taking away greenfield “home grown” infrastructure opportunities where OpenStack has much of its potential.

In summary, OpenStack is and will continue to be successful in offering an alternative platform for cloud and data center infrastructure.  In some cases it may even prove superior to other offerings.  But from a mass market perspective, the tooth and nail fight from established enterprise vendors on one end, and the turbocharged growth from massive public cloud providers on the other will mean that it will remain in a niche position for some time to come.

Posted in Cloud, Strategy | 2 Comments

Achieving Software Product Maturity

achieving product maturityWell established frameworks, such as the Capability Maturity Model (CMM), help us measure software development process maturity in a standard way.  But what makes the product functionality itself mature, and more importantly, how do we get there from “here”?  Software product maturity (or lack thereof) can make or break your business, especially as your sales execution becomes more and more effective.

Software Product Maturity in a Nutshell

If you had to describe maturity itself in just one key phrase, it would sound something like “do what you say, and say what you do”. Of course there is more to it, especially for process, where continuous improvement and metrics are key, but this simple axiom is a great starting point.  In product terms, you can further reduce this to one key element: Deployment.  Think about it: no matter how good your product is, if your customer can’t use it, it’s almost worthless.  In fact, it’s generally the difference between a product and a project.  A real product is mature, while a project is an evolving, fluid technology that creates often elusive value.  (Project in this case of course meaning code that is meant to be a product, not a statement of work-based project.)  Measuring software product maturity is as simple as measuring how deployable it is.

Key Indicators of Lack of Maturity

  1. Services Attach Rate… While services can be a profitable upsell to go along with your product, if they are mandatory even for basic installation, then all you’re doing is slowing down the sales cycle and frustrating the customer prospect.  In a presales situation, you generally can’t get away with charging a high enough rate for these services to even recover your resource costs.  You should aim for deployment of basic functionality without services, then upsell advanced capabilities. (Your basic functionality should meet general market requirements already, otherwise you’re building solutions without problems.)
  2. Stated functionality is fragile or doesn’t work… This sounds very simple, but don’t advertise a feature unless you know for sure it works within the use cases you claim to support.  If the customer or prospect is off testing exotic use cases without your knowledge, then you’re probably not maintaining technical sales discipline, which is a different maturity-related problem.  But, if you are in fact setting expectations like you should be, then your product should deliver on them.  Bugs are okay and expected.  “Dead on arrival” situations are unacceptable.
  3. Upgrades are disastrous… Typically this is a result of rapid innovation that makes your technology resemble more of a project than a real product.  While seamless upgrades are highly desirable, even complex upgrades should at least be deterministic.  You absolutely want your customers on your latest stable code base as much as possible for many reasons, so make sure it’s not impossible for them to stay current.

There are dozens of other indicators, such as unstable APIs, etc., but these 3 are generally the most common and detrimental to your business.

The Path to Product Maturity

Here are 3 simple steps to achieving product maturity if you’re not already there:

  1. Simplify… Most likely, your product has too many advertised features.  This is difficult to sustain and likely not necessary.  Deemphasize anything that either doesn’t work or doesn’t provide core value.  You can always leverage services for integration of exotic use cases, or build custom implementations for the exceptions.
  2. Speaking of use cases, make sure you define what works from a solution  perspective.  Remember, the customer buys your technology to solve problems, not because it’s cool.  State the problems, and make sure you are building and testing to solve them.  Of course you’ll likely need to put boundaries on the use cases, but if they are problem/solution oriented, chances are the “80%” will become obvious quickly.  If you have use cases that don’t solve real market problems, get rid of them and the likely exotic functionality attached to them.
  3. Live, eat, and breathe deployment.  Any feature you build must consider deployment and upgrades as part of its core functionality.  This will also dictate your test cases and eliminate surprises once it gets in front of the customer or prospect.  You should consider deployment as part of your Minimum Viable Product if you are a Lean Startup, otherwise you’re building a project instead.

Identifying and working toward software product maturity is no easy task, but it’s well within your reach if you stay focused on what really matters: Your customers’ collective ability to use what you build to solve their problems.

Posted in Development, Leadership, Strategy | Leave a comment

Paying off Technical Debt

Technical DebtTechnical debt is very similar to consumer revolving debt.  It’s convenient, especially when you’re resource or time constrained.  But it has an ugly compounding effect, and must therefore be managed as often and as early as possible.  The long term effects of the compound “interest” of technical debt can cripple and eventually kill a company’s ability to innovate and iterate through its product goals.

How Does Technical Debt Work?

Let’s suppose you’re with a startup trying to quickly bring a product to market.  Everyone in the organization lives and breathes iterative product development, constantly reminding each other how Lean and Agile the company is.  The single most important thing is to put product in front of customers, and validate the business strategy by monetizing it.  Because the process is continuous and iterative, there’s no need to get it 100% right the first time – you can always fix it in the next iteration (“sprint”), and if the customer doesn’t bite, you can pivot quickly to adapt to that.  In theory this is an incredibly powerful methodology.  What used to take months or years of sequential requirements gathering, design, development, and testing now takes weeks.  Most importantly, market validation comes very quickly – it’s not a huge bet with one shot anymore.  As long as your vision is sound, you are solving real problems the market actually cares about, and your team is talented, you can iterate and pivot your way to success faster than every before.

While all this velocity gets everyone excited, the engineers are charging the technical “credit card” to get it done.  In most cases it starts off innocently enough.  Problems are defined very tactically, with limited scope.  Everyone advises against “boiling the ocean” and overthinking solutions.  Your engineers go off and get the job done, satisfying the requirements and scope for each iteration with ease.  The problem is software development is a delicate blend of art and science, and it’s certainly not black and white.  In order to narrow focus on a solution, developers often have to ignore (or postpone) broader architecture.  Too focused, and the code works only for very limited use cases, which will no doubt expand in scope as time goes on.  This means lots of duplicate efforts to address related problems in future iterations.  In consumer terms, you just charged a shiny new gadget on a high interest credit card.  If on the other hand the implementation is too broad, it takes too long to hit the market for validation and defeats the purpose of Agile and Lean.  This is like saving up over time to pay cash for the shiny new gadget.  Time is an enemy few startups can afford to capitulate to, which is why…

You Can’t Build a Startup Without Technical Debt

Let’s all accept this.  Anyone who tells you their products are free of technical debt is either ignorant or delusional.  While consumers can decide not to charge credit cards, startups cannot avoid taking short cuts to bring products to market, and therefore incur technical debt.  It’s not shameful or even wrong to do this – in fact, if used properly, it’s a very effective tool.  In other words, think of it as low interest if used responsibly.  Did I mention it’s a lot like consumer debt?  Pay on time and your interest rates are low.  Pay late and suddenly you are dealing with a loan shark.  Just like in the consumer world, small technical debt can snowball to large, unsustainable sums thanks to the compounding effect.  When you build shortcuts on top of shortcuts, each iteration becomes less productive.  The financial minds will want to increase engineering headcount, but this is like raising a credit limit.  If it works at all, it’s just for a short time.  After that, the technical debt becomes larger and less sustainable.

Managing Technical Debt

As “bankruptcy” is not an option, and bill consolidation doesn’t really apply to technology, you’re better off managing technical debt regularly.  Here are 3 general guidelines to follow:

  1. Well Articulated, Forward-thinking Strategy: your Product Management and/or CTO types should actually articulate a long term combined technology and business strategy.  Of course in a Lean world, this changes regularly, but chances are it will become more and more consistent with each iteration.  Even though you can’t afford to architect everything properly up front, the company should still have a good idea of what future offerings will look like.  It’s imperative that everyone involved with product understands this, including the engineers themselves.  What problems are solved?  What use cases do customers have?  What are we likely going to have to support in the future?  Armed with this knowledge, the product and engineering teams can at least enjoy the benefits of context, which can enlarge the iterative problem solving focus just enough to reduce a lot of technical debt.
  2. Refactoring: fortunately, Agile already has a built-in answer to paying off technical debt.  Refactoring scares non-technical people because it implies lots of risk and lots of time, with no immediate tangible benefits.  It’s like selling an investment.  Financially sophisticated individuals understand the value of investing in the future even if it doesn’t deliver value right away.  You have to be able to articulate it this way when it applies to technology.  Thankfully, good engineers fully embrace and often even demand refactoring, so they’ve already bought in.  The biggest challenge is knowing when to refactor.  In some cases it makes sense to do it continuously as you go along.  In others it’s better to dedicate entire iterations to it.  Whichever way makes sense with your product and more importantly your team, the key is to take small bites.  Just like feature development, refactoring should be iterative.  This mitigates risk in quality and stability.
  3. Backlog: again, Agile has another secret weapon that you should be using all the time.  In most cases engineers know when they are taking shortcuts.  Many even take them reluctantly, and are not shy about letting everyone know they are implementing heinous hacks against their better judgment.  Knowing you have a problem is the first step to solving it, which is great.  But it’s not enough to recognize, you must also record this.  Engineers should be adding refactoring tasks to the backlog (or whatever makes sense in your Agile dashboard) for future consideration.  They should do this early and often.  This way you can keep track of the cost of your technical debt even if you decide to defer payment a little longer.  If you don’t do this, it’s like charging that credit card without even asking what the amount is.

Technical debt is a reality in our Lean startup world.  Companies that manage it effectively ensure they can continue to innovate at the pace the market demands for a long time.  Those that don’t end up with stalled, irrelevant products and eventually fail.

Posted in Development, Leadership, Strategy | 1 Comment

3 Keys to Being Disruptive


Disruption over Time

This week I was invited to speak on a disruptive technology panel. I thought about what being disruptive actually means, and what the keys are.

Your Disruptive Technology Has to Work

Whatever the nature of your disruptive product or service, if it doesn’t work, it’s dead on arrival. This is important for any technology, but even more so if it’s positioned as disruptive. The market will be naturally suspicious of a deal that is “too good to be true”… overpromising and under-delivering will confirm that suspicion. Don’t ever sacrifice fundamental quality, even if it means toning down your offering a bit. Focus on value, not glitz. Which brings us to…

Your Disruptive Technology Must Offer Compelling Value

Value is so much more than just price. Price is only one dimension of cost – the other major one being complexity. Offering the same technology at a lower price positions you as a discounter, not a disruptor. Ask yourself this simple question: even if your competitor gives away their technology, does yours still cost less to implement? That’s a good indication of compelling value. Examples may be software products that require less resources, so that even if given away, the competition still needs more expensive infrastructure to deploy. Another good example is technology that is faster and easier to implement – leading to less expensive deployment and operations. Sell value, and sell time to value. This will help you down the road…

You Must Have Plenty of Energy…

…to create and sell disruptive technology. Chances are, you will face entrenched, well financed competition. These companies have an enormous investment in status quo, and will do everything they can to stop disruption. If there are multiple large competitors, they’re likely selling the same general technologies with only minor variations. A major paradigm shift that forces them to react is poisonous to them. At first they will ignore you, until you start seeing traction. Then they start playing dirty – FUD (Fear, Uncertainty, and Doubt) is their initial weapon of choice. This occurs “on the street”, directly in accounts. These larger players will not acknowledge you directly, but expect their salespeople to scare your customer prospects, even if they have to lie to do it. “They’re too small”… “They can’t do what they say they do”… “There are hidden costs”… etc. Sometimes these attacks are well orchestrated, devised at the corporate level despite their seedy delivery. The best defense is to continue to demonstrate value, treat each customer as if your life depended on it, and stand behind your commitments. Honesty and willingness to partner with your customer, rather than dictate your offering, are your best bets here. Expose the dishonesty behind the FUD.
Once you get a bit more traction, the gloves really come off. Your large competitors will try to steal customers by giving away their technology. Remember the true measure of value? This is where it really counts. In fact, resist the urge to discount your offering, but still show compelling value. This is your finest hour. Make it so blatantly obvious that your customer prospect can easily articulate your value proposition themselves, even in the face of your competition giving away their wares. Sure, you will likely lose some accounts here, especially in very price sensitive markets. But chances are, they’ll be back. Make sure you are there to capitalize once they see the light.
What happens next? Your competition starts to copy your offerings. The time they bought fighting dirty means they could develop something a bit more competitive. This is where you really need to light the afterburner. Continue to out innovate them so even if they copy what you had yesterday, you are still one step ahead. But don’t compromise your core values, or forget what got you to this point.
To be disruptive, you have to sell technology that works, offers compelling value (not just lower price), and continues to set the standard in the face of fierce competition. Most of all, you must have the will to “fight the good fight”, no matter how ugly things get. Just remember that victory tastes even sweeter when you have to crawl through the mud to win.

Posted in Leadership, Strategy | Leave a comment

3 Steps to Leading an Agile Transformation

agile development metamorphosisAgile Development is right for most organizations.  Modern, competitive release cycles are much too short for more traditional methods, and customers have grown accustomed to continuous improvement in the products they buy.  We live in an age where software updates need to be seamless and frequent.  In a cloud context, it’s a no-brainer – you control the “infrastructure” (be it the service or the application), so there’s no excuse for not updating it constantly.  In a traditional COTS model, the market expects automatic updates with little or no interrupt in production.  The winning formula for vendors and service providers alike is iterative development resulting in code that is always stable and releasable – in other words, Agile (generally Scrum).

Unfortunately organizations can lose their way and become far too reactive, generally leading to divergent code bases, over-commitment, and decaying product quality.  At some point Sales demands a reset – they don’t care what the product does, as long as it works.  Good salespeople can sell working product with limited functionality.  They cannot, for very long at least, sell feature-rich product that doesn’t work very well (or at all).

This is where you come in – the Development executive charged with righting the ship.  Never mind that decaying product is generally a result of undisciplined account and product management.  The most obvious scapegoat is Development.  The sooner you accept that life is not fair, the sooner you can usher in lasting change, for the better, in very little time.

Before you do anything else, build a tight bond with your Product Management executive peer.  It’s both outdated and naïve to accept that Development and Product Management should be at odds.  You are both working toward the same goal, and in an Agile model, you are 100% codependent.  Chances are, the PM is fatigued from not being able to do his/her job well in the first place.  Product Management of course is not about prioritizing contradictory requirements from every individual customer prospect Sales runs into – it’s about building the right product for all customers in all markets the company targets.  While extremely important, the inbound flow needs to be balanced with the business strategy and the “big picture”, then lifted to a product level before any execution takes place.  A good PM will interrupt any question of “can we do <blank>” immediately by asking “what problem are we solving?”  Imagine the horrifying result of designing an airplane based on the (often contradictory) feedback of 100 customers without really thinking about whether it will fly those customers safely and in relative comfort.  As a Development executive, you completely understand this, so it should be perfectly natural to be in lockstep with your PM peer.  Your PM should already be in lockstep with your CTO (if that’s a discreet function in your company), so the internal technology vision will already be factored in.

Now that you’ve agreed to basic terms with your PM, it’s time to start the transformation in 3 easy steps…

Step 1: Sell Agile Development to Customer Support

Given that Sales will soon be happy receiving well defined product that actually works, agile support the biggest remaining stakeholder is your Customer Support peer.  His or her main concern is that existing customers in the field get timely fixes for their bugs.  Unfortunately the company probably has several outstanding code bases due to past indiscretions.  Your priority should be unifying the code bases and offering iterative stable releases very frequently, in order to maximize resource efficiency and boost product quality.  Here is a deal I’ve personally made that worked very well: Development will maintain current (stable) and one previous release.  Customers on older releases, in turn, will need to upgrade.  I had the luxury of having very strong relationships with our largest customers, so this was not as difficult as it could have been.  I handled much of the messaging myself, assuring these long term clients that we would take care of them.  It turns out customers were more receptive to this strategy than our internal support was.  They had simply stopped asking certain customers to upgrade.  Can you imagine if Microsoft decided to support every version of Windows back to 2.03?  Even for a giant company like Microsoft, this would be nearly impossible.  It’s even more difficult for a startup, yet you see this way too often.  Assuming you have the mandate to do what you need to do to right the ship, this must be step 1.

The other thing you must sell, which is more difficult for traditional thinkers to grasp, is that you will be doing active development in a stable release from now on.  Customer Support must buy into the promise of Agile, and iterative, stable development.  Your trump card is the 1 prior release, but in some cases, you may have to agree to 2 prior releases.  The thing you must stand firm on, of course, is that there will be no new development in the mainline of the prior releases, only critical fixes.  To get new features, customers must upgrade, period.  Otherwise, you’re not transforming the process, just changing the realization.  Doing the same thing and expecting different results is the definition of insanity, even if you measure those things a little differently.

Step 2: Sell Agile Development to Your Own Team

Engineers and architects love process, except sometimes when they have to follow it.agile developers Some will consider Agile Development to be micromanagement, which obviously it’s not.  Others will meet you with the same level of skepticism of quality and functional improvements as Customer Support did.  Agile is not rigid, but it demands team cohesion and serious accountability.  There’s no place to hide in an Agile organization, and this does create a bit of pressure for many, even if they are already doing a good job to begin with.

What worked very well for me was to offer a big incentive, which is inherently obvious.  Given that I negotiated the Support burden down to something manageable, developers had to do much less of the thing they hate the most: repeating themselves.  Fixes that in the past meant checking code into 3-5 different code bases became 1 or 2.  In exchange for this, I demanded transparency and accountability.  The team bought in right away, and more and more as we developed the practice, which brings us to…

Step 3: Stick to Your Guns, but Keep up Your End of the Bargain

Nothing sells change better than results. The first sprint will be rough, but in no time, you will have the machine running like clockwork. agile process  You’ve made commitments to your own team as well as Customer Support, and if you stick to the process, they will be recognized.  Inherently you agreed to full transparency up and down the chain, so be prepared to summarize the results both to the executive team as well as your board when called upon.  Produce charts.  I’ve found that cumulative burndown diagrams have a magical effect.  It’s easy to show the process working internally, and if you do it well, customer satisfaction will improve, and PoCs will convert more than before thanks to working code.

However – never, ever break sprints.  You may do this very early on but by the 3rd or 4th sprint it should no longer be necessary.  Do not split code bases unless it’s for a funded custom project.  If you have 1 product, you should not have 5 code bases.  And finally, measure, adjust, and repeat – your work is never done.  Practice continuous product and process improvement through iteration and you will make believers out of even the worst skeptics.


Posted in Development, Leadership | Leave a comment

Tangible Differentiation for Premium Products

formula 1 differentiationOffering products and/or services at premium prices requires tangible differentiation, at least if your goal is to acquire new customers and grow revenue.  This applies equally to technology products as it does to sporting events, for example.   Differentiating on nuances alone can win niche business from aficionados and experts, but you need very obvious benefits if you are to convince the mass market to pay you a premium over the competition.  The great thing about obvious (tangible) differentiation is that it appeals both to laymen as well as aficionados.

Formula 1 Racing’s Differentiation

If you’re not familiar with Formula 1 racing, I’ll summarize it for you: it’s the pinnacle of motorsports, recognized worldwide, where teams spend hundreds of millions of dollars per year to compete for two championships simultaneously.  The cars are closer to fighter jets than to even the most expensive sports cars you see on the street.  Sponsors pay tens of millions of dollars per year just to have their livery show up on television.  TV rights cost tens of millions of dollars (or more) per year in most markets.  The sport boasts classic, expensive names like Ferrari, Mercedes Benz, and Lotus.  Celebrities and even royalty flock to races in such exotic locales as Monte Carlo.  It’s been said that NASCAR drivers watch Formula 1 religiously on TV, even while preparing for their own races.  Simply stated, this is not your average racing series – it’s above all others, and it’s global.

There are 3 types of Formula 1 fans:

  1. Die-hard aficionados, such as the famed Tifosi who follow Ferrari all over the world
  2. Celebrities, politicians, and royalty who may enjoy the racing, but enjoy the glamour and attention even more
  3. Average racing fans from all over the world, many of whom already follow some other form of motorsport (e.g. NASCAR, Indy Car, Australian supercars, DTM, etc.)

Can you guess which one is the most important demographic for the growth of Formula 1 as a business?  That’s right, average racing fans.  This is no different than any other business – consider the customer demographics for any premium technology brand:

  1. Die-hard enthusiasts and experts who are 100% loyal
  2. “Fan boys” who don’t fully understand the technology, but know it’s “cool” to own it (and want to be seen with it)
  3. Average consumers of average competing products

Quite obviously, the revenue growth is in convincing the third demographic to spend more on the premium product.  The first group won’t grow nearly as fast, and the second group is likely to grow with an increased customer base anyway.   The average consumer is where the explosive growth lies, whether you are selling smart phones or tickets to a race.  There are far more potential customers in that third category than in the first two combined.

Formula 1 tickets for the 2014 British Grand Prix in July are advertised as starting at 85 Euros per person.  This is general admission, not seats.  Parking, transit, and lodging is of course extra and highly inflated during the race weekend.  NASCAR Sprint Cup tickets for this year’s race at Talladega start at $45 for grandstand seats, effectively less than half the price of sitting on the grass for Formula 1.  No doubt the racing is completely different – but to average race fans, it’s still racing: loud engines in fast cars screaming by each other.  Did I mention loud engines?

This year’s Formula 1 regulations effectively muted the cars.  Anyone who’d ever attended a race or seen one on TV could instantly recognize the insanely loud, high pitched whine of engines turning twice as fast as even the fastest sports cars on the street, and producing at least 2-3 times the horsepower.  It’s a sound that is unmistakable.  Imagine a jet engine, but louder and higher pitched, and much more mechanical sounding.  That pretty much describes it.  I’d bet 9 out of 10 people who ever attended a Formula 1 race would mention the sound of the engines right away if you asked them about the experience, even though they wore ear protection.  No other racing series in the world sounds anywhere close to it – tangible differentiation for sure.

Average race fans won’t necessarily understand (nor care) about down force levels, braking efficiency, DRS, KERS, or any of the myriad of other technical differentiators in Formula 1 vis-à-vis other motorsports.  But the sound of the cars is unmistakable.  If you are watching a Formula 1 race, you know for sure it’s Formula 1 and not Indy Car, for example, even if you know very little about racing, and even if you close your eyes.  That is, until 2014.

For this year, the FIA (Formula One’s governing body) decided it was time to go “green”.  The cars are hybrid, and feature powerful small displacement turbocharged engines.  Let’s not confuse this with an average Toyota Prius – they still get horrible gas mileage compared to even the largest gas guzzling SUV’s on the street.  Fuel flow is restricted, but again, it’s still racing.  Estimates say they use 30% less fuel on average than they did last year.  This is a good thing, of course, but at a terrible cost.  The new engine and exhaust regulations have completely muted the engines.  They sound more similar to street cars than proper racing cars.  Again, they still sound racier than your average family car, but not nearly as racy as they used to.  And worse, to the untrained ear, they don’t sound too different from other racing categories – in fact, they are generally quieter.  Quiet and nondescript is certainly not desirable, but the series was betting on drawing more fans by impressing them with the myriad of new technologies in the cars.  This is an arrogant position that ignores market realities.  The one differentiator that was clear as day is now gone, and judging by the overwhelmingly negative response from existing fans, it’s unlikely to attract new fans at the prices it demands.  Think of Formula 1 as the richest, most decadent chocolate cake.  This year, the slices are smaller, there’s 30% less butter, and it tastes the same as anything an average grocery store sells in its bakery.  But it still demands a premium price, and it’s likely to go up, not down.

Premium Chocolate Cake is not Health Food…

…nor should it ever masquerade as that, especially if it comes at the expense of flavor or texture.  It’s not enough that sommeliers can smell the difference in your cake and pay extra for it.  You must trigger the equivalent of an out of body experience in the average chocolate cake eater to get them to pay more for your treats.  Chocolate cake is really good, whether premium or not, especially if you are not a connoisseur.  If you like racing cars and are not an expert in racing car technology, Indy Cars and Formula 1 cars are not that different now, so why would you pay the premium?

The 2014 Australian Grand Prix Aftermath

As you might expect, almost all the outrage after the inaugural race of the 2014 Formula 1 calendar is focused on the muted engine sounds.  The Australian Grand Prix organizers are considering legal action for breach of contract, claiming the sport has lost sex appeal.  Fans are overwhelmingly disgusted and very vocal about it, all over the media and the blogosphere.  Formula 1 supremo Bernie Ecclestone himself is leading an effort to improve the sound.  Formula 1 politics are complicated, but just appreciate that this billionaire knows a thing or two about making money with racing cars.  It’s unlikely that existing fans will turn away, constructors will start a rival series, or television networks will avoid renewing contracts.  But far more dangerous is that new fans will take their money elsewhere, meaning stunted revenue growth and very angry investors.  2-3 years from now, it’s quite likely the FIA will change things up again, but by then the sport may have lost too much momentum to continue demanding a premium in all markets.  As a very dedicated fan, I am disgusted, but I won’t leave the sport because I appreciate all the other nuances and differentiators.  However, I will have a very hard time convincing others to start following it now that the most tangible differentiation is gone.  Put another way, being “cool” doesn’t carry you too far if you stop doing the things that made you cool to begin with.

Let the lessons of the 2014 Formula 1 season so far resonate in your premium product development.  If you can’t grow your revenue stream because you can’t convince average consumers to buy it, chances are your investors will take their money elsewhere.   Tangible differentiation is very important to acquiring new customers, especially if you demand premium prices.

Posted in Strategy | Leave a comment

Lessons from a Bachelor Party: Valuing Development Teams


Confession: I spent last weekend at a bachelor party, “off the grid”, about 140 miles northeast of Seattle, WA.  Ten savages (yours truly among them) left to their own devises, without a care in the world, honoring a very close friend before he descends into the inevitable abyss of domestic life like the rest of us.  At almost 40 years old, it’s about time, my friend 😉

As you would expect when 10 savages who happen to be extremely successful in their respective fields (ranging from technology to medicine, and everything in between) party together, there are precious moments of enlightenment here and there – like enjoying a 5 star restaurant quality dinner that my sommelier friend designed and executed, with the finest prime cuts of aged American, Australian, and Japanese Wagyu beef on hand, paired with an amazing 2010 Cabernet that he bottled himself.  As an aside, the (not too strict) vegetarian among the group was set to eat even the plates the beef was served on after all was said and done.  Choice quote of the night was “I didn’t know butter could taste like beef”.  If you’ve never tried Wagyu beef, please make the investment at least once – you won’t regret it.  Even at retail, it’s still worth it!

Behavior in the Context of a Team

Perhaps even more memorable than that dinner was a brilliant two hour conversation I had with the guest of honor’s older brother who specializes in child psychology and consults the state of Washington as an expert in the field.  We were cooking up collard greens to accompany the steaks later in the evening as we discussed behavior patterns.  I maintain that as a leader psychology is perhaps the most important tool at your disposal.  If you don’t understand nor care why human beings do the things they do, then choose instead to follow rather than lead.  The main takeaway from the conversation was that behavior is important only in the context of relationships.  This is two-fold.  There is the person actually exhibiting behavior, and there is the person either enabling it or causing it.  You cannot consider one without the other.  In his (correct) estimation, almost all bad behavior in children can be traced back to parenting, whether malicious or not.  Correcting a troubled child is about teaching the parents how to conduct themselves more than it is about anything else.

Not surprisingly, this applies to any other situation, including the “behavior” of a software development team.  Of course we are dealing with educated, independent adults in this context rather than children, but the concept is the same.  Sustainable “Good behavior” (on-time delivery, accurate implementation, etc.) of developers is directly dependent on team chemistry and team leadership, period.

Do you Have the Best Development Team?

Flashing back to a debate I had about 9 months ago as to whether or not I had the best team, I’ll put it in further context.  My answer was of course yes.  If there was any issue with team chemistry or execution, I dealt with it in stride, even going as far as replacing resources if necessary.  But the question really being asked was if I had an “A” team of talent, meaning the absolute best developers I could find.  The answer again was of course yes.  And this is where the disconnect started.  It’s true there is always better talent out there, no matter how good what you have is.  But it really doesn’t matter unless you actually have problems (that you should no doubt correct).  Every single one of my developers had passed tough technical scrutiny and was capable of delivering what I was asking of them.  Considering that only a small percentage of developers really “get it”, I felt I had the upper 90th percentile in house.  Did I have the upper 99th across the board?  Probably not.  But again, it doesn’t matter.  Applying Malcolm Gladwell’s take on the inverted “U” curve, trying to achieve 99th percentile would have either paid diminishing returns or failed outright.  I already had the team I wanted, and in fact it was the best team out there.  Never mind the risk and effort of finding better talent (you know how difficult it is), never mind the disruption to schedules while onboarding new resources, and never mind the budget strain of upgrading at that stage… it just wasn’t necessary since I already had the best team.

What Really Matters in a Development Team

Here’s what really matters: trust, mutual respect, and accountability.  All things being equal, this distinguishes “A” teams from teams that fail.  Your responsibility as a leader is to maintain legitimacy (e.g. lead by example), hold your team accountable for its commitments, and ensure that talent is applied correctly to the problems being solved.  In an Agile model, this is fairly inherent, and as obvious as the fact that the sky is blue.  But to an outsider who is perhaps more accustomed to judging sales professionals, it can seem like a foreign concept.  How can more talent not mean a better team?  Here’s how: trust and mutual respect take time to establish, and accountability is something that many very talented developers are not comfortable with.  To me, a top performer is someone who I can trust, respect, and delivers what he/she commits to.  Raw talent is not in that equation, because again, I already recruited the top 90th percentile.  Just as important is that other team members trust, respect and hold the top performer accountable as well.  When you look at this through the lens of psychology, what you have is behavior in the context of a healthy relationship, plain and simple.

How do you value a Development team?  Setting aside that you’ve already recruited strong talent, if the team members (yourself included) trust, respect, and hold each other accountable, it’s an “A” team.  Upgrading individuals won’t necessarily increase production, and in fact may have very detrimental effects.  Fixing problems with chemistry is far more important, and is something you should be doing constantly to maintain that “A” team.

Posted in Leadership, Life | Leave a comment