iKennect.blog

By definition this latin word describes a person who is no longer favored or welcome. In corporate America this describes a person that bucks the system once too many and is on the outs!

If you are anyway dedicated to the craft of developing software this definition may refer to you.  If you have been preaching about architecture, SOA, Agile, SaaS, etc to no avail, this definition may refer to you.  If you have made countless presentations to board members or executive management and are frustrated beyond recognition, guess what this is you.

I have free advice that will place you back in the favor of the powers that be. Let me harken on a quick but effective analogy. I'll try not to beat it to death.

Ever notice that laminate floors look just as good as real hardwood to the average Joe? Ever notice how quickly laminate floors can be installed by the average Joe? Unfortunately this represents the state of software development in many organizations today.  Companies want the quality of hardwood for the laminate price. Who can blame them? Scripting languages and WSYWIG tools have provided a rapid path to "it works" and have wet the appetite of entrepreneurs who want the software built yesterday. With the power of scripting languages and the willingness to cheat at every corner, a software developer can make amazing almost impossible progress in short order.  Amid the cheers of a working demo there is always at least one software developer with a sinking feeling in the pit of his stomach. He knows it won't work. Are they going to release this?

The best approach in defeating this evil short sighted principle is to first identify what type of company you work for. Is it a company that survives solely on the strength of its relationships? Do they starve the technology team for resources? Does the company actually make money because of the technology?  If they don't and you are a disciple of any software discipline you are in for a fruitless uphill battle to no where. Trust me no one will appreciate the science part of your degree nor will they care what data structures you are using of if your database has been normalized. Those pretty block diagrams and all that thinking at 3AM will go where ideas die.  That said if you are seeking to reduce the acids in your stomach, put away the botany set and give them a chia pet!

The best advice I can give is to understand the business need and give them what they want. And recognize that what they want is often not right! You will have more success understanding your role and producing quickly rather than convincing a ton of people from other disciplines that doing it "right" will yield them savings in the future!  Most business aim to produce revenue with the promise of profit. Your job is to help attain that goal with the help of technology. Sometimes creating a platform in 3 different scripting languages with a text file for a database is the best path forward.

Here is another piece of advice. Showing them a spreadsheet of how their decisions are wasting investor's money doesn't work. This is especially true the smaller the company. The winning formula is to produce quickly and talk about the craft of software with your geekie buddies.

A mentor of mine gave me priceless advice years ago. "Always act like a consultant." Consultants suggest but ultimately deliver what the customer wants. And if communication is managed successfully they get more business even if the final result is not what the customer thought they were getting. Try it and watch the results materialize.

Unfortunately non-technologists can only distinguish great technology from bad when something goes wrong. Plumbers and Engineers get paid the best money when things go wrong.

Trust me. You will be forgiven if you produce quickly-- even if it doesn't work!

The mathematics around investing in Software Development may be counter intuitive to most. As anyone in business knows, people are the greatest expense and assets. This well known fact seduces business owners to look for the cheapest talent possible in order to yield maximum margins. This can be a critical mistake when developing technology and a dagger into the heart of the business during a recession.  Albeit tempting to be penny wise and pound foolish, I hope to shed some light on how to spend today's important dollars to solve tomorrow's technology challenges.
 
 Producing sound technology is a challenging endeavor that requires investment. In software this translates into dedicating engineering resources and time to a common goal and plan. To state the obvious an engineer commanding 70K per year is different than an engineer commanding 100K+ a year and the difference is not just 30K. The delta represents mostly experience and to a lesser degree raw talent. Even still business owners load up on the least expensive engineers and plummet into complex product ideas only to find out later that the product has to be rebuilt! It is commonly known in software that the cost of rebuilding is far greater than double.  Consider building the foundation of a house incorrectly. To start over you have to destroy the house, demolish the foundation, rebuild the foundation and the house.  Let us also not forget there is a cost to throwing things away.  Suffice it to say that it "pays" to get it right the first time.
 
 What does paying mean? It means fewer engineers paid at a higher rate as opposed to double the amount of engineers paid a lower rate. Said another way, many junior engineers left to their own devices can often equate to more confusion and costly development cycles.  The result is often catastrophic preventing scalability and growth. Worse yet you sell a lemon to customers negatively impacting your product and brand. Having the right number of engineers with the right experience sufficiently compensated will increase your chances of having proper rigor in development reducing cost over time.  Ideally these engineers produce a blue print for what is to be built-also known as an architecture. It is the manifestation of this architecture that becomes the company's intellectual property (IP). IP-when done right-equates to a higher evaluation.
 
 Business owners will reap the benefit of additional savings for every engineer acquired after the architecture is in place. Although this will be invisible on the balance sheet, this will represent the most significant savings overall!  Investing in the talent up front that can give products the proper start and foundation and will ensure that you are maximizing your investment for engineers that join the project later.  Just as the painter cannot start until the drywall is in place, the software programmers should not start until the architecture is in place. This is often missed because all talent is mistakenly considered equal.
 
