FAQs: How Link Building Works in 2018

This week’s FAQ contains all the juicy questions about link building, as well as what I’ve been listening to recently.

What’s in the Boombox

Van Halen by Van Halen

I’ve never been a huge fan of Eddie Van Halen as a guitarist.

I know, I know.

It’s taboo to say that in the metal community. Especially if you’re a guitar player! I’ve just never “understood” the hype that came along with Eddie. I’ve been a Van Halen fan, but never thought of him as “the greatest ever.” This year, I decided I would learn all of the songs on the “Van Halen 1” album on guitar.

Regardless of my personal feelings, it’s difficult to argue that this album didn’t change how rock guitar was played. The tone, the guitar parts, the mix of traditional with new, and the “space style” influenced the guitar and guitarists, still having an impact today.

Eruption, You Really Got Me, and the “hits” like Ain’t Talkin’ ‘Bout Love steal a lot of the spotlight. I’m enjoying rediscovering some of the lesser-known tracks. From “I’m the One” to “Little Dreamer,” I’d forgotten about how fun some of these songs are to jam out to. It’s been cool to slow down, really listen to his style, and learn these songs.

It’s worth checking out if you’ve NEVER heard it before (especially if you’re into the guitar) and a fun album to revisit.

FAQ: How Do We Do Link Building in 2018?

I’ve received a lot of questions in the last week along the lines of:

“How do we get more quality links?”

“How do we get people to link back to us?”

“How do we rank #1 in Google?”

Top-ranking content on any given search engine result will have more quality links than the content ranking below it. Websites with #1 rankings always have more quality links.

The more quality website links you have going back to your website (people who link to you from their website) the better you’ll do in search engine results.

What is a “quality link?”

A link from the largest trade publication in your industry is a quality link. The local chamber of commerce putting the URL of your website on their page is a quality link.

10,000 links on a forum is not a quality source. The guy who emailed you and said he would put a link to your website if you put one on his website is not a quality source.

Social media isn’t really a quality source. While social media does have some weight in SEO, linking to content via social media won’t give you the #1 ranking you desire.

For the sake of simplicity:

A “quality” link is a link back to your website or content that was earned by having great content.

Good links live on websites with high-quality information. Review websites, popular bloggers, partners, trade publications. A website that people go to for content like yours.

A “bad” link is an unnatural link that you have created or commissioned someone else to create that links to your website in the hopes of influencing search engines.

Bad links usually live on “low quality” websites like forums, spam websites, websites with poor user experience, and new or unknown websites.

How Can I Influence People with High-Quality Websites to Link to Me?

Here are a set of ways that we use Link Building techniques for our clients over at Jay Nine, Incorporated:

Guest Blogging/Being Featured

Writing articles for your own website is fantastic.

Writing articles on guest sites with a new audience that hasn’t seen your content before is even better.

Guest posting on websites with a lot of traffic and readers (think Forbes, Huffington Post, or whatever the largest trade publication is in your industry) should be the ultimate goal of most businesses.

A lot of companies burn themselves out trying to only receive press from organizations they’ve heard of, like Forbes. This is a mistake! You have to start out with links from smaller websites and local companies, before moving up. The top 50 websites or blogs in your industry is a stepping stone. Once you have more content on different places in the web, it’s easier to be featured on larger websites.

Larger websites look for stories on smaller websites too. When you look at smaller trade organizations, magazines, and websites, you’ll have an easier time getting featured.

I know, your idea is earth shattering and everyone needs to hear it. The problem is, companies like Forbers ands Huffington Post are hearing thousands of other people just like you telling them the same things.

Start with simple guest posts. A great way to find Guest Posts or similar prospects is by putting large trade publications into Google, like:

((target site)) + guest post

((target site)) + guest blog

((target site)) + blogging guidelines

A lot of local or smaller companies likely won’t have that. So, be sure to gather how to do so on each specific contract.

Broken Link Checks

This one is pretty easy.

Use a tool like Check My Links and find industry blogs or local websites that have broken links. A broken link is a link that was, at one time, linking to an article or supporting content, but now doesn’t work anymore.

Broken links are embarrassing, and most websites suffer from them. When you come across a broken link, send an email to that blogger to let them know the post has a broken link.

Let the author know the link is broken, and that you just happen to have an article that would fit as a solid replacement for the broken link. Send them a link to the article or piece of content.

Supply them with a relevant article in order. Your article on the greatest technological advancements of all time isn’t going to be well received if the broken link was referencing the need for people to unplug and “get back to nature.”

This is a semi-cheesy but powerful way to get easy links back to your website, and to build new relationships.

Software

From SEO PowerSuite to Link Prospector from Citation Labs, there are several tools that are great for finding “prospects” in link building. These depend on the niche, and we use a variety of them to find new sources.

The best software is enough for a solo article, but paying for and using quality software (or hiring a firm that does this) is a great way to get a lot of prospects put together.

Good software will also tell you/help you find who is linking to your competitors. I’ve always felt this is kind of a “low hanging fruit” section, as you want to have MORE links than your competitors.

However, you can find good directories and other websites you may not have found otherwise by seeing what your competitors are doing.

HARO

HARO (Help a Reporter Out) does one thing: puts journalist together with people looking to have their expertise or content featured. I’ve been featured on articles like “29 Web Design Professionals Share their Top Tips” and others.

This is a great resource to be featured and build relationships with reporters and other content writers. This is not a “set up and forget it” type platform. Each day you receive an email with new “pitches” in your industry. You sift through those and respond to the journalist.

I usually have to write a dozen or so responses before being picked up by one.

An Offline Contract or Agreement

Quality links come from other agreements, too. This way to build links is often lost in an online-focused mentality.

Example:

An ecommerce client of ours sends products to bloggers to review for free. When a blogger or up-and-coming company reaches out to them, they are sure to include something along the lines of “you will include a link to our website on the footer of this article.”

Other clients are featured in local newspaper articles, and simply ask that a link to their website or landing page is included in the bottom of the article. This helps drive traffic from the article, and builds more quality links to your website.

The limits to this are endless. We include a clause in some of our contracts that a link to our website is featured in the client’s “About” page. Photographers I know ask that their link is featured when someone uses one of her pictures.

This step is much simpler in explanation, but more complex in nature. You are required to remember/weigh the importance of getting a “link back” to your website. You also need to make sure to ask for it.

Final Thoughts

This is important:

Google’s goal is not to make your website popular. Google’s goal is to rank the most popular websites.

Said another way, Google doesn’t care where your website ranks. They care if your website provides a good experience for their readers and users.

As such, Google doesn’t want to see you trying to influence that ranking by doing things to try and trick their algorithm that you belong on the #1 spot. Google clips websites, SEO tricks, and anything they can to prevent people from gaming the system.

It is far better to earn one quality link per month than to try and “game” the system by adding 10,000 links back to your website a month.

There is a difference between having a news website link back to your website at the bottom of an article they already wrote about you. Doing that is not gaming the system, it’s helping Google realize your company is featured in the news.

May 2, 2018

FAQs, The BoomBox and More with Jerry

I’m kicking off a series where I answer some common questions asked by clients and readers and show you what I’ve been listening to this week.

What’s in the Boombox

Year of the Tiger by Myles Kennedy.

This album came out last month and is Myles Kennedy’s debut studio album.

Kennedy comes from heavier rock projects (Alter Bridge, Slash’s band). His new album Year of the Tiger is a more singer/songwriter album, and it just cooks.

A lot of Zeppelin-style guitar and composition, especially Zep songs like “Battle of Evermore” or “Going to California.” The Kennedy album makes use of little rhythm sections and fantastic songwriting.

The lyrics are great, and that guy sure can sing. “Love Can Only Heal” is my favorite song on the album, and there are some nice acoustic guitar parts throughout the whole album.

Highly recommend checking it out, especially if you like listening to more 60s influenced singer-songwriter style music. The album does have his “hard rock” kick to it, but it’s subtle and nicely done.

FAQ: What Are the Differences Between WordPress Categories and Tags?

WordPress posts, pages, and products rely on Categories and Tags, to allow you to organize your content into better, well, categories.

According to the WordPress best practices, “Categories” are the broad category, and a specific tag is something that identifies the product. WordPress advises that Categories should definitely be used, while tags are more “optional.”

If you were adding a simple product like a Men’s Crewneck T-Shirt, the “category” might be “T-Shirt” where the tags are “Crewneck” or “Red.”

Realistically… You can set it up with what makes sense to you. The difference between a category and tag is more important to the shop owner (you) than anyone else. I personally recommend using categories over tags if you have to choose because WordPress offers more out of the box in regards to SEO and organization of categories.

In fact, a lot of websites I utilize don’t make heavy use of tags anymore at all. This was a much different practice six or seven years ago when SEO was different and changing.

Ultimately, it will boil down to how you choose to organize your products. I recommend you organize it in a way that makes sense to you, without going overboard. You’re not trying to impress anyone with your organizational skills, you just want to make it easy for users to navigate your website.

Using the example of T-Shirts, specifically the “Men’s Crewneck T-Shirt” I would recommend:

Category:

T-shirt
Men

Tags:

Crewneck
Cotton

Don’t get crazy and think you need to capture everything like “cheap t-shirts” or “cotton t-shirts” and “cotton” and purposely misspelled categories. You will achieve much better success in the long run if your site is simple, and this includes the way it’s organized.

So, use categories for the core keywords and products or pages you’re offering, and tags to fill in the blanks with little one-offs.

March 4, 2018March 4, 2018

The Five Best Books I Read in 2017

Creating these lists every year is a good reflection on the books I read, what I’d learned, and some fulfilling moments throughout the year.

Here are the five best books I read in 2017:

So Good They Can’t Ignore You, By Cal Newport

After enjoying Cal Newport’s “Deep Work” on a plane ride to Ireland in 2016, I immediately picked up “So Good They Can’t Ignore You” at the beginning of 2017.

“Follow your passion is dangerous advice.” The first third of the book argues (quite well) how often people are lead astray and feel lost because they can’t find their “passion.” From Steve Jobs to Steve Martin, Newport utilizes famous figures to demonstrate the true art of mastery, and how most people develop their passions later on into a career, rather than “following their passion.”

I’ll be honest, I’ve never been a fan of Steve Jobs. I think in the “Apple” genius, not enough attention goes to Wozniak. I think that a lot of modern “Jobs was one of the greatest leaders ever” turn a blind eye to a lot of his mistakes, issues, and arrogance Jobs had (remember he was fired from Apple at one point, the company he founded)!

While Jobs has inspired many dreamers with his talks and philosophy on following your passion, Newport points out he didn’t quite do this himself, “If you had met a young Steve Jobs in the years leading up to his founding of Apple Computer, you wouldn’t have pegged him as someone who was passionate about starting a technology company.” Young Steve jobs was heavily into Zen, his “passion.”

