nomadic_audio

trollmaster

i've noticed for some time in all the social networks that i've participated in over the years that there is a select group of participants who tend to attract trolls as if they were magnetized, now granted it's usually the abrasive curmudgeonly a-listers who bring out those with a trollish tendency because rather than ignore them like the rest of us, their ego seems to require that they debate with them - now some social environments (like friendfeed) have very useful blocking functionality so that you don't see a trolls activities and they won't see yours - but you have to first identify the trolls, and it seems these magneticly popular folk are the best at accumulating them and bringing out their true trollish nature for all else to see - it occurs to me that there's a new online role in the making here - trollmaster, an online personality that simply by participating can rid any community of its trolls - this would be very useful as new social networking environments startup, conspiracy theorists are always claiming that a-listers only use and talk up these new social sites because they are paid - forget about that, i say openly pay them to participate and rid the site of all its trolls - long live the trollmasters, pissing off and ridding the web of all trolls so we don't have to ;)

hey subscribers to nomadic audio

i'll still will be posting here of course but if you really want to track what i'm up to online as i mentioned in an earlier post, i suggest you follow me on friendfeed or swurl - that way you can get all the other services i interact w/ in one interface or via one rss feed...

see these two posts from my other blog for additional background: changes & personal soa...

post from iphone app store for typepad

this is a test - looks like all the basics but no html capabilities

friendfeed twitters my swurl

for those of us that adopt new tech early and often, such as social networking and lifestreaming tools, things have been pretty interesting lately - while twitter has been growing in popularity it has also been extremely unstable, to the point of user abandonment - along comes friendfeed which i first started using as a presence aggregator - a place that i could subscribe to everything my many online friends do whether its twitter, blogging, photos, bookmarks, netflix, whatever of the 41 services they chose to integrate into their friendfeed flow - a really neat platform that optimizes keeping up with the many different communities i participate in online - it appears to those new to the platform to be a chaotic mess, a sort of rss aggregretor on steriods, but then again its also a very dynamic communication platform that allows commenting just like blogs have and "rating" something/anything via a "like" which allows those who subscribe to you to discover the things you've liked algorithmically even if they don't subscribe to the original person via a pretty neat friend of a friend (foaf) feature - there are lots of other configurable options in friendfeed which others have done a really good job of chronicling so i won't...

what i really wanted to go through in this post is the differences between the communication styles that exist in twitter & friendfeed, from my perspective of course - which could be very different for others - this is the way i explain the communication practices in twitter and friendfeed to folks new to these tools: i use an escalator analogue...

this image shows three escalators side by side, the one on the left is going down and the two on the right are going up - twitter is like the conversation that occurs between two people passing each other in opposite directions on the up and down escalators - its brief, short and cryptic - while friendfeed is like the conversation that occurs while folks are traveling in the same direction on the escalator, if the conversation that starts while traveling up or down together is interesting it can continue either up into the building or out into the street - also the friendfeed conversation could have the potential to include multiple participants because you're going in the same direction while twitter feels more like many, many ships that pass in the night - i still use twitter but i prefer the depth and level of experience that happens in friendfeed...

one other presence aggregator that i've recently enjoyed exploring is swurl, it has a lot of similarities to friendfeed but is more of a record of activity for me than a place i'd live in - i especially like the timeline view, my impression is that folks will use swurl to track or locate elements that have been contributed to a lifestream & will use friendfeed to interact w/ others while lifestreaming...

personally, twitter is something that i'll decrease fulltime participation in as my time & community of interest transitions to friendfeed (or some other more robust social media environment to be named later) - i used to like whales ;)

my accounts are: friendfeed, swurl & twitter follow if interested (friendfeed is what i recommend)...

tech dd summary

to make it easier to point to this set of posts in the future, here is a link summary of my venture technical due diligence process:

part 1 - introduction
part 2 - staffing
part 3 - infrastructure & architecture
part 4 - workflow & governance

a word doc version is enclosed (or download direct) as well, pls feel free to utilize it if it helps you in your process or if you're on the receiving end of a due diligence process such as the one i've laid out here...

technical due diligence (part 4)

