Articles

Scheduling, Communication and Deep Work

By Rob Howard, Founder & CEO

The following excerpt is taken from The Agency Owner’s Guide to Hiring Web Developers, but it’s relevant to anyone managing remote team members — particularly as we all adjust to the effects of COVID-19 on the workforce.

While the focus of the excerpt is on web developers, most of the same principles can be applied to any remote team. Flexible scheduling, effective communication, and uninterrupted sessions of deep work are all essential to maximizing our productivity at home.

Scheduling, Communication and Deep Work

WHAT AGENCY OWNERS SAY…
“My biggest challenge in finding developers is determining whether or not they are going to be good communicators. We can figure out pretty quickly if the price, timeline, and quality are a fit, but it’s more difficult to know whether they are going to communicate at the level we need in order to manage the expectations of our clients.”
“I have tried to work with developers in the past, but the biggest hurdle is just that—they are developers, and I am rooted in design and communication. There are typically language and messaging barriers, not to mention the actual design of the site.”
“I need someone who can answer questions clearly, provide progress updates, and clear e-mail communications. Someone who’s willing to jump right in and provide solutions, rather than questions or challenges.”

Most developers are not going to naturally or automatically adapt to the fast-paced agency style, so in order to get their best work, you’ll need to craft their experience to fit a schedule and structure that’s conducive to heads-down, high-quality coding.

This is jarring for a lot of agency owners because we’re so accustomed to agency life that we don’t realize how dramatically different it is from most other types of employment. Ask around and see how many of your friends and family spend half their days pitching strangers for projects worth tens of thousands of dollars, only to transition to intense creative work for a few hours, and then to respond to a dozen e-mails and phone calls to “put out fires” for clients you haven’t talked to in weeks. Most people are simply not trained for this work-style, which is often much more frantic and disjointed than any other job (including a job at a technology company that’s building a single product over the course of many months).

Being able to successfully strike this balance while still delivering high-end development is one of the reasons my business has been successful as a partner to creative agencies. Even so, as I’ve expanded my company, I’ve had to adapt to the fact that many other developers don’t share my unusual combination of background and skills – a formal background in design, advertising and journalism mixed with 20+ years of hands-on technology experience.

This is where most agency owners get stuck. They don’t realize how unusual it is to have the mix of mindset and skillset to be a great agency owner, and they fixate on the idea that everything would be better if “I could just hire another me.”

In order to successfully hire developers, you’ll need to step out of that mindset and instead focus on setting your development team up for success (while still ensuring they meet your communication and deadline goals).

First, you’ll need to step back from minute-by-minute communication and give your developer time and space to do serious, deep work. It’s almost impossible to write quality code in short bursts – unlike your schedule as an owner, a developer’s day can’t be punctuated by phone calls, urgent e-mails, and random interruptions. While you’re likely on what’s called a manager’s schedule in your daily life, you need to do everything in your power to ensure that your developer is on a maker’s schedule, which means long stretches of undisturbed time focusing on a specific goal.

“One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.
There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one-hour intervals. You can block off several hours for a single task if you need to, but by default, you change what you’re doing every hour.
When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.
Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.
When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming in the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.
For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.”
– Paul Graham in Maker’s Schedule, Manager’s Schedule

At Howard Development & Consulting, we solve this dilemma by having three people on a manager’s schedule and five people on a maker’s schedule. This means our managers are always able to quickly respond to client questions, take meetings, and produce new proposals, without slowing down the progress of our makers, who are usually focused on one or two major projects for 20 to 40 hours each week.

If you’re working with a solo developer or a smaller team, you’ll need to take on that manager role – which means getting all your normal work done while explicitly protecting the time of your makers from unnecessary interruptions.

This is where a lot of agency owners start to panic. We’re so accustomed to always-on communication, the idea of a day or two without a check-in spurs immediate anxiety.

Here are three methods we use to protect our makers’ focus and our managers’ sanity at the same time:

Asynchronous Check-ins

This approach uses software to allow you to keep an eye on what your developer is working on without needing to personally touch base. This can come in a number of different forms; here are some of the ones that have worked best for our team:

Keeping a running checklist in your project management system, so that your team can check off items throughout the day and you’ll be able to see their progress without speaking with them directly. This works best when the checklist items require 1-4 hours of work each, rather than many days of work, so you’ll want to divide your checklists into reasonably sized chunks.
Subscribe to notifications for the developer’s code repository (for example, on Github or Bitbucket), so you can loosely keep track of progress as the developer commits new changes throughout the day.
Set up an end-of-day routine – for example, our project management system automatically asks everyone, “Are you blocked on anything?” at 4:30 p.m. each weekday. Everyone on the team can see that response, so if a developer is stuck on something or needs input from a client before they can proceed, we’ll know about it right away. Note, however, that this is a NOT a required end-of-day report – we’ve found that these are far too tedious and distracting, and developers end up just not doing them (and I end up bugging them to do them, which defeats the purpose). Instead, we are only asking you if something has gone wrong, which means on most days, the developer doesn’t need to respond to this prompt at all, and can simply continue in deep-work mode.

Frankly, one of the biggest challenges here is restraint on the part of the manager. It’s hard to transition from an always-on mindset to one where your job is actually to enable others to do deep work. That means never being a bottleneck (where they’re waiting on you for information or instructions), but also giving your developer space they need to do focused work for hours or days at a time.

Consistent Weekly Meetings

For longer-term projects (a month or more) where your developer will be doing 10 or more hours of work each week, I recommend setting up a 30- or 60-minute weekly meeting at the same time each week. This provides both you and your developer with a consistent target – for example, we’re always going to do a demo of this week’s progress on Tuesdays at 2 p.m.

The agenda of each meeting should include a demonstration of work completed in the past week and a planning session where you agree on the exact tasks that will be completed in the coming week. It’s OK if your developer gets a little more or less done in a given week, but they should always have a clear, prioritized list that they’ll work through as fast as possible during their week of focus time.

This is a loose application of the SCRUM methodology, which includes a handful of other weekly meetings for project planning, backlog grooming, and other more advanced techniques. I encourage you to dig deeper into SCRUM when you have time, but for our purposes, we’ve found that we can get the benefits of the system in about an hour a week – as long as that hour includes a demo by the developer, honest feedback from the client, and mutual planning for the coming week’s goals. This also translates well into the asynchronous checklist we discussed above, so you can follow along as your developer accomplishes the goals you’ve agreed upon over the course of the week, then see the full demo during your regular meeting.

Daily Stand-Ups

Some teams also find that they benefit from very short, very frequent “stand-up” meetings – meaning they’re so quick (10 to 15 minutes) that you can do the whole thing without needing to sit down. This is usually a very brief check-in with a manager and multiple developers, where everyone will share what they’re working on if they’re stuck on anything, and what their goals are for their next work session. Some teams do these every day, others a few times a week, and they can replace or supplement a weekly meeting like the one described above.

I know a lot of developers for whom this works well, but we find that this level of scheduling is disruptive for our team’s flow, particularly because we have a very strong focus on location and time flexibility. A stand-up at 9 a.m. Pacific may allow our developers in California to start the day fresh, but it breaks up the deep work of our team members in New York, who are already three hours into their day. It also puts constraints on people to be in the office at a certain time of day, which we want to avoid – you should be able to drop your kids off at school, run an errand, or get some exercise without having to play Calendar Tetris to work around your check-in meetings. Our approach is always evolving, but right now we’ve found that asynchronous project management and weekly meetings for long-term projects are our sweet spot.

“Within a semester dedicated to research, he alternates between periods where his door is open to students and colleagues, and periods where he isolates himself to focus completely and without distraction on a single research task. During these periods, which can last up to three or four days, he’ll often put an out-of-office auto-responder on his e-mail so correspondents will know not to expect a response.
‘It sometimes confuses my colleagues,’ he told me. ‘They say, “You’re not out of office, I see you in your office right now!”’ But to him, it’s important to enforce strict isolation until he completes the task at hand.
By consolidating his work into intense and uninterrupted pulses, he’s leveraging the following law of productivity:
High-Quality Work Produced = (Time Spent) x (Intensity of Focus)”
– Cal Newport in Deep Work

The Virtuous Cycle of Diversity in Tech

By Rob Howard, Founder & CEO

You and I are small business owners – and even though it doesn’t always feel like it, that means we have a lot of power. Collectively, we employ almost half of all workers in the United States.

We’re praised for being decisive, ingenious, and disruptive. We pride ourselves on being quick thinkers and taking daring, unconventional leaps of faith.

You’d never catch us with an out-of-date iPhone, and we’re always testing the latest productivity hack or working on a lifestyle redesign. And yet, when it comes to diversity and equity in hiring, many of us are stuck in a rut that is centuries out of date.

You’ve probably read a lot about dearth of diversity in technology – it’s true for Silicon Valley behemoths and for the vast majority of smaller creative and technology companies, too. Here’s an excerpt from a report in Wired from 2019:

“The numbers are particularly stark among technical workers—the coders, engineers, and data scientists who make these companies hum. At Google and Microsoft, the share of US technical employees who are Black or Latinx rose by less than a percentage point since 2014. The share of Black technical workers at Apple is unchanged at 6 percent, less than half Blacks’ 13 percent share of the US population.
The companies report more progress for women. At Facebook, the technical workforce is 23 percent female, up from 15 percent in 2014; Google reports similar gains. But no company is close to parity, despite having repeatedly pledged millions to address the problem.”

[convertkit form=1665473]

This is a complex problem, so I want to focus on what we can do today, as small business owners, to help the tech workplace better reflect the population at large. The first step is expanding our pipelines to include a broader range of candidates, which means changing our “default” behavior.

“You want to be diverse because you want different experiences and mindsets, and you want people to bring themselves to the table because that creates better access to your product for all of these other groups. That’s good because you genuinely care. You don’t want anyone to be left behind or left out.
That builds better retention numbers. People want to work for companies like that, because they feel that they’re contributing because it actually matters. It really matters that they’re there, for all the right reasons.”
– Pariss Chandler, Software Engineer and Founder of Black Tech Pipeline

“If what you are doing does not recalibrate power dynamics, then it is theater. Your Black Lives Matter graphic, theater. Your tweeting, theater.
You making a job available to somebody and allowing someone to launch a career at your company – that’s what matters. Taking economic parity into your hands, making sure that people have an opportunity to rise and advance in a way that is equitable – that’s what matters.”
– David Delmar, Founder and Executive Director of Resilient Coders

When we design and build software, the “default” option is neutral – the natural choice that you don’t have to change unless you have a really good reason. But when we’re hiring a team, our defaults are the opposite of neutral. Unless we go out of our way to change, we’ll end up looking in the mirror, seeing a team of 50 people that look just like we do, and wondering what went wrong.

If you went to college and graduated with a bachelor’s degree at age 21, your default may be to look for candidates with the same educational background or to network with fellow alumni.

If you grew up in an affluent suburb, your default may be to look for people who speak, dress, and act a lot like you and your neighbors – everything else might seem a little unprofessional.

If you’ve immersed yourself in the culture of Silicon Valley, close your eyes and envision a “brilliant coder” or a “start-up founder.” By default, you might see a young, white man with a slim build and a meticulously trimmed beard.

I know, because I’ve done all these things and held all these default beliefs myself. Changing them wasn’t particularly comfortable, fast, or easy. But it’s allowed me to make progress toward one of my core goals for Howard Development & Consulting – building a technology company that properly represents the diversity of the community we serve.

“It baffles me when I’m just not even given the chance to show what I can do, based on just how I grew up or my accent. I have the education, but there’s a race and trust issue. How can you rack up five years’ experience when you don’t even have a chance to do a three-month project with a big company?
I worked on a project for a major airport, and when I went in for the presentation to train the staff on how to use the app, I realized I was the only person of color in this huge conference hall. Things like that happen all the time.
It’s not like that group has a problem with you, or they don’t understand what you’re saying – but it’s the energy and the atmosphere. When you have diversity and inclusion, that type of energy is not present anymore.”
– Gabriel Alao, Software Developer at Howard Development & Consulting

“If I go to a company page, and I see everyone there is white, and there’s no black people at all, I don’t want to work there. I don’t want to be the only one like me. I already know the experience I’m being set up for, and I don’t want to do it, so I say, ‘Let me close out of this window and check somewhere else.’
At a previous job, we played a company-wide game where you bring in baby pictures, and you guess who’s who. No one stopped to think, ‘Is this game inclusive of everyone?’ Not for me. I was the only black person in the entire company.
I experienced tons of horrible things at that company – that’s just a minor example of, ‘You weren’t ready. You weren’t thinking about it. It wasn’t on your mind.’ That’s why diversity and inclusion are so important. You want people to feel welcome and part of the team.”
– Pariss Chandler, Software Engineer and Founder of Black Tech Pipeline

The stories Gabriel and Pariss told me were jarring – but even more jarring was the fact that they were so clearly the tip of the iceberg, the examples that came to mind in an instant when we started talking about diversity in tech.

Their stories also illuminate the fact that the diversity of a technology team quickly evolves into one of two things – a negative and vicious cycle, or a positive and virtuous one.

There are two forces that change your team’s trajectory at the same time, often before you even realize they exist. The first is the power of default behaviors. If you hire your first five employees from traditional university pipelines, and they all have similar backgrounds and look pretty much the same, chances are that when those early employees start hiring their own teams, they’ll repeat that same process. Soon, you’ve grown from five to 50, and the default behaviors that didn’t seem to matter when you were small have become exponentially more powerful.

The second force acting on your team is the fact that many candidates will look at your existing staff, see that your early hires lack diversity, and simply opt-out of ever getting in touch. Even if you become more serious about building a diverse team as you grow, it will become harder to attract great candidates, because your company will be less attractive to them due to its current lack of diversity.

To turn this vicious cycle into a virtuous cycle instead, make it a deliberate practice to expand your network and cultivate a more diverse pipeline of candidates. Speak openly about diversity and equity, even if it feels risky at first. And most importantly, show your current team and your future candidates that you put your money where your mouth is, by investing time and resources to break out of your defaults and lay the groundwork for a diverse and growing team.

“We’ve got to talk about humility, and then resiliency. Having the humility to listen. Don’t fight people when they tell you that they’re offended. Assume that you are going to be wrong sometimes. Assume that you’re going to say the wrong thing sometimes. And then have the resiliency to keep at it.
Because I think it’s also really sad when somebody, who might’ve been an ally, says the wrong thing and then they get shut down, maybe rightfully so, and then they’re like, ‘Well, I’m never going to open my mouth about it ever again.’ Then what happens is that you’ve lost an ally.”
– David Delmar, Founder and Executive Director of Resilient Coders

Why We Love Agile & Scrum

By Rob Howard, Founder & CEO

Multiple projects, competing priorities, scarce resources, client feedback, and changes in requirements — if you’ve ever run a web development team, it’s likely that you’ve faced one (or all!) of these challenges. So how do you manage them?

At Howard Development & Consulting, we’ve taken the basic principles of Scrum and adapted them to how we work best.

But what exactly is Scrum, why do development teams love to use it, and does it need to be adopted wholesale or can it be adapted to individual needs? In this article, we’ll discuss these questions using our experience as an example — and show you why we love Scrum.

What is Scrum?

In short, Scrum is a framework that is used to implement the Agile methodology of project management, which prioritizes interaction, delivering a working product, collaboration, and responding to change.

Or, in plain English, Andrew Littlefield explained the relationship between Agile and Scrum using this example on Trello’s blog:

“A good analogy would be the difference between a recipe and a diet. A vegetarian diet is a set of methods and practices based on principles and values. A recipe for chickpea tacos would be a framework you can use to implement your vegetarian diet.
This is similar to the relationship between Agile (the diet) and Scrum (the recipe you follow).”

And to extend Littlefield’s analogy further, the Scrum recipe is more akin to cooking than to baking — that is, you can adjust and adapt it based on your personal preferences instead of having to follow it to the letter. We’ll discuss this more below.

[convertkit form=1665473]

What Are the Components of Scrum?

The components of Scrum can be broken out into three groups — the people, parts, and events.

A Scrum team brings together all of the people working on a project together, with a few defined roles and responsibilities:

The Product Owner, who is responsible for the delivery of the product and advocates on its behalf (as opposed to the client or the development team)
The Scrum Master, who is responsible for making sure that the project and the process remain on track and that anything blocking another team member’s progress is managed
The Team Members, which includes everyone else on the team and is generally comprised of the developers doing the day-to-day work

Next, there are a few parts (called artifacts) that every Scrum team uses to organize and plan their work:

The Product Backlog is the list of all of the work that needs to be done on the project
The Sprint Backlog is the list of all of the work that will be completed in the next sprint (see below)
Both backlogs are comprised of individual Tasks, which can include new features, enhancements, bug fixes, tasks, or other work requirements and are listed in their order of priority from the top to the bottom

And because Scrum is a framework, there are a series of events (called ceremonies) that occur on a regular basis:

The Sprint, which represents one time-boxed cycle of work and always runs for the same length of time (anywhere from one week to one month)
The Sprint Planning meeting, where the entire team discusses the upcoming sprint and decides which work will be completed in it
The Backlog Grooming, which is when the items in the project backlog are discussed, confirmed, and their priority negotiated
The Demo where the development team demos the work they’ve completed in the previous sprint
The Retrospective where the entire team discusses the previous sprint — what went well and what could be improved
The Daily Stand-up, which is a very quick (usually 10-15 minutes, at most) meeting where each team member shares what they did the day before, what they’re doing that day, and if anything is blocking their progress (which the Scrum Master would help with)

Together, these form the basis of Scrum and can be expanded on or consolidated depending on your individual team, the scope of your project, or your workflows. For example, we often combine the demo and retrospective into a single meeting rather than scheduling two separate meetings to cover them.

Ok, So Why Scrum?

Simply put, Scrum does two things very well:

It empowers teams to be self-organizing, which let’s them organize their work in the way that best works for them and relies on their expertise to do so
It responds and adapts to change, which gives the client (internal or external) regular input into the work being done (rather than everything being defined at the start of the project) and generally allows the development team to complete the work more quickly

And as a small (but growing!) development team, this allows us to work more closely with our clients and deliver projects more quickly and efficiently. Requirements are gathered, tasks are organized, work is completed and demonstrated, feedback is received, and the project (or product) is iterated on — all in each sprint!

How to Make Scrum Work For You

One of the great things about Scrum is that you can adopt its principles without necessarily following the entire framework to the letter. For example, at Howard Development & Consulting, we tend to scale how closely we follow the framework depending on the scope of the project we’re applying it to. In most cases, we combine the demo and retrospective into a single meeting and we usually have one team member play the roles of both the Product Owner and the Scrum Master. Finally, our daily stand-up meetings are held virtually in Basecamp rather than in real-time.

For more information about how to adopt Scrum at your business, especially scaling it as you grow, check out Atlassian’s guide here. It’s a little comprehensive if you’re just getting started, but a valuable resource nonetheless.

To find out how Scrum works best for your team, you can apply one of its most essential principles — regular and frequent iteration. Try it out, gather feedback from the team, and adapt as you go — keeping what works and changing what doesn’t. Lather, rinse, repeat.

Getting started takes just a few simple steps:

Bring your team together and assign the roles of Product Owner, Scrum Master, and developers
Build your product backlog with all of the known tasks that need to be completed
Agree on the length of each sprint (we recommend starting with two-week sprints), then schedule the sprint planning, backlog grooming, demo/retrospective, and daily stand-up meetings
Get to work!

The 10-Point WordPress Security Checklist

By Rob Howard, Founder & CEO

In this article, we’ll share ten of the easiest and most effective steps you can take to help protect your site.

1. Update everything, every month

The first and most crucial component of your WordPress security plan is consistent, recurring updates. We recommend you run an upgrade routine at least monthly, and for larger sites or sites with dozens of plugins, we often do biweekly updates (twice a month) instead. This includes:

Updating all plugins
Updating all themes
Updating the WordPress core, if necessary
Running a quality-assurance check to make sure nothing broke in the process

Most of this can be accomplished by a visit to Dashboard > Updates in your WordPress control panel. There you’ll find a list of plugins and themes to be updated, as well as an option to update your WordPress core software if it is out of date. If you use any premium/commercial plugins, make sure you’ve properly set up your license keys so they can check for updates automatically as well.

