Moving to management is fun when you know what it takes
It’s not easy being an Engineering Manager and it takes more than just a good work ethic. The first step in becoming a good leader is learning about yourself as an individual. Self-awareness and self-reflection are key if you want to be an empathetic and confident leader. Once you know what it means to be you, it will be easier for your direct reports and colleagues to figure out how they relate their own strengths and weaknesses with yours. They must be able to see how their work contributes to the whole and feel valued as members of a team.
What makes a good engineering manager at Taxdoo? With our Taxdoo values and culture in mind, here are some tips on becoming and excelling as an engineering manager.
Motivation
One of the most important things you can do to become an engineering manager is to keep yourself motivated. And understand what motivates you. Motivation is a mindset that keeps you one step ahead of your competition and allows you to achieve more than what would seem initially possible.
In order for motivation to have an effect, the first thing to do is to make sure that there is a clear goal or set of goals that need to be accomplished. From there on, it’s easy. Make a plan with small actionable steps that are part of the overall goal. Once something gets accomplished, ticking it off marks an incremental step toward completing your goal. Not only does it feel good to work in this way, but it also strengthens the resolve of yourself and others as progress is tangible and constant.
Empowering Others to do their Best Work
A good engineering manager knows that empowering their team is their primary role.
Good leaders celebrate and hone the unique capabilities and personalities of their direct reports and strive to support each individual to grow whilst delivering business value. By trusting their team to self-organize with day-to-day operational tasks (such as attending stand-up or organizing code reviews), an engineering manager can then focus on coaching engineers and inspiring them to do their best work by gradually assigning them more significant pieces of work which challenge them and with guidance, push them out of their comfort zone.
Feedback is key
Constructive feedback is key to the success of your team. It’s about giving your team members the information and guidance they need so they can succeed, but also being humble enough to accept feedback from your team or your own manager. At Taxdoo, our culture fosters frequent feedback and this is one of the things our future engineering managers need to encourage as a constant.
To us, feedback is the cornerstone to creating a culture where mistakes are embraced and a growth mindset is celebrated. And encouraging our engineers to be brave enough to take action rather than avoid risk. It means setting up systems for continuous improvement and feedback loops between leadership and employees so that everyone knows what’s expected of them in each role on the team, or across teams. If you’d like to find out how we embed this from day one, check out our Onboarding blog post.
Celebrate mistakes
It’s important to remember that mistakes are encouraged when you’re an engineering manager. Think of it as an opportunity to learn and grow. No one’s perfect, so why should you or anyone else be punished for it?
In an engineering setting, we all know that the business of shipping code can be a risky business. Deployment failed? Major outage? Stay calm and fix it. Then assemble your team for a blameless incident post-mortem. Take the lead and share the results with the engineering department and the rest of the business. No one is more stressed than your engineers when something goes wrong; it’s your role as a manager to steady the ship, investigate what happened, support the solution, and show solidarity with your team in front of the entire business. This fosters psychological safety, which will unite your team when times get tough.
At the end of the day, we work in tech, not the emergency room.
Communication solves everything
Communication is so important when building a team. Something that people often miss though is that communication isn’t just about talking; it’s also about listening.
Communication in the workplace is essential because it facilitates collaboration in an environment that brings a diverse range of people together and helps them to harness their unique abilities to achieve success on projects and tasks that are important to the company. Collaboration is something we cherish deeply at Taxdoo. We believe that it allows everyone to simultaneously experience how their work impacts other teams, and how other teams’ work impacts their own. This builds awareness and makes the path to success smoother than ever.
Everyday is a school day
It’s important to keep learning, especially in a fast-paced environment like ours. You can learn from your team, and they can learn from you. Everyone has different strengths and weaknesses, so it’s best to understand each other before jumping into a critical piece of work.
For example one person might be great at writing code but not so great at understanding what their teammates are talking about; another person may have a very strong background in programming but not so much experience with business management.
We could go on and on, but the point here is that everyone has something unique to offer—and those differences should be valued as much as their similarities!
Learning is a lifelong process. You can’t stop learning and you never have to stop learning. The best thing about it is that it’s not just about reading, watching, or listening; it’s also about asking questions.
Learning isn’t something that happens once in your career—it’s a process of trial and error. Try new things and fail at them until you figure out why they didn’t work for you before giving up. Alternatively, you can try again with another approach or strategy to see if that makes sense for you as an individual, team member, and employee at Taxdoo.
At the end of the day, what you do matters more than what you say
As a new leader, you’ll face challenges that will push your boundaries and stretch your skills. You’ll have to learn new things and put them into practice, including how to empower effectively, motivate others, and communicate with the people on your team. Becoming a good leader is hard work.
If you’re interested in having a role that enables you to make an impact and grow as an individual as well as part of an organization, there’s no better time than now.
While becoming an engineering manager isn’t always easy, it’s definitely rewarding. The benefits of leadership are endless, and you’ll be glad you took this step when you see how much your team grows.
This article is written by the engineering managers at Taxdoo.
André Kowalewski, Katarina Lang, Zeynal Zeynalov, Maria Canero, Alexander Klein and Gabriel Guimaraes.
Hi, I’m Hendrik, a JavaScript enthusiast and Engineering Manager at Taxdoo. Today I wanted to take you on a journey of exploring what technical debt is and how we deal with it here at Taxdoo.
Working with Engineers you probably heard the term “Technical Debt“. But what is this “debt” Engineers keep referring to? Just an excuse to push features further out? Join us on a journey to understand what Technical Debt has to do with doing your dishes and paying back your student loans.
What is debt?
> Something that is owed
In its most basic form, Debt is simply something that is owed to another. The most common debts we owe are:
– Money 💸, that we owe to a bank or student loan.
– A favor 🤝, that I might owe to a friend who helped us move apartments.
This is what we most often think about when the word “Debt” is mentioned. But there is another kind of Debt that we all face in our daily lives. I like to call it “Dishes Debt“.
Why doing your dishes is important
Most of us use our kitchens every day. We go in, prepare our food, and then leave. One might say:
> Your kitchen provides value to our lives by allowing us to cook with all the appliances we need.
However, this ‘value-creation process of cooking food always leaves behind dishes that we have to wash before more food can be prepared. As a fan of one-pot meals myself, I know my big pot of pasta requires washing right after I finish it.
This is how I came up with the term dishes debt. Dishes debt is exactly that moment in time when I realize I have to do my dishes first, and only then can I allow the kitchen to deliver its core value of allowing me to cook my food.
> Occasionally the value-creating process of cooking produces Dishes Debt that has to be paid down before more value (food) can be created.
We find the same kind of principle at work in Engineering. We call it technical debt.
Technical Debt
In Engineering we as Engineers:
> Provide value to our customers by coding features for our products.
As engineers, it is our responsibility (and passion!) to provide value to our customers by coding the right features for the products we are working on. Similarly to how the kitchen provides value when it comes to food preparation, we engineer products that make our users’ workflow a pleasant and easier-than-ever experience. Of course, as with every process, engineering also leaves behind some byproducts that need to be taken care of before we can create more value.
> Occasionally the value-creating process of coding produces debt that has to be paid down before more value (features) can be created.
Remember the one-pot pasta dish I was talking about? Well, in engineering terms, this is her again.
That being said, the point where we have to do some coding before implementing new features, we call Technical Debt. The only difference here is that as your dishes pile up next to your sink, you can see them, count them, and make a plan of action. Technical debt, on the other hand, is not as tangible, which is why it takes some extra effort from our side to pay it back.
Before we continue to see how we can implement the best strategies for dealing with technical debt, let’s first learn what types of it exist out there.
Types of Technical Debt
At Taxdoo, we divide technical debt into three categories: deliberate, architectural, and entropy. Let’s dissect each.
Deliberate Technical Debt
Deliberate technical debt is one we take on knowingly. We either see it coming intuitively, or we’ve done something similar in the past where debt arose and we can just feel it in our guts. A sentence you hear us say most when deliberate technical debt is involved is “We need to deliver this now”. For the sake of making a deadline, we then cut corners.
> We know there are problems but we accept them to deliver something on time.
These problems we accept or corners we cut come in different shapes. They include “hardcoding” connections, maybe for now you can only filter a table of offices by a hardcoded list of cities while we know that in the future that list of possible filters should come from the list of all offices.
Architectural Technical Debt
In engineering, managing expectations is no easy task. Even more difficult is when we have to accommodate them. This is when architectural technical debt steps are the work we need to do to accommodate these ever-changing expectations.
> The system was not built to support this.
Whether we didn’t know about an important use case before commencing work, our original assumptions were wrong, or our company pivoted, all of a sudden our work becomes more difficult. Now, with all the other things we need to do, we also have to do some refactoring. Often we find ourselves asking the question: What do we need to change in the way we support the current use case to support the new use case?
This type of Technical Debt often arises in the conflict of creating a “solves all problems” vs “solves exactly our problem” solution. A highly-adaptable product might take a bit more time now but pays back with its flexibility later. Something more targeted is faster to accomplish now but will require a lot more work to become adaptable later.
Entropy Technical Debt
Entropy is the fact that:
> Over time the quality of everything you don’t consciously maintain deteriorates.
So many things add entropy to the work of engineers that it’s difficult to even start listing. New team members cannot know the full history of our code, for example, and will naturally work differently. Architecture and requirements change, and sometimes already utilized technology becomes outdated. It’s part of the game, and entropy technical debt is at exactly this intersection of time and relevance.
Washing the dirty dishes
Now that we can understand the different types of technical debts, it’s time to learn how to tackle them. We will do this by once again looking at the dishes debt and how we often overcome it.
Some of us (and I might be included in that) clean just what they need. Like my pot for porridge that I often wash in the morning to make today’s batch.
A trained chef-turned-programmer I used to work with was quite passionate about this one. He taught me that no professional kitchen could run if it didn’t take care of the dishes while cooking was still in progress.
Habits are great, they become involuntary actions that we don’t think about, we just do. And doing dishes every day makes sure we clean small batches that are easy to handle, enabling us to use all our dishes every day.
Sometimes there is nothing else you can do. For days you didn’t pay down your dishes debt and now you can’t see the countertop. You’ve got to put in that hour of effort and do everything now.
Maybe you can even find a way to not have as much dishes debt. Ordering take-out every day could be an option but it produces a lot of waste and is much more expensive. An innovation could be a dishwasher: it’s a bigger, one-time investment but now you don’t have to do the washing anymore, and it can handle a lot in one go.
Technical Debt strategies
The best part is that we can translate our dishes’ debt strategies to pay down our technical ones. Let’s change up a few words together, shall we?
Picture it: there is a new feature coming in but some technical debt is holding us back. No other choice but to fix that first. Only if we had fixed it on time… Now our system wouldn’t be so hard to maintain, estimates wouldn’t have blown up more, and Software Engineers would be at least a tad happier. What a dream.
In Software Engineering we often employ something we call code reviews. In a Code Review, peers check each other’s work and give ideas on what could be improved. Apart from being peer-to-peer learning opportunities, code reviews are also a natural place to catch Technical Debt before it makes its way into our main codebase.
Another great example of doing dishes while you code is often referred to as “scout mentality” – always leave a piece of code you touch cleaner than it was before. To reflect this, some teams always add a fixed percentage of “scoute time” to their estimates.
We at Taxdoo allocate 10% of our time towards technical innovation and learning. This time-budget is up to Engineers to spend.
And for the other 90% of our time, we make sure to prioritize both feature improvements and technical work.
Sometimes you either need to fix your technical debt now because your systems are failing, or there is no feature pressure right now, so your team can take their time to perfect the technical implementation.
For us this sometimes takes the form of taking a whole sprint just dedicated to fixing and improving things.
A great way out of technical debt is to solve the old problem in a new way. If updating the system always takes longer, maybe you can build a configurable system that can get adopted faster and erase the existing technical debt, thus making Engineers happy.
We drive innovation both as part of feature work and in the 10% innovation and learning time that our Engineers get. It makes me extremely happy to say that it has resulted in amazing improvements!
Preventing technical debt
Although we apply the above-mentioned methods to reduce our technical debt, there still are some residues. There probably always will be. This doesn’t mean that we still can’t take more measures to prevent some of this debt from arising, though.
The right tools can already catch some of the debt in the act. Using TypeScript over JavaScript, for example, will help you detect some of those runtime errors during the stages of development. Observability will make you aware of problems while they are still easy to fix. What a relief!
Realizing that debt is something we are likely to incur enables us to consciously take on debt where it helps us to move the business forward and turn it into a part of our prioritization.
Final thoughts
Writing code is a complex problem. Software Engineers constantly need to decide on trade-offs between “thinking about everything up front” – so that we will need no adoptions later – and “building what is needed right now” – so that we are fast. Both are right at times, largely depending on how easy the system is to change later.
When considering technical debt in the context of planning time for implementation we have only two options: either to invest time in preventing debt to arise, or invest time later to pay down the debt created. In either scenario, we need to look at our priorities and make sure we are making an informed decision.
But, and it’s a big but, if you ask me, it’s always worth investing in debt prevention whilst paying down your current debt. Doing this makes sure that your company can react to sudden market changes and not be held back by unfinished business. And we all know it: in a sea full of fish, being quick to react is the most important factor that sets you apart from the rest.