He goes on to say: “If a young Steve Jobs had taken his own advice and decided to pursue work he loved, we would probably find him today as one of the Los Altos Zen Centers most popular teachers.”

This was a very motivating book, and gives a lot of practical advice in mastery, ignoring some of our social “follow your dreams” rhetoric, and creating a more fulfilling career by becoming “so good they can’t ignore you.” The book is refreshing in a saturated marketplace of “just follow your dreams, work hard, and the rest will fall into place!”

The books core message is the importance of mastery, and mastery of a field. “[Scientific breakthrougs] require that you first get to the cutting edge of your field. Only then can you see the adjacent possible beyond, the space where innovative ideas are almost always discovered.”

The Phoenix Project by Gene Kim, Kevin Behr, and Geroge Spafford

“Improving daily work is even more important than doing daily work.”

I read this book twice in 2017. The Phoenix Project is one of the best DevOps and agile books I’ve read. My business partner in J9i, Dhiren is reading this book, and I’m considering making it required reading at my company for new project managers.

This fictional book follows Bill, a newly appointed IT manager at Parts Unlimited, who has been asked to take on a project critical to the future of the business. Bill is given an unrealistic timeline, the threat of outsourcing, and no additional budget to make this happen

A mentor arrives to help Bill and the company turns around the IT department, giving anyone who has spent more than an hour in IT plenty of “been there, done that” moments, as well as providing a proper scope on the power of DevOps integration.

My favorite line in this book describes a frequent “push-pull” between the business world and the IT world:

“It’s harder than ever to convince the business to do the right thing. They’re like kids in a candy store. They read in an airline magazine that they can manage their whole supply chain in the cloud for $499 per year, and suddenly that’s the main company initiative. When we tell them it’s not actually that easy, and show them what it takes to do it right, they disappear. Where did they go? They’re talking to their Cousin Vinnie or some outsourcing sales guy who promises they can do it in a tenth of the time and cost.”

Anyone involved in managing IT, working with IT, or who wants a better understanding of IT (and how you can fix common issues) should read this book.

The Daily Stoic by Ryan Holiday

Philosophy is stained with the stereotype of a bearded college kid using it as an excuse to annoyingly question everything. Outsiders see no practical value, and consider it something for the snide Holden Caulfield types and their asinine musing. I shared this view until a few years ago.

Stoic philosophy was introduced to me when I was reading about George Washington and his study of Stoic philosophy. At the end of the infamous winter at Valley Forge, Washing entertained his men with the production of Cato. A trail of warriors (like Marcus Aurelius), modern day football coaches and CEOs embrace the wisdom of Stoic philosophy.

The Daily Stoic gives you an insight and exercises each day of the year. The advice is real world, “Having an end in mind is no guarantee that you’ll reach it—no Stoic would tolerate that assumption—but not having an end in mind is a guarantee you won’t.”

Here were some of my favorite quotes from the book:

“That’s what Seneca is reminding us. As someone who was one of the richest men in Rome, he knew firsthand that money only marginally changes life. It doesn’t solve the problems that people without it seem to think it will. In fact, no material possession will. External things can’t fix internal issues.”

“When I see an anxious person, I ask myself, what do they want? For if a person wasn’t wanting something outside of their own control, why would they be stricken by anxiety?”

“Our reaction is what actually decides whether harm has occurred. If we feel that we’ve been wronged and get angry, of course that’s how it will seem. If we raise our voice because we feel we’re being confronted, naturally a confrontation will ensure.”

“The mind is a muscle, and like the rest, it can be strained, overworked, even injured. Our physical health is also worn down by overcommitment, a lack of rest, and bad habits. Remember the tall tale about John Henry—the man who challenged the machine? He died of exhaustion at the end. Don’t forget that.”

“In a scene in Steven Pressfield’s classic novel about Alexander the Great, The Virtues of War, Alexander reaches a river crossing only to be confronted by a philosopher who refuses to move. “This man has conquered the world!” one of Alexander’s men shouts. “What have you done?’ The philosopher responds, with complete confidence, “I have conquered the need to conquer the world.’”

Never Split the Difference by Chris Voss

A former hostage negotiator, Voss outlines different tactics and strategies he used in negotiation. Voss points out; you can’t just split the difference with a hostage taker by allowing her to keep three hostages and give you three hostages back.

While a lot of these books take a manipulative and condescending “gotcha” tone, this book focuses on real-world techniques and using negotiation to get a fair deal for all involved, even in extreme circumstances.

“It all starts with the universally applicable premise that people want to be understood and accepted. Listening is the cheapest, yet most effective concession we can make to get there. By listening intensely, a negotiator demonstrates empathy and shows a sincere desire to understand better what the other side is experiencing.”

This book provides a lot of sage advice for anyone who wants better deals when buying a car, selling more products or services to their clients, and other day-to-day “negotiations” we find ourselves in. The focus isn’t on sleazy tactics, the focus is on helping people understand the art of peaceful and cooperative negotiation.

“What does a good babysitter sell, really? It’s not child care exactly, but a relaxed evening. A furnace salesperson? Cozy rooms for family time. A locksmith? A feeling of security. Know the emotional drivers and you can frame the benefits of any deal in language that will resonate.”

News of the World by Paulette Jiles

