In order to make the move a success, in a company that still relied heavily on an email tradition, we spent some time carefully evaluating our policies around Slack usage, to make it friendly to non-tech users and also efficient for a rapidly growing team doing frequent on-boardings.

After almost 3 years and the opportunity to see how other companies use Slack “in the wild”, I decided to reflect a bit on how this went, spoiler alert it was a resounding success, and outline some of the policies I believe made a real difference and can help your company get a handle on Slack.

You are here: helping users find themselves

One very overwhelming part of joining a new company is getting access to their Slack. Which channels do you join, what is relevant to your position or to your physical office or even what is business and what is social? When joining a company and seeing dozens, if not hundreds, of public channels, how do you figure this out? and how can you do it quicker

One of the first agreements we settled on was the use of channel prefixes. Simple, short prefixes that allowed us to easily categorize channels and make them easier to navigate. Are you a new developer? easy, check out all the #dev-* channels to find your interests, maybe its #dev-edu to learn new stuff, or #dev-be-chapter to join our backend chapter group.

Or maybe you are new to our Amsterdam office so you can join #office-ams. Obviously once you are done with work you can head over to #ot-travel to get some sweet tips on that new city you want to travel to, or just relax watching awesome dog pics at #ot-dogs.

Adding prefixes, does indeed take some of your character limit away (Slack just upped the limit so that excuse is gone), but makes for a great and easy way to ease your new users, and existing ones, into your communication infrastructure. During the on-boarding of new employees, we share a list of our most relevant prefixes and their meaning so users can quickly skip over to what they are looking for. Here are some examples:

• dev- all channels related to development
• ot- channels that are Off Topic, usually social and not business
• team- channels specific to a team, this also signals this is not a channel for non-team members to ask questions
• warn- channels related to status and warnings, from infrastructure to dev to other parts of the company
• prj- short lived channels for projects that need new groups of people to collaborate

Combine prefixed channel names with meaningful “Channel Purpose” and “Topic” and you can really help people navigate and find what they need at the moment they need it.

Dashing and visible

At first look dashes seem like a waste of time and char-space right? But they actually play a real important role in discoverability of channels. Let me illustrate: let’s say you have a #hashtagdogsrule and a #hashtag-dogs-rule channel. When you search for dogs in the quick switcher, only the one with with dashes will show up, because Slack does prefix/word based searching.

Do it in the open: because transparency matters

We limit the creation of private channels, sure these are great for conversations between certain groups of people, but a private first culture can hinder your companies entire communication flow and make Slack a literal black hole of information. Of course there are exceptions, HR related channels, or our surprise party planning committee, or even sensitive projects, like acquisitions. But other then those cases, everything is done in public channels.

Public information is extremely valuable, by allowing people access to what is happening you create serendipitous opportunities for collaboration. Maybe a developer sees someone in a Customer Success team is trying to automate a process and they have the skill to help out, or you notice another development team is stuck on a similar problem to the one you just solved. Maybe even you notice sales is trying to approach a company where you know the right people. If all of this happens behind closed doors, you may never find the opportunity to collaborate.

Some channels are special, for example our #team- channels. You are more than welcome to join a team’s channel as an outsider, but you are there as a guest, an observer, preferably a silent one. For example instead of asking questions and interrupting ongoing conversations, you can reply to messages where you can offer help by using threads, these are less intrusive and still allow you to access the context in which to ask or offer help. We also make it very clear that this is the team’s house and they can ask you to leave at any moment for whichever reason they believe is relevant.

Slack-tiquette: it’s a new world, let’s make new rules

Let’s start with a simple one: you are beautiful and your avatar deserves to represent you. None of us look like colored blocks in real life and Slack is a tool for uniting people who may work in separate offices or in big companies, having a complete profile with a proper avatar, title, information such as timezone will help your co-workers talk to you, identify you and create a stronger bond, so put your best face forward.

Slack is a tool made to speed up the usual flow of email conversations, and it’s asynchronous, meaning you can ask a question now and get an answer when the person is available. You would not send an email with “how are you?” and only follow it up once you got an answer to that, same goes for Slack, its not rude to start off with your enquiry, it’s actually way more productive to both sides. Of course you can always ask that question as well, but don’t wait for a response before carrying on with the communication. Especially for people spread out in different timezones this becomes really important.

Pinning is winning. Humans hate answering questions over and over, and pinning can really help with that, make sure your important resources are pinned to your channels so they are easy to find and reference, and you no longer need to repeat yourself over and over.

The Steering Committee

Have you ever asked a company who is in charge of Slack? Now I don’t just mean who is Admin and can install apps or add people, who is guiding the formation of your slack? I’m betting the answer will be “no one” or “I don’t know”, another solution we established early was a Slack Steering Committee. A group of people from various areas that could guide the usage and build up of Slack within the company. I believe its always useful to have a group of people who can pull back points outside the curve, or evolve the ruleset as new requirements arise.

