How a Data-Driven DevOps Approach Helped HailBytes Meet 66% More Deadlines - 7pace
Published:Dec 18, 2019

How a Data-Driven DevOps Approach Helped HailBytes Meet 66% More Deadlines

Every engineering team has different goals, but there’s one they’d probably all agree on: They want to be more efficient.

Improving development efficiency means getting more done in less time and with less effort. Like the classic adage goes, it allows you to work smarter, not harder. What team wouldn’t want to do that?

Of course, that’s easier said than done. There are tons of articles, books, speeches, and more about how to up your team’s efficiency, but no solution is one-size-fits-all. That’s why it can be helpful to look to engineers and managers who have found the key to improving development efficiency on their teams, to learn from what they’ve tested and found to be true efficiency-boosting techniques.

Meet David McHale

David McHale is Principal at HailBytes, a cloud security firm. He drew on his experience working with nearly a dozen different software teams (and consulting for a few dozen more) to create a step-by-step plan that he says makes his team at HailBytes the most productive one he’s ever seen.

It’s not that the team wasn’t productive when he came on board, he said, but that there was room for improvement, just like there is on any team.

“I came onto my current team roughly six months ago and spent the first few months gathering feedback on each member’s pain points,” McHale explained. “I organized pain points and mapped possible solutions to each problem I uncovered, then weighted them based on the estimated level of effort, anticipated impact, and how many team members contributions each would need, then worked with team members that would be affected to gather their feedback and thoughts on each pain point.”

From there, he got buy-in from every member of the team, something he says is necessary to making the kinds of sweeping changes McHale had in mind. He created and refined what is now a 7-step process that he shared with us, in hopes that other teams might be able to recreate his process to up their own productivity. In his own words, here’s how McHale came up with his 7 steps, how he implements them every day, and most importantly, how he knows they work.

Step 1: Use Agile Methodology

This one might seem like a no-brainer to most teams of engineers, but McHale lays the groundwork for his ultra-productive team by having them use a tried-and-true Agile methodology with weekly sprints.

At HailBytes, developers are assigned to projects in 16 different workstreams, which means there are a ton of balls in the air at any one time. That brings us to step 2 in McHale’s process.

Step 2: Use a Task Tracking Tool

According to McHale, a task tracking tool is absolutely essential for keeping track of everyone’s different projects, as well as holding developers accountable for deadlines. At HailBytes, his team uses Asana, but there are a ton of great task tracking tools out there, many of them free. Find the one that works best for your team.

Step 3: Break Projects Down Into the Smallest Tasks

This is where McHale’s process really starts to take shape. An important part of how his team works is breaking all projects down into as many small tasks as they’ll take to accomplish. It’s not important how many tasks this ends up being — what matters is to turn large projects into the most digestible possible pieces.

“Breaking projects down into smaller tasks is the responsibility of each direct contributor,” McHale explained, adding that that means he does see some variance in how small things get broken down by different engineers.

“There’s a large amount of flexibility in how exhaustive breakdowns are, but we see our most productive team members tend to outline their tasks in the most depth,” he added.

To help combat how subjective the breakdown process can be, his team holds several short-but-focused meetings throughout the week.

“We host stand up meetings on Mondays, Wednesdays, and Fridays during which we provide our breakdown for the next few days, and a summary of what we’ve accomplished and what unexpected problems we ran into to solicit feedback from the team,” he explained.

Scheduling team standup meetings throughout the week was essential for executing and follow-through.

Step 4: Prioritize Instead of Multitasking

Once projects are broken down into the smallest possible tasks, McHale encourages his team members to focus on one of those tasks per day, and do their best to complete that one task rather than try to multitask.

Experienced engineers and managers will already understand the value of this step — multitasking is really hard for human brains to do, and trying to multitask will generally decrease efficiency and productivity, the opposite of what we’re going for here.

Step 5: Foster a Culture of Collaboration and Learning

Step 5 is a big one, and one that McHale is pretty passionate about. He’s not about remote teams; instead, he wants all his people together in one place with an open office layout to support frequent collaboration (with private offices people can use when they need them).

Yes, he knows it’s a controversial view. No, he doesn’t care.

“I’ve worked fully remote, partially remote, and fully in-person in the past, and I’ve yet to find a truly effective way of fostering collaboration without face-to-face interaction,” he explained. “Having the ability to listen in on ongoing conversations between team members, pull team members into a discussion or architecture to lend their unique expertise, and bond with team members over lunch & learns and similar activities remains tough to pull off, even with tools like Skype, Zoom, Google Hangouts, or WebEx.”

