Pinpoint Engineering

Creating goals and plans for an entire year can be challenging for a startup. Startups have smaller teams with intense focuses on weekly or daily cadences so trying to think about overarching, ecosystem-like goals can be difficult. Their environment can also change rapidly, so it’s important to constantly communicate changes in direction.

In preparing for battle I have always found that plans are useless, but planning is indispensable.
– Dwight D. Eisenhower

Constant pivots and realignments are not an excuse to ignore the bigger picture and overarching goals. Without the bigger perspective in mind, small pivots cause you to go in circles.

Chance favors the prepared mind.
– Louis Pasteur

Somewhere in the middle, between the micro-pivots that have to happen in a day-to-day cadence and the macrovision of a startup, are really important goals, processes, and cultural foundations that are necessary for high performing teams. These goals in the middle make the constant shifts in priorities efficient and processes that lay the foundation for scalability to the longer term vision.

This blog post talks about some of those “middle areas” that Pinpoint engineering is focused on in 2020. They span things like simple processes that no doubt any engineering leader will think “Of course you should be doing that”, to cultural shifts that we want to emphasize in the company.

An Emphasis on Learning

The desire to learn new things is important in tech and simply a requirement in a tech startup. If we’re not careful, we can miss the part where we’re trying to be engineering leaders. We can’t impact an industry with our heads in the sand.

Education is not the filling of a pot but the lighting of a fire.
– W.B.Yeats

There’s a lot of knowledge transfer happening on a day-to-day basis. This is great for groups that are working close together, but even in a small company, knowledge is lost across teams. We’re starting periodic “lunch and learns” for all employees and topics span to almost anything: sales, marketing, engineering, ideation, teaching and training, etc. We also do “war rooms” virtually in slack and/or in person where knowledge sharing is a key objective as well. 

If you think education is expensive, try estimating the cost of ignorance.
– Howard Gardner

Community-Active Engineering

Because our product’s main objective is to improve the process of building software for engineering teams , it’s important we have an empathetic attitude towards engineering across every level of an organization. That manifests itself differently across the organization, of course, but for our engineering teams, we really want to be open about everything we do. We want to open source things we’re building, share the knowledge amongst the community, help engineers and engineering teams continuously be better. 

Measure to Improve

We use Pinpoint at Pinpoint, and with every new release, we’re always ready to put the new features into action for ourselves. This year is the year we start using meaningful measurements to help teams improve their performance, software, skill, and happiness.

Smooth seas do not make better sailors.”
– Unknown proverb

Some key measures that are of most interest and impact to the team would be:

• PR review rate & merge time
• Workload balance
• Cycle time
• Rework rate

This is Team Bolt's dashboard in Pinpoint. We use this to help benchmark and see trends in these metrics. You can sign up to get these same dashboards for free here.

Bite-Sized Engineering Surveys

We use 15Five a lot for 1-1’s, weekly “How’d the week go” statuses, and OKRs. One thing we are starting to use it for is asking questions that help us understand what’s affecting our teams. 

Some important metrics we care about that we’re starting to pay attention to:

• Number of meetings in between coding
• How long of a period is there time to code, between meetings
• What are some of the biggest roadblocks, biggest wins that are happening, etc.

A Better Experience for Engineers

Moving at break-neck speed can leave some things to be desired. One area that can be improved is the internal developer experience, which our engineering surveys from above can help us identify areas of improvement.

For example, when you’re dealing with microservices, Kubernetes, multiple engineering and data science teams with their respective technologies, it can get messy getting things running. We can improve the experience and speed of getting an environment created with some relatively simple process enhancements. Suddenly, some tickets aren’t so daunting to tackle because we have reduced the complexity of simply getting the work started. This is a foundational thing we want to get right, so that working in and on Pinpoint is a good experience for our teams.

A good developer experience can really boost overall team performance and morale. 

Get Lean and Simplify 

An explosion of innovation and features is awesome, but if we’re not careful, the aftermath of such velocity can actually slow us down. It’s important to ensure we can continue to move fast by constantly learning from past action and then simplify our solutions. We’ve already started to do this and will continue to do so. We should always be asking questions like:

• “Will this let me work faster in a month?"  
• "Will this let us pivot easier in a month?"
• "Will this keep me from addressing a customer’s need in 2 weeks?"

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
– Alan Perlis

Feature-Flag First Approach

We’re adopting a feature-flag-for-all-things culture. That means everything we do will be wrapped in a feature flag. This type of feature componentization gives us some really powerful control over continuous development and empowers our product team to try out and roll out features with ease.

Here’s another great resource on feature flagging that I would recommend.

A Better Pull Request Process

We currently have an unwritten PR process that is generally followed by the teams. We’re going to codify the process more this year, while still allowing some flexibility. Some things that are top of mind:

• 1 reviewer should always be responsible for running the code
• 2 other reviewers review to be in the loop and approve
• Author merges when approved and/or ready
• Use Github’s new round-robin feature for selecting the 2 other reviewers
• Determine an acceptable % of time reviewing PRs vs. other work. PR fatigue is real and not only affects quality but can prevent team members from their work.

Instill Important Values

Every company has cultural and work ethics, here are some of our company operating principles. Some things we think are important for our engineering team specifically:

• Take ownership. We are too small to have silos in ownership or expertise. Everybody owns everything which is why knowledge-sharing is so important. 
• Discipline in the right things equals freedom and flexibility
• “A prototype is worth 1,000 meetings.” If someone feels passionate about something, they should make a PR, build a prototype, make a change, then socialize it. (Read more about our code review best practices on Built In Austin.)
• Have a bias towards action. We implement this through shared ownership and prototyping as mentioned above. 
• Stop and go requires more effort, so don’t kill momentum. 
• Consensus is great but communication on direction is better (again, see the prototype point above.)
• Beware of consensus that creates politics and not action.

Tell me and I forget, teach me and I may remember, involve me and I learn.
– Benjamin Franklin

These priorities will not only help shape our production as a startup but improve the overall value for our customers. We believe in a better software development experience and actively work towards creating it every day.

About Rick.