News of the World is a fictional set in the aftermath of the Civil War. The book follows an aging news reader (someone who travels to local town halls and reads newspapers from foreign countries) who agrees to transport a young captive of the Kiowa back to her people. Johanna is a young orphan, raised as one of the Kiowa’s own. She has forgotten the English language, tries to escape at every opportunity, and refuses to be “civilized.”

Captain Jefferson Kyle Kidd is your stereotypical Harrison Ford/Clint Eastwood “aging badass” who has lived through three wars, fought in two of them, and personifies a lone wolf.

I had never really known about or realized the children captured and raised in Native American tribes, nor known about the physiological aspects and provocative lessons they teach us:

“As Doris had said back in the Spanish Fort, all those captured as children and returned were restless and hungry for some spiritual solace, abandoned by two cultures, dark shooting stars lost in the outer heavens.”

The book is wonderfully written, with some strong characters. The overall plot and story moves along nicely, and engages you in subjects that aren’t as often topical. Some of these scars from America (the wars with the Indians, Japanese internment camps) are better explored in fictional novels detailing what it would be like to live on the other side.

“If people had true knowledge of the world perhaps they would not take up arms and so perhaps he could be an aggregator of information from distant places and then the world would be a more peaceful place. …And then he had come to think that what people needed, at bottom, was not only information but tales of the remote, the mysterious, dressed up like hard information.”

January 8, 2018January 8, 2018

The Jay Nine Inc Development Pipeline Explained

Jay Nine, Incorporated utilizes a development process heavily based on DevOps and “Continuous Integration” principles. We’ve found that an easy way to boost the productivity and quality of our business app development is by utilizing continuous integration.

Continuous integration provides safeguards for teams—even across different time zones—to create large and complex systems with a drastically higher level of confidence and control. The apps those teams build and deploy are more efficient, providing rapid feedback on any problems we may introduce with the changes we commit.

Amazon.com says “The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.”

In essence, we want a fast flow of left-to-right from development to IT operations to the end user (customer). To maximize this flow, we need to bring small pieces of a project to production faster, using more efficient intervals of work.

For the sake of explanation, I’m referring to everything as a “task.” A task can be as small as changing the logo on a website, or as large as creating a new app from scratch.

The Deployment Pipeline

The pipeline for taking a task from production to development should be:

Analyze the Requirements
1. Seek perfect clarity on what the task at hand is
2. Take a minute and make sure that this is a task that needs to be done properly in the first place. There is nothing worse than doing well that which not be done at all.
3. Confirm all developers fully understand the requirements
4. Create the test case we will run to test the task
Design/Programming
1. Task is developed and worked on
2. Task is documented
3. The process for testing this task is effectively passed down to QA
Implementation
1. Task is moved to the testing environment
Testing/Verification
1. QA should review the document of tests created in step 1 or step 2
2. QA should test the task
3. QA needs to test the task to try and break it (as a user will) not to try and make it “pass”
4. If the test passes, it can be moved into production. QA needs to use a video to document testing the test, one that can be sent to pertinent parties to confirm the success or failure of the task
5. If the test fails, it should go back to step 1, and repeat

The Pipeline Dissected

The first step is to “Analyze the Requirements.”

We need to be sure that this is a task that needs to be done (not just some fleeting idea or “nice-to-have” that is distracting from more important tasks). The developers and builders understand with perfect clarity what the final product looks like. If they don’t, they need to.

For example, if we’re switching out the logo on a website, the test would be: “Logo should look proper on all major devices (including phones) with no pixelation and without impacting the page load negatively.”

The philosophy dictates that the teamn needs to develop the test, first. This is a process known test-driven development. First, the developer writes a failing test, and then completes the task until the test passes. If the test doesn’t pass, the developer knows the task isn’t ready yet

The “Design/Programming” step is a fairly straightforward second step. The programmer develops the code for this task until the test written in the prior version passes. The biggest failure point here is when a junior level developer goes unchecked in creating the code for the task. Remember, it’s fundamental the task is thought of in the ecosystem of the application as a whole. In the example of updating the logo on a website, if the programmer isn’t careful they can break the elements around the logo (often either the website tabs/navigation or the phone number/contact information). The programmer needs to ensure this is done to be scalable and not break important other functionality.

Next is the “Implementation” step, where the program moves to a “staging” version of the app. This environment is a replica of the live server.

The last step is “Testing/Verification.” In this stage, a user or QA person uses the task description provided by the business, and make sure it works as intended. The goal here is not to ensure the task works.

Instead, the goal is to try and break the program.

If a QA person isn’t ruthlessly trying to break the implemented task, we can be sure the users will. Completion of this task should include an easy demo via video (which is better when working across time zones or busy schedules) and any necessary documentation needed to log a completed task.

Why is This Pipeline Important?

Fundamentally, this process must flow from left to right, and the team may find themselves spending more time than might be considered necessary on “Analyzing the Requirements.”

The environment these tasks are developed, tested, and deployed in is critical. All developers must be working in harmony to ensure full understanding of a task before it begins. There is no room for lazily investigating a task, nor room for cowboy programmers and working in silos.

All members of the team should be thinking about the project as a whole, not just some little part of the code. Identical to an assembly line, having to go back and fix a step doesn’t speed things up. It slows down production and deeply impacts the company as a whole. Here is a why, in the first stages of the process, developing tests and focusing on the end goal will minimize this downtime.

The business leaders and project managers need to question the validity of a task constantly. The leaders need to ensure the tasks are being done to benefit the end user, the final consumer of the program. There is nothing worse than doing well, that which need not be done at all.