McHale says working in an environment where collaboration is constantly encouraged makes engineers more open with one another.

“Crucially, we’re honest with one another about potential blockers and fostering a culture where engineers are comfortable asking for help early and often,” he said.

And that openness has paid off in some unexpected ways.

“Just this past month I found out one of the team members we have assigned to our security operations center has shockingly deep experience in data mining and big data analysis that I had no idea about before and which likely never would’ve come up in a remote situation,” McHale said. “That meant I could make an effort to get his feedback on a Hadoop cluster we had in the works for a client he’d never worked with, give him the credit for those insights, and now he’s making the move to that team for a morale and productivity boost. Understanding the strengths, weaknesses, and passions of your team is very important to maximizing productivity.”

Step 6: Implement DevOps Practices To Reduce or Eliminate Repetitive Tasks

As McHale puts it, “We’re also serious about DevOps. We have a Continuous Integration/Continuous Delivery pipeline for each workstream powered by GitLab.”

He says his team is continuously running through a list of tasks designed to empower designers by giving them immediate and comprehensive feedback on any changes they make. Included on that list of tasks is:

  • Code linting
  • Static error checking
  • Dynamic error checking
  • Format validation for XML, YANG, JSON, YAML files
  • Cyclomatic complexity analysis
  • Unit testing
  • Acceptance testing
  • Deployment to staging environments

Because of this, “The quality of our code is better protected from breaking changes, and we’re able to work at speeds our vendors and clients can hardly believe,” McHale said.

Step 7: Get Frequent Feedback from Clients

And finally, the last step in McHale’s efficiency-boosting process is the loop in clients as regularly as possible.

“We’re in close, frequent communication with our customers to get their feedback on minimum viable products for each workstream to ensure we’re not working on functionality that isn’t supporting our clients mission,” he explained. 

It helps keep the team on track and make sure everyone — team and clients included — is working toward the same goal, which cuts back on wasted time.

How McHale Knows His Process Works

Sure, you might be thinking, this all looks fine on paper. But how are you supposed to know it works in practice? 

Well, it all starts with how McHale implemented all these changes on his own team: Gradually, while keeping a close eye on metrics that would help him see what worked and what didn’t.

“Our sprint cycles are weekly, so we see improvements in the way we work together against our client projects every single week and discuss what we can do better the next week,” he said.

As for how he tracks all these big changes to make sure his team is getting more efficient?

“We use tags on each task to show how many sprints it’s been involved in which helps us understand especially difficult tasks, or tasks that didn’t have blockers properly accounted for,” McHale explained. “We keep an overall dashboard of progress for all 16 of our workstreams with agreed-upon milestones and track when we’re complete, on-schedule, at-risk, and behind-schedule which we expose for clients as well.”

Overall, he said the improvements he’s seen from implementing this methodology have made his team at HailBytes the most productive team he’s ever worked with — or even seen.

The number of behind-schedule workstreams were cut from 3 to 1 and the number at at-risk workstreams were cut down from 7 to 2.

“We’ve seen dramatic improvement across most of our 16 workstreams though sometimes vendor issues place progression out of our control. In the six months since I came onboard, we’ve reduced behind-schedule workstreams from 3 to 1, and at-risk workstreams from 7 to 2,” he said. “We’re continuously improving on our Continuous Integration and Continuous Delivery pipelines to help our direct contributors feel confident that every commit they make to a project will be meticulously reviewed for issues, and automatically delivered if it meets our quality control guidelines, and that if it does fail that they will receive detailed actionable feedback about how to bring it up to par.”

Ready to Implement McHale’s Process In Your Own Team?

Remember that there’s no one-size-fits-all solution for making a team as efficient as it can be. But McHale has a solid process here, and it’s worth trying out the different steps to see if they can help your team boost its productivity, too. Remember not to implement any huge, sweeping changes all at once. Instead, bring changes to your team gradually, making sure everyone buys in on changes so the whole team is equally invested in its success. Then, determine what metrics you can watch to see whether changes are effective for your team.

With gradual, positive changes, you can boost your team’s productivity just like McHale did for HailBytes, and find yourself working with your most productive team ever, too.

Free eBook

Rethinking Timekeeping for Developers:

Turning a Timesuck Into Time Well Spent

Leave a Comment

By submitting this form I confirm that I have read the privacy policy and agree to the processing of my personal data for the above mentioned purposes.


Sign up for GitHub News

    I would like to sign up to receive email updates from 7pace. Protected by 7pace's privacy policy .