What is the right talent? You need an architect that constructs the blue print of the house you are building. You then need a team of people who follow the blue print, in their respective areas of expertise, and a process to manage how things are built as well as the schedule.  You may be asking yourself how much should it cost? To answer a question with a question, how much is the problem worth to you?  I did a quick salary survey and found that software architects range from 125K up to 200K+ depending on geography and the complexity of the technology. If this article had ears, we would all hear massive sighs! It seems like a lot.

It's all about approach. At the end of the day the most effective team will have an architect spending 80-90% of his time ensuring that the overall design is followed and in tact. A large part of the job is making trade-offs where necessary keeping in mind there is always a happy balance between pure architecture and meeting the demands of the customer. Working with the architect is a Senior Engineer or two. Their task is to do most of the heavy lifting designing and implementing large chunks of business logic.These guys are typically coding experts ideally with domain knowledge. Last but not least and equally important to the team are junior engineers who focus on very specific components of the system spending 100% of their time coding, testing, coding, testing and coding and testing. Get the point?
 
The bottom line is quality software requires investment in time and money. Software has the uncanny ability to make it all seem easy like dragging and dropping icons on your desktop. Your team needs structure. Your process needs structure. Your software needs structure.
 
The tried and untrue method of cheap talent all empowered with blunt objects will waste time and investor capital. If you follow the same old route, you will end up at the same old place at a greater cost! Technorati Profile

By now you've heard the word scrum in the hallways of any company that builds software. In many cases, mid-sized companies managing multiple projects have embraced the term and have launched numerous projects under scrum management. Many technology leaders are befuddled when projects under scrum management false start or they see the utter confusion on everyone's face. Why is a system developed to be more simple and productive so hard?

It is simple right? Everyone knows that Scrum is a skeleton process with predefined rules anchored around the ever present "ScrumMaster." This product owner runs sprints, lasting 2-4 weeks, with a goal of creating incremental usable software. Ideally the business stakeholders see usable software at the end of a sprint and the big kicker is the developers produce testable code in nice bite sized chunks. Let us not forget that a product person chips in by owning a product backlog comprised of "user stories." The value of a user story can not be understated. In the simplest terms a user story defines the product/feature in layman's terms so that everyone is on the same page. This loose process is supposed to be a recipe for productivity.

A scrum purist will tell you that by definition scrum accepts that products and/or solutions cannot not be created in a predictive manner. Change is inevitable. Scrum embraces change and focuses on quick deliverables traversing a common vector.

So what's the problem?

Ironically Scrum is typically explained to the masses from a technical person's perspective. I've personally seen insane productivity numbers once scrum is underway. Despite measurable impact, the business stakeholders can be left with a stale taste in their mouths. As anyone in software knows, you can deliver on time and to the specification and still fail!

Scrums fail for two primary reasons: poor presentation and lack of focus on users stories.

Technologists often forget that they must sell the process. Proper expectations must be set in the language of the business stakeholders. One common mistake is to fall in love with burn down charts produced by scrum management tools and show them to the business team. Think about it! You show a chart that shows how far ahead you are or how far behind you are. Both have downsides. If you are ahead more features are required. If you are behind, in their minds you might as well revert back to old faithful- the Water Fall method. The reality is the schedule doesn't matter!

How do you sell it?

• Sell the business team on productivity and what they will get and not how well the project will run.
• Speak to the transparency of scrum. Everyone is involved sooner, thus identifying potential problems earlier saving time and money.
• Scrum is a methodology the company should use, not just an engineering process.
• Products/features are delivered sooner thus contributing to revenue sooner.

As the business changes, scrum adapts. It's like turning a speed boat versus the Titantic. The other common mistake is to build features that sound like the following : "Build SQL scripts to archive old table data" or "Upgrade source code to use LINQ." Neither of the two mean anything to the business team or better yet the sales team. While they maybe tasks that are necessary, completing the tasks yields nothing. A better approach is to develop crystal clear user stories such as "As a user of Acme site, I can search for data for up to 12 years in the past" or "When a user is in the process of registering, if he clicks back and then forward his progress is saved."

Concise user stories will level the playing field for the business and development teams and give them a common language.

Give it a try.

Overview

