Start fixing long standing bugs nobody wants to address because too complex
Yes, it's a nice way
51–60 of 186 posts
Start fixing long standing bugs nobody wants to address because too complex
Yes, it's a nice way
> My guys were time reporting into 3 different tools (and this is a Who is the fscking idiot that calls himself a startup founder and makes people report in 3 different tools?
This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks…
I am 1 month into my new position, same position you're in - new stack & straight into senior role. My tips so far: 1) Take over all the admin stuff you can to free up your devs from distraction and pointless tasks. Productivity and morale will immediately go up. My guys were time reporting into 3 different tools (and this is a <10 person startup!), I just started writing a summary of our standups and told them they…
Earlier quoted context omitted.
This kind of attitude is really unhelpful. Of course this sort of situation is undesirable, demonstrably, but it's not necessarily a case of idiocy - it's actually very easy for non-technical founders to get into this situation: let's say the developers want to use JIRA, but the non-technical staff find JIRA impossible to use (totally reasonable), so they want to carry on using Trello; straight away you've got tasks…
> This kind of attitude is really unhelpful. No, what's unhelpful is less than 10 people acting out in an noncohesive way This is weak management and a lack of focus
> My guys were time reporting into 3 different tools (and this is a Who is the fscking idiot that calls himself a startup founder and makes people report in 3 different tools?
Tackle the backlog - those bugs that have been just sitting there for months or even years because other things keep getting prioritized above them. They may be minor, low-priority fixes, but when you solve them, what people will think is "Wow! This developer fixed a bug that no one else could in 3 years! That's always annoyed me but now it's finally fixed!". Next thing you know, they'll be giving you the most import…
I'd also add that one of the big things to look at is the documentation and start improving it as a way for you to understand the systems.
Be aware that to do this in a time-efficient way, you might need to pull in one of the existing engineers who can give you the lay of the land.
Start fixing long standing bugs nobody wants to address because too complex
You need to exercise skill of being able to do an organised exploration of the codebase, probably producing documentation along the way.
The bugs give me an overview of the system and let me develop my mental map of the code base, the performance problems give me an overview of what's been done wrong.
Now, take a step back. How easy was this? It should ... must... be absolutely frustration free. If not, fix that.
To come up to speed on the tech stack, go sit with the other developers. Get a feel for how they are using the technology. Then, start picking off some smaller issues from the backlog and try and fix those.
Don't make assumptions. Learn the tech without an opinion. Sure, you won't like some of it (nobody likes everything), but find out if the team likes it. If they do, don't try to change that.