in my last post I went through the infrastructure and architecture aspects of the technical due diligence process, so in today’s post I’ll be finishing off this four part post with the final areas I focus on, the workflow and governance processes that the intended company might utilize. Again, I like to go back to my favorite conversation starter “take me through concept to production” as a way to dig into the details of how the intended company gets work done. Some of these processes are completely foreign to startup technology teams but again that’s ok, its useful to hear the reactions to these areas if they aren’t in practice and if they are utilized even better. I do not expect startups to have well defined workflow process but I do like to understand how the other cto envisions workflow and effects prioritized change which is always one of the most important things a technology team will need to undertake as they scale their environment and augment product functionality. For workflow I like to start with an understanding of how project management is handled as well as how the approval process and task allocation works. Most startups do not have dedicated pm’s so understanding how those who wear multiple hats handle insuring that proper process is followed to insure tasks are managed and prioritized correctly and that estimates of time to complete are as accurate as possible is critical. Many times I’ve heard “we don’t have time to do project management, we just like to get stuff done” so much so that I’ve gotten pretty good at not laughing anymore. Being able to explain to me how getting things done in an organized fashion is usually a good place to start, sometimes the team is actually using pm practices they just aren’t doing it in a formalized fashion, which is fine and again just going through the conversation is very useful in assessing how things get done and if the process is grounded and sustainable. Next I get into even more formal areas of workflow, how are the business requirements of new initiatives or projects documented and signed off on, which for startups is often driven by founders or senior management and rarely formalized but its important to understand what happens and who drives it. I like to see proactive approaches in this area that tie into some form of a roadmap that can be well understood by the technology team.

Most companies I analyse are web delivered software related but everything I ask related to development could apply to hardware or service related companies as well. For software development workflow, I pretty much like to go through every aspect of how work gets done starting w/ what formalized process (if any) is utilized, how new functionality is added and how change control is effected so that risk is minimized when anything new is introduced. This is where bug fix management is touched on as well. In today’s online world, how rich media, graphics and general user interface is handled is critical so i ask to go through this as well. If the company relies heavily on a database, and it wasn’t covered in the architecture discussion, which is the right place to go through it, then I make sure to dig deeper at this point. I don’t like to get into say the table design level, but rather just as w/ any layered approach to web application developments understand what’s being used, why and how is it managed. Next is an often-overlooked aspect of the startup development process, quality assurance. How is anything introduced into the environment tested and assurance provided that whatever it is functions as intended and does not break anything when introduced. Some startups utilize their own developers to perform this qa function, which is a very bad practice but if staff or funds are limited it might be the best that can be done. If this is the case I like to at least see some method to insure proper unbiased and thorough testing has occurred. Next is the always telling build vs buy conversation, which is one of the most important philosophical parts of the due diligence process. I believe that in today’s technology environment, commodity mundane technologies are readily available and as such most basic functions such as network, hosting, storage, advertising services, credit card transactions, site monitoring etc… can be outsourced to specialists at a very low cost compared to building these functions in-house. What can then be focused on by the development team is building the core product that will used to go to market, that which differentiates the company from its competitors. I know this sounds overly simplified but I tend to see a wide variety of product offerings so I need to keep things pretty generic, and that’s why the conversation that is generated by this process is the real goal and not just static answers to a list of questions. Finally, as mentioned before the roadmap for the company and how the cto envisions proceeding towards meeting it needs to be covered. This is usually an overview of what the funding will be used against and where the company wants to go w/in the next year or two depending on their maturity. I also like to cover how research is accomplished along w/ the roadmap since they are so closely aligned. This includes competitive landscape & potential beneficial acquisition topics. I like to get into infrastructure management practices at this point unless its been covered earlier in the conversation, just to make sure the workflow aspect of it is understood. Same w/ how integration and partnerships are dealt w/ and then I always offer up whether there are any other topics to allow the cto to cover anything I’ve missed but that they think is an important part of their value add. I usually incorporate whatever it is they bring up into my process for future due diligence if I think its generic enough. That way my process matures as I evaluate more and more companies, to date my guess is I’ve probably done this over 500 times in my career, but I always tend to learn something new as I go through it w/ thoughtful cto’s.

The final area of focus that primarily relates to acquisitions is a complete picture of all technology related costs. I ask for this for the previous 3 years (or since the company started), current year and an estimate of cost expectations to meet roadmap goals. This needs to include both capital and expense related costs, including amortization assumptions, buy vs lease philosophy and a complete overview of their governance process. How are budget and cost assumptions created, how are they prioritized and what is the process utilized to get approval. Along with all of this I ask for all technology related contracts, to include what they’re used for, how it relates to deliverable of the company, duration and statement of relationship, for example whether it’s a strategic or commodity relationship.

I end by asking for the names and contact info of all subject matter experts involved in case further explanation or follow-up is needed.