Repetition and practice are the key steps to mastery. When we integrate this process, we require all developers to do this on even the most simple of tasks. Otherwise, it will fail in production. If the developers, QA teams, operation teams, and business executives aren’t working closely, it will exponentially increase the number of issues in the production software.

If Apple has taught users one thing, it’s that software should just work. There shouldn’t be a lot of unnecessary troubleshooting or education, a user wants the software to perform the task as they see it. The process outlined in this article helps ensure that we can deploy many tasks into production using continuous deployment principles while giving users exactly what they want (increasing the profitability of the software).

September 19, 2017

What is DevOps? How Does DevOps Improve Software Development and IT Projects?

DevOps (a play on “Development” and “Operations) is an enterprise software development concept meant to join Development and IT operations with improved communication and collaboration between these two business units.

To the outside looking in, “IT” generally encompasses all areas related to technology, be it programmers, the guy who fixes your printer, or the guy who maintains your current systems. To the non-technical types, there is a myth that “being good with computers” means you can do any field of computing expertise.

In the medical field, if you have a vitreoretinal illness that requires a specialized surgery, you’re going to contact an ophthalmologist–not an orthopedic doctor. While the latter will likely do better than say, myself, you want someone who has studied that particular field of medicine and does it all day.

DevOps is a system that helps merge these different IT fields together, specifically focused on making sure the people who will maintain and use the application are involved in the process from start to finish. DevOps then goes a step further, with a focus on bringing an entire organization together to ship better software, more frequently.

Under a DevOps model, development and operations are no longer operating in echo-chambers and siloed. These two teams are merged together to allow engineers and different layers of expertise to work together during the entire application lifecycle, instead of just their core expertise.

The Three Ways: Principles of DevOps

DevOps is based on “Three Ways” of which all observed patterns and behaviors are structured. Unlike a more rigid system like Scrum, DevOps is much more philosophical:

From The DevOps Handbook:

The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.

The First Way is based on Agile/Lean production and focuses on moving bite sizes of the final product into production sooner rather than later while bringing all key players into the development cycle (from developers to project managers, and finally–the customer).

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and recovery.

The Third Way enables the creation of a generative, high-trust culture that supports dynamic, disciplined, and scientific approach to experimentation and risk-tasking, facilitating the creation of organizational learning, both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace.

The Second Way & Third Way are focused on creating safer systems of work where problems can be discovered and fixed without having to go through a committee.

Similar to the leader-leader method developed by Captain Marquet. Captain Marquet was a Navy captain, responsible for developing a unique method of leadership after he gave an impossible order to his men one day.

His method developed around the philosophy of never giving another order, rather, giving an intent. So, instead of (moving back to web development) a project manager saying “create a shopping cart with products for this new website” it’s “the intent here is to create a shopping cart that women in the late 40s, affluent, can use to purchase specialized spices for their kitchen.”

Of course, this doesn’t mean that everything is left to the discretion of the developer and lower-on-the-totem-pole people, the rules of the system (i.e., the generated PDFs from this application have to look exactly like our other branded materials, or, the conversion tracking on a website needs to be functioning 100% of the time) still apply.

What is removed is the ego of the project manager, company owner, client, and other factors that have a habit of delaying projects and causing confusion. This allows for all to have a core focus on the rules of the system.

How Does DevOps Work in an Organization?

Software and the Internet have helped transform this world, and software no longer merely supports a business; it is now a fundamental aspect of every business.

As Gene Kim (one of the founders of DevOps) mentions in a Forbes article:

“…which tended to be a set of principles from which one can derive all of the observed DevOps patterns. The first is all about accelerating flow as you go from left to right, [Development] to [Operations], in the value stream. The second is the flow of feedback, how do you create effective feedback from Ops back to Dev so that when something goes wrong, you can either prevent it or detect it more quickly. The third is about creating a culture of continual learning and experimentation using the notions of high trust culture.”

In the age of digital business, the DevOps founders realized that sites with massive traffic like Google, Amazon, and Twitter, are all known for being able to do deployments (moving new features or bug fixes into production) many times a day (or even many times an hour). In order to deploy new ideas this quickly, you’re going to need a system that doesn’t break what’s already working, can be undone easily, and relies on open and honest communication with others within the organization.

As Amazon puts it:

“In a similar way that physical goods companies transformed how they design, build, and deliver products using industrial automation throughout the 20th century, companies in today’s world must transform how they build and deliver software.”

Working in a DevOps environment helps place the focus on constantly shipping products, features, and changes to the customers. It means that you can establish an environment where you can create feedback as quickly, cheaply, and rampantly as possible.

DevOps & Your Organization, a Few Troubles

Initially, especially for a simpler website build or smaller piece of business software, an organization may be turned off to paying for an environment of continuous deployments. A lot of companies like the idea of treating a software project like an architectural project or remodel: there is a beginning, a middle, and end–with a fixed cost and time line.

With DevOps, you’re constantly working on improving your software or product, and focused on shipping new changes and features in a rapid environment. This means that you either have staff members or an ongoing contract with a company to ensure that software is constantly being worked on, improved, and released.

Next, if DevOps is the main philosophy of an organization or project, c-suite executives, customers, and project managers begin to get spoiled and think that this means everything will be much faster to build and implement. This is rarely the case, complicated tasks will still take longer than “an afternoon” to complete.

