One of the benefits of working in product companies is watching your product evolve, nevertheless, that road won’t be only a matter of innovation but avoid things turning into impossible to mature legacy systems.

One of my favorite references to the term I came across, which also motivated me to write about this, is from a book called “Kill it with fire” which I truly recommend.

“To understand legacy systems, you have to be able to define how the initial requirements were determined. You have to excavate an entire thought process and figure out what the trade-offs look like now that the options are different. Simply being old is not enough to make something legacy.”

The reality of the moment something was created doesn’t mean we have to carry on all the decisions when making a refactor or an upgrade, as the definition says tradeoffs might take a different path depending on newer contexts.

Modernizing technology for the sake of using something newer can be mistakenly confused as a way of dealing with legacy systems.

Defining which part of our solution needs to be evolved is where the puzzle is. Switching product A to a newer technology doesn’t mean it will be easy to adapt to the new reality.

I have seen this situation happening in places where a framework is introduced as a result of a partnership or just because it’s trending.

Although it can have drawbacks, using a well-known framework can also have benefits, as, it will make it easier to get new people on board. Imagine that if we have to still provide support to an old system that developers are unlikely to find, we might end up blocked.

As part of the previous point, we need to identify and scope as small as possible which is the part that needs to modernize.

Things like refactors and revisiting past decisions, and old vs new requirements can become crucial in the way we define the parts that are considered legacy against just old but functional.

Having deprecation policies will help us in regard to communication with our customers or consumers. It will make innovation and migration a lot easier to handle.

We have to make people aware of the change by explaining, not turning this into a revolutionary change, provide context and data on which we based our decisions.

There was a time I worked on a project that involved convincing people to move to a mono-repo setup and it was quite important to emphasize the communication of it, explaining the reasons behind the change, in order to have everyone onboard by understanding the reasons and not only the technology implications.

Communication is key, in preaching the idea and the people that might be affected by any change we would like to introduce. Speaking a common language to convince stakeholders what needs to be done, will play an important role in the whole process.

How often have you heard the phrase: “it has to work like this”?

In situations like this, where requirements are not set, and by looking at the code it’s tricky to abstract the decisions that were made while that was developed.

Moreover, as we cannot understand the context and historical decisions, is quite easy to drag errors or mistakes that were made back then and pull them into the new solution.

After going through this situation a few times, I try to remind myself to write conclusions and decisions that I have made when developing something. Rather than putting documentation that can be seen in the code, I focus on context. So that if someone is reading my code plus reads the story I tell, it will be much easier to avoid mistakes.

The same concept applies when submitting solutions for take-home type of code challenges in technical interviews. It will help the interviewer to understand my way of thinking and the tradeoffs I have to consider while thinking about the future, which could be completely wrong. But in a situation where the future is unknown and requirements are vague, it’s completely valid.

One of the things that people tend to forget when dealing with this situation is institutional knowledge (also known as institutional memory), and how tight these decisions of evolving a legacy are to the process and the culture of the company.

Having people who are long committed to the company culture, and have been working there for several years in multiple positions, will help to move the process easier.

As you can imagine in places with low retention and high attrition, having people leaving constantly will cause the institutional knowledge to be gone. Thus, having discussions or defining processes to move legacy systems would be more difficult to structure and move forward.

A bit related to institutional knowledge, there are cases where evolving something legacy affects the shape of the organization as well.

Coupled software tends to be by definition, more complex to maintain, difficult to test and scale, and hard to adapt to new situations, among other technical advantages, but from a business and strategical perspective keeping the parts decoupled can benefit from outsourcing part of our solution, to name one example.

Let's imagine we have an e-commerce website, and we have our custom in-house logging system if that was coupled or de-coupled, it can make the transition to external solutions simpler or more complex.

As an engineer, if I have to pick something that I always struggle with, and seems like a never-ending problem, it's worrying too much upfront about an issue that hasn't happened yet, and probably never will.

In general, given the number of unknowns and uncertainty that life has, preparing ourselves and worrying about what may happen in the future is a natural reaction of our body. And that can have multiple implications in our day to day as engineers.

Generally, as we can’t predict the future, we might end up in situations where we are working on something that might have no importance in the future, causing our time management fail.

In my experience, breaks or coworkers are the ones who help me get out of those situations. Or at least they force me to tweak my time-investing strategy.

Although context switching might have the opposite effect and makes me lose concentration, it encourages me to have fresh starts and empowers me to recap and look at what is happening from a different perspective.

