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

51–60 of 102 posts

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

#51

Post by lmm »

ozim wrote: post #12
TylerE wrote: post #6

Earlier quoted context omitted.

Not stuffing it into some horrible slow "enterprise" webapp would be a start.

Are we using the same Confluence and JIRA - I don't see it being slow as we use cloud. Only times when it was slow it was long time ago when it was on premise and business always skipped upgrading any servers so admins had to run it on tight rope.

> Are we using the same Confluence and JIRA - I don't see it being slow as we use cloud.

Well no we're not - if you're using "cloud" then you get randomly assigned an instance, some of them are fast and some of them are slow (presumably because of who you're sharing them with). Guess you're one of the lucky ones.

> Only times when it was slow it was long time ago when it was on premise and business always skipped upgrading any servers so admins had to run it on tight rope.

Nope, even on big hardware it was always interminably slow.

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

#52

Post by lmm »

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 experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not.

Isn't that precisely the proof that the development processes haven't been communicated clearly enough and got enough buy-in/consensus?

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

#53

Post by lmm »

abacadaba wrote: post #27
TylerE wrote: post #7

Earlier quoted context omitted.

The way it's typically applied these days, I'd go much farther. Capital A Agile is often not only not the answer, but the problem .

literally just stop the stupid meetings interrupting every workday other than maybe standup and grooming and then get out of our way and watch productivity improve /rant

Standup, backlog/planning and retrospective are literally the only meetings you're supposed to be doing. I'm always baffled how people manage to do the exact opposite of agile and blame it on agile.

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

#54

Post by Silhouette »

chinchilla2020 wrote: post #35
sanderjd wrote: post #26

Earlier quoted context omitted.

Pretty simple, really: Put it in the code. If it is too big to go entirely in the code, summarize it in the code and then link to the full docs (ideally in markdown files inside the repo). Another thing, which you can't really fix yourself, but which I'm still gonna shout into the ether: Ideally you have a browser-based code browsing tool, like GitHub or Gitlab, but one that actually lets people click through method…

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.

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

#55

Post by abacadaba »

lmm wrote: post #53
abacadaba wrote: post #27

Earlier quoted context omitted.

literally just stop the stupid meetings interrupting every workday other than maybe standup and grooming and then get out of our way and watch productivity improve /rant

Standup, backlog/planning and retrospective are literally the only meetings you're supposed to be doing. I'm always baffled how people manage to do the exact opposite of agile and blame it on agile.

I don't blame agile I blame the consultants and charlatans and the execs that listen to them. Also get rid of retro if there's anything to talk about do it in standup.

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

#56

Post by solraph »

ajb wrote: post #50
lowercased wrote: post #36

Earlier quoted context omitted.

> The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us.... Eventually the CEO saw that we were making very little progress... I'm flummoxed as to how someone can not see this. Can you not run a little thought experiment on yourself, like... "How much could I get done if every 3 days, I told someone to stop in the middle of their 4 day task and do something di…

Because that's not how the CEO's job works - his job is to keep a bunch of plates spinning, and switch quickly to the one that's about to wobble off its pole. Sales is similar. If your CEO came up via sales, it's hard to believe that other professions need to work differently. I tried to convince a CEO of this once and he initially just got angry, then started to parse it as my personal need that he might need to mak…

> 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 they want is immature and/or incompetent.

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

#57

Post by lmm »

abacadaba wrote: post #55
lmm wrote: post #53

Earlier quoted context omitted.

Standup, backlog/planning and retrospective are literally the only meetings you're supposed to be doing. I'm always baffled how people manage to do the exact opposite of agile and blame it on agile.

I don't blame agile I blame the consultants and charlatans and the execs that listen to them. Also get rid of retro if there's anything to talk about do it in standup.

Nah. Standup is for day-to-day current status. It's worth having a regular point where you have a think about how well your process is going over the longer term and if there's anything you want to change. You can always cut it short if everyone's happy with the current state of things.

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

#58

Post by lylejantzi3rd »

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.

It's also only visible to developers.

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

#59

Post by abacadaba »

lmm wrote: post #57
abacadaba wrote: post #55

Earlier quoted context omitted.

I don't blame agile I blame the consultants and charlatans and the execs that listen to them. Also get rid of retro if there's anything to talk about do it in standup.

Nah. Standup is for day-to-day current status. It's worth having a regular point where you have a think about how well your process is going over the longer term and if there's anything you want to change. You can always cut it short if everyone's happy with the current state of things.

and we're out here having meetings about how to make retro more actionable..

but ya it's really more scrum and associated bs that i have a problem with vs og agile.

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

#60

Post by kcplate »

solraph wrote: post #56
ajb wrote: post #50

Earlier quoted context omitted.

Because that's not how the CEO's job works - his job is to keep a bunch of plates spinning, and switch quickly to the one that's about to wobble off its pole. Sales is similar. If your CEO came up via sales, it's hard to believe that other professions need to work differently. I tried to convince a CEO of this once and he initially just got angry, then started to parse it as my personal need that he might need to mak…

> 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.

Post reply on HN