Comment by nhashem | Hacker News Reader

Comment by nhashem | Hacker News Reader

I think another key point is that boredom is inevitable, at least at any company bigger than a startup.

Software engineering is about solving problems. You get hired, and solve problems. Time passes and you get better at solving these problems, so they give you harder problems in the same domain space. Eventually you get so good at solving these problems in this domain space that you become The Guy. "Oh you have a question about the FooWidget manager tool? Ask Joe, he's the FooWidget guy." By definition, being The Guy has mean you've reached a local maxima of productivity in the company.

It also means you're bored. It's not a case of possibly being bored, or eventually becoming bored. Once you are are no longer a problem solver, that means you're bored.

I've been a lead engineer at two different companies thus far in my career, and every time I end up wailing the same things to management. "You have to let me get Joe off FooWidgets. He's been working on it for nearly years and all you make him do are stupid enhancements nobody actually uses." But then who will maintain FooWidgets? "Hire someone. You could hire a college kid for the level enhancements you guys want. Or let me assign it to someone else on my team. But do something, because he is going to get bored and quit and we'll have to do this anyway, only Joe won't even be here to help transition." Will we be able to make enhancements to FooWidgets as fast if someone else works on it? "Not at first, but within a month--" Bzzt, wrong answer, Joe's still on FooWidgets. And sure enough, within six months, Joe takes another position and we're hosed.

So while Rands had some good heuristics for detecting boredom, you typically don't even need to ask them directly or look for behavior changes. Are they solving problems? If not, they're bored, and you have a ticking clock to do something about that engineer before he leaves.

I've fought through MUCH more boredom during my startup career than at any other point.

Startups are great fun while you're building the product. Then you release it, and while you'd love to be implementing new features you're really stuck maintaining the beast you've unleashed onto the world.

In a startup there is no one else to give you a hand when things break. There is no one else to share the load of those boring tasks (deployments, unit tests, browser/phone compatibility, etc...). Even then you'll spend most of your time refining existing features, not inventing new technology.

At the end of the day, every god-awful task is on you (or a small team). While there are spikes of interesting problems, it will be a small part of what you do.

Just have to say that your assessment of things was refreshingly unromantic and honest - founding a startup won't solve your boredom issue. There's still work to be done.

Try introducing your management to the concept of Bus Factors: http://en.wikipedia.org/wiki/Bus_factor

Cross training isn't an avoidable expense so much as a cost of doing business. The question isn't will Joe become unavailable to work on FooWidget, the question is merely when. This needs to be thought about more like insurance than pure development, insurance for an event of significant probability. Of course one must still consider the full costs/benefits for any bit of training, my point isn't that one must always cross-train, but more that it's easy for managers to underestimate the amount of risk they are taking on, especially when business-critical knowledge turns out to be in only one head.

As an OT aside: this is yet another bonus for doing Code Review.

quit immediately.

if you have a job where you have a "lead" or "manager" title but have to ask someone else before making personnel/project decisions, you are not a lead or manager of anything, just a scapegoat.

Managers and leads aren't all-powerful. They answer to their managers and, in some sense, to their peers.

Sure, all managers answer to another manager, except the CEO. But it's also normal to delegate responsibility when it comes to hiring and working assignments in projects. If you're sufficiently high up in the manager hierarchy (which shouldn't be that high up IMO), you should have the power to make decisions like that.

But by your own admission, some levels of management shouldn't have that power - so what should we call them if not managers?

Imo, if you are managing a team of people, you're a manager whether or not you have total hiring / firing power.

if you are managing a team of people and you do not have at least firing power, in my experience, you are not actually managing a team of people.

But if you could take a valid reason for firing someone to your manager, and they would be fired, I think that would be enough to manage the team right?

in a perfect world, yes. but now you're relying on 2 competent, motivated people instead of 1 competent and motivated person. why rely on 2? why not just give the project manager the authority?

is there something about their ability in this regard you don't trust? then, why are they a project manager? the success or failure of the project could impact the jobs of all of the members of the project, and potentially everyone in the company. why will you trust this responsibility to them, but not the ability to fire individual members of their team?

Project managers manage projects, not engineers. In many cases, project managers are stakeholders in the project. They have conflicted interests. Being able to tell your project manager "no" is important, because it allows engineers to arrest function and scope creep without fearing for their jobs by saying "no" to the wrong person.

.

Where I am right now, we report instead to technical managers, and are allotted to project managers' projects based on scheduling availability, project importance, and a number of other factors.

you have bigger problems if you can't say "no" to the guy who could fire you, in my opinion

I can. And I have. That doesn't make it a good dilemma to create in the first place: do the right thing, or protect your job?

With due respect, I think your notion of how interpersonal relationships work in this sort of situation is rather flawed.

Agreed, it's more like a functional manager.

CEO generally reports to the board.

That's half his point. As a manager you should have full control of your direct reports. You shouldn't even need to ask permission to rearrange focus within your team. He shouldn't have even asked in the first place, though this is probably a sign of weakness in the manager and not so much the upper management of a company (if you have to ask, your peers will automatically play devil's advocate. The status quo, while not most efficient, has usually proved safe enough).

The individual in question may not have actually been under the sole control of the poster, for whatever reason. It doesn't necessarily mean that he needs to jump ship because he's being used as a pawn.

precisely. and ultimately we all answer to the market / your customers / the giant space ants.

however, how i should answer to my boss is in the form of "why was this late". if my management wants to question decisions i make, they can have my job.

you could argue "well, micromanagement is just being proactive". you know what? if you don't trust me, fire me and replace me with someone you trust to get the job done.

That's true, but you should able to manage your team as you see fit. If it doesn't work then you get the blame.

Nothing is more demoralizing that being a manager, but having little to no control over your team and being blamed for the failures. I'm amazed how many business people I come across that ignore or simply don't realize that you can only hold people accountable for things that they have the power to change.

I think another key point is that boredom is inevitable, at least at any company bigger than a startup.

Startups aren't all fun and games either. If anything it's worse because you have a lot of boring work and nobody else to offload it on.

Reply on news.ycombinator.com