Here are my workflow and governance sections of the outline that i tend to follow:

3.    Workflows & Processes

3.1.    Please describe your product/project workflow (or provide diagrams). For example, how are the following capabilities or functions handled:

3.1.1.    Project management & approvals

3.1.2.    Business requirements documents

3.1.3.    Software development & enhancements

3.1.3.1.    New features & functionality

3.1.3.2.    Change mgmt & bug fix

3.1.3.3.    Graphics & UI design

3.1.3.4.    Database overview (unless handled section 2)

3.1.3.5.    Testing & Quality Assurance

3.1.3.6.    Build vs buy decision making

3.1.3.7.    Roadmap and Research    

3.1.4.    Infrastructure Management

3.1.4.1.    Monitoring & alerting

3.1.4.2.    Upgrades

3.1.5.    Integration & Partnerships

3.1.6.    List any others specific to your offering

4.    Expense & Capital budgets with depreciation for previous 3 full years and anticipated for current year

4.1.    Provide an overview of Technology Plan, as implemented to-date

4.2.    Provide an overview of Technology Roadmap, especially any major initiatives outstanding or desired

4.3.    Describe how Technology initiative priorities and funding decisions occur (state your governance process)

5.    List of all 3rd party contracts with all relevant terms, including:

5.1.    Data center contracts

5.2.    Hardware and software maintenance contracts

5.3.    ASPs & outsourced services

5.4.    Software licensing agreements

5.5.    Outside software development

5.6.    Any other technology services under contract

6.    Please provide contact information of responder in case follow-up is needed

so that’s my technical due diligence process; most of what i've covered would be applicable to an investment but some of the more detailed areas would only apply to an acquistion or merger. as i’ve stated throughout these posts, i try to keep it conversational and generic enough in nature to handle a wide variety of company types and scenarios, going into depth via additional questioning as needed.

anything you think i missed in these posts? Feel free to contact me if you have any suggestions or questions, be glad to address them…

technical due diligence (part 3)

this is a long one so apologize but no short way to deal w/ the breadth of this part...

in my last post i went into the initial technical due diligence topic i focus on, staffing. from that topic i like to get into the infrastructure and then architecture aspects of the company’s technology decision making. for both of these, diagrams (if available) do the best job of telling the story, so i recommend that cto’s be prepared to provide network, server infrastructure and product architecture diagrams. both physical and logical are usually the best way to start the process of telling the complete story of their technology environment. easiest place to start the infrastructure overview is with the provider methodology: in-house or outsourced, so who’s doing the network they’re utilizing, how is it managed and where are the servers (or services) located. this should be provided for all areas, so development, testing, staging, production, redundant locations and disaster recovery. now most startups will not have all of these segmented areas from an infrastructure or even logical segmentation standpoint, but that’s ok. its always a good idea to hear the answers to things you know aren’t in place yet but might be desired by them in the near future or it could be an area you think they’ll need as they scale but maybe not when they’re still in their early growth phase. for buttoned up startups this is easiest part of the conversation since it involves mundane data center located systems that are highly commoditized so these cto’s can usually rattle off their low cost and high availability decisions that haven’t required much staff growth if any at all. ok I just showed one of my biases but in today’s world, network and infrastructure is highly commoditized and for a startup to opt for in-house hosting it really needs to be justified with a unique reason, can’t say i can think of any myself but that’s what these conversations are for, to hear about the intended company’s reasons for doing whatever unique thing it is they do with technology. next the budget allocated for these mundane infrastructure areas should be fully exposed, including assumed scale parameters. so they need to be able to state that their current deployment can handle up to “x” growth and then go through exactly how the environment would need to be extended to meet net new growth of “y”, what it would entail and how long they assume it would take to get it accomplished, especially exposing any assumed risk and what they’d need to mitigate that risk. the risk discussion is a normal part of internal company technology growth conversations so having it enter into a funding discussion is sometimes seen as peculiar but for me it just makes sense, i want to see how the normal technology decision making and thought process works so why not get into their treatment of risk.

