“It Starts with an Idea” – Available on Amazon

“It Starts with an Idea” is finally published and available on Amazon – Click here.


Read about the adventure of a start-up in Silicon Valley. The book interlaces the story of the start-up Intelic (renamed “Azerity” in 2001) with stories from prior jobs, valuable lessons learned. The book reveals how Intelic created a dedicated and enthusiastic team – a team that worked hard and had fun – and a great product.

Almost Ready to Publish!

Now that we’ve finalized on a book title and sub-title that ties in, the final draft proof is on its way in the mail. The title and subtitle are: “It Starts with an Idea” – How a little software company competed against the big software gorillas by turning an idea into practical software.

FrontCover BackCover

Our friend, Pete, came up with the title, which was actually one of the early chapter titles. Since the book is about a start-up, it made sense to use that as the title. I like it.

One final review then it goes to Amazon to publish a print and Kindle version. Hope you like it!

It’s the Holiday Season!

At this time of year, companies often wonder what the “right” thing to do is. Should we put up a Christmas tree or would that offend the non-Christians? Should we have a “Christmas Party” or a “Holiday Party”?

Often it feels like a no-win situation: The avid Christians are offended by the lack of Christmas celebrations yet most companies, unless you are Hobby Lobby or the like, want to respect their diverse employee backgrounds. There’s complaining going on about Obama Administration’s use of the term “Holiday Trees”. It’s hard to tell what to do nowadays.

I liked the way we handled it at our start-up, Azerity.

There were three co-founders: A Catholic, a Mormon and a Jew. We used to laugh about it and wonder how that happened – how the three of us ended up starting a company.

In December the first year we were in business, Steve, one of the co-founders and CEO, came to me and said “Let’s go get a tree!” I was chosen because I was the one with the biggest car – a Volvo wagon we could load a tree in. (He and John both had BMers). It was a bit surprising since our CEO was the Jewish member of the triad. But off we went. He loved to grab the saw, find the right tree and saw it down.

Julie had a good idea – she asked Steve if he would like to also put a Hanukkah candle in the entry. We all liked the idea of having both.

As we grew in size, next to the tree in the lobby we added giving barrels (one for toys, one for food). The employees enjoyed going to the salvation army one evening and volunteering to pack gift packages for needy families.

On our reception desk, besides the Hanukkah, Ashraf brought in a Muslim shrine. Behind the desk were hung red envelops representing Chinese New Year and colored strings of paper celebrating Pancha Ganapati, the Hindu alternative to Christmas. The invitation was open to all employees to display items showing how they celebrated this time of year.

We’d top it off with a party at our CEO Steve’s home. We’d do a white elephant gift exchange, eat a lot and have fun. The first year of the company it was hard to get many of the Indian engineers out to any parties or after work events. Not all came to the first holiday party. But through the years we worked to let all employees and contractors know we really wanted everyone to feel a part of the company. My favorite memory was the year when all the Indian engineers showed up to Steve’s house in traditional dress outfits – the women in beautiful bright-colored silk saris, the men in long jackets with Nehru colors, silky pants and dressy sandals. We co-founders were very pleased that they all attended and even more so that they felt comfortable enough to come in their traditional fancy wear. We were one big family.

We didn’t care if someone said “Merry Christmas”, “Happy Hanukkah” or “Happy Holidays”. Everyone felt included and enjoyed a season of camaraderie and giving.

A Tale of Two Universes (Selling “Vaporware”)

We’ve all heard the term “vaporware.” Software companies are notorious for selling it. It has become such an invasive practice that customers expect it.  

It seems all right at first. The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there. He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs.”

The customer debates a bit but three months later, the contract is signed, software purchased.

The Implementation Team has been selected. Before they head over to the customer site, the Services Manager calls the Services Lead into his office. “One thing you should know. The customer thinks the product does this and that and has these functions.”

“What?” says the concerned Services Lead. But it doesn’t!”

