Hacker Newsnew | past | comments | ask | show | jobs | submit | alexeysemeney's commentslogin

folks, thanks for all your comments, didn't expect that. The main issue with the keys appears when you have a full-size keyboard and a laptop with a different set of major keys. And there is one more thing — tactile feedback.


In your experience getting actual work done with the new touch bar, what was your personal feedback on how it felt not to have the tactile feedback?


haha, that's a working model, I was that CEO for my very first company several years ago


How did that end up working out? Really curious about that working model.


Outline what would your dream product-/company look like (it's like describing the goal settings and features all around the goal), then start reading a ton of info on dif markets/trends/things you like etc - then write/discuss/trying different things. First ideas will be crap, but then the miracle will happen.


Hey Bryan, I have built several long term project myself (and continue to do so) and helped a ton of folks running http://devteam.space. Maybe you can apply this process to your new project (about medium below that). Here it is:

1. Project description. Plain simple explanation what your project does, etc. You might think it's an obvious and redundant thing. But it's not. It does help you to nail the project, define critical points and set all the team members with the same vision in mind. It should be 1/2 of the page.

2. User path. Describe how user finds you, sign up, start using it, what gets out of your project, why returns, and why be proud to tell others about it. If you build a marketplace/platform - build these stories for all types of users you have. This one is super important. It helps you to define bottlenecks, interface elements, user behavior, strong/week points, etc. It also can help you to describe your project to your potential users, so you could check if they are cool about using it. You might find you need to pivot without writing a line of code.

3. UI - describe it in the list form with several levels. It will help you to understand the real complexity of what you are building and delete unnecessary things.

4. Features list. You know how to do that already.

5. Tech specs. I guess you know how to do that too if this is not your first project.

6. Draw the UI on a paper. It will help the designer, and you will see some obvious things you should delete/add.

Medium - we use gdocs. Mind maps work well too because you can present the user path in a visual format and play with it changing pages/actions.

It sounds a lot, but man it saves so much time and resources down the road. If you need more advice - ping me at alexey(at)devteam.space - happy to help, good luck!


Ops, missed the "technical" in your question. Anyways, hope that helps.


thanks!


I have been managing remote devs for 4 years and now running http://devteam.space. So, have a decent expertise at that. Maybe you can apply it too. Here are must have rules:

#1. You need to have a PM for remote devs, on their side. Or decide who is the PM out of these remote devs. This person will be your trustworthy manager. If something goes not right, you talk to him/her first. Ask him to provide all the honest and bold feedback from himself and all the other remote devs if something happens.

#2. Request daily short updates from every developer. Just 2-4 lines of text about what have been done during the day. Explain to them that you will not actually reply to these updates. It's just to keep everything transparent. So, they write - you only read. Rarely reply with some questions.

#3. Set the goals on projects you work on with them, request deadlines, you can set it in sprints. It's like mini OKRs (google it if you don't know what is it). It helps them to be accountant and spend their working hours wisely.

#4. Have at least one 30 min call per week with all the remote devs to chat about what you are doing and motivate them with some good news. So they would feel they actually get paid not just for the code, but they make a difference for your company and for your clients. Share with them what you personally have done during the week. All people want to work with even better people, so it should be clear for them that you are awesome. They will respect you more. Basically, treat them as your usual team members.

#5. Use some reporting tools. At DevTeamSpace we have this kind of dashboard - http://i.imgur.com/F6Q3COn.png . Maybe it would be helpful for you too.

In fact, so many companies struggle to manage remote dev teams. If you need any help - ping me at alexey(at)devteam.space.


Do you also work with single remote devs, or just teams?


I like how you work, can you please contact me?


yep, ping me over email


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: