There are some time-saving techniques that are applicable to engineers no matter what size company they’re at. Andy Phillips, a senior front-end engineer at direct-to-consumer hearing aid company Jabra Hearing, told Built In New York that understanding his natural rhythms was key to increasing his productivity. Anna Fenske, a software engineer II at SaaS monitoring and analytics company Datadog, said her favorite technique for saving time is extensive pre-project documentation.
At the team level, though, the size of the company does impact the challenges engineers face and the methods they can employ to save time.
Datadog is a publicly traded company founded in 2010 with more than 3,000 employees. As such, it makes sense that Fenske said her team’s focus when it comes to efficiency is on identifying and reducing tech debt. Conversely, Jabra Hearing was founded in 2018 and has only recently begun to scale, which Phillips said made it clear that a particular practice from their recent startup days was preventing them from working more productively.
Continue reading to learn more about how Phillips and Fenske save time in their day-to-day work along with the specific challenges engineering teams at large and fast-growing mid-size tech companies face in streamlining their workflows.
Anna Fenske’s approach to saving time on software development at Datadog can be summed up as “don’t move too quickly.” Fenske told Built In New York that rather than jumping right into her terminal, she takes time before starting a project to document the problem and possible solutions in-depth. Fenske’s team also follows a version of this philosophy and conducts weekly retrospectives to identify and reduce tech debt.
What’s your favorite time-saving hack when it comes to developing software? How do you implement this strategy in your work?
Before beginning a project, I make sure I’ve documented four things. First, is the problem, including specific pain points or user journeys that we’re solving and the requirements of its solution. Second, is a near-exhaustive list of possible solutions. Third, is the solution I have chosen, including why it has been chosen and why other solutions are less desirable. And fourth, are the short, medium, and long term visions for the solution. If I’m collaborating with another team, this document will also include the responsibilities of each team; both teams will agree on all components of the project document before any development begins.
Without a clear project roadmap, we risk losing engineering time to having to revalidate the goal of the project. In the absence of a clear problem statement and expectations enforced by a written roadmap, the value and purpose of the project may be put into question, and that slows or even stalls progress. Without a written agreement, teams risk overstepping boundaries or failing to hold themselves accountable to responsibilities, which may result in unclear ownership of a project. I like the old saying, “Measure twice, cut once.”
We’ve implemented weekly operational retrospectives and frequent reevaluations to continuously identify opportunities to reduce tech debt.”
What tools or strategies has your team, as a whole, implemented in an effort to streamline the software development process?
As a team, we’ve implemented weekly operational retrospectives and frequent reevaluations of past architectural decisions to continuously identify opportunities to reduce tech debt. This is often the primary culprit for poor developer experience, which in turn leads to decreased productivity and iteration speed.
As a growing team, it’s easy to forgo retrospectives that focus on past decisions in favor of looking forward to feature development. However, what often gets in the way of our ability to quickly deliver new features are the consequences of tech debt, such as monolithic APIs and frameworks that do not scale to the current size and complexity of a service, that have become the foundation of our product but may no longer meet the needs of our current context.
Additionally, communicating actions taken to reduce tech debt through blog posts, documentation and demos for other teams in our organization has allowed us to multiply our impact on teams that may also be affected by the same technical debt.
How have implementing these strategies or tools — either individually or as a team — changed the way you work? What benefits have you seen?
Documented roadmaps, alignment agreements and continuous review of past architectural decisions to manage tech debt, all help streamline our development efforts. This brings the extra benefit of maintaining a good relationship with our customers and stakeholders. It also allows our team to set an example of what an effective engineering culture looks like for other teams in our organization.
Andy Phillips joined direct-to-consumer hearing aid company Jabra Hearing as the company began to scale up. Phillips told Built In New York that as the company’s development team grew, individual bottlenecks became a challenge and prevented his team from moving as quickly as they were capable of. While increased autonomy helped to alleviate these issues, Phillips said it hasn’t come at the cost of collaboration.
What’s your favorite time-saving hack when it comes to developing software? How do you implement this strategy in your work?’
For me, the most effective hack is paying attention to my own natural rhythms. I’m definitely a morning person, so that’s when I try to tackle tougher tasks. And if I hit a snag, taking a quick break often helps me clear my head and find a solution. Honestly, understanding my own most-productive hours has been a game-changer and has helped me optimize my workflow and reach my goals more efficiently. And let’s be real, a good cup of coffee doesn’t hurt, either!
One of the most significant changes we’ve implemented is to ensure no individual team member becomes a single point of failure.”
What tools or strategies has your team, as a whole, implemented in an effort to streamline the software development process?
As Jabra Hearing has continued to grow, our engineering team has encountered various obstacles, including the issue of bottlenecks; but, I feel we’ve made tremendous strides in tackling this challenge over the past year.
One of the most significant changes we’ve implemented is to ensure no individual team member becomes a single point of failure. From a practical standpoint, this has meant removing gatekeepers from things like code reviews and production releases, and empowering individual engineers to take on these responsibilities. On top of that, we’ve also taken proactive measures to encourage knowledge-sharing via both training and pair programming sessions. This has had a real impact on how we work together, making us more productive and efficient as a team. It also helps that everyone on the team is so talented! It makes these kinds of changes a lot smoother.
How have implementing these strategies or tools — either individually or as a team — changed the way you work? What benefits have you seen?
The way we work together as a team has really evolved since implementing these new processes, and I’ve noticed some major changes in my day-to-day work. Instead of just focusing on our individual tasks, we’ve made it a priority to help each other out and make sure everyone’s work is progressing smoothly. Shifting away from a top-down approach has definitely had a positive impact on our productivity, and it has also strengthened the level of trust within our team. We’re all empowered to take control in different areas that interest us, which has been really exciting. I’m eager to see how these processes continue to evolve as we grow and face new challenges as a team.