“Can’t you just configure it on the outside?”

“It doesn’t work that way! We need some product changes.”

“That’s OK – the engineers said it would be easy.”

The Services Manager goes to the VP of Engineering. “When can we have this product upgrade?”

“Product upgrade? We’re just starting final test right now for our major release. If we put this in now it would delay the release significantly and we have customers who are planning on this schedule.”

“But it’s a ‘must have’ for our new customer. Sales committed to it!”

The Executive Committee has an emergency meeting. Engineering is directed to create a branch in parallel during their final test sprint to try to get these features out right after the main product release, against their policies. The new features will be released 1 month after the major release.

The concerned Services Lead is told that they will just need to “fudge it” for the first few months of the implementation project.  

“It’s OK”, says their Manager. “The customer is using the Waterfall method and are first going to firm up their requirements, then spend a couple of months on detailed design. By then the release will be ready.”

An uncomfortable team heads over to the customer site with their instructions. They had been directed that during requirements review, to pretend that the features are in the product and check off the requirements associated with the new fields and functions as “OOB” (out-of-the-box). “It’s all right”, they are told by their Manager, “because they will be in the product real soon.”

During the detailed design phase the customer starts asking to see the product to help them envision the customization changes they are designing. The Services team knows many of the big features they expect to see there just aren’t there. There’s tap dancing.

Eventually the customer figures out that the software isn’t all there. The truth is out. There is a huge blow-up and the customer calls the CEO to complain. The CEO assures them that their features will be in the new release. They are still upset but sit down with the frazzled Services Lead to iron out what a viable implementation schedule would be including incorporating the upcoming product release. They start their work on the current release for customizations that don’t require the new features.

The new release is delivered and the customer’s policies require a total re-test. While re-testing they uncover minor changes in the completed configuration needed due to the new product enhancements not being exactly how they’d envisioned them. Because of re-testing and re-work, both cost and schedule are impacted. Although the contract was “Time and Materials”, they call the CEO and refuse to pay any extra cost due to re-work and he concedes. Still the project costs them more money than planned due to the schedule impact.

The customer isn’t happy but is used to software companies that are less than truthful. Standard practice, they grumble. The skilled Services team eventually delivers the final solution but the customer is less than thrilled.

Replay in a Parallel Universe

The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there.

  He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep sits down with the Engineering Manager. Here’s the features and functions that Client X will need if they buy the product. Is it feasible to get them into the current release?

The Engineering Manager and Product Manager have a quick meeting to determine the feasibility. They will need to move some features out of the current release now to make it happen but there are no clients waiting for those. She gets back to the Sales Rep with an “OK – as long as the customer can commit within the next few weeks while we still have a few Sprints left.”

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs. These few functions are not in the software yet, but if you buy the product the Engineering Management team has agreed to provide them in the next release which will meet your schedule. If you can sign the contract this month.”

The contract is quickly signed, software purchased.

The Implementation Team has been selected. During their internal kick-off meeting, before they head over to the customer site, the Services Manager calls the team into his office. “One thing you should all be aware of. There are a few features that are missing from the product but engineering has already agreed to deliver them in the upcoming release which meets the customer’s schedule. The Product Manager will work with your team and your customer to make sure we build the features the customer is anticipating.”

“Great.” says the Services Lead.

During the detailed design phase they start reviewing the product and proposed changes. The customer can provide input into the new features and iteratively they improve on them before the product development team has started their coding. In fact, they find a way that the product changes can be implemented that remove some of the customizations that had been bid, saving the customer implementation money.

The project is completed on-time. The customer feels they are part of the team and the vendor is the best vendor they’ve ever worked with. They will definitely consider this vendor for their next project.

They are happy to give a Press Release and authorize a marketing blurb for the vendor’s website.

Why Sell Vaporware?

Why do software companies feel they need to sell vaporware? Some misguided notion that customers won’t buy a product unless it has all features today?

