Speeding Up Your Engineering Org, Part I: Beyond the Cost Center Mentality
blog.hut8labs.com
blog.hut8labs.com
Two years ago we agreed to hack it up quickly in PHP, but product promised us—PROMISED—that we would have time to go back and clean it up.
If "product" is deciding how much time engineers have, then the organization is fucked and deserves to fail. Running a technology company like that is like letting 5-year-olds fly a plane.
If you’re a mature, business-focused engineering leader, you might grab some coffee, sit Cindy and Scott down, and tell them something like this:
“Cindy, I’m sorry to hear that you’re getting bored doing so much production DB work, but realistically it would take you at least 40 hours of work to write, test, and deploy a migration utility, right? So if you’re spending a half hour a day on migrations, it would be 80 working days before we saw a return on our investment—that’s like 4 months, and that’s just too long for me to sanction—precisely because you’re such a valuable member of the team, and I can’t spare so much of your time right now away from our feature backlog. We can touch base if the migration workload increases too much, OK? Until then, I have to ask you to put your head down and be a team player.
I agree that that's a wrong approach. I go further. That hypothetical manager is being a condescending, passive-aggressive dickhead. "Too long for me to sanction?" What ever happened to supporting your people? I can't afford your time? Are engineers slaves now? If I got that ration of shit, I'd be changing jobs in a week.
I agree that the cost-center mentality is toxic, but the OP doesn't go far enough. OP seems to think that non-technologists can run technology companies. We have mountains of evidence that shows that it doesn't work. We need something like what the lawyers have (lawyers cannot, by law, report to non-lawyers) if we want to see actual technical progress in this country.
Law firms can't be publicly-traded or owned by non-lawyers.
It makes it hard to liquidate, but it's generally good for them. It tends (at least in theory) to give them the autonomy and respect of a true profession. In truth, it's never that simple, but the idea is right.
If we believe wikipedia, GCs used to mainly report directly to the CEO, and still do for smaller firms. For larger firms, it's not unusual for GCs to report to the board in conjunction with CEOs[1].
Going back to the idea of technologists reporting up to technologists, this is probably the same end state where the Professional Engineer (PE) designation for "software engineers" in the US is ultimately trying to get to. I think it's the NCEES and IEEE that are driving this[2].
It doesn't seem to me that you'd endorse the NCEES-IEEE vision for other reasons articulately expounded on at length on your blog, but would like to get your thoughts on it nonetheless since I don't think it's been touched on much in this forum recently.
Steve Jobs was not a technologist, but he seemed to do a fine job of running a technology company. Bezos is not a technologist, but he also seems to be doing ok.
The argument here is basically that the apparent opposition between what business wants and what engineering wants is mainly illusory. That if you think about business correctly, a lot of engineering desires are exactly what the CEO should want.
The "engineers must control all the things" urge is exactly the same one that managers have. It's really, "People like me must control all the things." The reality is more nuanced, and more mundane: giving a single viewpoint control rarely works; what we need are contexts where people respectfully collaborate.
The truth is, very high level marketers or sales people or product managers are every bit as rare as very high level engineers. And at some point in your career you realize there's a crapton of expertise in those areas you don't have, but others do. And working with them and even deferring to their judgement in those areas gets you a lot better results than getting to be king of the castle.
And what makes engineers the ones who are skilled enough to evaluate and prioritize the work? They understand the technology side, but do they understand what customers want and need? What will sell and market well? How a product will fit into the company's product lineup? What the competitors are doing? The problems customers are calling support about? Etc.
There are many competing priorities, and I don't think any one person or role can know enough to be able to accurately prioritize what work is most important. You need a team that works well, and members of that team need to be able to clearly explain the benefits and costs of doing or deferring any important piece of work.
As an engineer, we need to know those costs/benefits and how they trade-off against other tasks to make the right decision of which one to do first. That doesn't change if you're the one with the final say, so why does it change when you have to communicate it to a PM so they can weigh it against the other work to be done?
In the OP, the manager is doing the cost/benefit analysis. If Cindy and Bob were great engineers, they would have done a similar analysis themselves.
FWIW in my mind after all these years, I've come to some of the very same conclusions but these do a great job of articulating WHY. Sort of like learning to play music by rote vs learning to read music.
So in my "not a developer" mind I've chalked it up to the fact that every website is a cathedral. Each one is different. Each one is built by artisans from scratch.
But this post and other posts on the blog really explain exactly why each site is unique and the issues around research in a way no other engineer has ever explained to me before. Now I fully understand what to look for and how to ask for it. I'd had product owner/scrum training so I thoroughly understood story points, break stuff down, but the clincher for me here was the idea of prioritizing the smaller stories that help us learn quickly, almost MVPing the MVP.
Again, this is stuff I've sort of picked up over the years, but what a gift to help others skip that way of learning. These need to be in a book and they need to be taught to anyone working in technology.
Lean paradigm values flow efficiency and quality at the cost of resource efficiency (think mass production). You can balance somewhere between depending where what your business strategy is, but it is important to understand that maxing out flow efficiency and resource efficiency is impossible.
Saying that cost center approach is wrong, is misleading and targetting the wrong problem. There's a tradeoff there, it's not good vs bad.
There's a good book I can recommend for people interested in Lean and its position vs mass paradigm: "This is Lean: Resolving the Efficiency Paradox".