The Employee-Company triangle

Sandor Dargo - Mar 23 '22 - - Dev Community

After having read the title, you must think I forgot something. How can two vertices (the employee and the company) form a triangle?

The answer is simple, the employee takes up two of the three vertices!

But where does this triangle come from?

In my first corporate job, I was a database administrator. It became clear to me quite quickly that it's not the job that I'd like to do in the long run. Or at least not in a corporation.

As I explained in the first chapter of The Seniority Trap, corporations are wonderful places to try different fields. They give you the chance to find what you're interested in without risking changing jobs.

I was working for an oil major and my love towards IT and geography seemed to show a way towards developing solutions that help oil&gas upstream engineers to identify new underground resources.

There were two problems:

  • I didn't have the right qualifications
  • there was no such position in my country

Still, it was a romantic long-term plan for a 27-year-old junior.

My manager sat down with me discussing how to think about long-term plans and our place in a corporation. After a few minutes, he drew a diagram on a whiteboard.

Employee Company triangle

The three corners of the triangle

On the top, you have the business needs. It stands on the two shoulders of the employee. One represents employees' wants and the other symbolizes capabilities.

They are all equally important.

Business needs

The business has its own needs. You cannot directly change them as an employee. You might be able to influence them, but rarely in the short run. Let's say that your team owns an application written in Java. The main focus of the team is on Python. The old application must be significantly modified due to changed security requirements and it still has to be maintained for the next two years. There is no way to decommission or replace it before.

You might have an influence on the future directions, you can propose what language or framework should be used for the re-engineered solution, but the current business needs are not going away.

You cannot change them. Someone will have to do the job.

Maybe not you, but someone will have to.

Employee capabilities

Then there are the capabilities of the employee. It's important to have the right person for the right job. The management cannot simply put a Python developer in front of a complex Spring-based project and tell him you go and fix it. (No, it's not about Python and Java. It could be about any two distinct technology or just in the opposite direction.)

If the business needs fast results, it's important to match the needs with the right skills, with the right capabilities as soon as possible.

Employee's wants

Last, but not least, you need to consider what you, what the employee wants. Developers are not slaves, no matter what Yegor says. We often know what we want and we want that bad. The importance of this point might change from person to person or even from market situation to market situation, but it will be always there.

You might find people who have very little preference because they want to be a generalist so much, or because they are so well-paid that they don't care (it's quite unlikely though).

Also, in a market where jobs are scarce, employees' wants might not be as important as they are in these days when there are tons of opportunities for senior people.

What if one gets ignored

In the short term, you might compromise on one or the other pillars, but it will have consequences. Whichever factors you ignore, it cannot work in the long run.

Let's go through the vertices once again. But now follow the opposite order compared to the previous section and see what happens when one - or more - of them gets ignored.

Employee's wants

If what you want gets trumped by the business needs and maybe by your capabilities, then you will soon feel resentment and frustration.

If you have the knowledge on a certain topic that others don't have in the team, you will become the go-to person. After all, it makes sense. You know it! As such, you will basically have to work on any related topic whenever there is a business need.

Even if that knowledge is not something you would want to capitalize on.

At the moment it feels reasonable from the company perspective to move you on the project or just to assign you some side roles. Still, it might be harmful even in the short term.

I'm not saying that you always have to say no, but you must be very clear about your priorities even if you are fine with working on a project. If it's really against your will, but you like the team, you like the corporation, try to negotiate.

You could accept it on a temporary basis until the management finds and trains someone else who is interested and could take over.

But this requires trust.

If your management had already committed to such actions and they didn't manage to live up to the expectation, why would you risk now?

If your management fails to keep their promises, you should either reject the project or if you cannot do that, start looking for another team or job.

It's better than becoming angry and resentful and hate every single morning.

Employee's skills

What if the will and interest is there, just like the business needs but you lack the right skills?

This is a better situation than the previous one.

Where there is a will there is a way as the proverb says.

You'll find a way to learn what you have to learn.

But it's to be understood that when you don't have the necessary skills in place, both parties take on some risks and additional efforts.

I think it's fair to dedicate a bit of your own time too. I say it as someone who is clearly against unpaid overtime. But if there is a need for someone to do some Svelte and you volunteer while admitting you have never used it, it's fair to practice it a bit in your own time too.

Note that I do not recommend working extra hours on your new work project, I'm actually against that. First, it would qualify as unpaid overtime. Second, when you work on a project you focus on delivering it.

Learn instead!

Build some pet projects, complete some code katas, whatever. Focus on the learning and experimenting part so that at work you can focus more on delivering.

As such, you offer your own resources to share a bit of the risk.

The situation is different if there is only a business need, but you don't have either the skills or the will.

In that case, you should really ask your manager what the heck they are doing. I've heard the different answers from my managers or from others facing similar situations

  • "We think that it'll be good for your career!" They might be right, they might be not. Many managers like to think they know it better. And sometimes they do. The role of a people manager includes career development, career coaching. Probably they have seen more than you. So don't just assume that they are fools, engage in the discussion. Try to understand their point. You might find out that you actually want the proposed change. But beware also that your manager might only project his own biases, his own interests. Especially when you have a relatively young and inexperienced manager. If you know exactly what you want, if you have a career plan, don't be afraid of politely but firmly saying no.
  • "We need someone to cover this and we thought you could help us out!" It's probably an honest and fair point. Don't be shy to say that you'd prefer not to do it. Ask if they considered someone else. It might be the case that they actually asked everyone but nobody wanted to take on the role. Someone still has to do and they randomly picked you. Such things can happen. Negotiate for a deadline until they must get someone qualified for the job. If you really despise it, say no. After all, there are other people in the team too.

Business need

What if you have some skills that you either picked up on the side or that you brought from your previous job and you even want to use them? So far so good, but imagine that there is no immediate business need!

Too bad!

Most probably that's it, you won't be able to use those skills.

Let's say you learn about some graph database on the side, you learnt using it well and you'd like to use your fresh skills on the job. But your team uses a different kind of database.

What can you do?

You can definitely organize some knowledge sharing sessions where you can introduce the team to concepts and techniques you learned.

You might even use it for some side or innovation projects, but most likely it will stop right there. Don't expect much more. If you are a master of driving technical changes and you get lucky, maybe... maybe you will introduce a business need matching your skills... But I wouldn't even count on that.

Most probably if you have the skills but there is no business need you'll have to change teams or maybe even jobs. But before doing that make sure that it's not just a fad on your side. Probably you could contribute to some open-source projects so that you can experiment with your skills in a real environment. This, of course, applies only if you never worked with that tech.

Conclusion

In this article, we discussed how your position as an employee relies on three pillars that are equally considered. Your skills, your needs and that of the business.

We saw that it's possible that one or two of them will be ignored in the short run. But if it lasts long enough someone will have to pay a big price and that's usually the employee. If you don't do what you want, you'll be either unhappy or you simply leave (that's the better option). If the business needs are not respected... well... probably they will draw a quick conclusion which in the end will hurt the employee.

Always negotiate for a position that respects all the three pillars if you want a long-lasting and win-win partnership with your management.

Connect deeper

If you liked this article, please

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .