Many tenure engineers get frustrated with various small things if they have stayed in the same team or done the same job for a long time. They start getting annoyed by new people bringing not-so-new ideas that were already proved wrong two years ago. They had seen the projects put into the trash and, after three years, brought up like they were brand-new innovative ideas. They had been frustrated and demotivated and started creating a lot of friction in those projects. Or they are left behind and moved to another team because they create conflicts. The whole situation results in lost knowledge and the organization making the same mistakes again. I was one of them, and I knew I was never alone. Now, I want to talk about the case with Annoying Tenure Engineers™️.
These engineers are annoyed because they have seen various things: they have experienced how a system is developed, and maintained, witnessed the (good and bad) decisions made, contributed to them, and how the system evolved to the point that it accumulated tech debt and accidental complexity and needed to be rewritten, but there was no time. They have seen projects succeed, fail, evolve, and pivot. Within the same organization, they have seen good leaders who elevated everyone and bad ones who looked like good leaders but pulled everybody down. They worked with people who were frickin’ smart yet made such mistakes because they couldn’t see why something was built in a certain way in the first place.
You name it.
They have seen a lot.
They are valuable assets because of their accumulated historical and domain knowledge. They are long-time supporters of the mission. They are the sense-makers and challengers for new decisions. Although organizations aim to have more tenures—having these people is a tremendous asset to the company—they can quickly become drawbacks because they have seen a lot.
They can become blockers of innovation. If they just float around the same area without clear priorities, they prevent new things from developing and seeing the light. If you approach them to get their idea or learn why a particular feature of the product is built that way, they surface all the accumulated problems to your face and demotivate you. They suck the energy out of you by bringing up thousands of issues you couldn’t foresee.
Yes, you still learn why something has been built that way, but if these tenures are advocates for staying still instead of being consultants for sensible development, you have a hard time changing them. Once tenures are in their comfort zone, getting them out is challenging. Moreover, when they get out, it is often not easy for them to let old things go.
“I can’t stay silent and ignore what’s happening when people do all that stupid stuff to the services I designed and developed for years. I created them; these applications are my babies.”
— A random annoying tenure engineer.
As their strong ownership attitude was appreciated for a very long time, it is challenging for annoying tenure engineers to let things go. That reinforced ownership easily becomes a pain for everyone. They frustrate everyone around them and cause others to leave the company. Or these tenures can also abandon ship and move on to their next job in another company when nobody listens to them anymore.
Of course, not all tenure engineers are like that. Some will seek change and be open to letting others drive the ship they have built. When they want to change their position, team, or role, that’s a great advantage for the company to keep their employees and leverage their knowledge in another functionality. This cross-boundary knowledge transfer can increase innovation and produce incredible results that nobody could think of. And that’s the best scenario for tenures to become Counsel Tenure Engineers™️.
Counsel Tenure Engineers are like your best lawyers. They tell you exactly what would work and what wouldn’t while doing everything they can to win your case. They follow your dreams while pulling your feet to the ground.
Leading tenures through change is a big challenge. When they say, “It won’t work; we have tried that before,” or “Why are we going around the same things again that we did two years ago?” you, as their leader, have to stop and turn things around. You must show how things have changed since then and why you’re not in the same environment anymore. You must encourage them to see the holistic picture. Instead of coaching them with “give it one more try,” you should approach with “let’s use your knowledge and experience and figure out how to make it successful this time.”
Organizations must turn these engineers from advocates of endless stability to consultants for experimentation and counsels of innovation. Their accumulated knowledge must be extracted and used in cross-border domains. If the documentation is not that great (like most organizations), these people are the knowledge your organization has, and you have to treat them as historical non-fiction books, not historical novels; read them to learn what happened instead of getting stuck in a story.
If these engineers changed their domains or moved to other projects, make them consultants to their old domain. Draw clear boundaries that the decisions are not on these tenure engineers anymore, and they are sitting in a consultant seat. You want their ownership attitude on the mission, not the services they have built.
As a leader, it’s on you to make annoying tenures counsel tenures. If you don’t, they will be one of the most detrimental people to your organization, and you’ll have to make decisions that nobody will like.