The second scenario brings everyone on-board. The company is collaborating. The customer is respected.

Having worked on projects sold both ways, I can attest that the second, honest and up-front scenario is by far the best.

13 Tips for a New Software Start-Up

I was lucky enough to be the Co-Founder/VP Engineering, then CTO of a great start-up. Great in so many aspects:

  • Great partners
  • Fun, intelligent, hard-working team
  • Customer-driven product vision
  • Successful product deliveries
  • Supportive Board
  • Happy, loyal customers
The best job I ever had!   Intelic

What tips would I give to new software start-up entrepreneurs about Do’s and Don’ts for software start-ups?

Jan’s 13 Tips:

  1. Pick your partners/executives well. Co-founders and/or executive team needs the same vision and priorities and ideals. The team needs to trust the leaders and the leaders need to trust the team. Management needs to talk the talk AND walk the walk.
    Management Team

  2. People, people, people. Hire smart, hard-working engineers. I quickly recruited key engineers plus found a local company to provide consultants for a quicker ramp-up. If someone isn’t working out, do the hard thing that’s right for the rest of the team. Make the cut. This can be really, really tough and we all want to make it work out, particularly for nice, eager folks. But in a really small team, everyone needs to ramp up quickly and contribute.

  3. Don’t Over-hire. This one didn’t seem intuitive to me at first but worked extremely well for us. Our CEO had the belief that it’s human nature for people to always find work to fill their day. No one in a start-up is ever “not busy” – but are they busy on the right tasks? Another way to look at it is “focus”. If there are “just enough” people, then only the important tasks are done, instead of a lot of non-essential activity. In a start-up, non-essential personnel could include managers who aren’t hands-on part of the time, project managers there just to track status, IT resources, etc. Instead, initially hire for the key spots: Sales/Marketing, hands-on Engineers (including somebody that will also manage), one Finance guy (unless the CEO is also an MBA then they cover it). When the product is ready to be released, add services people, IT, Finance, and someone at the front desk.

  4. Keep the software team co-located. Nothing is as distracting to a small software team as trying to establish a remote, off-shoring facility. Team focus is extremely important.

  5. Focus on delivering what the customer wants. If you’re lucky, you’ll have what we had – early employees who had worked in our target business area that were smart and knew exactly what the customers wanted. If not, find those people – they are key to your team. We built a prototype. Showed it to perpective clients. Got feedback. Updated the prototype. On the day we officially formed the company, we had a robust prototype (HTML screens and flow) plus our first customer and $1 million from Angel investors (most of whom were also from our target business area).

  6. Focus on delivering what the customer needs. If you’re building the software, also think about all of the aspects of the product including how the IT managers will want to customize it, install it, take releases. Plan for that up-front in the way the software is architected and built. We did this in the first release through business properties so the clients could change business policies to match their needs. Also the code read from resource files that contained every word displayed on the screen, including error messages (I highly recommend all software be designed this way) so the clients can use their own terminology easily or even localize to different languages. Later we added a GUI configurator. The easy installer was built in an early release. The upgradability was part of the development thought-process. If you’re building software that needs to be installed and upgraded, this is key. If you’re building cloud software then you’ll obviously need to have easy configuration, install and upgrade tools. And plan for global users – review how “time” affects your application and if important (e.g., contract start/expire timestamps) convert to UTC/GMT global time and build functions to handle time appropriately/consistently.

  7. Pick the right architect. Monitor initial concepts and progress and pick as the key architect the engineer with the best sense of a clean and simple design, regardless of whether he had the most experience or was your initial architect candidate. The right architect is key to product success!
    Keep it simple

  8. Keep it simple. Don’t try to build an architecture that will be everything to everyone – build what you need. Refactor as you go along if necessary to keep the code clean and efficient. A simple framework will be quicker to develop new features on, more reliable, and more maintainable.

  9. Don’t be afraid to build it. Your CEO may say to buy, lease, integrate but for a small company if it keeps things simple to build, keep it simple. Originally we used a 3rd party object-to-relational layer. The night before a major demo it failed. If two people clicked the same button at the same time on their separate browsers, kaboom! We limped through the demo by having copies of the app running on each training system instead of the normal browser configuration. Our architect had, for fun, built a layer for his own use and we quickly migrated to that. It was exactly right for our needs. Simple, clean, just enough. Someone years later asked me if I were to do it again if I wouldn’t use Hyperion, said he would. “Better to buy than build. Better for the engineers resumes,” he said. No, I’d do it exactly the same way but start with the build, not buy version. There are exceptions – I wouldn’t build my own relational database, Java compiler, charting package, etc. But I’m not one for adding tens of thousands of external library files to my release “just in case” one of the handy, dandy tools comes in useful. Keep it simple.

  10. Implement a Practical Software Process and Tools. Choose a software process and tools that are simple and streamlined while you’re small but that can grow and support a scaling business model. Our recommendation is one tool that handles your key process (e.g., Agile story management, task tracking) and provides on-line automated spec viewing.
    Software 2020

  11. Focus on quality. Fix the bugs as they are found. Use a quick, iterative method for ongoing maintenance releases. The only bugs that should not be fixed ASAP are ones that are found internally due to some weird, illogical path through the software or that are so small and cosmetic no one will notice them. DO fix even small bugs that are cosmetic if they are visible on the screen (typos, etc.) as they detract from the professionalism of the software. To streamline the process, use a good bug tracker tool. Have a cross-functional team meet weekly to review new bug reports and keep the funnel flowing. We called it our SDRB (Software Design Review Board). In the early years the head of each cross-functional group would attend, including the CEO (who was also Product Marketing). As we grew the QA Director was the lead but still heads of each org attended: Director of Customer Support, VP Engineering, VP Product Marketing, etc. The top person would attend (if in town), else his/her delegate, so decisions could be made at that meeting and each new bug report allocated to the appropriate release. That way, bug reports and client issues don’t get revisited again and again but are reviewed and assigned to the right delivery timeframe once, promptly.

  12. Focus on application speed, performance. Performance is an extremely important aspect of quality. At Ford Motor, when they built CAD/CAM systems internally for their car designers, they found that more than a second delay in when the designer clicked the light pen to when the screen responded would cause the designer to lose focus and made the tool less effective. Screens must be blazingly fast. Anything taking more than a few seconds needs to give the user the option to “click refresh” or go elsewhere to do work while the screen completes (not hold the user hostage until the processing is done).

  13. Lucky # 13 – Work hard but have fun. We had off-sites. Most importantly, we worked to be sure that everyone, even our Indian consultants would attend them. So the entire team became a close-knit group and everyone was treated with respect. We had yearly “Star Wars”, then “The Matrix” movie outings where our CEO handed out hot dogs and popcorn. Make “fun” part of the culture, part of the daily dynamic. The engineering group had fun with humorous email comments (always respectful but cute). As a manager, play along, encourage it. Don’t be stuffy. We added ‘quotable quotes’ to our bug tracker tool so every time someone submitted a new bug or enhancement request, they saw a random quote. Something someone had said but taken out of context and therefore very hilarious to all of us. At cross-functional meetings when someone says something that can be misconstrued, someone will say “Ahah! Quotable quote.” and it will end up in the system. The more a team is willing to be playful, it shows they trust and respect each other.
    Quotable Quote

    As another example, decorating the cubes when someone goes away on vacation. My favorite: The engineers were going to nail a big piece of plywood over our Dev Manager’s office door when he went on vacation but I said “No nail holes in the building!” (We were leasing after all.) Just then our CEO came up and saw what the engineers were about to do. “Wait a minute.” he said and darted away. He returned with his power drill. “We need this! Nails won’t do,” and proceeded to tightly drill, screw, and seal the plywood over the doorway. Gary sure had trouble getting into his office when he returned 🙂

    Of course, the fun is part two – the tip is “Work Hard” THEN have fun.

