Hacker News Reader

Comment by teeray | Hacker News Reader

Remember that if one of your team members has a good idea about how to improve the codebase or the process that you should acknowledge that it's a good idea and tell them how much you like it. Then you should always remember to tell them that it's "not the right time" so you can then move on to demand status updates on features.

View on HN

If said teammate decides to follow through on his idea without your explicit permission, transfer him to another team ASAP (without his approval). No teammate can show initiative, self-direction, or autonomy. Furthermore, every piece of work must be represented in JIRA and every team member must report on it —- daily.

This happened to me recently. Yes, I’m a little salty about it. Although it’s probably for the better, as this guy is no longer my manager. For the record, my super-great-idea was upgrading some 5+ year old software that was giving us and the devs a lot of headaches. I was told it could not be done, and it would be replaced by The Next Great Thing, which would take 6-8 months of engineering. I upgraded the thing in a day (in dev) just to prove that it could be done. Despite praises from my teammates (and devs) I had undermined The Manager. Although I know he wanted to, he could not berate or yell or force me to rollback —- imagine telling dev we are rolling back to a five year old version. In any case, ten years in and I’ve learned that the manager is a hard cap on the productivity of a team. The most productive team I’ve been on did not have a manager. We didn’t need a JIRA board or a roadmap or someone to help us plan or prioritize. We simply got our work done. Imagine that.

In reality I know what you mean, but not a good look for you imo. Imagine that upgrade causes an issue upstream and someone has to explain who approved it. There's always a way to get housekeeping items approved, sneaking it in isn't it.

It was in dev environment which I doubt in his world required any sort of management approval.

I agree, it was a calculated risk. Without getting into the deets I was confident it wouldn’t introduce any major issues. In fact NOT upgrading had resulted in problems that affected production a few weeks prior. Would I recommend a junior engineer yolo it? Of course not. But I’d also warn junior engineers to always keep a healthy skepticism when they are told “No, this cannot be done.”

> There’s always a way to get housekeeping items approved…

Yes, at a functional software shop, upgrades and maintenance are not considered stretch items. I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint. However, at a dysfunctional software shop, none of those factors matter (or they don’t matter as much).

> I did my best to make the case from a technical (bug fixes and features), business (vendor X won’t support us on this version), and customer (customer wouldn’t be happy if they knew we were running version X) standpoint.

I feel your pain then.

> We simply got our work done. Imagine that.

Well what happened? Why did you leave? It sounds great!

We were assigned a manager. Who immediately tried to bring in his folks from a prior job (they weren’t a good fit), force us to adopt his preferred tools (with no consideration for our skills and tech stack investment), and took over daily standup, which exceeded 30 minutes in the regular for a four person team.

> We didn’t need a JIRA board or a roadmap or someone to help us plan or prioritize. We simply got our work done. Imagine that.

How did you prioritise?

When there is a lot to do and you are understaffed the highest priority things are usually obvious. For instance, we keep getting repeated requests for X from dev, let’s automate it or make it self-service. Software X is severely out of date and preventing us (or dev) from implementing X, let’s upgrade it.

Ah, gotcha. Single internal customer. Makes sense you wouldn't need much structure around this.

> The most productive team I’ve been on did not have a manager.

Ive been in the weird scenario of not having a real manager a couple times. One time it was how you described. Another was pretty bad, we basically became the dumping ground for unwanted projects and tedious work because we didn't have authority to say no.

