Hi, I got here from a link in your job posting that I’ve seen around a few times of recent. I was a bit interested in it the first couple of times I saw it, so if it’s okay I’d like to say why I didn’t apply:
It’s nearly impossible to find any info on what a potential employee can expect. Yes, you’d work remotely with a specific set of tools, but that’s about it. The posting speaks 100% about what is expected from the person and nothing about company, team, benefits or culture. There’s a link to a handbook that also only talks about work processes. Not much about it felt welcoming. I empathize that times are hard lately, but it also isn’t encouraging to be linked to this forum, and the first post I see is from a stressed-out developer.
The work itself seems interesting but you should consider making a broader appeal in your postings/on your website if you aren’t intending to give off the vibe that potential employees will join just to be worked to the bone.
Welcome to the forums. Your feedback is useful here-- I take it you’ve already read about our values and vision and our Open First philosophy in the handbook. You are right that compensation isn’t yet in the handbook-- we’re working on that one. Aside from those items, could you tell us more about what you would like to see in the handbook?
I’m actually one of the less stressed developers right now (in fact-- these days I do mostly sales rather than development)-- it’s my intent to make sure we don’t have issues like this continually and that we don’t leave our team members stressed out-- and not because it’s my specific ‘job’ but because I, like most (perhaps all) on the team, I take ownership of the group’s well being here.
You’ll see that we’re not sweeping the issue under the rug-- we’re facing it head on, and publicly for that matter, because we believe that instead of trying to conceal that we’re having some capacity problems, or pretending that things are perfectly rosy all the time, we’re more interested in dealing as honestly as we can about what’s happening and getting feedback from the team on how to fix it.
I would hope that the fact this thread has been made public and you see team members actively working to solve the problem should demonstrate some of our culture of openness and collaboration. However we are always striving to make things better, so if you have specific feedback on what you’d like to see in the handbook, I will schedule a ticket to add what I can to the handbook, assign it to myself (or one of the recruitment handlers, if they would like to take it), and schedule it for one of the upcoming sprints. Thanks!
Edit: Just realized a lot of what you were talking about was about the posting specifically. You’re right-- the posting could use a workover. I’m going to create a ticket for myself to add more cultural information up front. Right now it does seem intensely generic. Thank you for this feedback!
Thank you so much for replying here @diso! This is really useful feedback.
It’s totally true that we’re not very good at emphasizing the positives about working for OpenCraft on this forum – and there are many. We’re engineers, and so we focus on problems, not the good stuff We can get better at that.
Maybe a rewrite/refocus of some of the introduction and values areas of our handbook? There’s a lot of technical/process detail in there, but the culture stuff doesn’t get much revision.
Adjusting start dates could buy us some time, so that’s not a bad suggestion. But it doesn’t fix the issue, so it would have to be in combination with other things.
Can we slow down any of our existing large projects by reducing the monthly number of hours committed?
Yep, it’s a goal, and our targets are ambitious, based (I think) on capacity increases continuing the trend started last year. But it’s still less important than client work, so if we have to drop this % down to fulfill our external commitments, we should.
Of the people we trialed who didn’t work out – did anyone have any particular criticisms that might be usefully applied? We’ve been trying to improve our onboarding process, but maybe there’s more we can do there?
I’ve scheduled Log in - OpenCraft for updating the job posting. It’s in review already, as it turns :)
I’ve scheduled Log in - OpenCraft which covers updating our handbook for the business sprint after this one (or, the next developer sprint, since BizDev sprints are one week and Dev sprints are 2).
I’d also be interested to know this.
We’ll need epic owners to chime in here. Are any of the epics you’re running able to be slowed down?
On a somewhat related note: I feel like we’ve reached a pivotal point in our growth. From some time I’ve been entertaining the idea that OpenCraft should consider retaining the services of an organizational development (O.D.) consultant, specifically one that specializes in remote/software companies. It’s very niched, and therefore would probably be hard to find, but I think receiving ad hoc help from such a person could be very beneficial for OpenCraft. We’ve been able to successfully implement a number of truly ground-breaking work processes, but I think that receiving help from a HR or OD specialist could help us set the course for the future. Or maybe not, but at least we’d have tried! Anyway, my 2 cents.
As far as I can see, all of us are proud that the small white dot at the bottom of the opencraft.com website blinks with our name on the map. We love to work with OpenCraft and we are an entertaining and welcoming community. I can say without any doubt that everyone likes to work with any of the team members, also we always eager to help each other. Despite all these, this is not represented on our “primary” (self-)marketing forum, our website.
As a newcomer or someone who is trying to get information about a company, it is among the first things to check the website. As a developer, check its quality, content, and of course, how is the culture – regardless of the organizational structure or employment type.
What do you think about having a dedicated page about – not the individuals, but – how it feels to work with OpenCraft? I think it is beneficial during the recruitment and it can give some insights even for potential customers.
Don’t take me wrong, I mean it in professional manner, not some random pictures about team buildings and similar.
@Fox I think it is a really great topic that needs attention!
PS: it is so good to see comments from outside of OpenCraft, thank you for the feedback @diso!
This is an interesting idea. Maybe we could have Fixate design something for this? We could rename the ‘Jobs’ page ‘Join Our Team’ and have a sort of overview of the company from a member’s side with nice graphics, and then links to the current postings.
This is a good idea. I think it may help us in the long term. If they are highly specialized, though, it may take us some time to find one. Would we be able to start the search for this specialist and in the meantime contract a more generic headhunting service? @usman, @paulo (and @sid, when you come back) would you be willing to create a ticket to start on next steps for a headhunter/O.D. hiring, if these sound good to you?
Does anybody share the feeling that we’re the experts? Which is to say:
I doubt we’ll find a person that can pull solutions to our highly specialized problems out of a hat. Yes, there are larger remote, open source companies (Canonical, maybe some divisions of Redhat), but none I’ve ever heard of with OpenCraft’s particular blueprint. I’d go as far as saying that in some respects we’re more like Debian than a for-profit company (which is a good thing!).
Once we solve this phase of our growth, I think OpenCraft can start selling O.D. consultancy for this particular niche. (Dead serious: I consider doing it myself, from time to time.) Doing remote right is hard. Doing open source right is hard. Doing it all and making a profit, while being “open first” no less, is even harder.
Which is not to say that we don’t need somebody to sit down and think about the problem and try to find solutions. It’s just that maybe that(those) person(s) should be from our own team… once we have capacity, of course. ;)
PS: Re-reading this, I imagine it can sound like I’m volunteering. I’m not. There are many core members that have been here much longer and are much, much better at OpenCrafting than I am. Pretty much still have my training wheels on.
Now that I’ve had a chance to read closer on the O.D. Wikipedia entry, I have noted how strikingly similar it is to the work we’ve already been doing. I know I’ve actively engaged in many of the activities listed and didn’t even know there was a name for it.
This would probably go with our push to open up the other side of the business alongside the process manager-- since as we’ve discussed previously we want to be able to expand to market and sell consulting and software around our async processes. So yes, that’s a great idea long term-- finding a way to promote from within an O.D. specialist.
That’s a pretty big caveat… luck and timing will play a huge role in getting us through here, so success doesn’t automatically qualify us to bottle our approach and sell it.
But you’re totally right: doing all of this is hard. And the sheer number of hats we all wear, each day, is part of why hiring the right people is so difficult to do. I wouldn’t propose to add yet another hat by adding O.D to our consulting services. But I do think blogging about it would help other organisations like ours.
While I’m totally in favor of requiring previous open-source work for candidates, I think it could be a big barrier to entry for many who would otherwise be good candidates; in my case, most if not all of my contributions were done as part of my job but they only happened because I took the liberty of doing so, some times while omitting the fact to my employer .
One of the ways in which we could lower this barrier could be introducing bug bounties.
Pros:
candidates without previous open-source contributions can get paid for their work to meet that requirement;
might put some candidates that wouldn’t otherwise apply (for whatever reason) on our radar;
allows us to offload small but perhaps important pieces of work.
Cons:
extra work to maintain the list of open bounties (but not too much hopefully).
I think this is a very good idea. We have already been discussing adding a step in the interview process where candidates would be paid to submit (and merge) just such a type of issue. But the problem with the during-the-interview approach would be that we’d have to give each candidate their own bug.
If, on the other hand, we have a list of open bounties and some people work on them simultaneously, whoever gets the fix merged first gets paid.
I’m not sure we’d want to restrict the pool of candidates to those that got bounties, though. But maybe we could do both simultaneously, until a time when the bounty list is popular enough to generate enough candidates for our hiring needs.
This was a really poor choice of words what I meant, of course, was that I didn’t think it was necessary to ask for permission and went ahead; by contrast, I’m pretty sure many developers don’t work in an environment where that’s possible.
It’s worth noting that we used to do this. It was part of my interview process-- I’m not sure if we had the extended trial period then, or if this was the last step. An Open edX bug was selected, and then the candidate was to fix and submit the bug. They were paid for the hours, but the biggest problem with this approach was the amount of time it took. It was highly dependent on when Open edX would review a bug.
However… Now we have core committers. So if we made the bugs be within an area where Open Craft has Core Committer access, this might not be as much of an issue anymore.
Would we want to do this for all candidates or just for those for whom we had little to no evidence of open source contribution?
What @joao.cabrita suggested and I seconded was the other way around: we pay a pre-determined sum for merged bounties, and then we interview/trial from the pool of successful bounty-hunters.
Ok. That sounds like it could run concurrent to our existing recruitment process, and might be worth trying. It’d be a great way for people who are peripherally interested in making contributions but otherwise wouldn’t be able to justify the time to make them. They might not even specifically be trying to apply in this case, we’d just reach out to them as a contact afterward, yes?
I like this idea. It does sound like it’ll take a bit of dev/process building work to get going, though. Would be curious to get more of the recruitment managers to weigh in, and see what we can schedule in the future.
Maybe @joao.cabrita or you might want to run a discovery on how to implement this so we can get an idea what it would take to make a reality?
If nobody else steps in, I can try and find some time on SE.247, yes. But as you suggest, it’s a good idea to get the other recruitment managers’ takes on this (@usman, @paulo, heads up!), and of course Xavier’s, as this is going to cost money, after all. (Are we still allowed to ping him here in the forum for things like this?)
@adolfo I don’t think we’re supposed to ping him here, but what you could do is create a task to review the discovery and add that to the management board. He DOES, however, have a task to review this thread, and I think he may be doing that next week.
I’d go ahead and create the task now and schedule it, along with a management task for review. He should be through the thread here before then and can tell you to cancel the plans if he has an objection before then.
We can get better at that.
.
what I meant, of course, was that I didn’t think it was necessary to ask for permission and went ahead; by contrast, I’m pretty sure many developers don’t work in an environment where that’s possible.