What is “Respect”

In a LinkedIn thread, someone asked “what is ‘respect’ in the Agile context?”

What is a sign of respect?

Since Agile is team-based, an obvious trait of any well-functioning team, Agile or otherwise, is showing respect for each other. And, after years as a professional, it seemed kind of intuitive to me what “respect” in business is and the same applies to Agile.

However, is it intuitive when there are cultural differences – either global culture differences or workplace cultural differences?

  1. An American had held several meetings in a remote Japanese village. He was on the train returning to the city but had fallen asleep. When he awoke he was sitting by an elderly Japanese man. He said “Have I missed ‘X’ stop?” The man said “No”. A couple of stops later the elderly man got off the train. At the next stop the few remaining people in the same car left. At the next stop the train stopped. The American found a conductor and asked why the train had stopped. He said “It’s the end of the line.” “What?” said the American. He was furious because he had, it seems, only missed his stop by one and could have easily walked back but now needed to purchase another train ticket or find a taxi. Had he been Respected? Disrespected?

  2. There was a discussion about if it was respectful to shorten or change someone’s name into a nickname they did not use. Or to misspell or mispronounce someone’s name. I was reminded about when I was part of a business meeting with gentleman from Japan. We had been briefed as to the traditional meeting protocol.
    The Tradition of Bowing

    At the beginning of the meeting, the representatives from both companies formed a line and one by one as each Japanese businessman came forward they met each person from our company by exchanging business cards, both bowing, and each reading each other’s name from the card, starting with the host. We had business cards printed with English on one side, Japanese on the other. The first man came forward and presented his card. We bowed. I took his card and read his name. Then I presented my card with the English print facing up and toward him. I was to hold it with both hands by the upper corners. Lean forward slightly to bow while offering the card. He took it, flipped to the Japanese side and said “Jan Makuru-san”. Totally mispronounced my name. Respectful? Disrespectful?

  3. In the afternoon during the same meeting with the Japanese businessmen, I was presenting. The lights were low for the projection, the room warm and hum of the projector in the background. Two of the five businessmen were sleeping. Respectful? Disrespectful? Room too hot? Or was I just boring?

  4. More sleeping-on-the-job: It was a Sales Off-Site for a small U.S. start-up. In the morning, the CEO/VP Marketing was giving the presentation explaining the product direction and overview of the sales strategy. He noticed a newly hired Sales Director was asleep. Respectful? Disrespectful? Or was he just bored?

  5. I was newly hired as Director of IT Technology in a company that had only had a few newhires in the IT organization in many years. Most of the members of the IT organization had been with the company 10 years, 15 years or longer – most in the same job for as many years. Part of my responsibility was SAP Basic and two of my system engineers came to me to say they found that last night’s backup had issues – they feared the backup tape drive was failing. They told me who they used for service and could call and have them come in. I said “Great, have them come in as soon as they can”.

    One of the engineers said “Right now?”

    I said “Yes, if they are available.” I wanted to be sure if there were parts needed or any other issues we had the best chance of getting the tape drive ready for tonight’s overnight backup.

    They said “Will do” and started walking away to make the call. Respectful? Disrespectful?

Back to the first example. Was the elderly Japanese man being disrespectful? The conductor explained to the American – “In our culture, the worst thing you can do, the greatest disrespect, is to cause someone else anguish or grief. He knew you missed your stop but if he told you that would upset you. He would never do anything to upset you.” He was not being disrespectful.

What’s in a name? If someone says “Hi Kev” and his name is “Kevin”, is that disrespectful? It depends. Were they doing it in a “buddy/buddy” way, to show familiarity? To show friendship? If so, it isn’t disrespectful (unless Kevin tells everyone he “hates” to be called “Kev” and they keep on doing it to aggravate him). Are they saying “Hey, Bubba” to annoy you? Then yes, it’s disrespectful. If you mistype someone’s name is that disrespectful? No, it’s a typo. Was the Japanese businessman being disrespectful? Of course not! There are many syllables that do not exist in the Japanese language, particularly difficult is the distinction between our “l” and “r”. Adding “-san” at the end is the formal form of respect. So yes, he was being very respectful.

Sleeping on the job? It depends. I knew the Japanese businessmen would be sleeping in the afternoon – had already been briefed and told not to worry about it. It’s common practice. They do a quick nap after the noon meal and wake up and quietly whisper to get caught up on anything they may have missed so at the end they are all still up-to-speed. Was it disconcerting? Yes because they were either sleeping or whispering. Did I take offense or feel disrespected? No – because I understood the cultural norm.

How about the new Sales Director? He was fired shortly after. Not for the one transgression but it was the last in a series of attitude issues that demonstrated his lack of seriousness in learning the job. The once-a-year Sales Training delivered by the CEO himself is the very best place to gain understanding about the company, product, and sales value. Sleeping through that was unforgivable and the last straw. (And it definitely was NOT a boring presentation!)

That last one was a bit of a trick question until finding out more. I saw a glance between my two system engineers as they left and called them back. I said “Was that not the right choice?”

Their eyes got wide and both were “Huh?”

I said “Is there a reason not to do the servicing now?”

One replied “Well, to service the tape drive we need to shut down the production servers.” I was not familiar with these HP systems but others I’d worked with allowed the tape drive to be taken off-line and reassigned without the system having to be shut down.

“It’s only 2 PM, we can’t bring manufacturing down now. Is there any reason you would not want to do it at 6 PM instead?”

He replied, “6 PM is when we would do it.”

“I have to ask, why were you going to bring them down now then?”

“Because you told us to. Our last boss would have yelled at us if we didn’t do exactly what he said.”

“Even if it was the wrong thing to do?”

“Yes – he never wanted to be wrong. We could get fired!”

These two were definitely showing respect upwards. But their old boss had not shown them respect going the other way.

Is there any difference between respect in an Agile Team and respect in general? Respect in an agile team or any good professional relationship is a two-way street. In a top-down management heavy culture, the employees may show respect to their boss (as in my 5th example above) but if their boss doesn’t show them the same respect (by listening to their inputs, asking for their suggestions, and letting them learn and grow) it isn’t a culture of respect.

So what is respect? The list is longer than this but here’s a start of what I think are the most important aspects.

  • Working to communicate clearly. While the elderly Japanese man’s actions are explainable for his culture, the goal is for the entire team to have a common basis of understanding that it is not “bad” or “disrespectful” to communicate if there are issues in the code or other problems – that that is “good” because it keeps the issues from the customer.
  • Asking for/accepting input. This is the two-way-street of communications.
  • Listening to input without criticism. (Also referred to as ‘Attack the problem, not each other.’)
  • Communicating honestly, but with tact and care for each other’s feelings.
  • Evaluating your own feelings. If you are offended by something someone says (or feel disrespected), first step back to question if it is disrespect or lack of understanding. Lack of understanding can indicate either incorrect/incomplete communications or cultural differences. Go back through the first four bullets above to see if you are communicating and caring for each other’s feelings.
  • Working as hard as you can to do the job you have been assigned.
  • Doing as much as you can to help people you work with.

And after further discussion on LinkedIn, this seems like a good set of principle defining “What Is Respect in Agile?”:

  • Communicating clearly in a way that leaves no possibility for doubt on intent
  • Communicating honestly, but with tact and care for each other’s feelings
  • Working to continually improve the way the team functions and interacts
  • Communicating both ways – asking for and accepting input, listening to input without criticism
  • Being supportive of team mates
  • Being considerate of each other and the customer
  • Trusting each other to do the right thing
  • Working hard towards a common goal – contributing to the fullest extent towards the technical excellence of the product

Any healthy work environment requires respect both ways!