Yes, a good manager shields the team from distractions and lets them focus. I know I sound anti-mgr but I’m not. I’ve had some rly good one who gave us autonomy, trusted us, but also held us accountable. It seems most managers don’t subscribe to the servant leadership philosophy, but are prone to the dictator style (ie team members are subordinates whose role is to implement the (not shared) vision.

I have a feeling you're being sarcastic but this isn't terrible advice. I've seen a lot of dysfunction caused by that one engineer who constantly complains about the current code base and tell everyone how it should be done. If a tech lead can get them to quiet down and move on it will do the whole team a lot of good.

Even worse, someone actually listens to that guy, they go implement something “cool” or “elegant” that actually makes things worse, then they leave and people hate the thing even more.

I’ve seen one costly example in the wild - a problem domain was wildly oversimplified at an early stage of a project so one component was coded as a state machine. However, there were a bunch of background threads running independently of the state machine doing stuff and passing messages. And tracing code execution even within the state machine was a nightmare because a lot of what you’d think of as “call stacks” were coordinated by messaging passing between threads (mediated by the state machine controller) in a way that required you to do like 8 “find references” each time you wanted to see which function was actually getting called when a message was passed. Literally the entire thing could have just been a regular old init call making the same background threads, a regular request handler, and a regular handful of functions called if an error occurred but it was such a fucking mess we just started over in a new binary rather than trying to fix the existing one.

My favorite tool when someone suggests a code improvement is to say ”Cool! Love that. Make it so”

Then usually nothing happens. They didn’t think it was good or important enough to use their time, they just wanted others to Do Better. Oh well

Or they were actually asking for time to officially work on it. Thinking their superior must have a good view of the big picture. Waiting confirmation that their idea made sense in the grand scheme of things.

In that case giving them permission does the trick and the improvements happen. Huzzah!

The other side is making sure to always plan for enough slack in the system so people have time for these things, if they choose to use it.

AKA "The Wally Reflector" from Dilbert :_)

Looked that up thinking I'll disagree, but actually yes. As you grow in your role, you get to a point where the number of incoming "quick requests" outpaces your ability to keep up.

To most people they're just asking for a quick 10 minutes of your time, what's the big deal. But they don't see the other 20 people doing the same thing. If you devote 200min+ of every day to fulfilling others' requests, when will you have time to do your own work?

The problem grows only worse the higher in the org chart (formal or informal) you get.

Someone like a VPofEng may have 100 people asking "quick questions" all the time. Without the Wally Deflector, there's literally not enough time in the day to even have all these conversations, let alone do anything about 'em.

I always immediately approve implementation of any good idea regardless of roadmap or resource availability.

Ah, the luxury of no deadlines...

Looks like good long-term project stewardship.

If somebody just improved all future deadlines at the expense of a delay in one, isn't it great? (Yeah, there are a few times when it isn't; but if those are not few enough to be clearly communicated, your management is a bunch of dummies.)

If you are getting told to ignore it by people who can’t even evaluate how bad the problem is (because they’re nontechnical or just too lazy to dig into it technically) that’s a problem.

But as a technical person who has heard this a lot and been the person complaint before too, IMO people are too eager to make these complaints (if nobody in the current team understands why something was done, that doesn’t mean it’s tech debt) or have poor ideas (more READMEs! That in 1y will go out of date and just confuse people or be deleted because the person pushing for it left. And that was the only person actively reading them) or don’t actually have a way to solve it because there isn’t one (solving bugs often involves increasing cyclomatic complexity or adding some ugly code somewhere - there may not be an elegant way to avoid that. Same with having to do something hacky with a library or framework because it imposes constraints on some edge case).

If poor codebase quality can be linked to a more tangible problem like reliability, bugs, high engineering or operational maintenance problems, etc then it should be seen as a feature to improve that. If the only impedance is development speed you really need a decision maker who has a strong understanding of how a proposed improvement would improve development speed to get a good outcome IMO, because a small improvement for a big investment (and potential risks of new bugs, or an outcome that is actually worse after all the edge cases to fix bugs are added back) may not be worth it, but conversely a big improvement for a small engineering investment could be a no brainer. It’s just, a lot of engineers propose improvements that aren’t worth it.

The non dysfunctional way to deal with this is to allocate between 20% of dev time to process improvements and vote on large scale changes.

Ensure you use the dysfunctional version of that, where some individuals are always outvoted.

Over time, they'll become some of your favorite object lessons about employee engagement!

Every place I’ve worked has had a “20% tech debt” time. Universally, it’s used as a reason to not fix technical debt as opposed to enabling engineers to fix long-standing problems. “Oh you need to re-write such and such? Well that’ll take 40% of your time for 3 weeks and the max time we can allocate is 20% so…”

YES. Fake praise and empty, kind words will get you far. Unfortunately I learned this far too late. To me it feels gross and manipulative but that's what people want.

There should absolutely be separate meetings for new idea separate status updates, and ideally status update meetings should only be for chatting about what digital updates can’t handle.

Creating useful digital over-communication in the right way can go a long way to establish the “what do you need from me so I can get out of your way culture”.

Reply on news.ycombinator.com