We also recommend deleting any unused plugins or themes, rather than leaving them inactive on your site. This reduces the risk of bugs, security holes, or performance lags that come from having these extraneous files on your server.

2. Get a solid web host

Even the best security plan is ultimately at the mercy of your web host. Choose a cheap hosting service, and you open yourself up to uncontrollable risk – backdoors that allow hackers to get in, other customers on the same server causing issues or insecurities for your site, and an array of other potential dangers.

Our go-to hosting recommendation is WP Engine. They are a high-end, WordPress-exclusive host with excellent built-in security and caching, as well as live chat support with a very fast response time. We use them for our own site as well as clients ranging from small brochure sites to big magazines that get hundreds of thousands of monthly visitors.

If you’re a direct client of ours, let us know before you sign up for WP Engine and we’ll hook you up with a coupon code and other significant discounts.

We also host small to medium sites with Nexcess, and for very large-scale deployments we set up a custom Rackspace Cloud Servers stack.

The general rule: you get what you pay for, so find a host that charges more than $5/month. Going with a budget hosting provider is going to cause you tons of headaches in the long-term, and almost all of those can be resolved by spending an extra $20 to $100 per month.

3. Secure your site with SSL (it’s finally easy and free)

Not long ago, setting up an SSL (secure socket layer) certificate was a nightmare even for seasoned tech veterans. Thanks to new software, it’s often now a matter of a few clicks. It’s also ever-more important, as it benefits your security directly (passwords and other information passed to your site are encrypted by SSL), and also benefits your SEO, since Google is getting harder and harder on rankings for unsecured sites.

To add SSL to your site, we recommend:

Get a free Cloudflare account and follow our guide to set up free SSL.
If you host with WP Engine, you can also get a free Let’s Encrypt certificate installed with a few clicks (this also works in combination with CloudFlare)
If you need to purchase a certificate directly, GoDaddy is an inexpensive and effective option. You can buy your certificate through GoDaddy and work with your host to get it set up. (Note: We do not recommend their cheap hosting, but their cheap SSL is all good.)

Generally speaking, the least expensive certificate option is just fine, as all certificates are effectively equally secure. If you want your business name to show up in the browser bar, you’ll need an Extended Validation certificate, which is more costly and time-intensive to set up, but is visually more “authentic” since it carries your specific business name and makes the user’s browser bar light up to demonstrate the site is secure.

4. Add Two-Factor Authentication to WordPress (and everything else you use)

No security mechanism is perfect, but for the modern web, two-factor authentication is about as good as it gets. Also called two-factor verification or multi-factor authentication, 2FA changes your login process so that once you enter a correct username and password, you’re also prompted for a short numeric code which is sent to your mobile device as a text message or via an app.

The result is that even if someone manages to steal your password, they can’t log in as you unless they are also in possession of your phone, dramatically increasing the barrier to a hacker compromising your account.

For WordPress, we use a plugin that hooks up with Google Authenticator to provide 2FA on all the sites we build.

We also highly recommend setting up 2FA for all your accounts that support it, both business and personal. Especially with e-mail, it’s easy for one hack to cascade into others – for example, if someone gets your personal Gmail, they can use that to reset your Dropbox password, which contains your WordPress passwords, and so on. The best practice is to add 2FA to everything you possibly can.

5. Add Cloudflare for some serious firewall and performance boosts

In addition to its one-click SSL solution, Cloudflare is great as a security firewall. Almost all sites can get huge benefits from a free account, and the $20/month upgrade adds a lot of extra features.

Cloudflare’s security settings will detect malicious behavior on your site (for example, a bot trying to crack your password or find another vulnerability) and block that traffic immediately. The service also pulls on its global database of known malicious IP addresses, so you benefit from the experience of all other Cloudflare users in identifying hackers before they can cause trouble.

If you also turn on Cloudflare’s caching features, your site will likely see an instant performance boost. And if your web server ever goes down, Cloudflare’s cache will keep displaying any site pages it has stored, so you’ll still be up even when your server is offline.

6. Corral your administrator and FTP accounts

If you’ve been running your site for a while, you’ve probably experienced “administrator creep,” where more and more staff, contractors and other team members require access to your site to get their jobs done. The problem here is that everyone with access as an administrator, as well as everyone with an FTP account on your server, is a potential security risk. Their computer or e-mail or phone gets hacked, your site gets hacked – and the more people with access, the more your risk multiples.

First, downgrade anyone who doesn’t absolutely need to manage all site settings from the Administrator role to the Editor or Author role. Day to day, this probably won’t affect their work at all, but it significantly reduces your security risk. If they need Administrator access, you can grant it temporarily from time to time.

Do the same for FTP accounts, deleting any that are not immediately necessary. Where possible, using SFTP over FTP is also preferable, since it encrypts the data you transfer similarly to the way an SSL certificate encrypts data transferred via a browser.

We’ll dig into secure password practices in a moment, but for now, also be sure you don’t have a user with the default username of “admin.” Forcing hackers to guess a username, rather than using the default, makes it less likely they’ll be able to infiltrate your site.

7. Lock down your theme and filesystem

By default, WordPress allows you to edit theme files directly through your dashboard if you’re an administrator. This is largely unnecessary and creates a big security hole, which you can plug by adding the following line to your wp-config.php file:

define('DISALLOW_FILE_EDIT', true);

You can also tighten up security on your wp-config.php file and wp-includes folders by adding the following lines to your .htaccess file. (If you’re not on the Apache web server or don’t feel comfortable making direct code changes, check with your host for the best way to do this.)

<files wp-config.php>
order allow,deny
deny from all
</files>

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

This code should go above the “# BEGIN WORDPRESS” comment in your .htaccess file. For a deeper technical discussion on the WordPress Codex (from which we pulled these code snippets, which we consider the highlights of the document), check out Hardening WordPress.

8. Get intense about password security

By far, the most common and most easily preventable reason a WordPress site gets hacked is a stolen or easily cracked password. Hackers run bots 24 hours a day, 7 days a week, trying to guess your password and find other vulnerabilities of your site, so a little prevention goes a long way. We’ve already talked about Two-Factor Authentication and limiting your Admin users. Add these password policies for everyone with access to your site, and your site (and your whole IT infrastructure) will be much harder to crack.

One person, one account. No sharing logins between team members under any circumstances. This eliminates the need for password sharing, allows you to instantly shut down individual user accounts if they have security issues (or leave your company), and creates a clearer paper trail should an account ever be compromised.

Never use the same password twice. In fact, you should use the longest, randomest password possible in all circumstances. Purchase 1Password or LastPass for yourself and everyone on your team so they can securely manage all these random strings with ease.

Never send a password in plain text. We recommend using One Time Secret as a “dead drop” any time you need to share a password. For example, if you’re sending an e-mail, you can include a username in the message and a link to your One Time Secret drop containing only the password, with no other identifying information (the secret gets deleted after it is viewed once). That way, if either the e-mail or the One Time Secret data gets compromised, the hacker still won’t have the information they need to log in. For WordPress logins, you never need to share a password; just have the users reset their password via the normal WP interface.

9. A little help from some great plugins

Our favorite security plugin is All In One WordPress Security & Firewall. While we don’t use all of its many features for every site, it’s a very easy way to implement a few absolute necessities:

Enable the Login Lockdown feature to prevent brute-force password attacks. This blocks a user if they fail to log in too many times (e.g. 10 times in an hour), which stops robots from trying to “guess” your password hundreds of times a minute.
Change your database prefix. This can be done manually if you’re technically inclined, but it’s super-simple through the plugin’s interface. By default, your database tables start with wp_. If you change that prefix to a random string, it makes it harder for hackers to execute queries if they get access to your database.
Fix your filesystem security. This builds upon the recommendations in Checklist Item #7 to add some additional barriers to hackers editing your files. Note that if you’re hosting with WP Engine, you don’t need this feature and shouldn’t use it, as they have their own system for doing this.

10. Back it up!

Even with the best of security measures, there’s no way to completely guarantee that bad things won’t happen to your site. The best way to mitigate that risk is to automate daily, off-site backups of all your files and data.

We highly recommend CodeGuard, which can hook up with just about any web host and also has a simple WordPress plugin that’s useful for smaller sites. (Bigger sites need to be configured with FTP or SFTP instead of using the plugin.)

