Many engineers are unprepared for the autonomy and freedom they demand
twitter.com
twitter.com
In group B there are engineers that want to be in the business problem solving loop and have autonomy to solve problems as they see fit.
Group A and B aren't necessarily the same group.
I'm going to guess this guy has more than one talented, unhappy engineer on his staff. Some CEOs are unprepared to utilize the talent they hire.
In other words, if you can't motivate me to care about your product, I just want to turn cranks.
A paycheck isn't enough to ensure full commitment from any employee, not just engineers. You have to actually manage people, meaning that you have to provide direction and leadership (read "incentives").
I still believe that people will give you a lot more than they'll let you take, if they actually feel as if a project's success will be reflected as their success. People who are willing to give will act autonomously and take responsibility, because "getting it right" personally matters. They have skin in the game.
But things like artificial deadlines (i.e. no business consequence, but some exec gets an attaboy) and uninspired/unethical feature work (supported by HR-phony excitement) create an environment where "taking responsibility" gets reduced to "unpaid overtime and fake excitement".
In that case, yeah, you need to chew the cud for me, because what you're actually paying for is just the swallowing.
That is an awesome metaphor. A bit gross, but awesome :).
But I think Mike's point was if you ask for autonomy, you need to own responsibility, and part of that is problem definition.
To be fair, his company isn't big (< 10 folks, I think), and smaller companies tend to benefit from generalists who can tackle many aspects of a problem, rather than specialists who can knock certain problems out of the park.
I take some offense at this straw man.
Either give me the autonomy to solve the high-level business problems you want to make me accountable for, _or else_ I will default to expecting bite-sized, well-scoped tickets.
In exchange for six figures and autonomy, I'm capable of writing my own well-scoped tickets if you think that's a good use of my time, and I might do so happily if I need to be coordinating with other talented individuals in a team built on mutual trust and respect. But if I'm stuck with minimal autonomy, pulling some tickets written by a project manager off the backlog, then hell yes I expect them to be bite-sized and well-scoped so I can do my job and not waste an entire week figuring out what the problem really is, determine who the real stakeholders are, secretly talk to the end users, pick the brains of developers on other teams, implement a few thousand lines of missing back end services, coordinate with ops to get those deployed, and finally just add that button to the UI that the product owner, half a year ago, persuaded the team would only take a day, all why being grilled every morning about why such a simple task is taking so long. Don't deny me autonomy, let me be fed me crap, and have me do someone else's job without credit while listening to them complain. Let me do my job without wasting my time; is that too much to ask?
> Most problems in business will not fit in your well-scoped JIRA ticket. That doesn't mean you get to ignore them until they do.
But you're still chaining me to Jira, aren't you? I'm still being judged by how many points of Jira tickets I close per sprint, aren't I? And I bet you're still trying to insulate me so I "don't get distracted" from my tickets.
> People get paid the big bucks because they handle that uncertainty well and bring those vague, ill-defined problems to a good resolution.
So I can expect to receive the autonomy needed to take on those problems after all, and also get the compensation commensurate with that responsibility?
> "I'm pretty good with React" doesn't quite cut it.
Is that the bar we're using for hiring engineers around here? Damn, I did _not_ interview your company well enough before accepting this job!
> Yes, because of the implication: you want ownership? Great. Here's your KPIs. You didn't meet those KPIs? Here's your severance, best of luck at your next job.
Hold up. I already have KPIs / OKRs / MBOs or whatever flavor of the year HR is pushing on top of the sprint metrics you're tracking, and as a senior engineer or higher, I'm already in trouble if the product fails, which is another reason I want the autonomy to make sure failure is avoided!
> I made a comment to an advisor a while back about "a VP on a PIP" and they laughed. "Mike, a VP is always on a PIP. That's the role. You hit your KPIs or you're out."
Why are we bringing up comparisons with VPs? Is it VP-level autonomy or nothing here?
> Like, lemme get this straight: you expect a six figure salary, full autonomy to solve problems as you see fit, and _also_ bite-sized, well-scoped bug reports/features.
If someone else is setting up all the problems, it's not really autonomy at all. I can pick some other quibbles with this tweet, & the tweetstorm, but this illusion being presented that there is autonomy is just not true.
Almost all organizations will tell you they are product driven. That means that, you, the engineer, are a resource, for someone else's goals.
I fully think most engineers are bad with autonomy. But also the whole system has been set up to be combatative against engineers. To assume we are bad. To assume we don't have design mentalities. To assume our priorities are not aligned with the business.
I started my career doing development with small web shacks, doing early web application development for small & medium businesses. We've had designers on staff or that we've contracted with every place I've worked, but really the functional design was extremely liberally done, very ad-hoc, and it was wonderful. So creative, so exploratory, so collaborative. Mostly just developers running the show, a pleasant but somewhat out of site boss nominally running the things. Low ego, low titles, high collaboration, highly exploratory, highly creative. The maturation of industrial computing, has, in my view, separated out the responsibilities in a harmful way. Articles like this, to me, embody the prevailing attitude of the world towards techies: not to be trusted, incapable of aligning to & finding value, needy.
What I have yet to see is companies that actively grow & support the amazing creative anarchy of their radically technically empowered work-force. Sure, absolutely: bad match for some. There's good lessons about inflexibility, wanting too much structure provided to you, while asking for autonomy. But real autonomy is not just freedom to do a good technical job. Real autonomy encompasses a lot more, way more. And I just keep thinking- somehow, some day, someone is going to start trying to tap the endless reserves of techie ass kicking, start trying to systemitize ways to let us be the radical, out there, wildly creative, imaginative, explorative systems thinkers that we are, to bring that 101% out, into the world. Today though, there's endless euphemisms put forth for how impractical everyone thinks techies would be, how important it is that non- & semi- technicals hold the reigns. Most organizations are unprepared (& do not want) to generate real autonomy or freedom.