so once the infrastructure is understood, its time to get into the architecture. this is where the conversation can go in a lot of directions and expose whether the company is grounded in its approach or shackled with barriers to growth and success. i pride myself in being a technology agnostic, which i feel has allowed me to work w/ a ton of technology platforms w/out bias, thus i feel i’ve been able to select the right technology tool for the situation at hand instead of starting w/ a technology preference and trying to then force it into a situation that it might not be well suited to handle. so this part of the conversation is meant to fully document the technology framework that supports the products of the company, whether its appropriate for the stage of the company, thus not overbuilt but also not architected in such a way that any spike or growth event will expose its fragile startup state. this is also the critical area for most funding discussions, if the expectation is to use funds to extend the framework how this is going to occur needs to be fully exposed and vetted, especially if its to extend functionality, because that means new product components, added risk and a grounding in change control management. I like to understand every aspect of software and methodology utilized by the technology team, which is sometimes shocking to raw teams because while they know what they do to create on a daily basis, they might not have had to explain the how and why details of it to someone outside their team. so i do feel like my asking them to walk me through “everything” is a good exercise for them in step back, take a breath and break it down into, we need to do “x” so we did it this way w/ “y” because etc… again a critical juncture in the discussion but often the pivotal point when I feel like i’ll be able to tell whether they’re “real” (as mentioned in part 1) or not… 

here’s my core technology sections of the outline that i tend to follow:

2.    infrastructure & architecture

2.1.    network & infrastructure diagrams (or descriptions)

2.2.    systemic, programmatic & product architectural diagrams (both physical & logical)

2.3.    data center services

2.3.1.    summary of data center services contracts (or approach)

2.3.1.1.    bandwidth under contract

2.3.1.2.    racks under contract

2.3.1.3.    data center operations services under contract

2.3.2.    budgets for all data center and operations support services for previous 3 full years and anticipated for current year

2.3.3.    provide methodology regarding disaster recovery & business continuity

2.4.    list of development, staging and production hardware in use, including whether it is owned or leased (include full specs)

2.5.    list of major software systems in use, including whether they are owned or leased or purchased on an asp basis (include versions)

2.6.    describe methodology related to such key technology decisions such as: security, data integrity, scalability, change control and dealing with emerging technology requirements (include any others as needed)

2.7.    please list major software platforms, toolkits and applications, including:

2.7.1.    whether purchased, partnered with or built in-house

2.7.2.    detailed description of all product related platforms/applications

2.7.3.    detailed description of all supporting or backend platforms/applications

2.7.4.    explain who is responsible for maintenance of the above platforms/applications

2.7.5.    please list details of all patents (device, method or process)

2.7.6.    analytics

2.7.6.1.    please provide all traffic metrics, such as monthly page views and monthly unique visitors for previous 3 full years and anticipated for current year

2.7.6.2.    please provide any other relevant analytical reporting that is utilized by the company for previous 3 full years and anticipated for current year

that’s it on core technology; again as i’ve stated throughout these posts, i try to keep it conversational and generic enough in nature to handle a wide variety of company types and scenarios, going into depth via additional questioning as needed. anything you think i missed in these sections? next post i’ll get into workflow and governance areas that i focus on which will hopefully be the final part ;)

technical due diligence (part 2)

picking up where my previous post left off, i like to start the technical due diligence conversation off with an overview of the intended company’s technology team staffing decisions, because this ultimately ties into every other technology decision in my experience. the easiest way to start the conversation is via an organizational chart, which should include all full-time equivalents (fte) including freelancers, part-time/temps, consultants and any outsourced groups performing a service that could if staffed as such be performed by internal employees. something commonly missed here is a statement of any open and/or desired resources, so i make sure to ask that they identify these sorts of openings, especially if the funding will be used to satisfy these gaps in staffing. the key to staffing structures is to make sure they’re balanced properly to “own” the company's key differentiators and perceived intellectual property while outsourcing the mundane commoditized technology areas to specialists in those areas of focus. in today’s market it’s becoming easier to identify and outsource commodity areas related to staffing decisions. if your hiring full-time staff in the wrong areas it will be immediately identifiable. an example would be a web company hiring numerous fte system administrative resources when managed care hosting is a commodity in today’s market, now granted some businesses are so specialized that they aren’t comfortable turning over system management to an outside entity so under that scenario i recommend the cto be prepared to justify the logic behind their staff makeup. also very early stage companies probably won’t be able to afford managed care, but they should be looking at smart, low cost ways to fulfill their needs without building up staff in non-critical areas. it really comes down to being able to expose the logical reasons for staffing vs outsourcing decisions. for an investment i normally stop here, but if it’s an acquisition I would then go into compensation of all staffing and if it’s a merger i would then get into the always fun discussion of redundant staff reductions. its also important to understand the structure of the staff, so i get into how are these roles organized and how do these organizations or departments interact. for example is there a development team and a quality assurance team, and what process do they follow when launching a new version full of enhancements versus dealing with bug related issues. or how is change control handled. i always like to use the phrase “take me through how you go from concept to production”, i find this is a very easy way to expose the workflow behind most topics. finally, staffing decisions do tend to tie in closely to core platform technology decisions, so i try to hold off on forming my opinions on staffing decisions a company has made until i’ve heard more of their technology story.

