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

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

How to Maximize Employee Retention in Engineering Teams

25 May

Vimal Patel, Founder and CTO at iMORPHr, shares how he retained all of his employees since beginning his software development company in 2019.

Building A Team
Company Culture
Hiring
Retention
Psychological Safety
Vimal Patel

Vimal Patel

Director of Engineering at iMORPHr

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.