Simple Language, Simple Solution.

by Posted on

It has been quite the month, getting fully vaccinated for COVID (the second shot is rough), emerging from my burrow, client moves, internet providers’ vagueries, random OS updates, and some serious online seminars.

There is an old joke that AWS solutions architects can only use words with less than three characters, EC2, EBS, S3, SNS, SES, ELB, EFS, and the like. And I do resemble that remark.

One item from all of this is the importance of simple language and planned questions to discover business needs. Having spent the better part of a day designing a multi-site, multi-AZ, autoscaling environment with multi-region failover to be deployed with TerraForm and fronted with Cloudfront, web environment. After presenting the solution, the client commented, “I missed the class on crazy alien languages.”

/FACEPALM/

The client in question ran a WordPress site that served maybe 2000 visitors a day. So maybe my solution was a little over-engineered. Even more to the point, perhaps a few questions to discover the Business Needs before donning my engineer’s cap and designing a system that would handle 100 times the current traffic was in order.

I suspect some questions, would have served me well, perhaps in the line of:

  • What is your platform?
    • (or better, do the research.)
  • How many visitors do you get a day, a week, a month?
  • Is your traffic steady or burst driven?
    • (better yet, get logs and do that research)
  • What are your business goals?
    • (maybe ask that first?)
  • What are your business challenges?
    • (They have them, you’re here, right?)
  • How do you measure your site’s performance?
    • (Do they HAVE metrics?)
  • Don’t babble about security.
    • (You do security. You are a professional, ask the question once, and move on.)
  • Ditto on backups.
    • You are professional, you do this as a matter of course. Ask once, and move on)
  • Do you have a web design firm?
    • Or is this in-house?
    • How is the site updated?
  • What are your growth goals?
    • Follow up with questions on how the website helps those
  • Do you do e-commerce?
    • Again, you should have done the research.
  • What is the website update process?
    • Ask that of the webmaster, not the CEO, CFO, etc.
    • Target your discovery questions. Make them relevant to the audience.

This entire process is called discovery. BEFORE you walk into a first-time meeting, make sure you have the research done, be ready to ask some leading questions (PLAN THOSE QUESTIONS), be ready to note any specific issues mentioned, and be ready to follow up on those issues with the PROPER persons.

The CEO may not know his hosting spend; he WILL NOT know how the website is updated, upgraded, or even hosted.

The CFO will know what it costs, but he probably won’t know why it costs that much.

The Sales manager won’t know or care about anything, but how many leads / sales come from the website.

The webmaster probably won’t know the costs but should know all the moving parts, and processes.

At no time in the discovery process should you start talking about solutions or prices. Define the problems first, then consider solutions, AFTER you understand ALL the problems. (The C-Layer will know 10% of the issues.) This entire meeting or set of meetings is about the client and their needs; you will get your chance to talk your talk and walk your walk AFTER you sort out what the client needs and have a rational, UNDERSTANDABLE plan to meet them.

And ABOVE ALL ELSE, use full sentences, avoid techno-babble, and use simple plain language. (You can walk around the streets of Manhattan, mumbling incoherently to yourself like a crazed homeless person later. Just not in front of the client).

Check your certifications at your office door; the client does not care; they care about how you can help them with their issues, not your certifications.

Published by crawls