I helped building producthunt.com and overclockers.at (and other less successful ones)
Here a few learnings:
1. the community already exists, you just create a communication platform for it
2. make it clear what the community is about [positioning/marketing]
3. make sure the communication/content is interesting [quality]
4. make sure there is enough engagement [perceived critical mass] (encourage people to post, post yourself a lot, fake accounts if needed, only create subforums once the main ones are noisy)
5. have a rhythm - some communities need daily good posts, some live of the weekly newsletter
you read in your inbox
you act (potentially reply, potentially mark with star/label, always archive)
if it's a todo you dont get to now you put it in the todo label
if you replied and want to make sure you dont lose track -> awaiting reply
if you handed it off to someone and want to keep track -> delegated
if it's about some future meeting (or flight, hotel, etc) -> purple star (forgot what i called it)
you always archive
this way your main inbox is empty and you know what you looked at
by adding (or removing) label they end up (or get out) in the little boxes
at some point you might go through your todos - handle them remove the star/label
at some other point you might browse through the awaiting replies and realise they are done or no longer needed -> remove label
This is super specific to each project but here things that worked for me in previous projects.
Two assumptions: You plan to work on this longer-term (not a 1month project stint) and there are things worth improving (eg barely used legacy app might not be worth your time)
#1 Get the team on board
if there are multiple people you need their buy-in and support for whatever approaches you want to do
#2 Plan for "health by a thousand small improvements"
it will be an iterative approach and you will refactor as you go.
#3 Don't assume different = bad
people might have done differently, consider using their approaches. you might do it differently. but it's better if you keep a consistency within the codebase. in codebase management consistency trumps cleverness
#4 Create space
Consider introducing a fix-it friday where everyone can work on little improvements
#5 Create non-blame culture
Stuff will break if people risk improving things. Avoid blame shifted to them. If bug trackers ping individual people consider pinging the whole team instead
This one is the most annoying. But worth doing: whenever you improve a feature a bit try adding a test - often in legacy apps there are no good tests. A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do this try it. I always found the iterative approach more realistic as you can also do feature work while refactoring.
When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the "unit" contains critical or complex logic). Your goal is to know "that you broke something" - you get by if you don't always know "what you broke"
#8 Acknowledge tech debt
not everything needs refactoring. If it's not critical and nobody needs to touch it consider acknowledging it as tech debt. Add larger notes above the problematic areas and explain why you aren't refactoring it, explain things worth knowing to understand the code better, etc. Whenever you leave comments remember that comments should explain "why" not "what" the code does.
- Latest season has a 100% score on rotten-tomatos
- The visual effects are absolute top of the art (2)
- The fanbase is franticly close to the show (look at twitter how much they interact w/ the cast etc)
- Season 3 and we are about to start the big turn of the story arch
BUT… Canceled by Syfy because not enough people catch it at the time they happen to transmit it into the air.
If this show would be on Netflix it could become on of the defining sci-fi shows of our generation. Now we have to hope Netflix or Amazon happen to pick it up before the team disperses. (3)
(1) seriously watch it… the first few episodes are a bit slowish worldbuilding but it gets really good
usually write stuff down that i keep repeating in discussions
- eg management advice: https://klinger.io/posts/managing-people-%F0%9F%A4%AF
- eg my angel-investment decision making process: https://klinger.io/posts/how-i-make-investment-decisions
- eg simple productivity-hack: https://klinger.io/posts/q-codes