How To Run a Product Development Team With Hive

Welcome to A Day in The Life where we are showcasing the day-to-day moments of productivity with teams across the world. We’re asking real people how they spend their day in Hive — and what they accomplish because of it. ????

The Need-To-Know:

Today: The Director of Engineering on a remote team for a SaaS company
Occupation: Director of Engineering
Industry: SaaS, Productivity Management
Location: Long Island, New York
Hobbies: Playing guitar, getting the body moving and anything music-related ????
Pronouns: He/Him

How would you describe your role on your team?

I’m the Director of Engineering here. Basically, I’m overseeing engineering across all of our teams, in all of our ‘pods’ as we call them. It covers the entirety of our desktop application and mobile application. For the most part, the responsibilities kind of span a few different major areas. It’s my job to make sure that everything on the back end is working as expected, with performance and overall server stability.

Other than that, I manage large work projects or ‘epics’ — where we are working through large new feature sets.

Using Agile in Hive really makes our team work efficiently on projects. As I mentioned, the engineering team is organized into 3 pods. Each pod works in 2-week sprints with a certain story point target for each sprint as well as a few important tasks which are flagged as ‘sprint commitments’. Each action assigned is spec’ed by an engineer and then we collectively vote as a team to assign the story point value to each action. Those actions eventually then get allocated into sprints and eventually get merged into our codebase and deployed out to production.

We use story points to help ensure that we plan our sprints according to our capacity and velocity so that we don’t over-commit and can provide the rest of our team with more reliable releases.

And then lastly, just regular daily operations. So everything from like bug fixes to general app upkeep — those flow through our pods.

What does the Engineering Team do?

On the engineering team, we’re probably upwards of 25 to 30 people now, and that’s broken across three to four teams. Our main job is to work on new features or redesigns for features.

Because of the nature of our job, we work very closely with other teams in the company too, like the product team and customer success.

On the engineering side of things, we also have to make sure that our overall philosophy is trending in the right direction so that we can continue to grow. We want to make sure that when we bring on new engineers, they’re able to quickly ramp up to the same capacity and velocity as other engineers, focusing on getting the work done.

What are some of the main goals of your team?

There are a couple of key things that we focus on. We work off core metrics. For example, application speed. Everything from initial load times to times for basic app requests, it’s important to make sure those are all executing quickly so that users feel like they have a quick and stable experience.

We also have goals with progressions and making sure that as new features roll out, we don’t introduce any issues. We really focus on the goal of ample feature sets and making sure that our product still feels at par with other product management tools.

It’s always our main goal that we have the necessary feature sets to facilitate our user workflows and constantly adapt moving forward. And then lastly, we prioritize speed of delivery as a team.

What do you use Hive to do personally and how does it help you get your work done overall?

For the most part, the engineering team uses Hive’s Kanban boards for the entire software development life cycle. The way it’s organized is that we have a top-level project called tech teams, and then each of the pods or engineering teams has its own child project within each of those child projects.

The full software development life cycle is outlined there, starting with like sprint backlog, which is where each engineer picks up our tickets for the next two weeks. Once an engineer has finished a ticket, it goes through an entire review and approval process. That process is partially automated using the automation stages within Hive. It’s like pushing a button once you’re done.

This template is applied for those who need to be reviewing code, and who need to be running tests and approving before moving forward. Once the entire approval flow is done, the story is marked as ready for merge. And then it goes through the rest of our engineering workflow where that story is merged against our base code branch — called the bell — that gets merged up to beta. And then lastly, it goes up to production on our weekly schedule.

In terms of my more specific workflow, I use the entire software development life cycle mentioned. Other than the general Kanban view, the My Actions list view is helpful to me. I can see the stories that are awaiting my code review and approval along with my approvals list. My Actions help me track the items that are on my plate and make sure they’re going through smoothly.

Other than that, the engineering team uses Hive Notes heavily for things like engineering documentation, as well as write-ups for larger issues or investigations that we’re working through. Hive Notes are also used as part of engineering interviews and in general, large initiative tracking. We have recurring calls for performance meetings for our regression and bug tracking meetings. And notes are super helpful, in the context of keeping track of what was said in previous meetings.

Do you use Hive in tandem with any other tools?

Yes, the entire engineering team uses the GitHub integration. GitHub does a million very complex things on their side, making sure that code from multiple engineers is merged effectively without introducing issues into the code base. With our team, each of the action cards on our engineering boards is known as proper development stories — that means each of them will have an associated code change with them. And those code changes are all tracked by GitHub.

The way we connect with GitHub is we attach it to each of the action cards, using the specific code branch that we’re working on. That allows us to listen to GitHub on the backend and show all of those updates to users within that dropdown. The other way it’s super helpful is that by opening the GitHub integration, you can hit the open pull request button and that’ll jump you straight to the actual pull request. We can drop code reviews there and then eventually merge the stories once they’re ready to be merged. It makes it easy.

The engineering team has a lot of pretty specific and niche tooling that we end up linking to in Hive for reference. For example, for our metrics reporting, we use something called Datadog Dashboards which we share in Hive using screenshots or as a link to a specific set of logs. They don’t directly integrate with Hive, but we have the capability to include important information in Action Cards, which is very helpful.

A Day In The Life Using Hive

9:30-11:30 A.M

In the morning, I check my notifications and chat first thing to make sure that anybody needing an immediate follow-up is getting that. I also answer any questions that are posted on Action Cards. We have meetings across all of the engineering pods, and that usually comes with a number of follow-ups, which I try to address as soon as I start my day.

???? I also plan out hopping on calls with engineers to try unblocking certain issues and making sure we have the next steps for any issues that may have come up. I find that Hive’s My Day is super helpful for this. I remember when My Day became available, it was like “Wow, I don’t need to open the Google calendar like 12 times a day to see what I have going on.”

Instead, I get a notification now and join all of my calls at the click of a button. That specific feature is massively helpful.

12-3 P.M.

After that, the early mid-afternoon usually means some heads-down time. I’m able to take some next steps on some of the things that we want to make progress on, like general engineering initiatives. During that, any things that come in — like requests for pairing meetings — usually eat up the rest of the afternoon. ????

3:30-5:30 P.M.

Towards the end of the day, I usually find myself doing the last round of review of the cards on the Kanban board and making sure that no stories have gotten blocked and that we’re still making solid progress. ✔️

Making a True Impact On a Workday

What would you say are the biggest benefits of using hive overall for you and the team?

Hive is like the single source of truth for all work that’s happening. And I love that that source of truth can come from many different streams within.

It can come from the result of Hive Notes we took in a performance call or emails that are interacting with third-party vendors that need next steps. Having all of our work boiled down onto a single Kanban board, where we can see the progress and status of all-day items, is the biggest piece for me.

Other than that, I love that the entire team has the ability to check in constantly, collaborate, ask questions and get answers — all while we’re all connected remotely. 

What would happen if you couldn’t use Hive anymore?

On the engineering side, if we just magically had to make life work without Hive, things would be very chaotic. We’d have to use some other project management tool or system to help us track our work. Just using emails and spreadsheets would not cut it for our use case.

There would be a ton of growing pains because we’ve really ironed out the workflow in Hive. Everybody’s so familiar with it. I think trying to transition to another tool would also feel like an absolute nightmare.

So yes, I’m very happy that we have Hive.????

Would you recommend Hive to other teams and if so, why?

Absolutely, without a doubt.