To replace the mangers, the AI needs to take care of the following pain points (got some help from chatgpt):
Hiring and Talent Acquisition:
- Candidate pipeline quality is inconsistent.
- Time-consuming resume screening and interview scheduling.
- Lack of diverse candidate pools.
Performance Management
- Biased or inconsistent performance reviews.
- Goal-setting lacks clarity or alignment with org OKRs.
- Lack of real-time performance insights.
Project Planning and Execution
- Estimations are often inaccurate.
- Project scope creep due to unclear requirements.
- Dependencies across teams delay execution.
Technical Debt and Code Quality
- Mounting technical debt slows velocity.
- Inconsistent coding standards.
- Hard to trace ownership for legacy code.
Team Collaboration and Communication
- Cross-team communication breakdowns.
- Time zones complicate decision-making.
- Meeting overload or lack of clarity post-meeting.
Onboarding and Knowledge Transfer
- New hires take too long to ramp up.
- Tribal knowledge isn't well documented.
- Onboarding processes are inconsistent.
Incident Management and Reliability
- Blameless postmortems are rarely actionable.
- Alert fatigue from noisy signals.
- Root cause analysis (RCA) is time-consuming.
Career Growth and Mentorship
- Lack of clarity in career ladders.
- Mentorship is ad-hoc and inconsistent.
- Managers don’t have enough time for coaching.
Engineering Productivity Metrics
- Metrics often feel punitive or misused.
- Hard to attribute impact to engineers’ work.
- Lack of actionable insights from engineering data.
Cross-Functional Alignment
- Product and engineering priorities are misaligned.
- Specs often change mid-cycle.
- Lack of visibility into roadmap tradeoffs.
Each of these categories will probably need an AI agent in itself and probably an AI agent to control all the other AI agents. It would be a complex system, but will still need some monitoring until it is self-sustaining.
Hi Guys, Flutterbud is my experiment while I was learning swift. The app lets you record videos and share with your friends at a scheduled showtime. The recipients cannot view the video before the showtime. I created the app using parse-server, S3, Heroku. Let me know if you have any questions.
Yunha, Great App! I have been using it every morning for more than a month now. I have explored Calm, Headspace, etc but I have finally settled upon Simple Habit. Easy to understand UX and great gamification.
I launched 2 websites before my current startup.
1. Drawmics.com. It was about social comic creation. It failed because I couldn't find enough creative people to post comic on the website nor could I get them to create comic on it. There was no organic traffic and people wouldn't share the comic. Didn't know how to sell.
2. Findero.us. It was location based QnA iPhone app. People could post questions defined by radius of city/state/country. Failed because I sucked at user-acquisition strategies.
Now that I am on my third start-up I could see what different things I could have done with my previous 2.
1. Build a product that solves a problem, however small, for a big audience. This means that you have to work on your product until you find that problem. If there is none, it will not work. I remember I read something about finding questions before finding answers. Questions are more important than finding answers.
2. Once you know you have the solution, go aggressive with user-acquisition and then fine-tune the product. People will complain about missing features, but you want scale before you go for product enhancements if you are solving a real problem.
I would be interested in knowing about what it includes and does not include. If it seems interesting, we may be interested in it. We are venture funded start-up.
I usually open up my Audible app and listen to books that are totally outside my field of work. Great way to make your brain think outside your domain.
The real aim of a startup is to change the world either in the smallest, unnoticeable way or at perceptibly larger way. When you do a startup, you want to address a problem and change the world by solving that problem. If you don't want to change the world, what is your startup trying to achieve?
Btw, nobody reads books because they make choices for you, or teach you how to make choices. In fact, books don't teach anything if you are not ready to learn.
For me, the acquisition is a failure on all levels. Failure to execute, failure in reaching beyond one's capacity to take the startup higher, failure in self-belief. Even though one may have earned money after an acquisition, the real aim of a startup is to change the world and not to get acquired and die.
But failure doesn't come cheap. For you to fail, you will need to put your heart and soul into the startup to succeed. And as spotman says "build something you believe in, that solves a real problem, and gain real traction", he didn't add that once you start getting offers for acquisition, stop believing in your idea and get lured by the offer and the riches.
I personally believe in one learning from "The hard thing about hard things" book by Ben Horowitz, is that you should sell your startup when you have reached your max capability to take the startup to the next level.
I don't care about 2014. My long term plan is to continue caring and loving my family and go IPO with my startup. One of the things gonna be tough but who wants an easy life?
Yeah, google comes to the rescue more often than not, but I also believe that such code that we put in leads to hacks which may bloat up as messy in the grand scheme of design/structure. For me a good code is something that has proper structure, good mechanism for communication between related modules and maybe, free from hacks :)
Awesome. This is something I try to follow. I use the same concepts that you have listed here. Conforming to the MVC pattern makes it easier to develop. Since my team is using Parse, we don't have to worry about Data Objects and Web Services, but we do have Controllers, Data Managers and Utility functions in our app.
I checked out your github account for the HN app and it is a beautifully written one. Great work.
Fair enough. I agree that the code has to be working but sometimes, even after laying down the guidelines on how to write code a better way to structure out, things go out of hands with multiple contributors. In my opinion, the solution to this problem is to refactor the code as soon as the code is checked in. Not necessarily refactoring the whole code, but to make it conform to the existing design and structure.
Thanks for the suggestions. I checked out the book by Michael Feathers and it definitely looks helpful. I have embarrassingly low number of unit tests which I need to take care of and introduce more rigorous testing into our code.
Working across teams and developers is one more reason to worry about the quality of the code. Sometimes the code written in not as per our vision and we end up refactoring it. But again, all these things are possible if there is some time at hand. For startup like ours, we are continually iterating and adding code proof points. This makes it difficult to maintain the quality of the code how much ever we want to.
I like your idea of documenting, though again, it's time consuming. We do it with helpful comments, but I think it is not enough.
We recently had this exercise at our mobile start up when we were deciding on stack. Like any other start-up we wanted to be nimble and fast, so we decided to use ready products with our start up. We chose Parse BaaS for our data, Dotcloud PaaS (PHP, CSS, HTML) for hosting. So the only major things that we needed to worry about involved HTML, Javascript, PHP, Objective-C.
Phase 1. Idea Strikes. Absolutely no doubts. The idea will kick ass and change the world.
Phase 2. Idea development, customer discovery. Doubt creeps in and starts to spread its tentacles. Now the numbers and figures start to play a role in the strength of the doubt. More optimistic figures weaken the doubt and fewer "likable" numbers strengthen the doubt.
Phase 3. The fight goes on. As orangethirty says: "Everyday".
Performance Management - Biased or inconsistent performance reviews. - Goal-setting lacks clarity or alignment with org OKRs. - Lack of real-time performance insights.
Project Planning and Execution - Estimations are often inaccurate. - Project scope creep due to unclear requirements. - Dependencies across teams delay execution.
Technical Debt and Code Quality - Mounting technical debt slows velocity. - Inconsistent coding standards. - Hard to trace ownership for legacy code.
Team Collaboration and Communication - Cross-team communication breakdowns. - Time zones complicate decision-making. - Meeting overload or lack of clarity post-meeting.
Onboarding and Knowledge Transfer - New hires take too long to ramp up. - Tribal knowledge isn't well documented. - Onboarding processes are inconsistent.
Incident Management and Reliability - Blameless postmortems are rarely actionable. - Alert fatigue from noisy signals. - Root cause analysis (RCA) is time-consuming.
Career Growth and Mentorship - Lack of clarity in career ladders. - Mentorship is ad-hoc and inconsistent. - Managers don’t have enough time for coaching.
Engineering Productivity Metrics - Metrics often feel punitive or misused. - Hard to attribute impact to engineers’ work. - Lack of actionable insights from engineering data.
Cross-Functional Alignment - Product and engineering priorities are misaligned. - Specs often change mid-cycle. - Lack of visibility into roadmap tradeoffs.
Each of these categories will probably need an AI agent in itself and probably an AI agent to control all the other AI agents. It would be a complex system, but will still need some monitoring until it is self-sustaining.