In addition to keeping your backups safe for about $5 a month, CodeGuard also alerts you to file changes each time it runs a backup, which can be an early warning sign if your site does get breached.

We’re always here to help.

Whether you’re a direct client or a web professional looking for some extra insight on any of these security techniques, get in touch and we’ll be happy to lend a hand.

Automatic collaboration and deployment with Bitbucket and Deploybot

By Rob Howard, Founder & CEO

Building a great development team is a long and challenging process – but collaborating in a way that’s convenient and efficient doesn’t have to be. Today, we’ll dig into my favorite tools for sharing, deploying and keeping track of front-end code, such as HTML, CSS and JavaScript.

For many of our projects, we start by developing static front-end templates based on custom designs. There are always multiple people involved in this process, and we always want a quick and easy way to show the client our progress. To make this as easy and error-proof as possible, we have built a system that combines Git repositories from Bitbucket and automated deployment from Deploybot.

Here’s how it works:

We set up BitBucket accounts for each member of our team.
We create a repository and share write access with each team member. This allows each team member to share file updates and track changes each time new code is committed to the repository.
For those who aren’t familiar with Git yet, SourceTree is an extraordinary visual tool that hooks in directly with Bitbucket (they’re built by the same company).
We then set up an automatic deployment to an FTP site using Deploybot (which connects with Bitbucket).
Deploybot pushes all updates to the FTP server every time new changes are committed to the repo, which means nobody ever has to touch FTP, and we’ll always have a simple URL where the client (and our team) can see the current version of the project.

Getting started with Git, Bitbucket and SourceTree

First, set up a Bitbucket account for yourself and each member of your team. You can then create a new private repository and assign each user to have Write access.

To add users, go to Settings in the left sidebar, then User and Group Access:

Grant write access to your collaborators

From there, you and the other users can clone the repository by clicking Clone in the sidebar (see screenshot below). If you’re not comfortable using Git from the command line (or you just want a break from command-line code), we recommend grabbing the SourceTree app, which provides a visual Git interface and also hooks up with Bitbucket for one-click cloning.

Clone your repo to copy it to your hard drive

Cloning will make a copy of the repository and all its files on your hard drive at a destination of your choice. You can then edit the files in your preferred HTML/text editor, and your changes will be tracked by Git so you can easily share them with your colleagues. We’ll dig into the step-by-step details of Git and SourceTree in a future article, but here are the basics:

When you’ve made changes you want to share and publish, commit those changes to the repo
Push your commit to upload your changes to the Bitbucket cloud. (This also triggers an automated deployment, which we’ll discuss below.)
Before you start work, pull any commits that others have made since you did your last push.

It takes a while to get the hang of Git, and there’s a ton of additional complexity and power beyond what we’ve described here. That said, a simple commit-push-pull-repeat system will get you started. Next, let’s look at automating the upload of your project to your web server.

Make it automatic with Deploybot

Head over to Deploybot and set up an account. From there, you can connect your Bitbucket account to Deploybot and connect your first repository.

Your connected repository will take a moment to initialize, which is a great time to make your first commit.

Important: Before you can set up Deploybot, you need to make at least one commit to the master (default) branch of your repository. You can do this by adding a blank index.html file, saving it, committing it, and pushing it. (This is necessary because Deploybot needs you to choose the branch it will be tracking in the next step.)

Once you’ve made your first commit and the repository is ready for editing on Deploybot, click your repo’s name, then Create Environment & Server. Name your environment (for example, “My Staging FTP”), then choose the Automatic option to deploy to this environment every time you push a new commit to Bitbucket. You’ll also select the “master” branch in the third field on this form.

On the next page, choose FTP or SFTP. On the subsequent page, enter the host, username, password and path for your FTP site and the desired folder. Save your changes, and you’re good to go!

The magic of automation

Deploybot will now listen for new commits, and every time any team member pushes a commit to Bitbucket, Deploybot will immediately upload those changes to your FTP site.

The result: you and your team can collaborate easily, make changes on your local machines, and sync all those changes to your staging site within seconds with no manual uploading required. It’s a fantastic way to instantly share changes with your client and ensure you’re always on the same page.