Blueprint Seven Six is here!

Ever wondered what it takes to lead a tech startup from the early stages to a software valuable product business? I recently wrote and published a book from the anecdotal point of view of technology and product leaders, such as CTOs and Product Managers. It’s available globally in both Kindle (including Kindle Unlimited) and paperback format in your local marketplace. I’d be honored if you read it and were able to apply some of the concepts to your own endeavors.

Global links (via

Kindle (including Kindle Unlimited):


Posted in Uncategorized | Leave a comment

On the Limits of Automation, and on what comes next

I am not an economist, a futurist, nor a Silicon Valley mogul.  But like many, I’ve given a lot of thought to our present and future as largely shaped by labor automation and increasingly, artificial intelligence.

Despite everything we understand about macroeconomics and economic equilibrium, particularly in free market societies, the anxiety around technology displacing human labor is real and should not be dismissed as irrational.  Yes, economic shifts happen regularly – it’s why I personally have no clue how to grow wheat, but I can program computers to teach themselves to think.  It doesn’t matter if my skills are higher or lower than my ancestors’, what matters is that I live in a different world than they did.  And in turn, their ancestors lived in a very different one to them as well.  If you accept that we are fundamentally no more intelligent than Cro-Magnons were, then wouldn’t that make our modern skills more about circumstance than ingenuity?  Well no, and here’s why…

Despite all the genius and productivity we enjoy today, we work much harder than our prehistoric ancestors did.  I don’t have hard evidence for this (and I don’t know that anyone really does) but we do know that even pre-industrial workers had a shorter workweek than today’s.   And it’s not just productive work that burdens us.  Beyond providing for our basic needs, we spend time planning even recreation, and everything in between.  Much of what we deal with is self-inflicted, but again, that’s the reality of the world we live in.  If we work more than our ancestors did, was there ever a time when that wasn’t the case?

The Biggest Breakthrough in Human History Well Predates Automation

I firmly believe that if there is one compelling event in all of human history that matters, it’s when we learned how to create fire.  One can point to dozens of other things, ranging from the wheel, to vaccination, to internal combustion, and so on.  But the one thing that our modern world demands more than anything else is the control and distribution of energy, and the very first step was actually starting a fire at our discretion.  It lit our world, it killed harmful bacteria, it helped us become apex predators, etc., etc.  Before fire we spent our days finding food and simply surviving, and our nights huddled in fear under what little moonlight there was, hiding from the horrors of the dark.  We had neither production nor security, and certainly not much time to actually think.  But as advanced as we are today, we are fundamentally still using combustion to make our world (and beyond) function, and therefore, we should take a moment to thank our distant ancestors for giving us the gift of fire.

So what would we do with time to think?  Well let’s start with what’s happened since fire.  We invented or discovered the wheel, tools, physics, art, medicine, literature, government, transportation, and technology – in a nutshell, civilization.  But inevitably, we’ve slowed down our ingenuity as a result of diverting brain space to deal with our own creations.  Are smartphones as big of an invention as radio?  I don’t think so, they are simply an application.  The same can be said for just about everything else.  At the time of this writing Elon Musk just launched his electric car into space.  Both the car and the chemical rocket it rode on are effectively powered by combustion.  You can see the fire coming from the rocket, and the car plugs into a grid that delivers electricity largely originating from some sort of fire.  Despite the amazing things I’ve seen even in my short-ish lifetime, I quickly realize they’re simply recycled ideas put into practice because circumstances made them more feasible (such as cheaper materials, more widespread knowledge, etc.).

What needs to happen for us to have time to think again?  For us to invent what we cannot even envision, and change humanity as much as the discovery of harnessing fire did?  Let’s go back to the anxiety about technology automating away our livelihood…

Automation of Production

First, let’s divide production into 3 classes of labor: unskilled, skilled, and highly skilled.  This leaves out anyone who doesn’t actually produce, even indirectly, because that’s a different conversation.  But if you participate in economic production in any way, even if you are an investor who facilitates others to do it, you fit into one of these classes.  This has nothing to do with means – you could have inherited billions of dollars but have no skills to speak of, or you could be homeless and understand how quantum entanglement works.  It’s about what you produce, not how “successful” you are.  It’s true that we tend to see examples of higher means as we progress from unskilled to highly skilled, but let’s not define these classes by socioeconomic standards.  Also, let’s think purely in the context of free markets, because feudalism and socialism do not deserve further consideration.  These systems failed those who tried them repeatedly, and any full implementation demands suspension of human rights first.  I’m sorry, but I’m not interested in that.

Unskilled labor is 100% automatable with iterative machines and processes.  Stamping a shipping label on a box as it comes off an assembly line does not require any real decision making –  it just has to be done over and over again.  It’s very difficult to make mistakes assuming the process is correct, unless the operator (human or otherwise) is simply negligent or in disrepair.  I believe this class of labor is more or less finished for humans.  It is true that automation is not free, and there is a large implementation cost, but the writing is on the wall.  Any forward-looking company, realizes that they must automate unskilled labor in order to remain competitive because, well, their competition will offer the same class of products/services at lower costs as a result.  Specialty firms may be an exception, but I think of that as art rather than sustainable economic production at scale.

Displacing unskilled labor inevitably increases demand of skilled labor.  If machines automate assembly lines, someone has to maintain and operate the machines.  While understanding how to monitor sensors and adjust settings on a control panel may not be highly skilled labor these days, it’s certainly not something you can delegate to a worker with absolutely no training.  By definition it’s skilled labor – whether those skills are developed or acquired.  There is an additional pull for highly skilled labor to actually design and build the machines, but that’s a further derivative and not the immediate labor shift that occurs from automating in the first place.  It goes without saying that if we are not teaching our children even the most basic of vocational skills, we must start now.  Workers who know absolutely nothing are simply not employable, unless the employer decides to invest in them.  But almost certainly that investment is higher than that of implementing automation, at scale, and therefore not something likely to happen for very much longer.  It’s time that our liberal arts curriculums started to incorporate some basic vocational training if we expect to send inexperienced labor into the workforce successfully.  Not everyone can be a doctor, an engineer, or a teacher.  But since unskilled jobs won’t exist, we need to train more technicians.  The good news is that our children already have basic abilities with advanced technology almost from birth, so it’s just a matter of applying these into marketable skills.  Let’s start now so we don’t end up with complete a labor crisis in 10-20 years once the first wave of industrial automation is in full effect.  In addition to learning cursive, our children should be learning how to inspect basic health of computer networks, etc.

That brings us to the second step of automation – displacement of skilled labor.  These are the decision makers within a given system, or in other words, the technicians that we just trained.  The good news is that this probably won’t happen any time soon.  In fact it may take a generation before it threatens labor the way basic automation is today.  The bad news is that we already have the technology, and it’s starting to move from the experimental phase into production.  We can think of this as artificial intelligence, but more broadly, cognitive technology – machines that can learn and improve themselves and their systems over time.  For example, the technician inspecting a computer network decides how to fix it when it breaks – change routing, deprecate service, etc.  We have decision support systems today that can help those technicians by recommending the appropriate action based on analyzing all the variables at stake.  It would not be a huge leap for those systems to go from recommending to acting.  If we limited this to the scope of the system they have influence over, this would effectively automate away the need for skilled labor without (yet) threatening highly skilled labor.  Please understand that this is not new technology and has already been implemented repeatedly.  What keeps humans in control in many cases boils down to the ability to make decisions when logic breaks down – in other words, our ability to apply judgement and weigh outcomes ethically as well as logically.  There is also a huge debate over accountability of automated systems – if something goes terribly wrong, who do you blame?  A fundamental aspect of justice in modern society is accountability, and indemnifying decision making is not part of that equation.  But since you can’t put a machine on trial and subsequently in jail, it really complicates this matter.  A human operator is the ethical security blanket we cling to like Linus of Peanuts fame, despite having the technology to do away with that in most cases.  But, even this will succumb to economic pressure over time, especially when we face the hard reality that humans are far more likely to make mistakes than well programmed machines.  Machines don’t get tired, moody, angry, bored, or distracted – they fail only when their system breaks somehow.  Humans fail constantly even when their systems are in prefect health.  But just like skilled labor designs and builds machines for automating unskilled workers, highly skilled labor creates the algorithms to displace skilled workers.  Today’s technicians must become tomorrow’s data scientists in order to survive and thrive, because that labor shift will complete before we know it.

Can Automation Yield to Equilibrium?

Here’s where it gets very interesting.  Of course, you can argue that any time something hits really close to home, it suddenly becomes interesting.  But that’s not the only reason why it’s interesting.  I had a long conversation with my brother, a fellow technology professional, which inspired me to write this essay.  One of the things he reminded me of, and rightfully so, is that economies always seek equilibrium.  If we assume that unskilled labor is finished and we train lots of skilled workers, what happens when their jobs no longer exist because machines now make industrial decisions?  My brother thinks we will see a migration from cities and metroplexes to small communities and local economies.  As the price of products races to 0, limited only by the raw material cost, companies still need consumers to buy them.  If those consumers don’t have jobs, they can’t buy products.  Remember the specialty players I mentioned above and categorized as art?  While they can’t contribute to economic production at scale, they can certainly help at the local community level.  A local economy may look a lot like the macro economy does today, with more people than machines at the helm.  While this doesn’t scale, it definitely works.  A local community may have a PC repair shop, a restaurant, a sustainable clothing company, and a health clinic.  It may have a grocery store that sources produce from local farms.  And so on.  The doctor at the clinic may not drive a Rolls Royce, and the PC repairman doesn’t buy a new smartphone every year, but this type of economy can be sustainable if people commit to supporting it.  In fact I would argue it’s a good thing if people didn’t toss perfectly good products in order to buy the latest ones.  While it may look like a regression for industrial elitists, it’s a good outcome for those who would otherwise be left behind as skilled labor suffers the same fate as unskilled labor at large scale.  And more than likely, people living and working in these small communities would regularly go online to buy products from major industrial firms that are fully automated.  It’s a win-win.  As long as those communities put an emphasis on education, and teach children how to think rather than recite, there’s a good path to producing highly skilled workers to send back into the macro economy.  You can think of local economies as a “soft landing spot”, but actually, they may be more sustainable than we realize.  And quite frankly, some of us may decide to live and work there by choice.

Logical Automation, Gone Terribly Wrong

Back to the other interesting part: what happens to highly skilled labor?  Cognitive algorithms that are 100% in charge of localized systems will one day extend to having control over broader ones.  They may even make decisions that have little to do with their immediate problems at hand.  For example, in the distant future, if we have a crew of humans on a space journey with a cognitive system operating the ship, the most obvious thing for the cognitive system to do to conserve resource is to jettison the humans.  They take up way too much space, consume too much energy, and produce too much waste.  The ship can reach its destination with much less hassle and accomplish its mission if the computer just opens the airlock and disposes of the carbon units inside – a perfectly logical but terribly horrific decision that inspires countless science fiction stories.

Over a dinner conversation the other night I heard a story about sensors that feed cognitive algorithms which in turn make unsupervised decisions after analyzing the data.  I immediately said “that’s SkyNet” (of The Terminator fame) – because it is.  The truth of the matter is that highly skilled labor will put the brakes on fully unsupervised cognitive systems by building artificial barriers and protections – for example, the computer on that space ship may be able to regulate the temperature inside but not outside the range that a human can tolerate – at least not without a human overriding the safety system (yes I just described another inspiration for countless science fiction stories!).  It’s not that we don’t trust logic, it’s that we are fearful creatures.  Fear, along with necessity, is a fiercely motivating force – especially when survival is at stake.  I firmly believe we will build artificially intelligent systems engaging in unsupervised learning in the very near future – we have the technology right now.  I do not believe we would just walk away and let them do their thing.  At least not in our lifetime.  The academic interest in cognitive systems alone is too great, nevermind our fear of a nightmarish future of machine control.  As far as I can imagine, there will always be humans keeping tabs on their artificially intelligent algorithmic creations, whether for mere curiosity or outright protection of the species.

So that brings us to the other form of equilibrium – the one that occurs from expanding the possibilities rather than striking a balance with the current ones.  And for that, we need to think about rubbing two sticks together and making a spark again.  That spark today is artificial intelligence rather than fire – and while it’s way too early to tell if it will have anywhere near the significance that fire did (and it probably won’t), it bring us similar results.

Where Will Automation and AI Take Us Next?

I gave a talk at a conference a couple of years ago where I spoke of “the future of the 1960’s” versus the actual state of technology today.  I used the example of the HAL 9000 computer in 2001: A Space Odyssey as the epitome of futurism in the 1950’s and 1960’s – a machine that can pass the Turing Test, or in other words, trick you into thinking you’re interacting with a human.  We believed at one time that this would mark the inflection point where machines actually became intelligent, and would then live among us as citizens and interact with us as ordinary humans would.  What I see today with regards to artificial intelligence could not be more different, but makes absolutely perfect sense.  We don’t want to be tricked – if we want to talk to a human, we talk to humans.  We don’t need machines to live undetected amongst us.  We’re not even ready for the ethics of non-human intelligence – its rules, its rights, its feelings, etc. – and frankly it doesn’t matter because it’s not happening.  Instead, machines augment our abilities by providing contextual information derived from constant cognitive processing of our daily events.  This is the future of the 2010’s at least.  When we land in a new city, our phone recommends a restaurant across the street from the airport that we might like.  When a meeting runs long, our calendar reminds us that it will take us 30 minutes to travel to the next one, and that we should leave now.  Yes skilled labor is displaced but what it’s doing is boosting the capacity of highly skilled labor to invent.  We don’t need to think about many things anymore, but we’re still in charge.  In other words, we lit fire for the first time, and when we’re done hunting and gathering for the day, we can relax and think about what comes next rather than how we’re going to survive the cold, dark night.

Just like we are still burning things to this day, we’re still using the binary system for the basis of our technology.  We’re still moving from point A to point B rather than moving point B to us.  We’re still interacting with analog interfaces even in our newest digital devices, rather than just thinking about things and having them happen.  And so on.  We have so much to invent.  We can easily squander it by making ourselves even busier now that machines do a lot of our work.  But I believe that as we automate away that which can be automated, some of us will accidentally strike sparks that will take us to the stars, and more importantly, to whatever comes next.  Let automation happen, embrace it, help those temporarily left behind, but proceed fearlessly into the future because just like our cave dwelling ancestors who lit the first fires, we’re just getting started.


Posted in Life | Tagged , | Leave a comment

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 | 1 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