Like it? Tell your friends...

Viafoura has been trending toward a heightened awareness of its team members, their needs, goals and career growth.  All of this is wonderful and much of the groundwork required is borne of lessons learned while at other companies and organizations that did some things right, but most things wrong.

I don’t want to start off by blaming those organizations, but rather much of the blame goes to the lack of training, foresight and knowledge that many leaders possess. I really am not very different in that I have many shortcomings, however one thing I’m good at is to realize that something has gone awry and that it should be fixed.  This has lead to a pleasant experience at Viafoura for our Engineering teams and an overall team satisfaction that is VERY respectable.

How did we get here then?  What are some of the methods we use that differentiate us from other companies? Why are people happy?

All great questions indeed, let’s explore them a little.

How did we get here?

I was tasked with taking over Viafoura Engineering and growing the team from 4 to its current size.  There have been stumbling blocks, in hiring, managing and delivery of deadlines, but we are a pretty good place these days.  So what were some of the mistakes I (and we) made?


We have had issues with prioritizations in the past.  This lead to some of our team members, the brightest of the bright, being upset about not being able to “do the right thing” (in Engineering terms) and/or not having the time to think about these things.

How did we solve it?

It’s taken some time, but we have attacked this problem by making it increasingly difficult to NOT do the right thing. It’s become ingrained in our philosophy and culture that taking the time to do the right thing is crucially important.  Further, we’ve instituted weekly architecture meetings and tea parties for the frontend team that allow us all to meet and discuss ideas, issues and possible improvements that are available.

We often find these things not only based on our own knowledge of the platform, but also through exploratory looks at what other companies are doing, what technologies are gaining adoption and by challenging all the paradigms we assume to be correct.  Afterall, we’ve gone from a standard LAMP (well LEMP) stack to a very well-tuned Event Based Architecture (for which I will have a write-up in a few weeks).

Technical debt

This one is sort of related to above.  Not only do prioritizations matter, but once they are out of whack, you start incurring technical debt.  This isn’t the kind of debt that will cause the bank to foreclose on your home, however like a financial debt, the technical debt incurs interest payments. These happen in all the extra effort that we have to do in future development because of the quick and dirty design choice(s). We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

How did we solve it?

This issue made us totally re-think how we were doing things at Viafoura.  We knew that we would eventually end up with a system that would fall flat on its face and no longer be able to handle the requests we threw at it (for example – one story today cause a spike of well over 1500 requests/second – which we now handled without batting an eyelash).

We took the opportunity to re-factor absolutely everything about our system, slightly delaying product delivery and small features that had been requested. Yes, that does suck for our clients, however they’ll be so much better served going forward and we’ll be able to iterate against our series of micro-services (read Service Oriented Architecture) that they’ll (eventually) be happy we went down that road.  (Well, at least that’s the hope – right?)

Lack of expectations

One of our major issues was that no one had set out expectations for projects, people, product, etc… This year at Viafoura was the year of Accountability. All our departments were tasked with figuring out ways in which we would measure our success and minimize our failures.  During the year, we also hit large growth spurts which lead to rethink much of what we knew and reassess all the things we didn’t know (including those we didn’t know that we didn’t know).

How did we solve it?

This took some work!  It has been ongoing and will never cease to exist.  We attacked it from many angles to set expectations across the board and to communicate those to our team(s). The first change we made was to set expectations on a departmental level.  From here, we then further reduced these to goals and objectives that led to alignment on the part of everyone within those departments.

Everyone was now on the hook for something, but they still didn’t quite understand how they were being measured.

I then set up a performance review that runs quarterly, measuring all kinds of aspects about our team, outside of just the typical – completes his work, plays well with others, does not wet the carpet!

We work with all our team members to figure out what matters to them and how that will align well toward their career growth, personal growth and Viafoura’s growth and bottom line.  We then have them set some stretch goals that will take longer than one quarter to fulfill and measure their progress against it quarterly.  Once these have been achieved, we add more to it.  It’s really an ever evolving process.

We have a great range of talent, which lends itself well to cross-team, cross-functional, multi-disciplinary work.  As such, no one is actually bound to any one job title or description.  This is yet another one of those ever evolving, living documents that we take a look at with our team during review periods.

With all that being set, we now have the groundwork for expectations at Viafoura, which has led to better timelines, better delivery of work and happier people.

The lessons learned:





What’s in the Viafoura stack anyway?

Viafoura prides itself on its engineering practice and as such is happy to constantly share back to the community.  Much of our work can be found on github and I personally am an avid speaker, presenter and teacher of everything I know.


  • Java
  • Node.JS
  • JavaScript
  • PHP
  • Python
  • Erlang
  • Clojure
  • Scala


  • Competitive Salary
  • Viafoura University
  • Education reimbursement
  • Lots of vacation
  • Free food, snacks, beer
  • Learn from the best in Toronto
  • Collaborative space where many meetups are held
  • Monthly hack days where you “scratch an itch”
  • Have a voice – employee feedback genuinely taken into account




  • AWS/EC2
  • NetflixOSS
    • Karyon
    • Priam
    • Archeus
    • Eureka
    • ICE
    • Buri
    • Aminator
    • Hystrix
    • Turbine
    • Zuul
  • Cassandra
  • HAProxy
  • Pagerduty
  • Loggly
  • Percona XtraDB
  • Nginx
  • Kafka
  • Storm
  • Spark
  • Spark streaming
  • Lucene
Why not listening to your team is killing your company

Post navigation

4 thoughts on “Why not listening to your team is killing your company

Leave a Reply

%d bloggers like this: