Jeffrey Greenberg on Technology Strategy

I’m feeling immense waves of fear as we move to a beta release for http://www.tweettronics.com. Some of the fear is irrational, and some of it rational. The rational stuff I handle through traditional risk management: identify the fear, convert the fear into clear risk statement (So, the fear that our system will be crushed by hackers and our business will be destroyed becomes one or more risk statements such as this one, “Risk our System database will be corrupted by hackers”), we look at the impact, we find evidence that supports the existence or likelihood of the risk (have we done enough architectural process and QA to know about this possible risk?), we look for ways to mitigate the risk, we look at how much time/effort/expense is needed to do the mitigation against the impact of the risk, and we prioritize our response. The non-rational stuff I constantly address at a personal level by being aware of it: untangling it from the excitement of launching a business, respecting my fears for they may contain real concerns that have to be managed, and fears that are driving from our particular psychological makeup.

Fears are useful in helping to recognize real concerns. But fears can be unhelpful in that they may cause you to avoid taking action, delay addressing real concerns, and make you feel miserable. In a competitive business you don’t want to be avoiding or delaying anything without due consideration, and fear is not consideration. So learning to feel, unpack, and manage your fears is something you can expect to spend some time on.

Dealing wit hfear is not easy. And it’s especially difficult if your doing a startup on your own. It helps to have support of your team, partners, and friends. With the team you have to get to the rational side, and with your friends you can get into the irrational stuff without causing too much havoc. But it is truly difficult.

I’ve seen founders fail when they are afraid of their own weaknesses and inabilities, so they cannot rationally deal with their shortcomings. It jeopardizes the entire effort when this happens, because they are not managing themselves, so they cannot manage others or the situation well.

Risk Management is an effective process for dealing with fears and risks in a clear headed and rational way, and it has some useful ideas that can be applied by anyone to manage their fears, especially a startup founder who faces so many different risks and so much responsibility.

Testing javascript heavy, web frontends remains a hard problem in software development. Everyone wants to do it in order to be agile, but few if none can really do an ideal job of it. Some key reasons they want to automate are:

• allow developers to quickly smoke test their work before they commit it
• support extensive, comprehensive functional testing

The reasons it’s hard to do are twofold 1. the frontend in a new product development is always in flux, and 2. there’s no great tool for quickly creating robust test scripts that can be automated. In particular, while there are some recorders for the gestures on the frontend, they usually fail in certain ways that demand one to further generate custom test scripts for that tool to run. It’s extra work that often becomes outdated on the very next build.

Generally, good agile practice demands lots of test code to support quick and reliable bug finding and fixing early in the development cycle, and not sometime later. So good teams will make some compromises to their agile test strategy to get as close as is reasonable to ideal without it becoming non-agile. The typical strategies are:

• create unit tests for all infrastructure, including going up into the javascript client as far as possible, but not automating user interaction
• create testable javacript widgets (look and feel) that can be instantiated into test pages that can be quickly looked at by a developer or tester

Some tools that help automated javascript and RIA testing are:

• http://windmill.osafoundation.org/trac/wiki/BookChapter-1-Install
• http://windmill.osafoundation.org/trac/wiki/BookChapter-4-3-JavascriptTests

• Provides multi-platform testing and recording
• Downside: recorder doesn’t handle all circumstances so programming is required, and test scripts will end up with dependencies on DOM structure

• Dojo is a javascript library with testable widgets, and a testing infrastructure for scripts
• Provides an experimental testing infrastructure, DOH, with a recorder

All three provide recorders. though Selenium is probably the most mature. They all suffer from issues in recording where the auto-generated scripts can often fail, require knowledge of XPATH to sort things out, and are not easy to incorporate into development processes so these scripts are maintained easy.

The key thing here is that it’s tough to incorporate these tools, which are themselves less than ideal, into workable processes that developers want to do and that support the flexibilty product designers need on the frontend. The upside is that if a working compromise can be found, the development will ultimately go faster & cheaper, because issues can be found sooner.

The long and the short of it is that if you want to do an agile process, it takes time and planning but the results can pay off. In the end, simplicity on the frontend pays off not only with users (typically) but also in development costs and time.

For one of the startups I’ve been involved with we used Trac as a quick way to support “development”. But Trac is very limited and problematic. We choose because it’s free, and a number of successful opensource projects use it. It works pretty well for supporting developers and an open environment, but as we’re running a startup with a rag-tag fleet of programmers, testers, project and product management it’s really not sufficient for all of them. Out of the box, Trac is best for developers and developer run projects. But if you’re a product company, then you’ve got alot of other things to manage other than what the bugs are and which developer is working on them. Because that’s really all you get. When you have people in other roles than programmer and technical manager, you’re beyond the capability of Trac: there simply not enough fields and capabilities to support different kinds of development roles and their interactions.

