Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

At a former (large, organizationally deficient) company, there was this small team of 5 people with very different specialties (and personalities). They were a "strike team" of sorts, tasked with helping out at a technical level different projects that were in trouble. They were excellent. They saved my team's integration of a camera co-processor in an SoC.

But finally a re-org came around and some high-level manager didn't have a box under which to put them (or didn't have the right budget item to fit them in), and the team was dissolved.

The guys were good in the teams they each landed in, but the synergy[1] was dead.

Nowadays, my primary criteria for joining a team is the quality of the people and of the manager. I wish I could say I've seen other teams of the quality of that first one.

[1] yeah I said it

View on HN

One of my most enjoyable periods while working for someone else was at CapGemini when I was between teams and lent out to do short term fixes for teams where they didn't have enough developer resources/the right resources. Typically just a week or two to go in figure out what was going wrong and patch their systems then get swapped. I don't know if it was the change of pace or the fact that you kind of got to feel like an office superhero that I liked more but I was really young so probably equal parts both.

Are you still doing consulting? I find that the upside of consulting is that there is a well defined finish line before you are deployed.

When you land in a role that has no finish line, it kind of removes the benefit of being a consultant.

Not really. I moved more into product work but I have one existing contract still going for a few hours a week. No finish line but it's a steady income stream and minimal hours so I've not minded it. It helps that the client is fantastic.

I had a similar stint helping teams with system performance issues. I think I found it so enjoyable for two reasons:

1) Solving the problems involved the focused exercising of all of my software dev knowledge – often around database access, sometimes around garbage collection and memory allocation of the specific platform.

2) The impact was highly visible and appreciated (by the team, management, and system users), and the result was usually objectively measurable, e.g., the global search now completes in 1/50th of the previous time.

That said, when I reflect on the 10 or so projects I helped in this time, they were all problems the senior dev(s) on the team could have figured out. So, it wasn't really that I was some rockstar who had special knowledge. It was more that I was given time to focus on the issues, while the regular devs on the team had bugs to fix, features to work on, etc.

Like you, I now work for myself, but if I were offered a job doing small-medium performance optimization projects (without travel), that would be tempting.

If there were one key benefit of consulting / being an internal developer at large it would be the ability to leave after finishing a project.

Sometimes that's sad. (When the client / team is awesome)

But usually it means not having to deal with any of the worst parts of office politics. (E.g. de facto stack ranking, non-merit-based favoritism jockying, office management politics, dysfunctional management priorities, waiting for someone to die / retire for a promotion, etc)

That reminds me of a (proably apocryphal) story regarding IBM's "Black Team" [0]:

> The individuals who made up the team were not exceptionally intelligent or talented, but they all enjoyed testing software and were better than average at it. When these like minded individuals were assembled, they they spent their working hours, lunches and sometimes free time collaborating on how to better find software defects.

> Soon the members of team were twice and then dozens of times more effective than their peers, and they began to view their jobs not as testing software, but as breaking software. Team members took a well-deserved pride in their abilities and began to cultivate an image of villainous destroyers. As a group, they began coming to work dressed in black and took to calling themselves "The Black Team."

[0] https://news.ycombinator.com/item?id=2472219

How do you measure and quantify a team's quality when joining? Especially if you are moving from a different company, I feel like it is probably impossible to know as you may only meet a small subset of the team you work with, if you even get to meet anyone on your future team at all.

You can't measure it before you join, just as they can't measure your effectiveness before you join. The best you can do is hit the eject button after 6 months after you've assessed what's really going on. Same goes for the employer's side.

> You can't measure it before you join

You can generate heuristic data though. This really should be a priority for you during the interview process. They have the right to ask you very difficult questions, and you have the right to ask them very difficult questions as well.

I would say: - Look at what they have accomplished. But be sure you are looking at accomplishments of the actual team, not people who are taking the credit (that is a little trickier). - See if there is relaxed communication and trust. - Ask everyone individually what the goal of the team or the goal of the project is. Really talented teams sometimes put their individual goals ahead of the overall goal. As in: the front end engineer says a responsive front end is most important, an AI dev. says deep learning is the key feature etc. All can be talented and well meaning. But if everybody doesn't agree on the trade offs, effectiveness will suffer.

What's your criteria to measure "quality of the people", in this context?

Can I communicate with them well? (which is a huge topic in itself) Are the people I talked to focused and flexible? (this is not a contradiction) Do the team members refer to each other, and if so, in positive terms? Are the people interesting and curious?...

> Nowadays, my primary criteria for joining a team is the quality of the people and of the manager.

That's mine too, but nowadays teams and especially managers last about 6 months in one place. What is one supposed to do?

But, that's leveraging A talent across an entire organization. Why pay for 2-3x for all A players(that are going to piss all over each other anyway) across the entire org when you could with 1/2 hr of help a day use a bunch of B and C players. and save a lot of money.

thats ok, its still a real world and a real thing if its used in a meaningful context

No worries. It was a reasonable deployment.

Reply on news.ycombinator.com