Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I learned after managing a small team for 2 years

luispcosta.com

Post reply on HN
Print view View original

81–90 of 102 posts

Re: What I learned after managing a small team for 2 years

#81

Post by solraph »

kcplate wrote: post #60
solraph wrote: post #56

Earlier quoted context omitted.

> And this wasn't a stupid guy, no matter what it might sound like. He might not lack intelligence, but a CEO unwilling or unable to understand the other people work in a different way to him /is/ stupid. CEO is management, and (effective) management means well... managing the various people, resources, and other restrictions to achieve the goals at hand. Being pissy that people and the universe don't work they way t…

> CEO is management I disagree, a CEO is not management in the sense you are describing. Being a CEO is more about decision making and direction setting for the organization holistically to maximize the value to the shareholders of the org. Depending on the size of the org, management might be a task they perform, but in larger orgs, CEOs rely on managers to manage.

Even accepting that definition (I don't 100%, but nevermind), a CEO is still making strategic decisions that need to take into account the variety of people that report to them and how they work.

For example, if a CEO in a large org demanded that engineers are all available via phone for level 1 support calls to cut support costs - that would be stupid, because even two short calls a day is going to have a massive impact on those engineers productivity on building the product(s), followed by any of the half decent engineers leaving for other jobs shortly afterwards.

Re: What I learned after managing a small team for 2 years

#82

Post by spacemanspiff01 »

Silhouette wrote: post #54
chinchilla2020 wrote: post #35

Earlier quoted context omitted.

Love this approach. It keeps everything in a 'one stop shop. There is nothing worse than having to chase a tangled graph of google sheets, word documents, readmes, confluences, and figma diagrams in order to understand a piece of code. Just put the whole bloody thing in a little documentation file in the class and be done with it. Better yet, actually use the python docstrings or java docstrings (whatever you call th…

That strategy does limit your documentation to text though. Sometimes a literal big picture and a few well-considered supporting diagrams can be worth more than a hundred screens of Markdown.

[dead]

Re: What I learned after managing a small team for 2 years

#83

Post by kcplate »

solraph wrote: post #81
kcplate wrote: post #60

Earlier quoted context omitted.

> CEO is management I disagree, a CEO is not management in the sense you are describing. Being a CEO is more about decision making and direction setting for the organization holistically to maximize the value to the shareholders of the org. Depending on the size of the org, management might be a task they perform, but in larger orgs, CEOs rely on managers to manage.

Even accepting that definition (I don't 100%, but nevermind), a CEO is still making strategic decisions that need to take into account the variety of people that report to them and how they work. For example, if a CEO in a large org demanded that engineers are all available via phone for level 1 support calls to cut support costs - that would be stupid, because even two short calls a day is going to have a massive im…

I am not saying that every CEO decision is a sound or good decision, but the failure in your example would be at whatever management level is between the CEO and the engineers because they provided could have provided sound advice.

However, if the strategic need of the organization required that level of direct engineering support more than the specific engineering productivity…it could be a sound decision.

As an example, I worked at a organization in the late 90s managing field engineers. For an entire week the CEO required our team to be in office instead of in the field. We thought it idiotic at the time, but apparently it help create the optics that convinced the owner of a small company to sell his company which allowed our company acquire a game changing product.

None of us understood the big picture because we couldn’t see the forest through the trees.

Re: What I learned after managing a small team for 2 years

#84

Post by nikau »

jonpurdy wrote: post #19

MVP: minimum viable process I’ve worked for a few orgs as a TPM. If you can get by with a kanban board and weekly sync meetings, and everything else async, do that. If you need more rigor or the team is big enough or developing software that would benefit from Scrum, then go for that. Most importantly, get team input and buy-in. There’s no point in dictating process to teams if they’re not into it.

MVP: maximum possible tech debt.

I know the theory about reducing scope, but my experience has been 100% keep the scope and reduce the quality.

Re: What I learned after managing a small team for 2 years

#85

Post by nikau »

lmm wrote: post #52
screye wrote: post #41

Genuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ? It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. How flexible are we with requirements ? How many stages are in the to-do list ? How many hierarchies are in the todo list? How often do we features to be deployed ? What more do you nee…

> It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My e…

> since we still get people who want estimates months in advance

Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

Re: What I learned after managing a small team for 2 years

#86

Post by nikau »

tacker2000 wrote: post #11
ilrwbwrkhv wrote: post #8

> Agile is not always the answer can be generalised to: Agile is never the answer.

So whats the answer?

Hire smart people. Use common sense. Get rid of bull shitters who regurgitate the latest fad on medium.com without any thought of its appropriateness for your environment.

Re: What I learned after managing a small team for 2 years

#87

Post by glonq »

Scarblac wrote: post #63
glonq wrote: post #9

I've managed small-to-medium teams for a very long time. Agile is very often not the answer, because on a small team you don't have all of the people and roles necessary to do agile "right". I tend to just do Kanban with frequent demos and milestones. I agree on documentation. I try lead by example and document all the important bits to a "hit by a bus" level. Because on a small team losing one person means losing a…

To me a core part of agile is self managing teams. It makes sense that a team manager sees it as not the answer.

My disdain for agile comes from being a developer more than from being a development manager. I get how and why it sometimes works, but the whole cult of agile is a bit much.

Re: What I learned after managing a small team for 2 years

#88

Post by sanderjd »

lylejantzi3rd wrote: post #75
sanderjd wrote: post #74

Earlier quoted context omitted.

No, you've taken this same dismissive know-it-all tone elsewhere in the thread as well.

Where? Quote me. I'm telling you, this is the only part of the thread I've replied to. Maybe you should take a good hard look at yourself before accusing others.

Oh you're right, I was thinking of another comment in this same thread. Mea culpa!

But my criticism of your attitude stands. If this is how you responded to developers on your team making obvious suggestions about how to make documentation useful to them, then it's no wonder you've had this problem of people not reading documentation.

Again, this just isn't a problem most teams have, because there are good solutions.

Re: What I learned after managing a small team for 2 years

#89

Post by lylejantzi3rd »

sanderjd wrote: post #88
lylejantzi3rd wrote: post #75

Earlier quoted context omitted.

Where? Quote me. I'm telling you, this is the only part of the thread I've replied to. Maybe you should take a good hard look at yourself before accusing others.

Oh you're right, I was thinking of another comment in this same thread. Mea culpa! But my criticism of your attitude stands. If this is how you responded to developers on your team making obvious suggestions about how to make documentation useful to them, then it's no wonder you've had this problem of people not reading documentation. Again, this just isn't a problem most teams have, because there are good solutions.

Similarly, if you were on my team, I'd probably fire you[0]. You have no self-awareness. You've doubled down on your flawed misinterpretation of my attitude, even though you've already admitted you came to that conclusion in error. You're the type of person who can't ever be wrong. That sort of thing is murder on morale.

[0]: After multiple warnings, inevitable complaints from the other team members, efforts to help you improve, etc. I don't fire people willy nilly.

Re: What I learned after managing a small team for 2 years

#90

Post by sanderjd »

lylejantzi3rd wrote: post #89
sanderjd wrote: post #88

Earlier quoted context omitted.

Oh you're right, I was thinking of another comment in this same thread. Mea culpa! But my criticism of your attitude stands. If this is how you responded to developers on your team making obvious suggestions about how to make documentation useful to them, then it's no wonder you've had this problem of people not reading documentation. Again, this just isn't a problem most teams have, because there are good solutions.

Similarly, if you were on my team, I'd probably fire you[0]. You have no self-awareness. You've doubled down on your flawed misinterpretation of my attitude, even though you've already admitted you came to that conclusion in error. You're the type of person who can't ever be wrong. That sort of thing is murder on morale. [0]: After multiple warnings, inevitable complaints from the other team members, efforts to help…

Edit to start with this: I think you're right that I was too hasty with my "you need to look in the mirror" comment, and this whole discussion would have gone better without that comment. So I'm sorry about that one!

Ha, I sincerely doubt our higher-context interactions in an actual working environment would go the same way as our internet strangers with no context discussion.

But it is definitely possibly that we wouldn't ever be working together. Right from the jump, the way you framed the question of "how do I get devs to do what I want them to" suggested that you're more a top down do-what-I-say leader than a servant leader, and that's fine but it's not the style of organization I look for when evaluating hiring managers.

Then you aggressively dismissed a frankly very boring suggestion that has been a best practice for decades. Which was just a weird reaction IMO.

But again, I suspect you would be more tactful about your response to it in an actual workplace, and I would probably be less likely to tell you how strange I found your rejection of such a simple suggestion.

But my mea culpa was about forgetting which thread I saw your comments in, not about my evaluation of your (to me) pretty mystifying attitude about this.

Post reply on HN