Happy Slacking

I hope this brings you some inspiration and makes your Slacking a better experience, but I will warn you, caring about all this may make you open pandora’s box and you will never be able to stop cringing when you look at another Slack.

The post Productive Slacking first appeared on Rafael Dohms.

CONFLICT (content): Merge conflict in composer.lock
Automatic merge failed; fix conflicts and then commit the result.

Don’t panic, breathe, let’s walk through this.

Since I joined Usabilla, I have been working once more in a large team. With more people involved in the process of working with composer, adding, updating and removing libraries, merge conflicts are bound to happen. Ideally I would tell you to leave that process to only one person, but that is not realistic in teams over, well, one person.

So it will happen, but how do we keep our sanity?

What I AVOID doing.

While reading other blog posts on this I found a practice that I consider not ideal. In most blogposts the first step towards fixing the conflict is usually:

$ git merge --ours composer.lock

What does this do? this will impose your version of the lock file, which seems fine, but has a catch. The catch here is that by ignoring the remote lock file you are discarding any updates done by the other developer.

“but Rafael, semantic version is great nothing will break cause my json file has ^1.2”, I agree, but as a policy I try to make sure our updates are conscious, just for good measure. Also I feel its good to respect the work of other people in your team and not discard those changes unless really required to.

What I DO do.

Its a simple switch around.

First I get the other developers changes:

$ git checkout origin/{base} -- composer.lock composer.json

Then you replay your changes on top of this, like:

$ composer require {new/package} --update-with-dependencies
$ composer update {existing/package}

You should know exactly what changes you made, so this should be no problem. Now you have kept all non-conflicting changes and updates from the other developer and applied your changes on top of it and the state of your dependencies is predictable and stable.

Oh, and you obviously run that great test suite after doing this, right?

The post Solving conflicts in composer.lock first appeared on Rafael Dohms.

This journey is now over and I have found my new challenge, but more on that in a bit. Let me tell you a bit more about the journey.

Interviewing as a team

Few months ago Stripe posted an article about hiring teams and the benefits of that, I would like to also mention the benefits of interviewing as a team.

Our team went to many interviews as a full team, either together in big meetings or as individuals. The interesting aspect of this is that since we were a diverse group of people with many different roles, we analyzed companies from various angles, some of which I, in my interviewing experience, may never have thought to look into.

This made for a very fulfilling and unique experience, I got a lot more insights into companies than ever before. How does the business decide on features, how is UX looked after outside of screens, how do you make money and down to our usual questions of code/infrastructure.

If you ever get a chance to coordinate as a group and exchange notes on interviews, I do recommend doing so.

What’s next?

I’m happy to announce my next challenge, not just because I’m very excited to join the company and add to the great work they already do, but also because I was lucky enough to bring Rick Buitenman, my former manager, and Pauline Vos, my former “mentee”, along for the ride.

As of the first of July we will all be part of the Usabilla family!

Usabilla is a big player in the Dutch tech scene, a company built on the belief that continuous user feedback is the key to successful products. Their focus is on providing “Voice of Customer” solutions to help their more than 20K clients improve their user experience, conversions and boost customer satisfaction.

If you have ever used websites like ABN AMRO, KLM, HP, Philips, Vodafone and countless others, you may have noticed a feedback button, that is one of the many tools Usabilla provides.

I’ll be joining them as Lead Backend Engineer, where I’ll be able to focus on my 3 personal passions: coding/architecture, development work flow and growing/mentoring developers. Together we hope to take the platform to new levels of architecture, quality and performance.

Apart from coding, I’ll be working with the development team to take our development practices to even higher levels and make sure we are all learning and growing all the time. I love teaching and exposing people to more knowledge so this should feel right at home for me.

I’m also looking forward to learning from a entire new set of great developers as well as also getting a chance to expand into Golang which is in line with my own personal goals for this year.

I’m very excited to dive into the company and see how I can contribute to a great business and an amazing team.

The post Land ho! New challenge ahead. first appeared on Rafael Dohms.

Code Reviews, to me, are about getting the team in sync. They are about making sure the team’s core values are spread throughout the team and observed. I’m not talking about Coding Standards, those can be enforced and checked with automated tools, I’m more concerned about architecture, code simplicity and conventions, things that are not measurable to some extent and more about making sure code reflects the core values you have.

In my previous team I made sure to on-board every developer by having them read up on Object Calisthenics, a practice that helps code awareness and promotes simplicity. This practice cannot be enforced by automated testing like coding standards, and this is where I believe Code Reviews have a role to play. While having your code reviewed and then reviewing other people’s code, you are exposed more and more to these aspects, and both of those parts are equally important.

During our on-boarding process the first thing developers are exposed to is reviews by the team lead. In our case we were expanding from a one man team, so the team lead held the core values, what we believed good code should look like. The first few weeks were about expressing this and showing, by example, to the team. This is where you can show what your thinking would be to solve these problems in alternate ways. For this step its very important that both sides keep an open mind, because at this point you are building the new core values, which the team will believe in, this means no one is right.

