Engineering Culture: How Humility Helps Better Our Team and the Product

Not long ago, prior to joining Protenus, I found myself contributing to a string of successful software projects. These projects, with small but talented engineering teams, didn’t shy from wild west development tactics: committing directly to the develop branch, merging without peer review of code, foregoing best practices ranging from automated code formatting to strong unit test coverage. Our technical chops and the disposable nature of our solutions meant we could move fast and muscle our way to a result that looked great while checking every requirement box. Management and clients were pleased to have features delivered on time. Developers enjoyed the low drag process. We were doing it right.

Sometimes you need to see things done a better way to realize you’ve been doing it wrong.

I decided to join Protenus because I was ready to build something for the long-haul. With that came established standards and expectations that support developing a platform intended to last for decades. Perhaps counterintuitively, I found the rigor we apply to the codebase and development process for the purpose of a long-lasting solution could also benefit short-term projects as well. Few, if any, of these practices were created at this organization (many are now industry standard), but putting all of these techniques together has produced predictable and efficient results for our engineering teams.

Sharpen Yourselves and Your Codebase with Pull Request Reviews

Chief among all of our practices is code review through pull requests. This serves so many functions I kick myself for not instituting it in past projects:

• Acts as a quality control for the codebase
• Allows the author (and reviewers) to learn from their peers
• Provides documentation for testing functionality
• Gates features from entering the develop branch until they’re ready

The UI team actually takes this step as a time to give the feature a test spin in the browser. Sometimes what worked as a design doesn’t play as well in reality.

Invest in Tackling Tech Debt

We’re lucky enough to have a leadership team that understands what technical debt is and the importance of addressing it. Each engineering team segments out roughly 20% of our allotted roadmap points toward paying down tech debt. Sometimes we know exactly what we want to slot into that bucket each quarter, but we also reserve space for when we encounter “that part” of the code and want to give it a nice refactoring. We treat falling short on that 20% mark as a failure just as we would if we failed to deliver on a big roadmap feature.

Having trouble convincing leadership on the importance of tech debt?
Loss framing can help: “We won’t be able to deliver as many features without addressing this.” 

Handle the Dreaded Cross-Team Effort

Cross-team efforts are typically the biggest (and most critical) features to deliver, bringing pressure and complexity onto the engineering teams. There’s always room to improve here and your process will be influenced by your organization’s makeup. The following has worked well for us:

1. Assign an owner from an engineering team. Without this, participants might think someone else is making progress toward the effort’s goals. It’s incumbent on the owner to collect requirements from customers and/or internal parties. 
2. Author a design document (as owner) that outlines the problem, one or more potential solutions (with pros and cons), and any additional information including schema designs. This document is sent to other engineering stakeholders with a meeting invite in tow, allowing stakeholders time to review the effort, consider potential solutions, and comment on the document with design or implementation concerns.
3. Meet with all stakeholders and discuss the proposed design. Outline next steps (which may be to repeat steps 2-3).
4. Keep regular communication between teams during development, sharing partial results when possible. Coordinate a release strategy if necessary during these talks.
5. Give the feature a test drive on an integration environment (it beats crossing your fingers hoping everything lines up in production)
   
   

Put thought into your cross-team development process and consider retrospecting the process with technical leads.

Chill with Your Fellow Engineers (And Other Departments)

It’s easy to get stuck in the loop of knocking out tickets and move onto the next release before you’ve had a chance to revel in last deployment’s accomplishments. Celebrate the big wins as a team. Take time to get together for drinks, gather for a night of board games, or simply sit down together to eat lunch (remote included). Doing so, especially across teams, puts faces and personalities in place of the cold dependency graph inherent within all organizations. You perform the work levied on you not just because it’s your job but because you know the person on the other side - and they’d do the same for you.

Use the office A/V equipment to power a game night instead of a
Keynote presentation.

Gain Strength Through Diverse Backgrounds

Adding swaths of employees from a single previous workplace (or team) has its benefits. You construct a team built on known commodities where the members are familiar not only with each other, but with a common development methodology. Don’t deny the team and company the benefit, however, of recruiting individuals from different backgrounds. Unique experiences or educational backgrounds bring new approaches to problem solving, fresh perspectives and new technologies that are currently in your blindspot. 

Implement These Quick Hitters

• Automate code formatting and agree to code organization best practices. You shouldn’t be able to tell who wrote the code by looking at the file!
• Document as much as you can, especially in regards to testing. This can be useful to share with other teams and particularly for new members on the team.
• Release frequently if possible. Inviting your end-users into the agile process means you can deliver value quickly and it enables them to join you on the iterative process of feature development.
• Create tools and scripts that assist in your everyday tasks. You’d be surprised by how quickly you regain the time spent on creating them.

Staying humble manifests itself in many ways: submitting your work to get dissected by team members, admitting that old code isn’t so hot and needs to be reworked, bringing an open mind to design sessions, and on and on. We’re always looking to do better and learn from new members and external resources. Don’t be afraid to connect with me on LinkedIn!