Completely agree, I left out the "other side" of leadership, working with other departments and senior leaders as it seemed out of scope of the question.
I put "optics" in quotes to use it as a pejorative as I only seen it used as a strawman. eg. "Your team is never at their desks... it creates bad optics". I prefer to file that under transparent communication between all sides of a company.
In one particular case it was a team that 19 times out of 20 hit every goal and expectation on the product roadmap on time to near 100% ask. As a snarky and sarcastic asshole my response was of course "Do you want to potentially sacrifice the fact that we nearly hit every roadmap deadline and OKR in order to make it "seem" like they are working harder?".
Note: This is based on the startup world... Its never senior management who does things like this as often all they are about is the company they put their blood, sweat, and tears into is successful and cant afford the luxury of ideal "optics". This is an argument/toxicity that comes from less experienced "leaders" who needs to find fault to make up for their lack of success or are micromanagers themselves.
As someone who's been leading people for 8+ years and also who remembers why I have left places... here is a long but comprehensive list.
1) Pay Fair at hire and try to keep it within the market as they grow in experience/skills.
2) Give opportunities to learn and grow based on their own personal/professional goals.
3) Be Communicative and Transparent when it comes to everything.... company/leadership asks, values, deadlines, hiring, firing, promotions. Attempt to have documentation/processes for these things so theirs no question in ambiguity or favoritism.
4) Have check-in's often and Listen to the wants, needs, issues of each individual. Attempt to quickly get back to them with a solution or at least an answer/explanation.
5) Create a 'culture of winning' where wins are always celebrated and mistakes/failures are treated as actual learning opportunities to improve.
6) Ensure everyone has a voice, it is heard, and people feel safe to be critical as long as its constructive.
7) Do everything you can to eliminate toxicity... weather is from members on/under you or above you. You cant stop others from being toxic but you should be able to shield most of it from those who report under you.
8) Since you should have the authority EVERY problem you have or those under you has and its then YOUR problem and your job to fix it (or at lease respond/escalte).
9) Judge people based on objective results not on "optics". Ass-in-seat time is a lazy and pointless measurement in most cases.
10) Delegate and empower those under you as much as you can. Lack of autonomy/ownership are signs of micromanagement, over-control, and poor leadership/delegation.
11) Accept a truth... your reputation/success as a leader is a direct aggregation of the success of those under you. If in anyway this is not the case there is a problem and that problem is you.
Scrum, Kanban, scrumban, tickets with predefined checkins... all can work.
"Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders.
A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.
As a manager you are responsible for your department those responsibilities dont magically poof away because your on vacation. If you have successfully set up your team/department in a way that you can "go dark" for your time off (e.g. no need of your knowledge, and proper key teammates can step in for you to interface with other teams/departments) then great, otherwise you should expect backlash if something goes wrong.
I have been in the startup world for like 13 years, and have been everything from an IC up to CTO. This is IMHO:
> a) has Hacker News/YC ever seen a startup fail because the codebase is so bad.
No, but I have seen the mass velocity hits from short term decisions living on over the years. Tech Debt is real and can eat into 20 - 60% of a teams output because of bugs/issues/lack of documentation & context. These places are miserable to work at.
> b) what is the best calculation to make when trading off code quality vs features?
Unfortunately this may not be a popular opinion but here is what has worked best for me. You need a sound ARCHITECTURAL base from inception, to do this the person who makes the decisions or is in charge needs to use tools/languages/etc that they are experienced with to develop a clean base to work from. Its not hard to set up CI/CD, unit testing, proper devops, and code decisions like inversion of control, and proper service segregation from the outset IF you use technologies you are strong in. This lets you move quickly if need be but the "bad" code is limited to services/systems. Its easy to fix a single poorly coded rushed class/function/file. Its a nightmare if your entire basis you build off of is crap.
Startups tend to be limited on time... and sadly often startups hire inexperienced people who cant do the above or experienced people who focus more on shiny new technologies then using things that work and and be quickly executed.
c) do most YC startups write tests and try to write cleanish code in V1 or does none of this matter?
Never been part of a YC startup, but I would say my general experience is that when your still figuring out what your product/market fit is things like scale/code quality/architecture shouldn't matter... however two things need to be kept in mind. The first is having an "escape hatch"... this code is crap we all know it but its the code we need right now, is their a way we could pivot/transition to a new system/architecture in a few weeks when we finally get funded or "grow"/"scale". The second is identifying that pivot point and investing time to create the the first generation foundation (if you go full unicorn/scale again you may need to deal with this yet again).
In conclusion you need to do what gives you the most velocity for your effort, this means when you are super small and still figuring out the basics a costly foundation inst worth much. Then if you survive and shift into growth mode you need to expend some effort/rescourses into a good base to keep that velocity alive.
So they need a set bushiness and tech teams to build an internal ad stack, and try to get advertisers... many who wont buy in without 3rd party tracking to mitigate fraud.
- It makes it easier to parse information, reread, and catch things like hey 2 people are working on the same thing.
- Helps catch people stuck/avoiding work as you can see someone on the same task for 5 days, or rotating between 2 to 3 tasks when none are done.
In terms of discussions, questions or post standup followup, a thread tends to get started per checkin which could lead to a meeting. This also creates a good historical trail for when issues come up.
Though I am a huge slack fan, having a channel per project/epic and any conversation had or meeting gets summarized and put back into the chat
I keep seeing things like this, people hating on the delivery companies. Customers moving to takeout and restaurants moving to self delivery.
Its pushed me to have my quaranteen/layoff project be to create a competitor that supports only self delivery and takeout but has the order, management, aggragation functions, and crm of the competition for a low flat fee (plus cc fees).
Redux always had to much boilerplate for me to prefer it.
The last couple years I have been using the new Context API and spliting my app state out by creating a global context, and many domain specific contexts where the context contains both the data and functions used to work with that data. Typescript + state with data and functions created a great api per domain. I found this approach just as clean but with less boilerplate.
Though redux does have some performance and tooling benefits.
I dont know if it was because of wework but I interviewed some od rgw top engineering leaders at meetup for replacing leadership roles at a startup I was consulting for. I gained a lot of insights into the engineering org at meetup.
As someone who looks at a "growing" startup up as 30-100 people the "bloat" of the company had me beside myself. Its a site where you search/join/pay to have groups meetup. Why do you need 10 different engineering teams with managers, directors, and VP's?
Conversation points like "I only lead the api for payments" and "how did you launch 5 features in 3 months!!!! Makes me wonder how much bloat, inefficiency, and dead weight exist in such companies.
Disclaimer 1: I get companies in certain spaces requires slower and more careful development practices and policies such has fintech and medtech, i do not consider meetup fitting those criteria.
Disclaimer 2: The startup I consulted for, asside from the founders, executives, and senior management had a great work/life balance so it wasnt like the engineers were doing double time effort, they just focused on being lean and efficient.
Any JavaScript/React or Scala engineers in NYC (and some remote opportunities). Looking for a job my company dv01 has a lot of open roles. Currently doing interviews over hangouts.
Thanks for the insights. Personally as a manager I give as much autonomy as I can trust a person. If you ass kick and get shit done the last think I want to do is hinder you.
In terms of honesty and transparency I feel being open and honest to a fault is the best practice. That and also having.my directs feel comfortable challenging me... I make the final decision but its thoes under me who do the work.
Lastly I personally hate "hands on" management roles... all that does is two things:
- have two critical paths... one for managment bullshit plus individual contributor work that are always in conflict
- make me just a god level tech lead as if I am working on a system of course ill.choose tools and processes that fit me best as an IC.
I once interviewed at wework for an engineering manager position....the projects they were working on were.... asinine... I couldnt nearly keep a stright face on what I felt they were pissing money away on. Funny I didnt pass the first
in person :).
Sorry I dont see value in spending millions in some ar rig to project how an office space may look. It would take thousands of buildings decked out to make.the cost worth it... how stupid...
Honestly php seems like the common cold... an annoyance that is everywhere and treated with little seriousness. However every evolution it gets better and stronger and adapts other learnings from other languages. It really shouldnt be treated as a joke any more.
Ps: I love php and jquery... not for any real saas systems but no other tool set allows me to spin up and prototype full web app prototypes in sub 90 min. As a senior tech manager php and Jquery allow me to show functional prototypes quickly and easily get buy in from other department stake holders.