Now, only having your code reviewed and criticized is not a learning experience, the real learning happens when you start reviewing other people’s code. This is where you have to start internalizing the agreed values and projecting them on other people’s code. In our process I noticed that some developers were focused on large tasks and some on short tasks, the ones on longer tasks took more time to integrate into this, due to the long feedback loop. I recommend you try to make sure new developers have a balance of short/long tasks so they are not out of the feedback loop.

After a few months of our team expansion we noticed that the comments made on each other’s code were a lot more standardized, especially to me, the team lead. I noticed that by the time I came in to make a comment, another team member had already made it. This was a good sign that the core values were being spread.

One thing to note is that when a big change happens in the team, here we went from 2 devs to 5, it is important to re-build core values together, not simply impose them. We had many team meetings to discuss code together in order to evaluate if our values were indeed useful and made sense. The practice of “code burns” is great for this. Code Burns are nothing more then team code reviews where you can make comments and discuss as a team about each point.

If you are trying to implement a Code Review process or if one is being implemented in your team, be sure to keep this in mind, its not about having your code criticized by someone else, its about helping everyone be on the same page about what the team believes is good code.

Looking for someone to do this in your company? I’m currently looking for new challenges

The post Code Reviews – Not just a quality tool first appeared on Rafael Dohms.

As is the lifetime of disruptive startups, sometimes there’s a will and a way but not enough resources to make the plan into concrete products. This is, from a 10,000 foot view and as much as I can share, the outcome of our hard work at Symbid. We achieved amazing things and built an extraordinary team over these years but were cut short of rolling out most of the exciting developments.

So as of today, I’m available to help other companies build amazing teams and release cool new products. If your company is in need of a Technical Lead with experience in many markets and a passion for growing teams and producing quality software, please drop by my LinkedIn profile to see more details, or email me at jobs@doh.ms, and let’s chat about how I can help your company and your team achieve both.

But that is not all, our unique situation also allows me to suggest even more. Many companies are in the process of hiring and building new teams, we all know that this takes effort and time, to get a team in sync and working like a well oiled machine. If this is where your company is at, I can offer you a chance to talk to our entire team, a complete team from backend and frontend developers to UX Experts, Product Owners, and Product Managers. If you want to kickstart your in-house team, we can offer you a fully integrated team that is ready to start building your visions and get your plans off paper. Please also reach out to me at jobs@doh.ms if this sounds like an opportunity for you.

What did I do at Symbid?

At Symbid I operated as the Technical Lead Developer. From my early days as “developer #1” my work revolved around converting business value into software feature, determining the best architecture and technologies to achieve goals and integrating our many partner systems. As we expanded into a Product Development team I also took on the responsibility of managing the developers, defining work practices, creating tooling to support our flow and team, as well as mentoring and guiding developers to achieve more of their potential. Over the last year I also had the chance to design a microservices infrastructure that would join all pieces of Symbid’s “Funding Network” and partner software, as well as migrate all our code to PHP 7.

I’m a lover of innovative and clean code, bringing many new ideas to our code base with concepts of DDD, TDD and strategies like CQRS and Command Buses, as well as many other technology and concepts currently under research and evaluation. I’m also a mentor and teacher at heart, so I love being able to bring some of what I do at AmsterdamPHP into the workplace, mentoring and growing our developers, pushing them towards leveling up their code as well as exposing them to the concept of community which I’m quite fond of.

What am I looking for?

I love building products, especially long running products that have a vision that aims at making the world a better place. Sounds corny but I love being able to leave a mark in the future of society through my tool set of technology. I also love iterations, being able to refine software over longer periods, redesign, refactor and improve constantly, which is why I love long running products and not the quick turn around of the web agency style of work.

This is also where I feel my skills are of more use. Companies that are involved in the local community and giving back to OSS get a big bag of bonus points. I do enjoy running UGs and spreading technology at various conferences, as a speaker or attendee, so I do expect my company to see the value in that and support my efforts. Give me that much and I’ll spread the love to every person I see and make sure I’m bringing back to the company as much ideas and knowledge as I can to take us even further.

I love leading teams technically and building/planning systems to solve the problems your company is aiming at. If possible I prefer focusing on the tech side of things and not so much on the HR part of that, I’ll mentor and help developers plan their careers, but I’m not so good at managing their vacation days.

If any of this, sounds like what your company needs please tell me about your vision and your needs, I would love to be a piece in that puzzle.

Above all of this, the team we have built at Symbid is close to my heart and we are all out there looking for a new challenge, any chance I have to keep them together will be the best outcome I can imagine.

Look me up on Linkedin: https://nl.linkedin.com/in/rafaeldohms
Email me at: jobs@doh.ms

The post Need a Lead? Here’s my story. first appeared on Rafael Dohms.