The vast majority of start-ups fail. Roughly speaking one in ten have a shot at the proverbial IPO and even then an IPO can mean nothing. We often forget that an IPO with a low stock price means nothing to anyone involved except maybe to the preferred shareholders. Having worked at about 7 start-ups, I thought I'd share my experience with the hope of helping the techie entrepreneurial crowd. I am biased!

None of this shared information guarantees any success whatsoever. Rather it should definitely help you identify the true dud. I am certain some duds have made it to the big time, but if you play the percentages like anything else, numbers don't lie.

This topic is near and dear to my heart. Many technologists align themselves with early stage companies, excited about the technology and hope only to end up with lots of software that does stuff, but nothing you can put in the bank. Read the following with a grain of salt.

If the idea doesn't make sense to you, it probably won't to anybody else

We've all met the savvy business types that can sell any idea.  While most software engineers can conquer millions of search requests all happening at once or write sorting algorithms that simply boggle the mind, most still get hood winked by slick talking MBAs. Most engineers at a certain level can build anything. Anyone who doubts that can search the net and find the tons of absolutely brilliant ideas out there. Many are free! I am amazed at what the open source market has produced. When listening to an idea, it must make sense to you first. Many times the technology is held out as a carrot. "You can build it with anything you want."  Don’t let your excitement about the technology get in the way of sound judgement. You should understand the business model thoroughly before giving 1 to 5 years of your life to a project. Many business types think if you get a 30" monitor and cokes in the fridge you'll work until your fingers turn numb and they hope you don't ask too many questions about the financials or the model. Ask yourself if anyone you know would use the product or service or would buy it. What's the market size? Give it the same analysis you would a complex design.

Structure good contracts

Most CTOs or Chief Architects get pulled into a company as a founder and get offered about 3% in some type of equity. In many cases this is a fair offer given that you are not a founding member of the team. That said if you are this is a complete rip off! Consider the task at hand in a nutshell. You will design the technology; code it; setup the company site including phones, switches and email; manage a staff often including product management, QA and any support; manage the ISP; jump through hoops not to use licenses; work very late hours, etc. Why sell yourself short? Know your value and ask for it. If you aren't a founder, tie deliveries to bonuses. Try to get a sum of money or equity by hitting key milestones. Investors and founders value people who value themselves so don't be afraid. Remember only 1 in 10 have a shot!

If you are a founding member, get everything in writing up front. This seems like a no-brainer, but tons of trust and excitement have often resulted in huge disappointments. Many startups get bootstrapped with small amounts of cash from the CEO and/or angel investors. As soon as the company takes a round of investment capital, you are likely to be diluted. Even with anti-dilution clauses (almost no one gets this anymore) funny things happen. You are still better off with a contract in hand. Show this contract to a lawyer.

Technology != Commodity;

If you are a CTO of a billiards company, you will not be able to maximize your opportunity. I used a billiards company because it sounds ridiculous. The point is work where the technology you develop is valued. What you do should produce revenue. What you work on should be why investors invest. What you produce should not be perceived as a commodity. Business types often describe technology in such a way to devalue the effort. If it’s not really technology it shouldn’t take so long right? This means that what would take 6 months can be done in 2 weeks right? Don’t believe the hype and don’t take the job. If you are a true techie and work where this is the case, blow the dust off your resume. The best deals are given to those that are between the investor and his or her money.

The business model should not be "Go public!"

Many entrepreneurs are fixated on going public. A sure way to fail is for a company to focus on the exit strategy before developing a good product and service and understanding their audience. Run for the hills if being presented with an idea in a coffee shop and before the coffee is made, the exit strategy is brought up. Companies that win understand their market and can adapt when the market changes. These same companies also understand what they should measure. Conventional wisdom suggests that companies should have 3 things they measure constantly to determine the health of the business.

Sure everyone wants to know the exit. Why else would you join a start-up? This does not debunk the fundamentals of business and sound execution. Good companies have vision, plans and a way to execute. Strong leadership can sometimes compensate for what isn’t written down, but you need one or the other. Start-up and plan don’t have to be mutually exclusive.

Look for what investors look for in a company

I've had the pleasure of working with lots of investors who are worth all sorts of money made all sorts of ways. I approach them like a student and ask tons of questions. I often ask, "what makes you invest and take a risk in a company?" More often than not they are investing in the management team and/or the person - usually the CEO - who presented them with the idea. Yes the idea might be sexy, but at the end of the day they are investing in the team. That said evaluate the team for your self. Is the CEO execution oriented? Does he just have a good idea or do you think he can deliver? Has he delivered before? Does he have people who will challenge him on the board? Does the model make sense? Can he tell you his vision of the company in 5 years?

