At Cerner, I've spent a majority of my time as a software engineer. My days were consumed with writing code, working on user stories, helping other engineers make decisions on what direction we should take.

Last year, I became a Team Lead, and my priorities have shifted to managing both people and projects, and in a world where my time is constantly being consumed by many different priorities, I'm finding that I've needed to learn how to do something I've spent my entire working life not doing: I gotta go slow.

Sonic the Hedgehog Mentality

Software engineers are taught that speed is everything. In all aspects of our work, we strive to achieve the highest levels of automation and performance that we possibly can in all aspects of our work: our projects, our processes... Hell, it even spills into our home life with the amount of automation we do!

From our builds to our tests to our runtime environments to our development cycles, we're always looking to do the speediest thing possible. After all, time is our most valuable asset when it comes to software development.

In a world where as engineers and managers our time is rapidly consumed, we're always thinking like Sonic the Hedgehog: we gotta go fast.

While there is no problem with speed when it comes to automating development processes or increasing the performance of code, we can't carry that mentality to the design or architecture.

Going Fast Has Consequences

As a manager, my team often has questions about how I think the code needs to work or needs to be designed. I feel obligated to ensure that they are armed with the information they need to be able to make good decisions with the code.

However, what I've found is that when I make very quick decisions, or when I encourage others to make quick decisions about code that impact design or functionality, it ends up creating more work for us in the long run. Why? Because I make decisions based on what's worked in the past, but not what I think would be best in the moment.

As a manager, I've also helped coach them in the ways of agile development processes. To help track the progress of our projects, we story point all of our tasks. To their credit, my team follows the acceptance criteria of their tasks in a very strict fashion, which is awesome.

However, I sometimes don't include everything in the acceptance criteria for our stories and tasks that I expect out of them because... Well, I expect that my team considers all the same things I do! Rather than taking the time to think through all of my expectations and communicate them clearly, I can sometimes be hasty in my decision making. This again leads to more development cycles and more work.

By slowing down and spending more time making decisions, I've found that I'm able to consider more aspects of the work that I wouldn't have otherwise been able to consider. This has lead to much more effective decision-making.

If you are experiencing the same things within your organization, take the advice that my 1-year-old's favorite show gave me: sometimes slow is the way to go.

It's actually extremely funny how many nursery rhymes have great life lessons in engineering, but that's a topic I'll leave for another day because it warrants it's own discussion.