At Ekreative we believe in regularly slowing down and taking the time to look back. This helps us to analyze our current practices and think about how they can be improved. Over the years, we’ve done this an enormous number of times. One of the things that drives this process really well is having a weekly, monthly or quarterly routine that enables you and your team to do this.
In our case, as well as running project post matches and individual performance reviews, we also have a monthly “project managers lunch”. For the last 4 years, almost every month has begun with a time when all our PMs, (along with Ekreative’s upper management) get together outside the office for a nice meal and a chat. Sometimes the PM lunch has a specific agenda, sometimes it doesn’t. A lot of great things have come about as a result of those informal meetings. As we’ve continued to grow and required new processes, the ideas raised, discussed and developed during PM lunches have been invaluable.
As I approach the end of my 7th year at Ekreative, I’ve been reflecting on some of the things we have gone through over the years. I want to recognise some of the bigger patterns of our business and in the same way that a monthly PM lunch gives space to review current practices, I want to use this step back to review the bigger picture. As part of that process, Im going to use this blog post to pinpoint 7 areas where I feel we made some big mistakes as a company during our early days, but where we’ve now changed and adapted our practices for the better.
No retrospectives
As I’ve already explained, looking back and analysing is a crucial step towards improvement.
Running retrospectives is a massively important exercise in any business. While we had processes in place from almost the very beginning to analyse our mistakes and processes, in the early days we rather ignored the project-based nature of so much of our work, and missed the opportunity to run project-specific retrospectives when we completed a project. That oversight inevitably led to our repeating the same mistakes on new projects, even though we could have easily foreseen and addressed them with them help of a simple post-match review.
No team leads
As a small company of 15 to 25 people, we were able to get by without having technology-specific team leads. Once we reached a certain size though, and the number of people in each department grew, we found ourselves struggling to keep everyone in each department on the same page with where each technology was going. I think we turned our attention to this issue a bit late in the game (we had about 50 employees at the time). It was only when we realized that something was broken that we addressed it. Our solution was to create team leads for each department and that system has served us well ever since. From that point on, team leads have been responsible for communication within their teams and making sure each department has up to date development guidelines and regular meetings to talk about problems they face, best practices and new tech evolving.
Not maintaining contacts
In Ekreative’s early days we finished one project, washed our hands and moved straight onto the next one without a second thought. We didn’t keep in touch with clients after finishing a project with them and it didn’t take too much reflection to realise that this was both somewhat rude and simply bad business.
Admittedly in some cases back then we were working through an agency and didn’t have direct contact with the client, but that wasn’t the case with everyone and we still didn’t create the capacity or processes to keep in touch, for some reason feeling that this work was of a second order of importance. This is completely backwards and obviously something that needed to be rectified fast. Creating regular follow up points of contact is not only reassuring for clients, allowing them space to provide feedback and request minor changes, it also helps ensure ongoing good relations and opens more doors to potential future contracts.
Lack of early feedback
Gathering feedback can be a gruelling process. No-one likes to be criticised and sometimes getting feedback can feel like you’re setting yourself or your team up for a bad day. And if everything’s fine and the client is pleased with the way things are headed, you might feel like the review was a waste of time. Not even slightly. The importance of getting early feedback from a client is paramount.
We actually learned this lesson the hard (and expensive) way during an early project. Don’t make our mistake. Don’t wait for the project to be over. As soon as you are actively into it (within the first month), ask for feedback about how things are going. This feedback helps you to understand whether everybody’s on the same page, whether expectations are being met and as a result whether you need to make any changes, adapt the way you work to meet the needs of this particular client or perhaps you need to explain your processes more clearly to the client to ensure that they understand the work being done.
Adding an early feedback phase to our projects dramatically improved our processes, it helps us to ensure that projects closely meet client expectations and generally improves our relationships with clients over all.
Non-English-speaking team members
We’ve always been proud of the English level of our PMs and of the way we communicate in general. Working as a development agency for clients largely in English speaking countries, mastery of the English language is obviously central to being able to effectively deliver the goods. That’s why we made sure we invested in PMs with great communication skills and high proficiency in English. When handling smaller projects, that was enough, but as the complexity and scale of the projects we deal with has risen, so has the need for our developers to communicate directly with clients or with other teams responsible for other areas of a project.
That’s why we’re pushing hard now to make sure that all of our developers are capable of fully communicating in English, not just reading, writing or understanding, but speaking too. This entails provision of English classes for all employees and incentivising learning by making higher pay grades reliant on demonstrable English improvement.
Excessive detail in initial estimates
The nature of most businesses is that time equals money. People on our team are our biggest asset, and their time is our most precious resource. One of the ways we were able to dramatically save time, was by eliminating or at least drastically minimising the time spent on initial estimates.
I want to be very clear here: I am talking about initial rough quotes, when it’s still not clear if we are a good fit for the potential client or whether they have the necessary budget for the build out.
The mistake we used to make was to overspend time on that initial estimate. Thus, since the number of projects we won was lower than the number we estimated, we would lose a lot of time on projects we didn’t even have. The time for a detailed estimate is when the client comes back after hearing your initial estimate.
Low priority on code reviews
When we started out it wasn’t uncommon for a developer to work on their own for a long period of time, even for the duration of a project, without anyone else looking at their code. Developers would feel almost insulted when someone else deigned to review their work, let alone point out coding errors or mistakes in their approach to coding practices. Several years ago now we decided that this situation wasn’t doing us any favours and it was time to escalate the importance of code reviews. Now we have a process whereby each developer is regularly reviewed by his mates and all of their code meets our internal standards and security practices.
Looking back
It’s great to look back and see how every time we faced a challenge, we were able to find a solution to build upon and move forward. This would not have been possible, however, if we didn’t take the time to get out of our daily routine and take a look from a different perspective. By openly talking about the issues we are facing, we can come up with several options for potential solutions and then try implementing them. That’s why we still have this routine of looking back and reviewing our processes to this day.