The key to performing a technical due diligence is an understanding of the business goals that are driving the audit. To perform the audit well requires discipline to listen and the knowledge to ask the right questions that will uncover what is going on. A simple methodology is helpful as a guide to obtain information without bias, to remember to ask all the questions that should be asked to get a fuller picture — you don’t want to dwell on one sore spot or mine only one’s particular interest. Knowledgeable listening and experienced objectivity is key to not getting lost in the expectations and projections of the sponsor rather than the reality of situation. In the end, the client is happiest when the truth is told, even if it’s not what they want to hear. Sometimes it’s worse than the sponsor expects and sometime not.

Kinds of Technical Due Diligence

Due Diligence for an investment interest is different than that for a CEO or division head who is worried about the performance of an organization. All organizations have problems, but some matter more than others with respect to the goals of audit.

Sometimes the outcome of a due diligence has been that I am put in charge of fixing it, but that is not my intent in taking on a due diligence. I am after providing the best insight into what is going on, what is working and what isn’t, and what isn’t so clear, and what of all that really matters to the business and what’s to be done about it.

I’ve been on both the buyer’s side and the sellers side of M&A conversations and in many other angles that drive a due diligence assessment. I know what the various players are looking for and what they are wanting and avoiding. This (advice from someone being assessed I find problematic in that it’s more about defending oneself than learning. A decent due diligence should be constructive for all concerned. It certainly depends on the situation, sometimes the agenda is loaded and sometimes it is merely exploratory… and in the end transparent truth is best, for it serves the greater good.

Acquisition Perspective

In an acqusition driven audit, the team being evaluated often has much at stake, and defensiveness can come into play. However, it is best to work closely with the auditor, because that constructive play can be the best card to play. A team that represents itself as knowledgeable and effective in an audit is not only being the better corporate citizen but also serving it’s own best interests.

Investor Perspective

Buyers are after ensuring their investment is all they expect. They are looking to avoid buying problems or at least to understand them enough to price them. This requires a bit of digging since the Buyer isn’t incented to display their issues. The role of the assessor is to dig in this case, but in this case there is a win-win in the assessment. The buyer already sees value in the company, so the assessor has the opportunity to help identify with the team being assessed the challenges ahead and how to address them. The question is can they or what will it take, and with what impact. If they are worth buying they will be able to face these challenges. The assessor should be able to help the seller and enable and identify a successful relationship between investor and invested company

Seller’s Perspective

Are looking to maximize value. They need to be showing their real issues rather than hiding bad surprises for later, and they need to show how they are constructively addressing these issues.

Team in Trouble

This is always tough because these teams can be embattled. Change is imminent. Due Diligence means that something isn’t working and things have to change. But the upside is that aim is for mutual success. People in this situation typically are doing their best to fix things or to survive a tough situation. It’s not a happy occasion, but there’s lots of pride at work, and that can be a powerful factor. Engineers like to ship real working code, and when it’s not happening, there can be many factors at play. The assessor must stay focused on the business goals, and is looking also to enable the values of the business. At times this might seem cold to a team, as in the icy ‘it’s just business‘, and at other times it will seem senstive to the considerable work and care teams typically put into their work. Nonetheless, a profitable and successful enterprise has to focus on the bottom line (be it a single, double, or triple bottom line), so the truth must be spoken. Like in hiring, if something doesn’t fit, it’s best to change it rather than hope to change the person… it’s better for all concerned, eventually. But often, changes to process is what is needed, validation of what the team already knows and helping them get empowered to act is often the cure. I will often not only make recommendation to the team, but to the senior management as well who are often part of the problem.

We’re working with a rag-tag fleet of development folks: programmers, admins, designers and so forth. Amongst the challenges is that as we bootstrap our development it is a huge challenge for the folks we’re working with to be as committed as we are. For many of them this work is part-time and they squeeze into their busy lives. On top of that, they are distributed all over the place so that keeping everyone in sync and focused is a challenge. And the remoteness itself, without having worked together, makes it very hard for us to develop a solid team feeling.

We stress respectful communications. And we really can’t over communicate in this situation, have too many meetings. Not yet anyway.

Some of the relationships work really well at a very high level of professional commitment, and others are not so engaged and we move on. We’re looking for folks who passionately involve themselves.