If you’re going to completely change your application to move from the web to a desktop or iOS style application, DevOps will not get it done by the end of the day. Rather, it means that the philosophy of DevOps will be used to ensure that when you launch the application, you don’t spend the next 3 months putting out fires for angry customers and losing business.

The next issue we see a lot in implementing DevOps: dealing with egos. The human ego has a nasty way of creeping into processes and philosophies like this and losing sight of the core focus.

It is generally agreed that DevOps is about efficiently providing the customer with the best possible product. It’s not about providing the company CEO with a new website “look” two weeks after the last website was deployed because she found a new website she likes, and this is now the top priority.

It also doesn’t allow for inter-department wars, where programmers are furious because designers keep making “asinine changes” without seeing the full project picture or designer are furious that developers came back with a two week lead time on what they felt was a “simple fix.”

DevOps is all about breaking down isolation chambers, which can be extremely difficult for some organizations.

It’s Not Everything

Much like some of the other systems we’ve talked about, DevOps has attracted a lot of Zealots that exclaim this system can do everything and the kitchen sink. While DevOps is good at creating a collaborative and agile corporate culture, it is specific to how operations and development tie together to work in harmony. It should focus only on the delivery and project management of software, without trying to fit into areas it does not belong (like the overall company structure, human resources, or other similar items).

September 11, 2017September 12, 2017

Applying the Socratic Method to “Problem Solving” in Project Management

When utilizing the Socratic method, an instructor asks her pupils a series of questions designed to stimulate more complete thinking and insight. Applying the Socratic method forces you to look more closely at your ideas, beliefs, and assumptions.

Did you know, more data has been created in the past two years than in the entire previous history of the human race? While the ramifications of having access to this much knowledge are still to be determined, one thing is clear: we have (at our fingertips) access to an unprecedented amount of data.

The key point of the Socratic method (that we apply to our project management systems) is using cooperative argumentative dialogue to stimulate true critical thinking. Put another way, we don’t let opinions and non-facts stand in the way of making the best decision.

In web and software development, a lot of tasks that seem like much simpler tasks are often found out to be more difficult.

Take this example of updating the design of a website:

We’ve decided we want to replace the logos, and update the website colors and schemes. We know it’s just reorganizing the home page, updating a few logos and changing the text around.

At first, this seems easy, we think it’ll take a few hours. We don’t need to do any research to see how long this took in the past (accessing our own data) or how long it took competing companies (accessing available data on the internet or other resources). We already “know.”

So we compile the necessary materials (new logo, branding guide, fonts) and we begin. Unfortunately, we find out after two hours the new format takes longer than we thought. We told the boss it’d be ready by the end of the day, but now it looks like it won’t be ready until tomorrow.

Tomorrow comes around, the new look still isn’t ready. It turns out the designers didn’t properly account for mobile websites, and the new email templates are horrific looking in Outlook. Chaos ensues.

This takes all day to correct, and the next day begins.

We’re now on the second day of a project that was supposed to only take an afternoon, and the boss mentions “even Amazon Prime could have delivered it by now!” Developers begin to worry if they’ll see their wives again (play Battlefield 1) and designers are blogging furiously about how incompetent programmers are.

No one took the time to plan the projects, with a focus on moving beyond underlying presumptions (“it’s just a simple redesign”) and finding out the real issues (“this wasn’t properly planned for across device and in different platforms”). Nor did anyone check the data we have readily available to set proper timelines.

Larger problems have a nasty habit of disguising themselves as “just a few more hours of hard work,” and unrealistic deadlines (whether hindsight or known) cause unnecessary stress and fires to put out. Couple that with the standard human ego–especially when dealing with “experts” in an industry–and you have a perfect recipe for unnecessary stress.

Enter the Socratic questioning method, and we now have a solution for solving all of our tasks:

