We’re Launching a Sabbatical Program to Help DevFactonians Grow

When David, Ransel and I set out to design a different type of company over twelve years ago, we were all young and naive. We knew what we liked and disliked about our past employers, and we were driven to create a different kind of work environment: one with a great, constantly evolving culture and a lot of flexibility. As our first joint decision at DevFacto, we came up with a simple mission statement, or rather a simple mathematical equation (since the three of us are geeks): “Happy Employees = Happy Customers”. This equation has stood the test of time and has been our guiding beacon ever since.

Years later, it isn’t just a nice-sounding catch phrase. It’s how we work. In fact, we continuously measure employee happiness and client happiness. We take this so seriously that our executive team’s compensation is closely tied to these two metrics.

To keep our employees happy, we look after their well-being in many different ways. And while the list of our perks and benefits is vast and fairly unique, we felt it lacked something to reward our longest-serving staff. The ones who have been with us for many years, doing great work for our clients and pushing us to get better along the way. The smart, talented and loyal employees that most CEOs dream about. The kind of people that recruiters call me about to express how frustrating it is to try to “poach” them from DevFacto. We owe our success to them. Although we don’t believe in rewarding roles based on tenure, we wanted to celebrate and honour employees who have been with us for a long time. So, after some conversations with our amazing staff we came up with the concept of “Discovery Days”.

“Discovery Days” is a two- or four-week fully paid sabbatical, duration of which depends on the length of service with the company. It’s main purpose? Expand the employee’s horizons as a human being. Employees that qualify, apply for the program by sharing what they will do with the time and how it will take them outside of their comfort zone. It doesn’t need to be extreme, although it very well could be. Anything goes, as long as it meets the following criteria:

  1. You will do something that will help you grow as a person.
  2. You will document the journey and share it with the team via a Pecha Kucha talk.

The program has launched, and the initial reception has been great. I can’t wait to learn about our employees’ adventures and if you’re as curious as I am, be sure to keep an eye on our social media profiles where our marketing team will be sharing these journeys in the upcoming weeks/months. After all, personal growth and self discovery enrich the entire community and not just the individual.

And who knows, maybe we will end up rewriting that simple equation to “Happy Employees + Discovery Days = Delighted Customers.”


Hackathon Tips from a Hackathon Mentor

Last month, The University of Alberta’s Computer Engineering Club held HackED, an annual 24-hour student hackathon. I had a great time volunteering at the event alongside a bunch of DevFactonians, and even had the privilege of judging several great projects to cap off a wonderful weekend.

One of the biggest reasons to participate in a hackathon is not necessarily for the prizes (although there were plenty!), but for the valuable learning experience that the setting of these event offers. So, if you are considering taking part in a hackathon, read on! I’ll be sharing a few helpful tips for anyone preparing themselves for a similar event.

Plan Your Project

In most hackathons, time is the biggest constraint. At HackED, students were given only 24 hours— that’s not a lot of time! While observing several teams, I noticed that the biggest trap participants fall into is picturing the finished product and not planning out how to get there. It might seem counterintuitive to dedicate a lot of time to planning when you’re given a short deadline. However, even 30 minutes spent early in the hackathon means uncovering potential issues before they can surprise you!

Planning a project doesn’t need to be time-consuming, complex, or boring. A planning tool I like to use with teams is a Kanban board. It’s as easy as putting to-do items on sticky notes and then arranging your notes into columns titled “To-do / In Progress / Blocked / Complete”. You can even go one step further and use differently-coloured sticky notes to categorize your work items. When work is being done, write down the name(s) of those who are working on an item. This helps to prevent confusion and also provides a rough gauge of who might be taking on too much/too little work. Lastly, remember that plans can change. If the finished product you were picturing is no longer possible, at least you have an existing plan that can be adapted!

If your hackathon space isn’t conducive to having a physical Kanban board, I recommend Trello to keep it all paperless. It’s free and simple to use, making it perfect for a hackathon!

Ask for Help

Students and industry professionals alike volunteer their time to help you out. It might feel awkward to have to pipe up and flag somebody down, but trust me, it’s worth it. At work, I’ve had moments where a 5-minute conversation solved a coding problem that I had spent hours trying to crack by myself. At HackED, we have mentors with web, mobile, 3D, embedded, and hardware experience. If we don’t know the answer, we can find somebody who does.

Take Regular(-ish) Breaks

Developers are an interesting breed: we need extended periods of undistracted time to solve tough problems, but we also need time to decompress. When starting your project, decide on when the team should take breaks (for lunch, for snacks, or simply to relax) and give your minds a rest. Set a rule to not even talk about the project while you’re taking your break. As unintuitive as it may sound (the clock is running!), your mind needs a break too. For those who need to be told when to take breaks, the Pomodoro Technique may be helpful.

Sleep (Yes, sleep!)

I get it, 24 hours is not a lot of time. But then again neglecting sleep is probably going to hurt your project. Some teams that I assisted ran into problems caused by late-night coding. They patched issues with hack after hack, eventually causing a big mess that became hard to fix. Plan that the whole team (no late-night warriors allowed!) gets at least 6 hours of sleep (either on-premises or elsewhere) and re-convenes in the morning, recharged and motivated to finish the project. Lucky for us, breakfast was provided at HackED making hackathon Sunday a little less stressful.

Rehearse Your Demo

Judging can be subjective, but all judges appreciate a well-prepared demo. Some teams straight up admit they are at the hackathon for the learning experience rather than for building a demonstrable product, and that’s ok! So as long as the presenters knew what they wanted to say, us judges appreciated the gesture.

For teams that have something they want to demonstrate, it’s useful to describe what your project was about, and what each person did. From there, demonstrate key areas of your project and leave time for questions. I recommend leaving the last 30-45 minutes of your hackathon to identifying what you’d like to demonstrate, and then rehearsing the demo at least a couple times. Remember that a hackathon is a learning environment, so even if you’re not a strong presenter just yet, you can use it to practice your presenting skills as well.

Don’t Forget to Show Up

The last, and most important piece of advice, is to just attend the hackathon, even if you don’t have or don’t feel like you’re ready. As someone who graduated from the University of Alberta not that long ago, I do regret that I never took part in hackathons when I was an undergrad. The excitement in the air at the beginning, the antics that happen as the night wears on, and the intensity of the final hours are just some things you have to experience at least once in your student life.

I hope that these tips will help you get the most out of your next hackathon experience!


Big thanks to the U of A Computer Engineering Club for the opportunity to take part in the 2019 HackEd hackathon and for providing photos from the event. 

Tales of a UX Designer in a Dev Shop

I wonder how many designers, after reading the title of this post, thought of a perfect meme to describe how that scenario plays out. I mean, even though we all know that working with brilliant developers who can bring your most precious ideas to life is the dream, we also expect that the designer-developer relationship won’t be filled with rainbows and unicorns.

Last summer, when I was thinking of joining DevFacto as a UX consultant, not only did I picture those memes too, I was also unsure if this type of challenge was going to be a good fit for me. Could I picture myself debating which features matter and which ones don’t, every single day? Hmm…

Luckily, soon after coming on board, I got to meet the developers over beers and got a true sense of the personalities on the team. The excitement of collaborating with brilliant minds quickly grew on me and I looked forward to learning within a fun, supportive culture. Now, six months into being a DevFactonian, I can report that I’ve learned a few lessons and busted some myths about the relationships between UX designers and developers. Here are my top 3 discoveries:

1. Developers attach to their work as if it were a baby (just as much as designers do)

Whether in a dev shop, or a design studio, we all protect what we create, foster and put effort into making. So, when someone else modifies our work in any way, it’s difficult to detach oneself but very easy to discount any modification as a nonsensical idea.

