Founder of Slite here, your reply is spot on, we try to be as honest on the pros and cons of remote when we think internally of the future of this market, and when we share our research or insights outside.
It's not all pink, and our mission is very much to remove the roadblocks, so we need to acknowledge the issues that prevent remote from being seen as a no brainer
by some teams today.
Hey there, just wanted to say as a remote junior dev who has been at it for about 10 months now, that I appreciate the article a lot. These 10 months have been the most difficult of my life, professionally speaking. I was assigned a mentor, but there were no training exercises, or "easy bug fixes / small wording changes to make, so they can focus on learning the workflows" quite the opposite actually, and no processes explained or documented anywhere.
I'm a bit older and I couldn't imagine going through this as a fresh grad out of college. I would have loved to have had my hand held in my first days as a dev. I was constantly demoralized by not having the domain knowledge (and not having any comprehensive documentation to learn it), being assigned complicated stories (that even the mid/senior devs had trouble with), and by not having anyone just regularly check in with me and make sure I was doing ok. I would like to continue working remote indefinitely, but man it was really tough starting out as a dev remotely. I say all this to say I do think it's possible to successfully onboard a new dev remotely, but there has to be a plan and resources available to do it and I think your article is a good template.
Absolutely, we onboarded multiple junior folks over the year, but always put special care there, it needs a very different approach to any new remote teammate.
Out of curiosity do you foresee Slite hiring more junior devs in the near future? Sounds like an awesome place to work that's more aligned with my goals than my current place of employment.
It's rough out here! I'm still very grateful to be in this career and things are (slowly) getting better. If I ever end up in a senior position I will insist on better onboarding practices for junior devs if poor ones exist.
Slite.com (YCW18) serves exactly this purpose. Full disclaimer it's my company, but this is the core issue we are tackling.
2 classic pitfalls with knowledge are
- what do you put in this word (for instance are meeting minutes "knowledge"?)
- how static you think it should be
If you only envision knowledge as static processes, traditional wikis work.
If you want all your team to contribute and for this knowledge base to be a daily used tool, with all the information that matter you need another setup and we are building Slite for this (happy to have feedback!).
We clearly have a lot in common with Quip. The main difference as of now is organization : Quip is organized exactly like a google Drive, with nested folders while Slite uses channels. It makes the content accessible, permissions easy to manage and actually shows your team important changes of the content.
The other thing really different that we're building is integrations: Quip focuses on in-editor integrations (which are great, we're working on those as well). But for the rest, unlike quip we keep a simple markdown-compliant (& thus universal) format, which let us fetch and push content to all your toolchain.
This import is there to let you invite your team more easily after signup. You can absolutely login with email password if you want to avoid that but do note that it's just an helper, the app won't send emails by its own.
I realize this can be a little bit (sometimes more than a little bit) of a development overhead to manage, but isn't the right way to do this is to only require the minimum oauth scopes upon signing up, then add additional scopes and re-auth at the time it's needed (i.e. when someone wants to perform an import)?
I tried logging in but it says there doesn't exist a team to join. So when I try to create a new team using gmail, it asks for my connections.
I also assume it won't send emails on its own, but still it's information that shouldn't be necessary for me to share in order to join your application.
For the differenciation with Slack, the similarity really stops with the channels pattern. Using Slite allows you to separate use cases: Slack or equivalent to communicate instantly, Slite to write and retrieve information.
As a back story, Slack did try something similar a few years back: they built Slack posts with a similar vision in mind. But having those burried in threads and writing in a constantly ringing place defeated their purpose. From talking to our users, it seems like really few people use posts as they were intended in the first place. At the end of the day, having to organize your content and handling collaborative edition is a job for a standalone product
For the wording indeed, a teammate just mentionned the same thing on "public" wording, we'll think of a better term, "team-wide" maybe.
As for the templating option it's clearly something we're thinking about, the challenge is to make the feature simple enough.
Sure, this is something a bit special : we clearly have an easy way to get into new companies, there is no friction on getting on Slite for them.
The thing is we solve way more issues for teams between 20-200 people, as they are the one struggling with process and knowledge sharing. The strategy we have to convince them is by integrating in their workflow : if Slite can solve their issues while requiring a low-cost setup by integrating in their toolchain, we think it can prove value quickly enough for those teams to adopt it. And clearly Skype or Office will be at some point included in those integrations.
As for the Exchange servers to be honest I have no idea and it will highly depend on our users' demand.
It's not all pink, and our mission is very much to remove the roadblocks, so we need to acknowledge the issues that prevent remote from being seen as a no brainer by some teams today.