here is the staffing section outline that i tend to follow (1.2 & 1.3 are my acquisition versions):

1.    technical staffing

1.1.    organizational chart (or staffing list)

1.1.1.    please include all fte names & roles

1.1.2.    include any contracted resources & outsourced roles

1.1.3.    describe relevant groupings of roles such as development, operations and i.t.

1.1.4.    provide a logical workflow of how groupings interact

1.2.    salary information, tenure and basic background for all technology staff including compensation history for previous 3 full years and any changes anticipated for current year

1.3.    contracted costs for previous 3 full years and anticipated for current year

1.4.    please list any unfunded yet desired staffing or contracted roles with an explanation of reasoning behind desire

that’s it on staffing; again i try to keep it conversational and go into depth via additional questioning as needed. anything you think i missed? next post i’ll get into actual technology areas that i focus on ;)

technical due diligence (part 1)

i'm part of a venture related media summit next week, which falls at the tail end of nyc internet week, so i wanted to post something related to both. i’ve been asked many times to put my technology due diligence process online, usually by cto’s who have gone through it w/ me and in hindsight wished they’d have been more prepared for the level of scrutiny that not only my process puts them through but other venture or acquisition entities do as well...

“the goal of this due diligence process is to allow us to fully understand the technology practice of your company, including how you are staffed, your tactical and strategic utilization of technology and the processes that allow them all to work together to produce whatever it is you do for your company. we would like to be able to understand this for both your current state and your roadmap. so where relevant to your business, please be prepared to discuss and ultimately provide written answers to the following scoping questions...”

this is the way I start my investment or acquisition related technology due diligence questionnaire. if you’re a cto, at some point in your career you’re going to be asked to either help judge another company’s technology or be responsible for the technology of your company that someone else will be judging. this could be because of a desired partnership, a merger or acquisition situation or due to venture related funding. For any of these scenarios, the process is commonly called technical due diligence, the preparations required to handle the process can be a useful proactive exercise no matter which side you envision you’ll end up on. frankly at some point in your career odds are you’ll find yourself needing to provide questions and answers in most of the scenarios i listed above, that’s certainly been the case in my career. to optimize the process i’ve created a couple of standardized guidelines that i follow that can be easily distributed to a company under consideration, which normally gets addressed by the other cto. The level of due diligence is different depending on whether its going to be an partnership, investment, acquisition or merger opportunity, thus the need for slightly different approaches. By the way, in today’s market, most investment opportunities could change into an acquisition at any moment so its important to nest the approaches as well. For a partnership or investment you want to determine if the company is making good technology decisions and is “real” (more on this later). For an acquisition you also want to be exposed to every detail of their technology spend, plus identify areas for improvement that could be delivered as they become part a of your company. Finally for a merger it’s all about looking for gaps and redundancies that a combined entity could deliver. The goal of the due diligence process is to allow the interested company to fully understand the technology practice of the company in question, including how they are staffed, their tactical and strategic utilization of technology and the processes that allow them all to work together to produce whatever is done by the company. You would like to be able to understand this for both their current state and their future state called a roadmap. So where relevant to the business in question, be prepared to discuss some specific areas of focus for the technical due diligence: staffing, technology decisions and the processes utilized between the two. The ultimate goal of the due diligence process is to create a comfortable conversation between two technologists so that an understanding of current and future state can be achieved.

in order to keep this overview manageable i've decided to break it up into multiple parts so next post I’ll dig deeper on the specifics…

want dalai lama humor - news groper delivers :)

Richard Gere cheated on me - Dalai Lama's News Groper Blog

"What does Desmond Tutu have that I don’t? I know he’s not more spiritually endowed than I am. (We measured once at a Nobel laureate conference.)"

a friend of mine started this network of fake blogs, so i'm biased but i absolutely love them - i'm sure some of them offend some folks from time to time but life's to short to not enjoy harmless humor & how can you not laugh at a blog that pokes fun at the dalai lama, richard gere & desmond tutu all in one simple post based on a real world news event - brilliant stuff, even the comments are funny especially the troll baiting ones...