Find the person in your org who has high impact, and does NOT want the spotlight. Reward that person on their terms.
My mother in law likes to decide what you want for Christmas. Don't do that. Ask the kid what he wants for Christmas.
Only recognizing the people in your org who are making noise is lazy leadership.
As a developer, there are so many occasions when you'll be lost in the maze, and you need to reach out to a fellow dev for direction. Devs being devs, they'll oftentimes go to great lengths not to talk to you.
A 15 min zoom call can save hours of fumbling around in the dark, yet we face so much friction in getting someone to agree to it.
"Look at the Jira ticket", they'll say. Yes, I did, there's not much there.
"Read the documentation", they'll say. Okay, where is it? Oh, there it is. Surprise, the documentation is lacking and doesn't help much.
"Here's a git repo with some samples." Guess what, your utility apps rarely "just work".
I know, I know, part of being a developer is learning to navigate a landscape with limited guidance. Just figure it out And we will, eventually. But at what cost?
As a developer, your value to the company is greatly correlated with your willingness to jump on a zoom call.
There is one team member who's been around long enough to know the secrets of the fire swamp. But guess what, he's tasked with the most critical projects, under the most schedule pressure. If everyone bombards him with questions, he'll never get his work done!
We're hiring, we need to grow our team from 5 to 25 developers. At one point does it make sense to task your most experienced developer with being a concierge to the other developers? Senior team members provide more value by boosting the productivity of the larger team. Be willing to zoom at a moment's notice. There's more business ROI there than telling people not to bother you because you're busy with your own project.
I've seen leaders encourage this behavior. "Don't bother Jeff, he's focused on a critical project and can't be distracted." Now Jeff has a license to ignore you or tell you to buzz off.
The developer experience is a concept that's gotten a lot of attention these days. As a company trying to attract and retain from a scarce supply of good developers, you'll need to consider how your organization rates in terms of developer experience. The pandemic and the rise of remote work amplifies the problem.
You'll easily boost your developer experience rating if you can appoint an experienced team member to be a concierge, with a hospitable attitude.
I've seen enough different workplaces to see a pattern. The most tenured team members have been molded by that company's culture. They talk about the old times, back when everyone was free wheeling and shooting from the hip. The company was young, perhaps just trying to achieve lift off.
That culture may have been right for the company at that time. However, the company has achieved escape velocity and is now in a different mode.
Some people grow with it, and some .... don't.
A person may eventually be let go, with the explanation being "you're just not a fit, you don't think strategically, you shirk process, you don't do things the *right* way, etc".
To which the person may naturally respond, "You made me this way!"
Take a business who's core competency is not software/systems, for example a manufacturing company.
This business may have started from humble beginnings, assembling parts in the garage, selling them online. Eventually, the company needs a website, then an inventory management system. They'll start with spreadsheets, using Excel to manage and track everything.
Eventually, they'll find that this doesn't scale. Next, they'll purchase "my first ERP" system. One aimed at small businesses.
Eventually, you hire a person to manage your IT needs, but you watch him closely and give him very little respect. He wasn't brought in as a business partner, but as a contractor, to do "spot work". You still haven't realized that your IT needs will be a forever endeavor, an ongoing need. As much as you want it to be spot work, where you shell out a one time fee and it's "done", you have the sinking realization that it will never be this way.
This single person who keeps IT running is buried, so you hire another. Then another. One of them eventually cobbles together a little custom piece of software to solve a specific problem, and WHAM! You are now in the software business. And you can never get out of it.
In 2011, Marc Andreesen famously declared that software is eating the world.
Five years after that, software is still eating the world.
If you want to play in this world, and have a development team embedded in your organization, you probably ought to learn how to engage with them, or hire someone who does.
But maybe you don't have to. Because in 2019, Forbes says that Software Is Eating The World, But Services Are Eating Software.
If, as an organization who never set out to be a tech company, you are frustrated by trying to be one, then just stop. It's not your core competency, it never will be, and you don't want to pay for it.
Fold up now, and just use 3rd party services. As they say, if it flies, floats, or fucks, it's cheaper to rent. If it compiles, deploys, or whines like a prima donna software developer, it's also probably cheaper to rent.
Developers have a reputation for being whiny and entitled. I'd argue that this is simple economics. The people who openly criticize management are the people who are not afraid of losing their jobs.
That is, those who can easily find another job are more vocally critical. If the market for devs was dry, and BA's and PM's were in high demand, suddenly the devs would be quiet and fearful, and BA's would be more apt to call out something as "broken".
Simple supply and demand.
See "The Dead Sea Effect",
…what happens is that the more talented and effective IT engineers are the ones most likely to leave — to evaporate, if you will. They are the ones least likely to put up with the frequent stupidities and workplace problems that plague large organizations; they are also the ones most likely to have other opportunities that they can readily move to.
What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.
Adding an improvement to an existing system without shutting off the old way is a classic mistake. Mature teams and leadership make it a point to replace, not append.
If you don't have the obligation to be backward compatible, consider yourself lucky enough to be able to shut off the "old way". In fact, the "new way" should not be considered complete until the old way is completely gone.
Ask yourself, when is the last time you truly decommissioned a component of your technology stack? If users have multiple ways to achieve the same workflow, this is a smell.
This typically stems from inability to measure the usage of your product. You're afraid to take something away, because some user might scream that their cheese was moved. You should know whether or not it's in use with some basic logging and instrumentation. If you don't have that, then get it.
Code is not an asset. Code is a liability. Strive to reduce liabilities. Your users will adapt.
Let me get this straight. You're asking "senior developers" to monitor a help desk that is flooded with incoming "issues"? And you also want that developer to focus on his project? And you're mystified as to why you can't seem to
a) hit a date on these project "commitments"
b) retain any senior level dev talent