Following techniques such as Pomodoro often helps me prevent this from happening. A technique, which basically consists of doing 25 minutes of work, with a 5-minute break. But most importantly, I turn off notifications to make those workspaces more productive.

I must say that I don’t use any tool or software for time tracking. Being aware of it already does the trick for me, since sometimes 25 minutes is not enough to finish something that I can continue later.

On the one hand, being meticulous with details is positive, since things may seem simple, but in reality, the details are complicated and likely to cause problems. On the other hand,  it could make us lose focus on the big picture. With time and experience, we will eventually find the right balance.

Like I said before, I tend to worry about details and possible scenarios that may or may not happen in the future beforehand.

How many times have you, as a team or individual, invested a lot of time on a specific problem or edge case that ended up not being a problem?

An example that I always recall when discussing this matter, was that time when I spent a week trying to figure out a CSS issue on Internet Explorer. And, over a cup of coffee, some stakeholders noticed my demotivation and told me that for that particular browser I shouldn't worry too much, as the analytics for that browser were lower than our official threshold.

Or even from another angle, sometimes I feel that in previous experiences I have foreseen performance issues because I was assuming how the users were going to use part of an application.

In both cases, the investment of time and effort didn’t pay off, and I could have used that time to develop other meaningful tasks.

These situations are not only discouraging in terms of technicalities, but also demotivating, as we realized too late in the process that what we have done in the last few days or hours, has a really low impact.

I also attribute this to the fact that we just like to be challenged, and the feeling we get after solving a complex is hard to explain, but maybe in the environment we are in and from a business point of view it’s meaningless.

In a nutshell, let issues become problems, and look for real evidence instead of gut feelings or making the wrong assumptions.

Did anyone give us feedback about that particular issue? Is it really an issue? Is it a blocker? Try to get the full context.

Speaking of getting the real context before jumping right into it, I remember one Christmas Eve I was on-call and got a phone call about a service not working. I spent 2 hours fixing the issue with the other person, and when I asked the counterpart to do a verification check, he sent me a QA link.

As you can imagine, that was the exact moment when I realized that it wasn’t a real issue and it was only affecting the QA or staging environment for that particular person.

Hope this doesn’t sound like I am against preventing, just being aware that sometimes we go too far down the rabbit hole.

As we progress, we begin to realize how important meetings or sync ups events are (whether they are synchronous or asynchronous) to align expectations and learn more about the business plan. As a result, it will give us the ability to make better decisions in the long run.

Iterations and metrics also play an important role here, as those two factors can be deterministic to define when, how, and where should we invest our time.

Lean on stakeholders or co-workers with higher views such as Product Managers, Engineer Managers, Project Managers, etc, when in doubt about something. Being autonomous is great, but it doesn’t apply to all scenarios.

In simple words, validate ideas up front before making big commitments.

Being preventive helps us prepare for the future, but if we turn that into a waterfall, we might be holding ourselves to deliver faster in a world without patience.

So, in case you spot a potential issue, simply save it to investigate later on when there’s less of a rush. And most importantly, avoid getting caught up in the scope creep of a task.

When we start growing and moving through the laddering of promotions or switching teams, we start experiencing different types of leadership from diverse perspectives.

When referring to leadership, every company or I dare to say even teams within the same company, define a level of accountability and delegation, that suits them better.

Rarely appreciated, this plays an important role when defining responsibilities. And, I believe it’s quite important to define and draw a line between accountability and delegation.

Wait! Before we get immersed in the topic, let me try to clarify things a bit.

In my appreciation the one in the leadership team is the one accountable, responsible, and who owns the problem (or whatever other subject), meaning that if something unexpected happens, although it’s a team responsibility, it will be mostly on that person's back.

Once that’s defined, in bigger groups where responsibility is shared, we would have some level of delegation depending on how flat the company/team is, just to name one possibility. This means that, for example, in flatter companies, responsibility for decision-making, the team is expected to get more involved.

But where do we draw the limit between delegation and accountability? Who should be the one making the decisions? Do I trust the team to leave the freedom to make decisions to something that I am accountable for? Is it only a matter of trust and experience? is it just a reflection of the sense of having control? If we go to the other extreme does it mean we are gatekeeping information?

As you can see, things are starting to get mixed up, that’s what I regularly see on teams when responsibility is shared, and this definition is not discussed or clarified beforehand, in some sort of team agreement or even an informal discussion.

So let’s rephrase and put it in one sentence, although the responsibility is shared, there will be always someone accountable in the laddering of management and leads if something happens, even if that needs to bubble up to the CEO.

If we go back in time and think about the old days, we might probably end up in situations where the hierarchy was defined in stone and hardly challenged by others.

