I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially similar to the kind of work that often does have long-term value.
If you're confident enough in your long-term decisions, and how you spend slack time, then you should be fine with being rewarded for delivery, since you expect your long-term work to pay off in future delivery and future rewards.
I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.
on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :(
moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient
I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc.
If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.
It's easy to obsess with the artistic side of the discipline when you're doing it on someone else's money and assume it's coming from an infinite bag.
Once you are a manager and given limited resources to get a job done by a certain date, art goes out the window and it's all about efficiency, you get paid to get the job done, not have pretty code.
I think people focusing on SW engineering being art have been spoiled by only working at companies with infinite money, like Google, who treat work as play in hopes that 1 in a million toys will be the next billion dollar idea. But open your own shop, get customers, hire people and let's see how much you'll care about their work being art VS efficient, when it's your dime on the line, then you'll embrace and understand the managerial mindset you've despised.
Furthermore, the art of the trade is not "pretty code"; it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands. There is a balance to be struck between business interests and legitimate engineering concerns around technical debt. And as we've gotten more of these MBA wunderkinds at software companies, the balance has swung very far toward the "Just get it out the door, engineers are just spoiled brats who are never happy with anything" end of the pendulum. Pretty much the entire attitude you espouse in your second paragraph.
You're not wrong that it's not the engineer's dime in terms of money. But it's also not the manager's dime on the technical debt credit card. Engineers have to make the trash solutions forced by their management work and scale for years. That doesn't show up on a quarterly report, but that doesn't mean it's free.
When you're a start-up starting out to build your product, nobody knows what your product or the market will look like in two years, let alone in 10. YTOu might not exist in 2 years if the product isn't a hit, so there' no point in investing in robust codebase if you'll be broke by then.
Very, VERY few companies starting out have the luxury of having secured the funding, customers and the knowledge of knowing upfront what the future will look like in order to plan well from the start.
>Pretty much the entire attitude you espouse in your second paragraph.
It's not my mentality, I'm just telling you what the real world mentality is of those who pony up the cash. Then again, I'm in Europe, where VCs don't throw billions of ZIRP money at SW engineers, so nobody here values your "code quality" but your ability to push something out the door fast and cheap to multiply their investment ASAP.
It's been a frustrating thing to talk about. The people who've seen high quality work in action just say "well, obviously it will be faster and more effective", and the people who haven't simply refuse to believe it. It's like there are two incommensurable paradigms around software, and we're just talking past each other :(
The best places get a ton done with very few people. Like, XTX has, what, ≈100 engineers? And they're operating a system trading across 35 countries using hundreds of petabytes of data. That's more logical complexity with higher robustness and performance requirements than tech companies with thousands of engineers. And they're not doing this by slinging crap code at the wall as fast as they can!
Artistic side of the discipline doesn't mean pretty code. It means good design, no rushed spaghetti code, expandable architecture, etc.
"Getting the job done", in manager speak, often means shipping features with awful code behind them, just to give the manager enough time to move up the ladder without suffering the consequences of their awful decisions. With engineers left behind to fix the mess.
Not necessarily. The problems rather are:
- Those who are mostly immune to this will hardly ever be put on a management track.
- Those who are resistent regarding this kind of infection won't make any further career in management (incentives matter).
Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture.
But this still of working will never get through management because the moment you show them a working product, they'll tell you to ship it and won't give you a chance to rewrite.
I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.
Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?
It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.
Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.
I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.
Trying to hire an employee and tell this story that they "own" the product is just silly. It's like companies that try to describe themselves as a family - just kind of a weird and incorrect use of a real word that has other meaning.
'Ownership' is taking on those same stresses and responsibilities without any of the potential pay-offs... or at best a marginal rounding error.
It's not surprising that few people want to work as a founder but get compensated like an employee.
On the flip side, I've seen early-stage startups and scale-ups where engineers did not have real ownership. It's easy to get into a situation where an individual engineer "owns" a specific part of a startup... but can't make any real decisions on it because the founders want to dictate work at a week-to-week level or something.
It's a function of culture, not scale.
But I think that is beside the point.
Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams.
And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team members, to give you redundancy.
The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.
Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages.
We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.
> I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
what do you mean by "the smallest unit of software ownership and delivery is the engineering team" in practice?
what's the largest scope of work some engineer can do entirely on their own recognizance?
None. Everything we develop was built on someone else's work. Even when our collaborator is not physically in the room with us, the work is still a collective endeavor.
individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.
Resilience against what? It isn't like teams make decisions quickly, an individual will get decisions done faster in almost every case, and if they are on leave right now its just slightly slower than a team.
For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later. That isn't faster than an individual on leave, so I don't see what "resilience" even is here.
> For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later.
feature not a bug etc. they should already have and know their priorities and if yours doesn't trump theirs, there's no reason you should get a concrete answer.
Edit: My current pet project is eliminating a bad DSL which has led to so many bad implementations and near-identical but different copies because factoring aspects isn't well supported. I started with a PoC, then a Hackdays project, and now with that looking good, the team is willing to convert all of the codebase we maintain so that we can use normal programming language features like static typing and source navigation with easy to follow data flows.
I've had a great time on teams where folks can go off and build great tools/libraries/etc that others can use and adapt, without needing a whole team around them—ideally there's lots of collaboration, but it doesn't have to be formally structured
I guess the main difference is that you don't have to operate a tool or a library; if somebody has issues with it, they can patch the code themselves or simply adapt around it in their own code
I also enjoyed working on simulation and optimization problems for similar reasons; there's lots of direct business value, but there's enough slack around it that if I go somebody else can take a model over and maintain it without any issues
unfortunately lots of organizations do not know how to make library-style code "count" the same way a service or stateful component "counts"
When the owner is away, the other people involved keep things moving. If they're away long-term or leave the company, we'll designate someone else to take ownership.
It only seems like not a big deal while "good enough" is a really low bar.
I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years.
It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.
In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)