I can’t stress enough the importance of a good board. If the board is unable to help the company or they are simply friends of the CEO, it’s probably a bad idea. Many companies when raising money lean on the board for connections and all sorts of partnerships. You also want a board strong enough to keep the CEO in check. If you are taking such a position meet the board and get comfortable with them. If you are unable to meet the board run for the hills again. Relationships are king and you need your own relationship not the filtered version provided by the CEO.


Every investor meeting or opinion is not an emergency

Successful companies are true to their products and most of all their customers. Think of the products you like or the websites you visit regularly. Good products take focus dedication and a keen ear pointed towards the user. After all they matter most at the end of the day. There is a thing called good solid product development! Why do I point out the obvious? In many cases early stage companies chase their tails based on what some investor thinks or some article they just read. If a company has started with the proper research and was able to get money based on that idea, develop that idea. Proper research should prevent any company from having the rug pulled from under them such that they need to switch models or product on one particular day.  While new ideas are good to vet, they should work within the overall product model. Companies like Google and Symantec spend lots of effort matching a product to a market and understanding their users. I’ve worked for both.

If you work for a company where technology counts and you are the expert, it’s your job to protect investor interests by developing the right product the right way.

Pay attention to who the CEO hires

Good leaders hire to their weakness. They understand the value of having a domain expert assist in propelling the business forward. This should be the reason they are hiring you! If the IQ among your peers seems to be low, run for the hills! I’ve been in several situations where CEO’s have hired positions to have a check mark on an investor presentation, including CTO. Typically this character assumes they know your job and everyone else’s better. Every position is trivialized except of course the CEO position. I strongly suggest that you interview your peers and get an in depth understanding of their background. See what they know about the value of delivering technology. Smart business people will understand that there is a huge difference in value between companies that develop real technology and those that shift weekly producing only demo ware.

Before I write this first blog, I must send out a thanks to Phil Haack for taking Subtext to the next level. I can't wait to see what's next.

The focus of this blog going forward will be the business of software. The goal will be to shed light on issues like landing good consulting contracts; negotiating that great deal as an architect or CTO; landing a great project and managing it to fruition on time! Given that I am transitioning from Google to WebVisible, I thought I'd take a second to blog about that.

Working as a Google consultant has been a great experience. As you may have read, everyone there is smart! I don't recall working anywhere where almost everyone is a master of their domain. Google has done a great job of providing an environment that promotes maximum productivity while making it fun. It's like a college campus filled with electric scooters, engineering gadget toys, a pool table, assorted snacks and all you could dream of in terms of resources. They really have crafted an environment that balances life and work. I worked in the Irvine office and from what I hear the main office has much more to offer.

The Google mystique is a hot topic among engineers looking to advance their careers. I've heard countless stories about how hard the interviews are and how many seemingly qualified  candidates are turned away. It's all true! I've known of good friends, many of them rockstars, that were turned away. They simply bombed in the interview.  While I am not a huge fan of their particular process, it works! You might say it only works because of their success and the countless engineers that would give up salary to work there. You might also suggest that a soring stock price can attract anyone. My answer to that is well, it works!  The vast majority of companies would fail to hire anyone with such a rigorous process.  Google perseveres and would much rather pass over 10 possibly qualified engineers to get the one they are sure about. It is what it is! Embrace it if you wish to work there.

What is the interview like?

I won't recount any of the questions I was asked but I might be able to shed light for anyone looking to become a Googler. First and foremost prepare. Dust off your computer science books and become one with the basics. That means knowing all your data structures, basic algorithms, implementation techniques and design.  The kind of engineer that makes it into Google is one that is passionate about software development itself. One that can work out problems on the white board and is truly interested in object models and the like. This engineer will also be able to expound on topics like lists and Hashmaps, when to use them and why. As with any interview in any business vertical, you need to walk into the interview an expert. The simplest advice I can think of is, you will be asked very challenging questions, talk them all through no matter what. You aren't expected to nail each and every question. You are expected to think and you should be able to apply computer science principles to real life problems. Read any data structures book you can find. Seriously! You should also know Big O notation and how to analyze algorithms as such.

Why leave such a great place to work?

While Google might represent the happiest place on earth relative to software development, my passion has always been building technology companies.  The process of amassing a team from the ground up and taking a company to that next logic step and beyond is rewarding. I've always likened software to making a movie. You take an idea on paper, flesh it out, get a great crew and work hard until you are successful. My next production will be WebVisible. They made an offer I couldn't resist and their philosophy on balancing family and work is outstanding. This philosophy is the future of successful companies.

Wish me luck!

Powered by ScribeFire.