Across nearly all industries and job functions, managers are struggling to manage rapidly changing technology which is transforming their industry. For managers of engineering teams this problem is even more pronounced.
Over the last two years, I’ve found myself managing my first engineering department. This was a daunting challenge and meant I would need to learn a lot very quickly. Do you find yourself in a similar situation? Well not to worry, here are 6 things I’ve learned to up my engineering management game.
Be a Technology Advocate
We’re in the business of technology, so let’s embrace it. It’s easy to play it safe by sticking with technologies we’re comfortable or experienced with. Oftentimes this can lead to situations where our applications bloat into dated platforms running on legacy languages or frameworks with dwindling industry mindshare. This can lead to challenges in hiring new talent as well as having that “black hole” in our application where everyone dare not go.
As technologists, we need to constantly push our comfort limits; that’s the only way we learn new things. We never know when a language, library, or framework that we’ve never used before turns out to be the right tool for the job. So when new things come along, as they inevitably do, we need to experiment with them.
The most critical aspect of vetting something new is understanding the value it offers in our application’s ecosystem. That value may be in the form of new ways of solving existing problems cheaper and faster or it may be in the form of a broader available talent pool when hiring. Most importantly though, is that we can identify that value when we see it and can demonstrate the ability to translate it into meaningful benefits to our product or organization. As industry trends continue to change, being a technology advocate means both we and our organizations won’t get left behind.
As technologists, we need to constantly push our comfort limits; that’s the only way we learn new things
Employ People in Accordance with Their Abilities
This one comes from a close friend of mine straight out of his military training. I really took it to heart when managing engineers on my teams. Everyone wants to learn and continually improve and if they don’t, they should. That said, everyone does have distinct talents due to either experience or innate ability. When those talents are misapplied some of our most talented people aren’t able to do their best work for both themselves and the organization. It can lead to unhappy people and even codebases.
To get the most out of our people, as well as create an environment of success and growth, we need to be in tune with what everyone’s talents are and how and where to apply them best. If you don’t know what your people’s; talents are already, start by asking them.
It comes down to helping our people be more successful. By employing our people in accordance with their abilities we’re helping them succeed in the most apt way possible.
If you don’t know what your peoples’ talents are already, start by asking them.
Stay Product (and User) Focused
Taking my consulting hat off for a moment, I can say that as an engineer it is extremely easy to get very excited about an idea, tool, technique, technology, or even feature when it’s fun to build. This can lead to some sticky conversations with the product team trying to wade through why something was done or is being proposed, and what value it offers.
Putting that consulting hat back on, what we can’t forget as a Senior Architect or Engineering Manager is that engineering exists to implement solutions that solve customer needs. Product teams exist to work with customers to understand what problems they have and what solutions to those problems might look like. Engineering steps in to make those solutions a reality.
Focusing on our development from a user’s perspective helps foster better conversations. Whenever there’s a question of how something may affect the product or the user it is our job to discuss it with the product team, rather than solve it by ourselves, unless called upon to do so. During strategic planning, we need to work closely with the product team on our engineering roadmap; their needs will inform the technical direction of the application ecosystem. Avoiding distractions ensures our teams are providing maximum value to the product and the customer.
Product teams exist to work with customers to understand what problems they have and what solutions to those problems might look like.
Hold People Accountable, Including Yourself
When mistakes happen, or efforts fall short, we don’t always do a great job of acknowledging our issues. It’s not fun to call out problems when they happen, especially when we have to accept responsibility for it. Sometimes we’ll make excuses, blaming our tools or technology. By not being direct about problems we may end up with issues in our codebase or architecture that go unaddressed and turn into even more pronounced problems inevitably needing to be dealt with in the future.
Mistakes are okay. They’re a necessary part of learning and we need to recognize that. When we make excuses or ignore mistakes it doesn’t do anyone any good and just delays a resolution to the problem.
So let’s acknowledge them; we’re all human anyway. When bad things happen, let’s go ahead and fix them. We should be encouraging our team to openly address issues when we haven’t necessarily done our best work, so we can learn from it and resolve any problems. Most of all, we need to admit when we ourselves haven’t done our best work. If we don’t hold ourselves accountable, how can we expect our teams to? Let’s lead by example.
When we make excuses or ignore mistakes it doesn’t do anyone any good and just delays a resolution to the problem.
Don’t Forget to Write Code
As Engineering Managers, it’s easy to find ourselves without any time to actually write code. We’re running from one meeting to another with no end in sight and before we know it, the day is over. I know it’s a pain and it seems impossible to be able to keep our hands in the thick of things when dealing with all of that. However without doing so, we inevitably lose some touch on where and how things are with our application’s codebase.
There is no better way to understand the pain points in our applications than when we are actually developing for it. Sometimes we may think it’s enough to meet with our engineers or work side by side with them to solve problems, but there’s no replacement for doing work ourselves.
Obviously, time doesn’t always permit us to be doing feature development and delivering code every day, but we can still tackle strategically important work that doesn’t necessarily map to a specific deadline on our roadmap. Prototyping new features, experimenting with new infrastructure or dealing with long standing architectural issues everyone else has avoided not only keeps us sharp as engineers, but can be gold for helping stay in touch with our engineers and our applications. We need to find the strategic work that we can do to still keep our hands in the thick of things that doesn’t hinge on the constraints of our time.
There is no better way to understand the pain points in our applications than when we are actually developing for it.
Think First, Code Later
It’s common for engineers, especially ones with less experience, to jump straight to code when implementing a feature or bug fix. While this isn’t always a problem, sometimes it can lead to a knee-jerk reaction approach to implementation.
Sometimes engineers may need to take a step back and ask some questions. Do they fully understand the problem? Do they fully understand the feature? If it’s a bug, is the way it’s manifesting itself directly indicative of specific code or is it not immediately visible? How does the user expect this to work? Does the implementation jibe with that?
Sometimes taking a step back and asking questions about what we’re about to do can lead to a totally different approach. More often than not, we will find ourselves writing far less code to implement features and fix bugs; often the simplest approach to something is not necessarily the easiest to identify. By encouraging the engineers on our teams to think first and really analyze what they have to implement we’re more likely to find a better architecture as a result.
Sometimes taking a step back and asking questions about what we’re about to do can lead to a totally different approach.