Back to resources

Implementing Development Processes

Dev Processes
Company Culture
Collaboration
Cross-Functional Collaboration

20 July, 2021

Tina Cessna
Tina Cessna

Senior VP of Engineering at Blackblaze

Tina Cessna, Senior Vice President of Engineering at Backblaze, was able to organize her engineering and QA teams by bridging the gap between departments with processes that made the work easier for both sides.

Problem

When I took over my team three years ago, I helped them scale from twelve engineers to forty-five. Part of that involved introducing development processes to our workflow. We wanted to make sure that everybody on board knew what they were supposed to be doing at any given time, as well as to provide context into why they were doing it.

This was one of the biggest things that I had ever had to do for the company; I spent a lot of time during my first year doing this. We wanted to bring everybody into alignment over the work. This was challenging, as we had to achieve this alignment across multiple teams who were all focusing on something totally different. This included our QA team, who also reported to me.

Actions taken

The engineering team used one tool to track the bugs that needed to be addressed; there was no real process outside of this tool. We were releasing weekly, so there was always something to be done in front of us.

The teams were not used to relying on a process when it came to the work that they were doing together. We ended up trying out kanban boards, adding an element of Agile to our workflow. Kanban boards are great because they allow the engineer to work at their own pace. Adapting this tool eased the transition between departments as they passed off work to one other.

We also started using JIRA, creating tickets for every task to be done. This goes beyond fixing bugs and things of that nature; the system also includes feature work, as well. Everything has a place on our Kanban boards, and it’s made our work together much more efficient.

I wrote a lot of documentation explaining the processes that we had implemented. I wanted to make sure that everybody who was utilizing the system understood how to do so. There was some disconnect between QA and the rest of the engineering team, so I wanted to lay out their needs clearly in the documentation. This provided others with the context of what they needed to test the product on their end. One of QA’s biggest challenges was planning what they needed to test before our releases every single week. This process gave them the visibility that they needed to carry out their work effectively and autonomously.

When all that a person has to do is refer to a ticket on their Kanban board, they know exactly what they should be doing, immediately and without question. We diverted our releases into branches using Git branching, stabilizing our main release branches while still making progress elsewhere. I let the team figure out their pain points so that we could get together and talk about resolving those issues.

My message to my teams: nothing that we do is set in stone. We try things, and if they don’t work, we collaborate on ways to improve them. This is how we evolve as an organization.

Lessons learned

  • I think it’s really important to earn buy-in when trying to instate processes like this. If I’m just telling people what to do, I run the risk of implementing “solutions” that cause more trouble than they solve. Some leaders work blindly in this way. Feel the team’s pain and work together to resolve it.
  • We have many more managers now than we did before. For feature work, each team follows their own personal Scrum board. We plan our sprints in two-week intervals. The work is now so much smoother. We are more able to orchestrate releases and to work with our product managers and my QA team. They have all of the visibility that they need to do their part; we even invite them into our sprint meetings. We ask to hear all of their challenges first-hand.
  • Listen to your entire team and remember their pain points. Guide them through the process of solving them. Let them be an active participant when finding a solution. It’s a lot of talking and understanding, but it will be effort well-spent.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Managing remote first organization

4 January

I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.

Building A Team
Company Culture
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

Facebook vs. Google: 10 Contrasts for Engineering Careers

7 December

This is a brief comparison and contrast of Google and Facebook, as a place for one’s software engineering career. Both can be amazingly good places for engineering careers. But both places can be misfits for otherwise excellent engineers. This is a short differential guide. [Originally on LinkedIn]

Company Culture
Michael McNally

Michael McNally

Chief Technology Officeer at GraphStax

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero