I've participated in a framework migration at every company I've worked:
*Alianza is a special case because that migration never actually started and that's part of what I want to talk about today. We'll come back to this later.
Luckily, every framework migration I've participated in was ultimately a success. They each had their own level of challenge and impact on development productivity (and ultimately the user), but ultimately, the migration was a success.
But I don't want to limit my thoughts to things as big as framework migrations. What I want to talk about is more general. It's truly:
How to convince "the business folks" to let you do what you want.
In a functional company, the company's mission is paramount. Everything that happens should push that mission forward. The mission could be something boring like "make us all rich" (it seems that many companies have this as the primary mission even if it's unstated), interesting like "democratize financial services," or inspiring like "accelerate the world's transition to sustainable energy."
Before you're even hired on at the company, you should ensure that you personally are aligned with the mission of the company. If you aren't (and the company is a functional one), then you'll struggle with this next part and you'll not enjoy your time at the company very much. (And if the company is not a functional one then you'll probably not be happy either).
For the rest of the blog post, we'll assume that the company and its employees are focused on the mission of the company. If they aren't, then you have bigger problems... I do address this below though, so continue reading.
Also, I'm going to assume that the person who decides your task priorities (and therefore the person to convince) is the product manager. Feel free to swap this for whoever the person (or people) in your situation has that responsibility.
Let's assume you want to make an investment into your codebase. This could be anything:
You probably come up with these possibilities on a daily basis. It's unlikely that the product managers will bring these things to your sprint planning meetings. Why is that?
The thing those investments share is that they have an indirect impact on the mission of the company. Product managers are focused on the product itself and how it's accomplishing the mission. This is normally seen from the outside with a look at capabilities, features, and customer requests. They will occasionally notice the side-effects of some of these needs: slow dev velocity, frequent bugs, performance issues. But in my experience, more often they assume that "this is just the way it is" and they'll focus on giving you "user stories" which are focused on features that will directly further the mission of the company.
In your mind, you see these platform deficiencies and recognize how they are detracting from your company's ability to accomplish its mission. However, you may struggle to bring it up because you feel like you're swimming in custom requests and can't ever get around to these investments. Maybe you feel like deciding what to do with your time is not "your job."
But your job isn't to turn user stories into code. The company's mission is your job. The company has a mission. Everyone at the company is hired to push that mission forward, whether they be in Quality Assurance, Sales, Custodial, Marketing, Finance, Engineering, or Management. You're not a software engineer hired to code. You're a human hired to push their mission forward. It just so happens that you are a human with coding skills and during the hiring process, they recognized that those coding skills could help them in their mission.
Do you feel like these problems make an impact on your ability (or the ability of others) to push the mission forward? Do you really feel like these things you're thinking of are more important to the success of the company mission than the features you're building? How can you be sure? They make an indirect impact at best (and no impact at worst).
Take the top feature you're supposed to work on right now and weigh it against the top investment you want to make. Compare the benefit-to-effort ratio. Keep in mind the long-term impact as well. Some features and investments have a compounding effect over time. And don't forget that your long-term horizon/vision should factor in the mortality of your company... you gotta keep the business afloat for long enough to realize these benefits.
Another thing to keep in mind that you may not have enough information to perform this analysis. You may need to ask the product manager questions about the features and how they tie into the mission of the company. Go into the conversation with an open mind and a desire to understand. Your goal should be to push the mission of the company forward, and that might mean you don't get to work on these investments any time soon.
Ok, so you've done the analysis and you have convinced yourself that your investments have a higher long-term benefit-to-effort ratio on the mission of the company than the things the product manager is bringing you. Time to talk to them.
First, your product manager should not be surprised about this conversation. This should not be the first time they hear about these investments you'd like to make. Keep them in the loop about some of the investments you're considering. Let them know that you're conducting an analysis on their value to the mission. That way, when you come to have this conversation, it's just you reporting the results of your analysis.
Your job is to help them understand that your investments are mission-critical.
How you accomplish this depends on the investment, but in principle it's all the same. In fact, it's the same for user features too: Start with why (the problem). If the decision makers don't have a clear understanding of the problem, then it doesn't matter how good the solution is. You need to internalize this problem and have them begging you for the solution. The problem must be related to the mission. It needs to be their problem. If it's just your problem, then they won't be convinced. Keep in mind that when you're communicating the problem you'll want to make sure they understand the cost of doing nothing to address the problem in the long term.
Once they've been able to associate the problem with the mission of the company, then you can communicate the solution: your investment. Remember that the product manager is going to try to conduct the same analysis that you have about the long-term benefit-to-effort ratio and weigh that against everything else when they prioritize your work. You need to make sure they have all the information. In communicating the problem, you've hopefully given them an idea of the benefit of a solution. When communicating the solution, you'll want to make sure they have a clear understanding of the effort involved.
Ultimately, the company hired the product manager to help prioritize work in the optimal way to push the mission forward. You should trust them to do their job well and recognize that they may have context that you're missing. So long as you effectively expressed all the information you can about the long-term benefit-to-effort ratio of your ideas then you've done all you can there.
If you experience cognitive dissonance when you hear their decision to forego your suggestions or de-prioritize them, then there's been a misunderstanding. Either you misunderstand the problem/solution that you yourself presented, you misunderstand the importance of the other things the product manager prioritized, or they misunderstood those things.
Wherever the misunderstanding lies, you can put forth an honest, good-faith effort to bring things to light. Express your thoughts on the matter and ask them to help you understand their perspective. In that discussion you might gain new insight to help you be more comfortable with the decision they have made. You may also uncover and correct their misunderstanding and get a more favorable outcome for your idea.
Get out. Or find out what motivates the decision makers and ensure they see the connection between what you're trying to do so they can prioritize it properly.
The mission of the company is one thing, but what actually matters is the true outcome of the work of the people working there. If you can be comfortable with that outcome (and helping put that "unstated mission" forward) then fine, adapt to that. Keep in mind that if an unstated mission exists, then it can be changed or even hidden/misunderstood. A dysfunctional company is often infested by in-fighting/political games that are not fun at all. You'll find unexpected and ridiculous road-blocks. I suggest you start looking for a better place to work that has a motivating mission.
Finally, we get to the Alianza story. I had been working at Alianza for almost a year when I started thinking I'd like to switch from Angular.js to React personally. I was getting fed up with Angular.js and Angular 2 was "on the horizon."
After investigating it, I realized that "upgrading" Angular 2 wasn't much of an upgrade at all but more of a migration to a completely new framework. Angular 2 didn't seem to address the issues I had with Angular.js anyway, so I thought: "Well, it'll be just as easy to migrate to React as it would be to migrate to Angular 2 and I'd rather work with React anyway."
So, I went to the ultimate decision maker and brought up the topic. In retrospect, I was unsurprised (but still disappointed) when he said that they just didn't have the budget to migrate to any new framework. We were a small company (only two of us on the frontend) and benefit-to-effort ratio just didn't make sense. We needed a lot of features and migrating to a new framework was not nearly enough of a benefit for us to justify the effort within that time horizon.
All the other companies that had conducted this kind of a migration needed to move forward and had compelling and mission-based reasons to conduct the migrations.
Now, I just want to make sure that it's clear that at this company they had let me do a LOT of investments in the platform. They were super responsible and had treated me very well. Like I said, I wasn't surprised. It just didn't make sense.
But my personal career goals involved me moving from the Angular.js community to the React community (that decision played out extremely well for me), so I started looking for a new job.
It wasn't that I was unhappy with the mission. I was happy to get behind the mission and push, but my personal career goals and the good of the mission were at odds. So I changed to a new company where my goals and the mission were well-aligned.
To sum up, the way you convince the decision makers to do what you want is to first convince yourself that your idea has an appropriate benefit-to-effort ratio within a relevant time-horizon that is grounded in the company mission. Once you've convinced yourself of this, then you communicate that to the people who prioritize your tasks.
Let me say that again. It all comes down to this:
You need to determine and communicate the benefit-to-effort ratio within a relevant time-horizon that is grounded in the company mission.
The business and engineering alignment comes down to both being focused on furthering the company mission. If you're both truly working toward that goal, then alignment becomes a matter of proper communication, mutual respect, and understanding.
Good luck!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。