Speed is a valuable currency in the workplace for Michael Timbes, software developer at Medtelligent Inc. But for Timbes, speed doesn’t solely boil down to the rapidity of one’s individual output.
“Speed in software development isn’t simply writing lines of code faster,” he said.
To the uninitiated, that might sound surprising. But in connecting with Timbes, Echo Global Logistics Staff Software Engineer James McGuire and Enova Senior Salesforce Developer Sean McCarthy, it becomes evident that moving with speed relies on a number of different factors and approaches.
Timbes, for example, stressed the organizational component of the equation — meaning, in order to move forward, there needs to be the right working environment to empower speedy, quality work. For McGuire, zooming out to get a big picture view of “what went wrong and what we did well” is beneficial. After all, you have to get the lay of the land to navigate it successfully. And McCarthy noted that a high altitude lens — focused on the consequences of potential decisions within the larger whole — helps tee him up to move forward quickly, versus simply steaming ahead.
And moving deliberately like that is crucial. After all, what good is speed if the caliber of work suffers and things fall through the cracks? As McCarthy observed, “It’s critical to take a step back to ensure quality is maintained.” Plus, the specter of burnout never lingers far from the topic of working at a quick clip, and there’s only so much even the most talented pro can handle.
So how do they strike the right balance? Below, these three professionals shared how working with speed is beneficial, how they’ve acquired the ability to do so and some ways to avoid the potential pitfalls of rapid work.
Employers obviously benefit when we work with speed. But how does moving fast as an engineer benefit you?
At the beginning of my career, I worked as a paralegal on the liens and subrogation side of personal injury law. There, I learned what working with a high volume to meet unmovable deadlines truly meant. Through working at that kind of pace, I became hyper-attuned to what it took to keep my pipeline flowing. From that heightened awareness, one of the things I quickly noticed was how changes in processes or systems would affect my ability to maintain that day-to-day pace. Sometimes that effect could be good or bad, resulting in an increased pace or potentially causing process-stopping results.
As luck would have it, I was able to grow with the company where I could abstract myself beyond the day-to-day trenches and move into a more analytical role helping shape the systems the company utilized. Knowing — and more importantly respecting — the ripple effect that systematic changes can have on the people at the front lines of the business was a key lesson for learning how to work with speed as an engineer.
During your career, what have you learned that helps you work faster?
Once I truly embraced the idea of moving slow to go fast, everything else I was taught as a developer fell into place. Instead of rushing the solution for the sake of forward progress, I began to take a step back and think, “Did I do this right? Is this reusable? Have I identified the right level of abstraction? Is this going to cause issues down the line when changes are made?” That mentality, coupled with an organization that facilitates small, concise, deliberate changes, offers an unparalleled opportunity to move at speed.
At a high accuracy and a high volume cadence, the work becomes enjoyable. I get to see my work continually make measurable advancements, adding to my drive for continual improvement. In a world where you constantly hear about negative cycles of work, it is incredibly refreshing to be part of such a positive pattern. When I hit that cadence of completing those manageable tasks with measurable results the work becomes rewarding. Once I have that dynamic shift, I enjoy what I’m doing and burnout isn’t an issue. However, I am still diligent about using my time off and making sure I take time away for myself. I categorize that as more of a personal skill.
Once I truly embraced the idea of moving slow to go fast, everything else I was taught as a developer fell into place.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
The aforementioned ripple effect lesson still holds true to this day in my current role as a Salesforce senior developer. In a role such as mine, a developer must have the ability to make sweeping changes that can offer exponential cost savings to the company — while remaining humble. While the role does not directly earn the company money, it exists to ensure the processes behind revenue-generating activities are as efficient as possible. With that understanding comes the realization that it is important to the company as a whole to work at a fast pace.
At the same time, it’s critical to take a step back to maintain quality. Implementation strategy and proper documentation skills are just as important as the ability to code a technical solution. Even a great solution is useless if it cannot be properly advanced, tested and released with adoption. One of my favorite quotes from a data engineering friend of mine sums up the idea: “You first have to learn how to drive the slow car fast.”
Employers obviously benefit when we work with speed. But how does moving fast as an engineer benefit you?
Moving fast allows my team to experiment with new tech and learn new design patterns. At the root of it, it allows us to fail fast, learn from the mistakes and pivot into a better, more refined design. Echo is consistently encouraging us to try new technologies, design patterns and DevOps practices and patterns. Pace is critical and we are unable to spend months testing out proofs of concept. As a result, we test things out on small projects and move forward with what is best for the teams and Echo.
During your career, what have you learned that helps you work faster?
Having the ability to step back from my work and figure out what went wrong and what we did well allows me to jump back into developing with new context and perspective. Then I rinse and repeat: Given enough of these cycles, you end up with a better product. Ultimately, I have learned with this cycle that if I’m not always learning, I’m not becoming a better engineer.
Moving fast allows my team to experiment with new tech and learn new design patterns.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
The drawbacks to moving at this speed are twofold: the potential to take failure to heart and burnout. It takes time training and working with developers to understand that we can’t take the occasional failure personally. As long as all the developers understand that we are working as a team and ego is left at the door, moving quickly can be successful.
Burnout can be managed by controlling sprint velocity. Crafting achievable goals and cross-functional communication are essential. Communicating with product and the larger business to set clear and meaningful expectations and goals for each sprint as we move toward larger deadlines helps manage expectations. Most importantly, we make time for fun and find ways to show our passion for the technologies and products we work with.
Employers obviously benefit when we work with speed. But how does moving fast as an engineer benefit you?
For a software developer, being able to move with speed really means that we have well-designed architecture and a strong DevOps pipeline to be able to deliver features and upgrades quickly. Having that solid foundation is great because I can spend more time in the planning and design phase of our projects, which is where I learn the most.
During your career, what have you learned that helps you work faster?
Speed in software development isn’t simply writing lines of code faster. Instead, it’s a function of multiple things: team communication, leadership, planning, code quality, architecture, DevOps, creative freedom and developer craftsmanship. When I’m in an environment that is healthy, supports skill growth and has strong, collaborative leadership, that is when I am able to work quickly and efficiently.
When I’m in an environment that is healthy, supports skill growth and has strong, collaborative leadership, that is when I am able to work quickly and efficiently.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
There are two main issues with working quickly. The first is burnout, a concept that has come to light more recently and a mental state that will eventually slow a person down or cause them to completely stall and not be able to work at all. It is important to actively be aware of this on our team and make sure that people are not only able to rest but that they are able to work on projects that align with their interests and passions.
The second is working too fast. That’s when details get missed, communication breaks down and countless other things just fall apart. There is an optimal speed that a team can work at. Sometimes they can push to work even faster than their average, but it is important to gear back down to the optimal speed to avoid the issues of moving too fast.