Whenever that happens, it helps to remember that we are all in this together and we share the same goal – make the best solution possible. Or, as I like to think about it, create “the perfect baby.” In each project, we all contribute from our own experiences to build a product that combines a fresh, sleek look with exceptional functionality. However, ultimately, we do this not to appease our own egos but to create value for the people who will be using what we’ve built.

2. Sharing your process promotes collaboration

After talking to one of our brilliant devs, I realized that effective collaboration is all about sharing the process. The developers write code, make something come to life, and it either works or it doesn’t. In that way, the mind of a developer is binary. Meanwhile, as designers, it is our job to come up with various ways to create success (usually there are many) and put forward the best one in a mockup or a prototype. However, sometimes we fail to share how we arrived at the presented solution. This makes it hard for a developer to understand why we are making certain suggestions and can lead to a rejection of the idea.

Collaboration comes from having a common understanding of a problem.

Therefore, sharing both my approach and context helps them see where I’m coming from and take my modifications as potential improvements, rather than just self-preference edits.

3. Feelings matter

Even if we try our best to be rational and logical, at times it can be hard to accomplish. As software users, we respond to emotions, we make mistakes and get distracted. We like or dislike things based on how they feel, even if that sentiment makes no sense. That’s just how we’re wired. Even though we’re trained to think differently, it is still easy for us to fall into certain patterns and behaviours quickly.

It’s easy to forget we’re all just human and that does not make us the ideal user.

Empathy has been THE card up my sleeve as a UX designer. I use it both internally with our project teams and externally with our clients. In my work, I’ve learned to play that card as much as possible for the sole purpose of creating products so easy to use, that people will want to use them more.

I do know for certain, that there are still many lessons to be learned and plenty of discoveries to be made about the process of designing user-centric software solutions. But one thing I can attest is that despite the left-brain and right-brain differences between designers and developers, the awareness of the value of good user experience goes well beyond our roles.

2018 DevFacto Winter Summit

Hi there! It’s Don here, DevFacto Consultant from the Regina branch, bringing you a “consultant’s perspective” on our semiannual DevFacto Summit event.

“What’s a DevFacto Summit?” you might ask. In a nutshell, it’s a laid-back, one-day event designed to fill the DevFactonians in on what’s currently going on in the organization and what’s being planned. In addition, we typically have an interesting keynote address and an opportunity to get some hands-on training.

The Winter – 2018 edition delivered on all of these, in spades!

Embracing the Change

The first item on the agenda was an inspiring talk by our keynote speaker, Mr. Bruce Kirkby. If you’ve not heard of Bruce, he’s what you’d call the adventurous type. He’s ridden across deserts, led his family on a round-the-world tour (without electronic distractions of any kind), and tackled more challenges than any ten of us combined will probably ever face.
Bruce’s talk was all about change and overcoming the inevitable obstacles that crop up when you want to, or are forced to, make a transition from where you are now to where you need to be in the future.

Bruce Kirkby Speaking at Devfacto Summit in Edmonton

Adventurer Bruce Kirkby at the 2018 DevFacto Summit in Edmonton

This subject is especially relevant to us in the IT consulting field, because our world is ripe with change! Whether planned or imposed, we face it constantly and understanding how to deal with it can make our lives a whole lot less stressful and our work much more effective. Through stories of his family’s adventures, Bruce explained what challenges to expect when we work through the process of change, and how to overcome them with understanding and by taking care of our minds and our bodies.

I found Bruce’s talk to be extremely relevant and enjoyable. As I was listening, it struck me that this wasn’t the typical keynote address that one would expect to hear at a technology company’s event. Instead, Bruce’s content addressed the personal – rather than technical – well-being of everyone in the room.

Tackling the Future

Next on the agenda was our own David Cronin, co-founder and CTO of DevFacto, who led us through no less than 19 initiatives that the leadership team has planned for 2019. I’m not going to go into detail on each, but as a summary I can tell you that many of the planned initiatives will directly impact the experience of our employees in a very positive way.

One item that particularly stood out for me, is the planned implementation of employee sabbaticals that will include not only time-off but also awards funds to be used during the sabbatical. To me this goes well beyond the clichéd “employee appreciation.” Rather, it proves that when our leadership says that they care for the happiness of all employees, well, they’re not just saying it because it’s a nice sound-bite but because there is a true intent behind those words.

Devfacto Summit

New perks sure sound exciting.

David’s address finished up the morning of our summit and brought us to a fine lunch where we had a chance to recharge the batteries and socialize a bit with our DevFacto family.
After lunch, DevFacto’s Taylor Reese, our in-house illustrator supreme, User Experience expert and all around great-guy (no, he didn’t pay me to say that – honest), led us in a hands-on learning session on the topic of Ideation. It went something like this…

It all comes down to Ideation

First, for those of us who don’t really get what this whole “Ideation” thing is all about, Taylor explained that it’s our process for getting to the bottom of what the end user needs really are and which of those needs should the client be focusing on.

The task laid before us was thus: brainstorm a solution for how to implement a dress code, given a limited budget and stiff business criteria to meet.
The group was divided into teams and we quickly got to work.

Now, I have the honor – perhaps dubious – of being the oldest DevFactonian, and I’m not talking service-years. Along with me, there are a few others in the company that, while not quite as ancient, can still remember when the words “dress” and “code” rarely appeared in the same sentence so, for us, the stated problem didn’t really look like a problem at all.
As one of my teammates pointed out, “What’s to think about? Shirt, tie and suit. Simple! Problem solved.”

Indeed, I wore a suit to my first job interview those many moons ago. When I was hired, I wore a suit, and every day for the next 5 years, I showed up to work in a suit. Even though I rarely dealt directly with customers, it was understood that that was the way I was supposed to dress, and I can’t even tell you how I knew it! The dress code, though never explicitly stated, was universally understood. It was a given, not a problem to be solved.

Facing the ideation challenge reminded me of what Bruce Kirkby was talking about in the morning. Life is all about change and working around, through or over the obstacles standing between where you are and where you want or need to be. That process involves overcoming fears, uncertainty and resistance and coming up with a way of moving past those barriers.

As consultants, we need to be able to embrace the concept of change and help our clients to do the same. We need to be equipped to guide them through the process of achieving a solution to the challenges that inevitably come with change, and we need to be able to do this in a manner that makes an impact.

In my mind, Ideation isn’t just a service offering that a few of us in the company are designated to deliver. Instead, it’s a mind-set that each of us must embrace in order to deliver real value to our clients.

As was apparent in the solutions that the teams presented, the challenge was met with creativity and innovation, and while some ideas stood out more for their comedic value than their practicality, it appeared that the entire room gained the insight that Taylor intended.

It was a great ending to a day full of knowledge sharing and fresh ideas leaving us all inspired and ready to hit the ground running in 2019.

DevFacto 2018 Team

DevFacto Does Mexico: A Lesson in Team Building

In the weeks and days leading up to the DevFacto 10-year anniversary corporate retreat, I wasn’t sure what to expect from travelling with a group of over 150 employees and spouses Read more

Longing for Change: Empowering Horizontal Ambition in a Flat Organization

From lean start-ups to intricate enterprises, flat and open structures have become the new gold-standard for the modern organization. But while flat structure comes with significant perks (employee empowerment, transparency and engagement to name a few), it definitely presents challenges when thinking traditionally about career growth. Read more

Embracing Your Crucible

Hi, I’m Natalie! I started at DevFacto the second week of September as a User Experience Researcher (UX) / Business Analyst (BA) who has been working in the product software space for the last few years.

Where most organizations will ease you in to your first week or so, my first week at DevFacto started out with a bang. Read more