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

31–40 of 102 posts

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

#31

Post by mdgrech23 »

azangru wrote: post #29

> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me…

Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.

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

#32

Post by siva7 »

mdgrech23 wrote: post #31
azangru wrote: post #29

> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me…

Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.

Delivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.

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

#33

Post by marktani »

rented_mule wrote: post #24
ozim wrote: post #16

Agile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to che…

> I just fail to see how one can build anything if priorities change on a daily basis. I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him…

Your comment made me smile. The manager seems smart and nimble, props to them!

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

#34

Post by andrei_says_ »

rented_mule wrote: post #24
ozim wrote: post #16

Agile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to che…

> I just fail to see how one can build anything if priorities change on a daily basis. I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him…

Thank you for sharing this.

As I gain experience I see how important managing processes, requests and expectations is.

The software and systems we build are a part of organizations and people with their personal agendas expectations and patterns.

Seeing how everything is connected (all at once ;) is an incredible superpower, a true “Whoa” Neo moment.

I am starting to apply my engineering skills to people and organizations, in the best meaning of the word - by seeing what they need, honoring what they are, approaching them with best intentions and clarity.

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

#35

Post by chinchilla2020 »

sanderjd wrote: post #26
lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

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 them) and generate the sphinx doc or java doc.

Look at this wonderful documentation one-stop-shop for the python flask repo that was autogenerated with sphinx. https://flask.palletsprojects.com/en/2.3.x/

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

#36

Post by lowercased »

rented_mule wrote: post #24
ozim wrote: post #16

Agile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to che…

> I just fail to see how one can build anything if priorities change on a daily basis. I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him…

> 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 different?"

It's not 'management rocket science', it seems it's just basic human behaviour. If every couple of days, someone kept giving the CEO new/different tasks, would he ever expect to be able to get anything done? How can you not see the root cause of such a plain-as-day problem? Willful ignorance?

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

#37

Post by BarryMilo »

siva7 wrote: post #32
mdgrech23 wrote: post #31

Earlier quoted context omitted.

Agile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.

Delivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.

Agile is better than nothing, which is what most teams would/did have as an alternative.

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

#38

Post by theptip »

> However, looking back, I don’t think we needed agile or sprints. The project is not big enough (in scope and size) to justify a system like that. But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. As in, weekly, and sometimes daily. So sprint planning goes out the window every week when new requirements and priorities are discussed

Sounds like you needed to be very agile! But maybe not Agile(tm).

Honestly Kanban (what they were doing before) is a great fit for this sort of environment. But for a small team maybe you don’t even need that much structure.

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

#39

Post by sodapopcan »

stock_toaster wrote: post #5
lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

> What black magic do you have to cast to get devs to look at the documentation? Not use Jira and Confluence? More seriously, I have found that confluence is where documentation goes to die. Something about the tooling, the slowness, poor search, admin tools leading to overzealous compartmentalization, not-quite-good plain text format, awkward gui editing tools, versioning system, distance from the code[1]... somethi…

Ya, there is some wisdom in "don't use Confluence". It's far too heavy for a wiki. Maybe it's fixed by now why should a plain text page show a loading spinner??

I'm personally a fan of one massive README with a table of contents for technical docs. YMMV.

Also, definitely link the docs in the description and not the comments. I've found that you should never rely on anyone reading the comments (or re-reading them, at least). Any important info that is surfaced in comments should be moved to the description.

Of course, if you're team isn't going to read tickets then that's just a plain problem.

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

#40

Post by taeric »

lylejantzi3rd wrote: post #3

> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look…

I see two traps here that I largely blame, curious if there are more.

First is that documentation is only worth it if you are keeping everything surrounding it stable. Software has been changing a ton in the past few decades such that a lot of documentation from last year is irrelevant. I /think/ this is slowing down, but I can't say for sure. Examples for this are many. Python 2->3, Web frameworks 10 years ago (this one has legit gotten better), general systems management and deployment.

Second is that it was easy to get burned by documentation that was really more of a promise of things to come. By that I mean you think you are going to buckle down, research the right way, and make progress. Only to find out that all of the time you just dumped into the "right way" doesn't actually work today. It may work next week, but if you want to do something today, you have to do it the way they did it before. Which is a ton of warnings about how you will need to be prepared to upgrade, at this point. Examples of this, for me personally, have been trying to use XHTML back in the day, WSDL promises, and now OpenAPI.

Post reply on HN