> As a side-note, creating external deadlines is also a great way to rally a team
My experience with this is that external deadlines work for teams that are unfocused and whose own motivation is low. However, for a team that is already executing well, an imposition of an external deadline (especially for a reason as poorly-thought-out as "to rally the team"), if it's aggressive enough to see increased throughput, will lead to poor processes, cut corners and burnout.
Perhaps there is an element of rationalization here, where a poor manager, who failed to anticipate at a distance a goal that was then attainable, becomes aware of it once it is closer and in danger of passing by, and has to make huge efforts at re-prioritization and motivation to meet it. In hindsight, the manager rationalizes that the fire drill was a good thing for the company, because obviously, the deadline was achieved! Oh, and look, next week there's a customer coming on-site, wouldn't it be great if this other feature was added in time for that...?
I have not had to build and lead a team yet myself, but the process I would follow, and the advice I would give others, is to choose to work with a focused, motivated team, and reduce the importance given to external deadlines. They should influence the prioritization given to relative projects, but cannot be used to crank the throughput nozzle.
Once you do lead a team, which I'm sure you will do in the future if you're so inclined, It can be a bit harder than you would think! Even a team of all A players can flounder and never produce anything if you're not careful.
For me the thing is that you just have to constantly adapt your plan as things develop. I don't think deadlines are inherently bad. But if you do set deadlines, the team needs to be a part of that process and the goals need to be based on reality rather than just arbitrary. If you have hard external deadlines, then that may dictate the features you can deliver. I find that developers (myself included) appreciate being able to focus on their individual tasks, knowing that the manager is making sure the ship is heading in the right direction.
I've found that teams (and individuals) function best when tasks are either scope-delimited or time-delimited. Not both, and not neither. If the task is concrete enough that the desired outcome is crystal-clear and there's not much risk in completing it, then just say "It's done when it's done" and let someone work at it. If the task has fuzzy success criteria - "Make this UI better", for example, or "speed this up as much as you can", or "explore new approaches for this module" - put a deadline on it. It's possible to spin your wheels forever if you don't have a clear destination and clear timeframe.
I would say proficiency makes motivation even more critical, because proficient people know they can go wherever they want, so they're less inclined to put up with bullshit.
A-players don't need artificial deadlines because they are already pushing themselves hard to deliver at a solid pace. And if they slow down on something or need to take a more moderate pace for a bit, it is often to manage against their own risk of burnout and once they recover, they are back at it.
Unfortunately, you can run into situation of mixed teams of A-players, B-players and C-players. While the C's should probably be let go, B-players often need deadlines because they are not driving things forward enough on their own (or they would be A-players).
I have not found a good way to solve for this in a manner that doesn't constrain the A-player by the arbitrary deadline as well when they are all working on something together.
Personally, I hate artificial deadlines. I want to do good work and put it out there when it is good enough to go out there (not perfect, just good enough), and not have to rush. Rushing leads to mistakes and overlooking things.
And its totally possible for a supposed 'A player' to suffer a dip in productivity (due to, y'know, LIFE) and its similarly possible for a B player to upgrade to an A given enough experience.
Overall the whole A/B/C boxing just smacks of 'humans as resources'.
Is it just me or the whole "I have to be an A player" just another way of dividing everyone into winners and losers, good or bad?
I have a theory that because American society is so ultra-competitive it alienates people who think it's impossible for them to ever be "winners", leading to Some of these people to "win" by shooting the Winners and the indifferent.
Are mass school shootings done by C players so think they won't ever be A players and who take it out on the perfect As and indifferent Bs?
I've caught myself thinking things like "I have to be the best in the world or I'm going to be stuck in $DEADENDJOB". That can be detrimental and have the opposite effect to what you want.
Over the past while, I've become more proactive and I'm trying to make positive changes in how I interact with co-workers and what I do and don't get involved with at work. Even if you do believe in "A" players, there's a limit to how much one person can take on and manage.
Never said anything along the lines of "humans are resources."
In fact, I specifically addressed the case of an "A player" having a dip in productivity, and essentially said there is nothing wrong with that. They manage their time and their output accordingly to strike an appropriate work/life balance to take care of what needs to be done outside of work, and also manage against burnout when they've been pushing too hard for too long. And the fact that they manage this effectively on their own and can get back into things is part of what distinguishes an "A player" from a "B/C player."
The A/B/C boxing is just a shorthand for categorizing overall performance of people on a team. But if you think it is an inappropriate way to classify individuals, I'd love to learn how you approach it, and how much management experience you have with that approach.
I never said you mentioned anything along the lines of "humans as resources" - I meant that the A Player mentality lends to this. Apologies if it came across any different.
My issue is that A/B/C boxing is almost binary view.
You're either good or you're not.
Life isn't that simple.
I've worked with fantastic developers who are a pain to communicate and participate on a team with. I've worked with average developers who can anticipate customer needs from a spec better than most and are energising for a team. I've never worked with someone who is excellent at all facets of their job. I have worked with some people who seemed hopeless at all facets (though it always struck me that they're in the wrong sector rather than just being completely useless individuals).
The largest team I've led has been 5 people whom I had much experience with and so knew various strengths and weaknesses.
And I'm rambling here but that loops back to my first point: people have strengths and weaknesses and boxing them into lettered teams just ignores this.
Totally agree that life is not that simple, and that people have various strengths and weaknesses.
The boxing is simply a way of summarizing those in a simplified (perhaps overly-simplified) manner.
If a developer is great at coding but a paint to communicate with and has participation issues, that honestly strikes me as a "B player" if communication and participation are key parts of their job. If not, then those factors aren't as important in terms of weighing overall performance, and that could make the same person an "A player" in a role with differing responsibilities.
I also have never worked with someone who is excellent at all facets of their job. The question is, are they excellent enough at the core aspects of the job where their weaknesses are sufficiently offset. And this is where you can compare team members. It all comes down to their responsibilities, the needs of the team/business, and how they are tracking against those.
So to summarize--everyone is indeed unique in terms of strengths and weaknesses. But at some point the weighting of those strengths and weaknesses tends to crystallize into something more easily categorized as a higher-level bucket of "exceptional", "meets expectations" (and that's not a bad thing), or "needs improvement." A/B/C is just a shorthand convention for that.
Not long ago there've been an article here at HN about how the existence of A, B, and C players is a consequence of bosses labeling them, not of the actual players.
It claimed exactly this mentality, where, for example, A players are allowed to manage their worload and avoid burnout, B players have little liberty, and C players had none.
Not that I don't think everybody is as capable, but the environment's influence is so great that, except for a really small amout of obviously incompetent people, you won't have a good idea of who is who.
Agreed - 75% of those labels are management's perception - which is often wildly innacurate
Maybe A,B,C players was an insightful distinction at one time, but now it's such a cliche that the only people you expect to say it are the ones that sleep with a copy of Jack Welches autobiography under their pillow
I normally wouldn't respond to such an unconstructive comment, but I'll bite.
In any team, there is often a sense of some people being better at their jobs, or performing at a higher-level than others. If they do it consistently enough and progressively tackle higher-level problems, that is a good indicator someone might be on track for a promotion.
If someone is good at their job, but doesn't really push themselves to improve, that might be ok for the time being depending on the role, it just means that person is less likely to advance, or advance as quickly as the former person.
And then you have people who are very clear underperforming. Whether it be lack of attention to detail, poor communication, letting things slip through the cracks, or just not doing their work. If you can work with them to improve in the areas needed, awesome. If not, you often need to get them off the team one way or another.
There is nothing dehumanizing about this. It is recognizing people's strengths and weaknesses, and trying to optimize accordingly for the best outcome. Further, to pretend that this dichotomy does not exist is sticking your head in the sand.
At the end of the day, regardless of the category these individuals fall into, they are people, and I never said otherwise, so I don't appreciate you trying to paint me as such. Not all humans are equal at their jobs, and if you can't identify that and adjust your management style and approach accordingly, you can't be a successful manager.
I don't think they were trying to paint you in any way. The whole "A player" thread of thought is quite common in tech - I think this is what he was getting after.
I'd disagree his comment is unconstructive and argue that the aforementioned philsophy is a _destructive_ one.
Another way of saying this : a lot of B and C players are really A players working for the wrong person. A lot of how productive and successful engineers are has to do with the environment they are working in.
At least by this definition - the one implied when A players 'manage the risk ofburnout' indicating that a critical part of being an A player is working enough hours that burnout is a risk.
If we take that away, the terms are as good as any, and I think it does a disservice to believe that all employees (sw engineers in this case, but in general I suspect) have equal capabilities.
In the context of my engineering experience, I consistently see ~4 strata. Not all levels may be present at a given company.
* Outstanding - has vision not only about how to do something, but why they need to be done in the first place. Open to helping others learn and improve. Has a way of being able to demonstrate that his or her plan for things is the best approach - and can accept when it's not. Is quick to learn both the internals of a system, and internalize the bird's-eye view of it as well. As such can design complex interactions between components.
* Excellent - just under 'outstanding'. This person gets things done with little direction, but gets lost in the weeds sometimes. Has a deep knowledge of the system and troubleshoots well. Can design key components of the system. Can often grow to 'outstanding' over time.
* Good - Needs direction to make the scope of problems clear. Can usually find a solution to a problem on his or her own - it may not be optimal, but you can be certain he or she will understand it thoroughly. Good troubleshooter. Can design small changes.
* Adequate - give them a spec and/or strict instructions, and they'll get the job done. Don't come to them for any deep understanding of the system - unless you have years to wait for that knowledge to seep in via osmosis or repetition.
Note that none of those mentions as criteria, "willing to go the extra mile", "works around the clock", and "buckles down and see crunch time through".
I think when you add those additional criteria is when you get into dehumanizing territory.
I think it is worth noting that "risk of burnout" is not something solely generated by working excessive hours.
I think it is a lot about focus, and the type of work. If you are 100% laser-focused on something in a very stressful situation, you can still burnout from spending "normal" hours on it without overtime.
For example, if I'm running a major holiday promotion (and I am), that is incredibly stressful from a cognitive load standpoint. The actual tasks may not require me to burn the midnight oil, but I sure as heck need a mental break afterwards. Whether that break is actual time off or just switching gears to something not as mentally demanding is a separate issue.
Individuals who can constantly be laser-focused on mentally straining tasks are a rare breed. I'm also not sure how healthy it is for someone to keep that pace up.
It's insane how prominent talk like that is. At this point HN is like being part of the Muslim community that never says shit against the radical elements in the community. Good response, enough of the alphabet soup bullshit, be a human.
Yes, it irks the good team that there are new "deadlines" being set as if they can't meet the deadlines assigned to them. It is really lowering the team moral when done and should never be done. I was lucky to have an amazing manager for that one doomed project, we were 4-5 months behind timeline yet he said, "I am not going to micromanage you, I trust you that you'll deliver this on time" (he had been assigned halfway into the project), the project had escalated to one level lower than the CEO and the result? The team delivered! Because the team wasn't micro managed!
It doesn't sound like the guy said, "Let us search for an external deadline so that we can rally this team!" Instead, it sounds like a reasonable amount of time ahead he said, "Hey, there's a cool chance to demo this publicly coming up -- let's see if we can get it out there!"
Sure, the guy was in some sense a manager, but this isn't some corporate situation with external motivation as one of the few rewards. It's a small team of people who are into the idea enough to work on it on the side, to begin with. The article presents this as an internally chosen external deadline, and those can often be really useful.
The benefit of external deadlines, for me, isn't so much about motivation, but about prioritization. When you have a lot of stuff you could be doing, deadlines are an effective tool in ensuring you work on what is most important. I don't think they should be the sole or even primary tool for this, but they're pretty helpful.
I worked with Robleh on a memory game using images from Instagram back in the day called InstaMatch. I had made the simple game and published it, and he helped do all the marketing and design to make it quite successful. He was always great to work with and we made decent money until Instagram decided to stop having apps use any part of their name in the title.
In reality though, I'd like to know what the author did for health insurance when he quit his job weeks/months after having a baby. Medical risk is very high during this period.. looks like he is based in Canada (not US), so I guess that answers it.
I'm eternally bemused that the US considers itself entrepreneurial and pro-business when it doesn't get this.
Then again, if your cost of entry is much lower and more people can bootstrap from personal savings, they're all that much less likely to need investors just to stay alive, or to put up with demands for unicorn growth.
Even if you quit your job in the US, you're entitled to COBRA coverage for 18 months if your employer had more than 20 employees.
It allows you to continue the health plan you had at your employer, provided you cover the entirety of the cost. With Obamacare, COBRA is not necessarily cheaper now, but it was in the past.
When I left my previous job, I elected COBRA coverage because HSAs weren't available on healthcare.gov. I pay $280 for an HSA plan with a maximum deductible of $6k, dental, and vision in Texas.
It's not cheap, but it's not completely unaffordable either.
In contrast to all the cynicism I see in other comments, this is awesome! Even if it doesn't happen to everyone, I find anyone who can manage to survive building and pursuing their passion to be inspirational. It reminds me that even if the odds aren't good, the journey can most certainly be worth quitting your job.
As I start bootstrapping my own idea off the ground it helps to see stories like this. Being able to stay motivated and optimistic looks to be a helpful component of success.
Why would you quit your job to make an app? I have bootstrapped 3 apps and pushed them to the app store in my own time.
To be fair, every time I do it, it's hard. I have to prepare my family that I'm undertaking something that will take up a lot of my time. It's tough but, they know I love it.
I've done this before. I've failed every time, but quitting the job was more about regaining my freedom to decide how I should be spending my time. It allowed me to wake up and work on something I was excited about instead of hitting snooze 5 times before sitting in traffic for an hour and then being bored as fuck all day at work.
If you can afford it and you know you can get another job if you fail, it's a fine decision and I'd highly recommend it.
I've been thinking about doing this for a month or two. Mainly because, like you said, its so much better to wake up in the morning and spend your day pursuing the new business instead of 8+ hours being displaced from the venture and dreaming about it at work.
Right now, I don't have enough money to sustain longer than a month without a daily job. So, I guess the answer is to start there and build a little next egg over the coming months so I can have a solid 2-3 months that I feel I need to get going.
Unless you already have a product with some traction and at least some revenue coming in, I think 3 months is not enough runway. Something like 1 year is more realistic.
As far as my project, its getting a little traction with my IG feed (instagram.com/artjutsu_lightbox). That said, there's more improvement that needs to be done on the main site to really see if this can be successful (artjutsu.com).
I believe it will, but man is life ever-so-hard now with all these certs I need for my day job. Studying for those has taken all of my free time unfortunately.
Did you ever have trouble with keeping apart intellectual property created for your employer vs. for yourself on your own time? For example, did you use different computers and made sure to never do this at your work place? I'm always worried that this might become a problem if you create apps while still being employed somewhere.
I use my own machine. That and you have to keep in mind a few things. Does the company actually have the money to spend to go after a developer who made some simple app? Would doing so piss off their entire engineering department? Is it really worth it to them? Usually the answer is no.
Not that any of the above matters since I do this on my own time, with my own resources.
If you work for Apple (and I think the same for Google, Facebook or Microsoft), don't they own your output even if it's on your own machine in your own time? I seem to remember part of their contract is that they own all your intellectual output. Some other discussion of this here:
On the other hand, in Queensland at least, it depends on the definition of your work role. If it's specific enough, you could even create a game using your employers equipment & keep ownership & copyright yourself (the Queensland government provides that as a specific software example here):
I work at Microsoft. I don't speak for the company but feel like sharing my experience.
We do have to comply with certain restrictions (e.g. don't do it on company time, company property, company equipment; don't compete with the company), and I'd definitely read the full legalese before trying to make a paid app. But it's not anywhere near as bad as "everything you write while you work here is ours."
Apple does not claim ownership of your output that is done on your own time, with your own resources, as long as it doesn't relate to work you're doing at Apple.
I recently signed an employment agreement with them. It was the most fair one that I've ever signed.
I've never had a problem with that, and it's pretty straight forward IMO.
Work computers stay at work. My computers stay at home (or at least not at work). If I create something outside of work, not using proprietary data/algorithms/whatever from work, and using my own computers, then it's mine. I'd never work somewhere that tried to claim ownership of work I did outside of work.
Needless to say, common sense applies, and it's probably not a good idea to have a side project that competes with your employer (even indirectly), helps their competition, or makes them look bad somehow.
Articles like this always skip the most crucial point.
Author talks about "outreach" and press coverage and such. But how is that done exactly? I realize this might be dependent on the app but there has to be some general principles one can follow.
If I were to launch an app in the app store today, almost NO ONE would know.
How do you get from that - to real influencers writing about your app?
really nice and inspiring.
- how did you reach out to so many customers ?
- i see the UX of your apps are good. did you do them or you got a design agency doing it for you ?
I understand the sport in extracting the most uncharitable interpretation of a thing and distilling it into the most concentrated snark that you can, but amusing as that can be, you harm the community by posting it here.
Snark always gets many upvotes, perhaps because we enjoy the dopamine rush of briefly feeling superior to others. Such comments rise to the top, become emblematic, and pretty soon we're all in the habit of looking for clever ways to put others down instead of learning and asking questions together.
This is an existential risk to HN, since if we lose the open-minded exploratory quality of the threads (never secure to begin with, and always under pressure from stronger forces), successive waves of thoughtful users will exit, putting the community into a fatal feedback loop.
I think sanitizing the community possibly puts it at even greater risk. Look at stackoverflow whose contributors are dwindling due to overmodding. There is learning in this comment. You are the one layering on the interpretation of the need to feel superior. That wasn't how I read it.
Encouraging civility and kindness is no risk to a community that is at its best when people are civil and kind. The campaign to promote civility and eradicate meanness has been waged publicly by Dang for over 18 months and more quietly by PG and other mods for long before that. The overall volume of contributions hasn't gone down and the volume of thoughtful and substantive contributions had gone up, and for me it feels like a more safe and welcoming place in which to post thoughtful comments.
The point of the comment could have been made in a civil and thoughtful way if the commenter chose to do so, and when people do that, there is far more "learning" to be had and we all benefit.
That may be. I replaced "probably" with "perhaps".
I don't think "sanitizing" is an accurate description of what we do or call for, though I get that it's a rhetorical way of saying not to take things too far. Overmodding is definitely not the goal—undermodding is. The dream is to get it asymptotically approaching zero. That requires a self-regulating community, which requires a self-sustaining culture. Most of what we do, when not posting "please stop" and whatnot, involves figuring out how to get there.
> So how would have been an acceptable way for the commenter to make his point?
If by "acceptable" you mean better for HN, it's not hard to imagine a thoughtful comment about the difference between making money from an app product vs. an app-building shop. Also it would be easy not to belittle the OP's achievement (as "empower others to fail", for example, does).
I would start by not using the the Step 1, Step 2 format.
To me saying they sh*t on the other person is accurate because to me he is not trying to offer anything constructive. I understand your opinion may differ.
To be fair, most of the money in mobile apps is in helping big companies put out apps to engage their customers and show they're not obsolete dinosaurs.
Come to think of it, pretty much all of the money in startups comes either from making lucrative big companies obsolete or selling software to big companies to assuage their fear of becoming obsolete.
My experience with this is that external deadlines work for teams that are unfocused and whose own motivation is low. However, for a team that is already executing well, an imposition of an external deadline (especially for a reason as poorly-thought-out as "to rally the team"), if it's aggressive enough to see increased throughput, will lead to poor processes, cut corners and burnout.
Perhaps there is an element of rationalization here, where a poor manager, who failed to anticipate at a distance a goal that was then attainable, becomes aware of it once it is closer and in danger of passing by, and has to make huge efforts at re-prioritization and motivation to meet it. In hindsight, the manager rationalizes that the fire drill was a good thing for the company, because obviously, the deadline was achieved! Oh, and look, next week there's a customer coming on-site, wouldn't it be great if this other feature was added in time for that...?
I have not had to build and lead a team yet myself, but the process I would follow, and the advice I would give others, is to choose to work with a focused, motivated team, and reduce the importance given to external deadlines. They should influence the prioritization given to relative projects, but cannot be used to crank the throughput nozzle.