Times when speaking out to managers, or being called “bosses” back then, were regularly seen as lack of proffesionalism. Or maybe, we just thought it was impolite, as I, at least, tended to believe they were not interested in knowing about my feelings or opinions.

Fortunately, management has evolved into something different, and we now can find places with the intention to follow other ideas. Yet not ideal, but better than the old days.

What I am referring to as the new management is where team members feel more engaged, empowered, and take responsibility for success as a group effort. In a team where suggestions matters, responsibilities fluctuate across the team and communication flows up and down with not much restriction or friction.

There are, of course, levels of interpretation, on how deep we want to go with delegation. We can ask for feedback and then the leaders will decide, or just let the team decide and the leader just agrees on it, just to name two extremes. That is exactly the level of delegation that for me needs to be stated somewhere, whether it's implicit or explicit, to avoid misunderstandings in the responsibilities scheme.

Usually, failures are probably the biggest trigger that forced us to think and set up a balance in the delegation levels we have during a post-mortem analysis.

Situations that by setting and preparing ourselves in advance could be avoided.

From another angle, the premise "we are in this together", easy to break, can fall apart when recognition comes into the picture. Who’s going to take the credit? Ideally, this shouldn't be the most important matter, but it can break the trust and commitment of the team if only the one accountable takes the prize.

Things are not always that simple, another problem I have seen with delegation is that leaders or managers, put pressure on the team, with the excuse of “we are flexible and modern”, just to prevent them from taking decisions and being exposed or finger-pointed by others. Which slowly turns into a lack of alignment, trust, commitment, etc.

Eventually, when you become a leader or manager (you name it), what took you there should be your mantra, not suddenly changing your spectrum and becoming what you normally hate.

As a side note, I have noticed that in the IT world most managers come from engineering backgrounds. I am not saying that they don’t have the skills but it’s funny how they can change career paths and become a senior manager in 1 year, and in most cases, that change is based on wishes over the skill set, myself included.

To highlight this topic, I sometimes use the word meritocracy to define that path we have to discover, but as it’s currently misused, especially in politics, I heard a replacement in a song that says that smooth seas never made a good captain which seems to emphasise how I experience things in a more elegant way.

The confusion between accountability and delegation

Within that transformation, there are certain misunderstandings that can cause a team to fight for the wrong problems or get lost in the processes.

We can all agree that there are different types of managers. But just making one segmentation between the ones that like to have everything under control and the ones who like to delegate most of their work, there is a balance that needs to be defined.

Ownership in the sense of I take responsibility, I trust you to move this forward, but I can't expose or blame you if in the end this never gets done.

It’s the manager/leader's responsibility to make that happen, so that is exactly the point where I see the gap between accountability and ownership. I do agree that managing and measuring success as a manager is difficult. But as it’s a matter of delegation, it doesn’t mean it’s your responsibility now, and I (as manager) am out of the picture.

Enough about exposing the issues, what can we do?

If I were to become an Engineer Manager now, I think I just know what I wouldn’t do. I only have a little experience as a Product Manager, but back then although there was a lot of stakeholder management, I had no reporting lines coming to me.

Even considering that I just came back to coding, I do see myself in people management over something purely technical. Or at least that is what I have been told by former colleagues and my own vision and preference.

Having said that, what would I do if I get into this situation?

Build an environment where there’s no such thing as pressure or rush. I know that's difficult but If I can absorb that and abstract it from the team, I will.

No room for egos. A place where people feel comfortable sharing experiences and opinions. Where introverts are not afraid about sharing, and the ones with imposter syndrome can open up.

Transparency overall. When I know what to do or not, whether I am lost or not, the team will know about my feelings, and if I ever feel overwhelmed or incapable of playing the role, I will be the first one to admit it.

Not playing the blaming game, whether we win or lose, we are a unit, but if something goes wrong or expectations are not met, I will be the one to blame and take action to make things better.

If I ever have a strong opinion about someone’s career path I would ask in advance if they are looking for ideas or a piece of advice from me.

I would define expectations, and responsibilities by roles together with the team, and reflects on them from time to time.

Unfortunately, as with most of the human problems in industry organizations’ schemes, there’s no such guide we can follow. I based my recommendation on my experience from the other side of the fence.

But, just asking ourselves and clarifying the questions I have shared across the article, could lead to a better understanding of scoping the responsibilities accordingly within our environment.

Mixing leadership, delegation, and accountability

Hola, welcome to my safe space!

Latest articles

Evolving the Legacy

Worrying too much in advance

Mixing leadership, delegation, and accountability