Findhelp Leadership & Management

Does your team or engineering org have a central ethos or mantra that drives how you develop?

Our mantra is “Pick Up Sticks.” 

In a game of Pick-Up Sticks, the goal is to pick up each stick without disturbing any others. This is how we deliver high quality while keeping customers front and center. 

We complete the quick and easy tasks first —picking up the sticks on top — while delivering on customer commitments, all without disturbing the other areas of code and clearing the way to safely tackle the next item. Just like when you near the end of a game of Pick-Up Sticks, tangled areas of code that were once deeply buried now lie clearly on the surface. 

Simplistic policies such as requiring all touched code to have a given level of code coverage forces your developers to pick up all the red sticks first. Perhaps some of those red sticks are deeply buried and removing them first would disturb the entire pile. Each stick removed makes the code slightly easier to change. Since keeping customer commitments and fixing bugs requires changing the software, we can say that the definition of quality in software is that it is easy to change.

The trick is getting all those small changes aligned department wide and empowering your people to make them.

How do you put that ethos into practice? Share an example of a project or product that embodies that theme.

We began the modularity initiative after recognizing the need for deeper alignment in our existing code. I began building consensus through a request for comments followed by an architectural decision record. The concept of Nemawashi was very useful during this process. 

One of our engineering principles is “refactor along the way.” Our engineers do so by making targeted tactical changes with every customer-related item while being sensitive to the business needs and the timescale at hand.

Like all software organizations, we have some legacy code. However, unlike many organizations, every developer knows our target modular structure and is empowered to make manageable changes that will get us to our target architecture on a reasonable timeframe. We have clear, collaboratively developed standards that guide us as we pick up sticks.

As engineering teams imagine possibilities for their culture, how can they ensure that the shared vision is inclusive, inventive and future-proof?

At findhelp, we decide where we are going through a collaborative process where all the engineer stakeholders are empowered to participate through RFCs to solicit early feedback, which eventually becomes ADRs that formalize and keep a historical record of those decisions.

Will Larson writes in his blog about technical vectors. Imagine four pull requests each lying on the unit circle since they all are of the same level of effort, but pointing in different directions due to a lack of architectural alignment. By placing them end-to-end, the total architectural movement was small. Without a shared understanding of where an organization is going, that's the best that can be done despite valiant individual efforts. When there is broad architectural alignment, the same level of individual effort produces a much larger architectural movement.

For example, we have decided to always align our work toward a target software modular architecture. A modular architecture is one in which dependence between internal components is limited to minimize coupling which makes our code easier to change.