Break each task into pieces, elements, and components.
Look for relationships between the components, and missing information. If we need to add a new logo to the website, do we have all of the logo sizes and files, or is it buried in some PDF?
Add the simplified as tasks within the Task Tracking software (we’re currently using Asana).
Check prior tasks within HubStaff (this is a tool we use to track how long it takes people to complete a given task). If we’ve never done a task like this before, spend some time on the internet or with a trusted colleague to get a better estimate and possible task-outliers
Ok, now go back and actually read all of the materials and provided project tasks. Seriously, a number of tasks that aren’t done properly because someone skimmed a PDF (“Hey, I’m the busy CEO, I don’t have time for reading memos”) is baffling. Spend 15 more minutes planning a task and save yourself hours of back-and-forth.
Create a video or have a meeting to review all the tasks, ensure all developers and people responsible for the task ask the important questions (and are ready to identify and immediately point out potential constraints, bottlenecks, or failures”
Check the business logic and make sure there is a point for doing this. A lot of time is wasting on people doing well what needs not be done at all

It seems there is an accepted form of professional blackmail, where experts are expected to have the answers to a question at any given moment. Let’s be honest and acknowledge this is rarely the case. Using the Socratic Method for problem solving, while taking a few extra hours, is bound to save days and weeks of headaches and “delayed projects” from affecting other areas of business.

August 29, 2017

The Pros and Cons of Scrum

SCRUM is an Agile framework used for working on complicated projects, generally with a close-knit team. Simply, Scrum is a project management system.

A High-Level Overview of the SCRUM system:

Scrum consists of three distinct roles: product owner, scrum master, and team member
Scrum works by setting sequential goals that must be completed in a fixed length of time (called a “Sprint”)
First, the product owner creates a “backlog,” which is a fancy term for a wishlist of tasks that need to be prioritized on a project. This is the set of deliverables needed for the product.
Second, the Scrum team conducts a sprint planning session where parts of this wishlist are broken into smaller chunks.
Next, the team creates a sprint backlog, plans for the implementation, and settles on a time duration (usually 1 or 2 weeks) for every sprint
The team gets together every day for a scrum meeting where they share daily updates and access the progress of the project. This is led by the Scrum Master
The product owners and stakeholders review the sprint cycle at the end to assess progress

Pros Of Scrum

What Scrum does is bring teams together to create great things. Scrum requires all project members to see the end goal and to work incrementally towards it.

Scrum is focused on creating a workable product that can be brought to market as soon as possible.

Doing sprint cycles and focusing on fixed periods of time where you bite off small bits of the project is a welcome breath of fresh air in stale and non-moving projects. It focuses on making sure the product is deliverable, not that stakeholder’s egos are met.

Having a structured system is a great starting place for getting a project organized, on track, and meeting well thought-out objectives. The product backlog and user story is a great way to avoid scope creep and egocentric decision making.

Cons

SCRUM is one of those systems that really requires buy-in from all different aspects of the organization. A quote from Sutherland’s book on Scrum:

“For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.”

At first glance, it seems crazy to believe that anyone in senior management would accept and welcome impediments to any sort of project. This assumes two things, 1., that the impediment is obvious, and not an unforeseen 2., that ego isn’t involved.

I’m sure this doesn’t happen in your organization, but some organizations we’ve worked on have hired 1 – 3 designers and spent months tweaking a design until it was perfect. “Perfect” was only defined by the COO of the organization.

Scrum really requires a revolution of culture, which can be hard for businesses. It can be even harder if there is a larger disconnect between IT and the business teams.

Even if the business understands and buys into the Scrum process, individuals can have issues. This would be someone like a middle-level sales manager or analyst. Now, they have to make User Stories instead of the documents/mock-ups/spreadsheets they were used to.

I knew a developer who took over an extremely dysfunctional engineering team with about 100 people. The first thing he did was implement Scrum. It worked incredibly well for about 2 – 3 years.

Then, it didn’t work anymore. The team had matured, the organization had become much leaner, and the process of doing Scrum was just too much. It was time for a new change.

This is something a lot of Scrum and Agile advocates don’t realize or won’t admit — Scrum is just a tool for specific applications. Scrum is not a be-all-end-all system that will solve all of your organizational issues forever.

I’m reminded of a great quote in reference to Growth Hacker Marketing and Growth Hacking: “You can’t growth hack your way out of a PR crisis.”

These lean and mean systems everyone is talking about work in dysfunctional environments where documentation is lack, communication is poor, and there seems to be no end in sight. The goal, I feel, should be to utilize pieces of these consistently, and only rely on the main systems in specific situations.

Like all systems, Scrum creates zealots too. It creates people who spend more time focusing on how Scrum is perfection, instead of seeing the pros and cons and focusing on the business objectives at hand.

Takeaway

Scrum, and similar systems have a habit of establishing the villainy of the status quo, and as such, a lot of the zealots spend more time refusing to see any downsides of Scrum, rather than looking at it as a useful tool for specific applications.

Another great quote in Sutherland’s book on Scrum:

“Years later it occurred to me that organizations, teams, and people are all complex adaptive systems. The same things that move cells from one state to another are also what move people from one state to another. To change a cell, you first inject energy into the system. At first, there’s chaos, there seem to be no rules, everything is in flux. When you do this to organizations trying to change, people freak out. They can’t understand what’s happening. They don’t know what to do. “

Overall I feel the principles behind Scrum are very solid. When executed properly, it really is a great way to get things done in a short period of time and to get an actual working product up and running.

Think a startup or major overhaul of an existing application. Scrum does a great job of focusing on the core components (what the users will use and need) and rolling out and testing those components. It has little room for the “surprise” meeting where we need to discuss a new offering because the CEO received a sales email from a competitor.

However, with an actual working product or existing project, I think elements of Scrum (the focus on sequential goals and eliminating waste) is a fantastic mindset all organizations should strongly push for. It’s the User stories, weekly/bi-weekly sprints, and similar that create issues.

August 22, 2017

How We Organize Our GIT and Why

All of the projects for Jay Nine, Inc use a very specific process in with our development projects. Everything in the project must be checked into a single version control repository: all of the code, testing scripts, database scripts, build and deploy scripts, and anything else needed to create, install, run, and test your application.

This is for several reasons, namely:

This makes it so that we have a ready-to-go back up of the entire application that we can launch at a moments notice
When working with a team of developers, you can easily have multiple developers working on the project without a lot of hassle

If a bug is pushed live, our team has a rule that we try to fix it for ten minutes. If, after ten minutes, we don’t have a solution, we’ll roll back to the previous version in our version control and fix it from there.

This is auto-synced with our live websites, so when we make little fixes and update, checking in the completed code will automatically update the website (allowing for continuous deployment).

The GIT folders are organized very simply like this:

The “Application” folder contains all of the necessary code that comprises the application
The “Database” folder contains the latest copy of the database, in an executable format to create a new database if needed
The “Documents” folder contains all of the project documents on how to use the project (end user manual) and how the project code is broken down
The “Publishing and Testing Scripts” folder contains all of the documentation needed to publish the application in its environment, how to test the application to make sure no core functionality is broken, and a rollback plan in case you need to roll back for any reason

This has allowed us to drastically squash live bugs, as the checks and processes in place ensure things go live safely. A common issue with the continuous roll out plan and the frequent changes to working software is when you have live bugs.

Live bugs generally mean two things:

Live bugs = lost money.
Live bugs = people pulling their hair out because the customer facing version of their product/software is broken. What if a key customer sees this? What is a partner of ours sees this?

The version control system we use removes this fear. On top of that, it ensures there is always a working, ready-to-go version of the software in case something really bad happens.

August 14, 2017

How We Use Asana for Task Tracking and Project Management

In the late 1940s, Toyota re-imagined the approach to manufacturing and engineering, forever changing the automotive world.

This system is highly visual in nature, allowing teams to communicate more easily on work that needs to be done, and when. It standardizes cues and refines processes, and will help eliminate waste in an organization (while maximizing production).

How the Kanban System Works

The system is easy. First, we define workflow that is specific to our business. We then use a system of priority setting, to decide which pieces of work should be tackled first. Using a pull system, we pull work from a queue in a clear system so everyone can see what’s going on.

This system controls the release of work in a project, and more importantly, ensures that the most constrained resources are doing only the work that services the goal of the entire system, not just one component.

We have a board that generally has 5 or 6 different items.

The board has a column for each step of the workflow, and a row for each item of work. This allows us to see who is working on what, and when. Tasks are sorted in priority order.

Asana provides an excellent platform for team collaboration in the cloud, and we have customized the boards to display based on our flow:

Wishlist – new ideas, tasks, and “to-dos” are added to this column
Live Bugs – live bugs and urgent tasks are pinned to this column
In Progress – when someone begins working on a task, they pull the task from either Wishlist/Live bugs and moves it to the In Progress column.
Waiting on Client – When a task is completed, it is submitted for approval. The project manager will check the task, then send it to the client. Upon approval from the client, the task is move to “completed.”
Completed – A list of completed tasks in the order they were completed.

As with Scrum and other project management systems, the “Wishlist” serves as a place to store good ideas that are brought up at the right time. These could be tasks that need to be followed up on in the future (“we need to have photography done before we can put new pictures on the website”) or tasks that are hopeful/maybes that need to go somewhere.

August 10, 2017August 10, 2017

How We Use Checklists to Keep Our Projects on Track

Faulty memory and distraction are a particular danger in what engineers call all-or-none processes: whether running to the store to buy ingredients for a cake, preparing an airplane for takeoff, or evaluating a sick person in the hospital, if you miss just one key thing, you might as well not have made the effort at all.

-The Checklist Manifesto

In large projects with many moving parts, professionals have a lot to remember. Hundreds, sometimes even thousands of details make up a completed project.

One of the main tools we use in project management over at Jay Nine Incorporated is the simple checklist. All of our projects and tasks have checklists associated with them to confirm crucial working parts aren’t forgotten in the haze of an ongoing project.

The checklist offers the reassurance of verification while instilling a discipline for higher performance. A checklist removes the “you should have known” variable and provides a concrete explanation of the project requirements and important aspects of the project.

For example, we have a “Website Launch Checklist” that includes the following requirements:

Check that all basic SEO items are included
Confirm 301 redirects are in order
Ensure loading speed is normal (below 3 seconds and at least 70/100 on Google Page Speed)
Test the 404 Page and make sure that works
Test all contact forms and confirm they are working properly
Confirm the website has a privacy policy
Ensure all web servers are in the proper time zone.
Ensure the website works on all browsers and devices indicated in the contract

Some of these may seem trivial, some things may seem missing to the trained eye, but these are core features that we’ve seen missed in multiple projects (at both our company and other companies).

Checklists also serve a second purpose…

Have you ever heard the story of David Lee Roth and the contract clause of “No Brown M&M’s?”

David Lee Roth is often mocked for having a clause in his contract that stipulated he had to have a bowl of M&M’s in his dressing room–with all of the brown ones removed.

In the Checklist Manifesto, it’s explained:

“Van Halen was the first band to take huge productions into tertiary, third-level markets. We’d pull up with nine eighteen-wheeler trucks, full of gear, where the standard was three trucks, max. And there were many, many technical errors—whether it was the girders couldn’t support the weight, or the flooring would sink in, or the doors weren’t big enough to move the gear through. The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings to make it function.’ So just as a little test, buried somewhere in the middle of the rider, would be article 126, the no-brown-M&M’s clause. “When I would walk backstage, if I saw a brown M&M in that bowl,” he wrote, “well, we’d line-check the entire production. Guaranteed you’re going to arrive at a technical error… Guaranteed you’d run into a problem.” These weren’t trifles… The mistakes could be life threatening. In Colorado, the band found the local promoters had failed to read the weight requirements and the staging would have fallen through the arena floor.

This was a checklist. It also perfectly explains the philosophy behind using checklists in large productions:

The no-brown-M&M’s was an easy way to find larger issues under the hood. It was a quick way to determine there were serious issues before a serious issue occurs. In our checklist, If we go to a “completed” website and see that Google Analytics isn’t working we know there are bigger issues. We know the checklist wasn’t followed, and can go from there.

The checklist does not discount the importance of expertise and human input. It’s just a way to help our brains remember the trivial (but nonetheless crucial and often forgotten) pieces of an ongoing project. It’s also a way we can have multiple people with different levels of expertise working harmoniously towards “perfection” in a given task or project.