Monday, 13 May 2019

Job Titles Form Mindset - Digital Producers VS Project Managers


Job titles form mindsets and behaviour. I have been working in digital/web since 2007, worked at several companies and with dozens of Project Managers. Many organisations want to be "more agile", and it is my opinion that one of the first baby steps is to fix job titles. An attitude change requires a mindset shift.

In this article I will discuss how to get your Project Managers to become more collaborative and less authoritative. This is a stepping-stone to a more collaborative Scrum mentality, as Scrum does not have the job title of Project Manager.

If you come from a traditional project management background, then I ask that you please keep an open mind.

Project Managers

Project Managers are not evil, and most of them are not jerks. Very often the pressures that are felt by designers and developers are due the pressures "pushed" onto the PMs from further up stream (eg. client services, the company). This can exacerbate undesirable behaviours such as micromanagement.

Many would agree with the opinion that this stems mindset of what a "Project Manager" is meant to do. They are meant to "manage". However, this elicits certain types of communication and behaviour which can dehumanise their colleagues. It is obviously not the PMs intention, however this is a result.

Every time I hear these phrases / questions, I cry a little inside:
  • How do I book a designer for my project?
  • How do I know which developer will be assigned to my project?
  • When will you be done using Greg? I need to use him for my project
  • Can I have Greg next week?
  • I need a QA resource

These are common things you will hear in a standard digital agency. The problem with these phrases is that they dehumanise the people who they are referring to. The people you work with are no longer people. They are resources to be handled and monitored. I have seen how developers and designers have been micromanaged and traded between PMs as if they were sauce bottles on a dining table. I have also seen really poor behaviour where PMs have become aggressive when it came to "protecting their resource", they were untrusting, micromanaging, and have even stopped other developers asking "their developer" for advice/help. This totally sucks, and is very bad for your work culture and morale.

But but but... how else is a Project Manager is meant to manage things? Isn't a manager meant to manage tasks, people, time, etc. My project success means that I will get a promotion/pay increase.

It doesn't have to be this way...

The Best Manager Does Not Manage Anything

The best "PM" I have ever worked with was an absolute joy. He didn't manage people, he didn't manage our time, he didn't manage our tasks, he didn't manage the client, he didn't assume any type of authority over anything in the project at all. He wasn't a Project Manager in the traditional sense. He was a facilitator

He lined-up work, collaborated at ground level with everyone, asked if we needed him to do anything, he let everyone make their own decisions, he unblocked our obstacles, he cleared our path so we could succeed. He was an absolute joy to work with. He helped us produce great products for our customers. But he was not a "Project Manager". He was part of the project team, and trusted his teammates to do their part. The projects where he was involved in were the smoothest I have ever had the pleasure to work in.

What I have just described is a person who would pass a certification without even doing the training.

The Mindset of a Digital Producer

When you refocus people on producing value rather than managing people/things, then a shift in mindset occurs.

If you work in the digital space, you may have come across the role of Digital Producer at some point. It is very interesting that when a Project Manager title is changed to Digital Producer, then a load of different behaviours can emerge.

There are plenty of PMs out there who are "managing" projects which have little value to the stakeholders/customers. However, a Digital Producer is actually meant to "produce" value. This is a mindset shift which can encourage more a collaborative attitude and behaviours.

Many would agree that the job title Digital Producer better suits an Agile environment. The job title of Digital Producer not only sounds cool, it doesn't come with all the baggage of being a traditional PM. There is no longer an expectation for you to "manage" anything or anyone. The team/company/organisation only expects the person to facilitate the "production" of value for the customer/stakeholder. 

If you are a Project Manager at a digital/advertising agency, you should totally ask for your title to be changed to Digital Producer. It is so much cooler!

Digital Producers, Scrum Masters and Product Owners

Let's talk briefly about Scrum...

The next evolution of Digital Producers, is a splitting into 2 different roles which are Scrum Master and Product Owner.

In scrum a Product Owner understands the stake holder's needs. They line up the features, and have full control of the backlog because they know what is most valuable to the stakeholder/customer. The Scrum Master is the facilitator of smooth workflow. This person is a coach. They prompt and facilitate conversation, and encourage people to be more mindful of good habits and processes. They are a servant leader.

I have seen scrum work properly. It is amazing!

Final Thoughts

Job titles actually form a mindset, and these mindsets form behaviours. "Project Managers" are not bad people, however their title and role elicits some behaviour which really can dehumanise the people who are meant to be their colleagues. This is especially the case when the PM is getting pressure from further up stream.

By changing the job title of Project Manager to Digital Producer, it can drastically affect the mindset of those in this position. People will start to be focused on "producing" value, rather than "managing" tasks & people. It is one potential first step in becoming more agile, and on the right path to facilitating production and fixing your work culture.

I hope this article gave you some food for thought.

Agile Mindset 

A mindset shift starts from the right knowledge and training. If you are a leader who wishes to promote a real organisational change, then I highly recommend the Professional Agile Leadership certification.

Check out my Scrum certification reviews below:

Wednesday, 8 May 2019

Good Help Is Hard To Find - Tips When Offshoring Development Teams

Good Help Is Hard To Find.

This is the sixth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


Finding good developers is especially difficult during rapid scaling, and even more so when you have budget/time constraints. Offshoring is a potential solution, and can potentially save your company a lot of money.

I helped to set up our Krakow office way back in 2015. I tried to keep the Polish developers integrated as much as possible, and devised policies to help with communication and team building. Part of this involved travelling to Krakow very often. I got to experienced the culture, food and of course the vodka.

In this article I will present a few of the challenges I tackled when offshoring.


Before I get started on the real part of this article I just want to touch briefly on fincances.

Back in 2015 the Zloty was 1/6 of the GBP. Then June 2016 came along and the GBP took a nose dive. Suddenly our staffing costs and office increased by 20% literally within 1 day. All I can say in this scenario is, ensure that you give yourself a buffer to account for fluctuations in your exchange rate.

The next thing we didn't expect was that the Polish developer market started to boom. Much larger companies were opening offices in Krakow and Warsaw, so the competition for workers was fierce. Suddenly our devs were being offered double the amount that we were paying them. We couldn't keep up with the pay increases so we had to offer much more flexibility and other work perks.

If you believe offshoring is a great way of saving money, I hope this story prompts you to think about mitigating these issues. We definitely didn't think of the possible financial consequences when we started.

Understanding The Workers

There are stories that float around which can be quite damning of Indian developers, however the people complaining about them tend not to understand the type of developers they are getting.

Indian IT has a reputation for workers who do what they are told... to the letter. This can be a great advantage if this is what you need.

If you want to create an offshore office, then you need to understand the type of workers you are getting. Culture and work culture need to be understood.

Culture Gap

There are definitely some cultural, work differences, and faux pas which you need to look out for.
Offshoring from the UK to Poland and surrounding countries is relatively painless. Although, if you ask anyone from Poland about "Eastern Europe", they will remind you that they're not in "Eastern Europe", as they are actually geographically central to the continent. So don't tell a Polish developer that they are in Eastern Europe, as they might get annoyed at you.

Basically, you need to ask questions. Ask your new colleagues if there is anything that foreigners say/do which they find annoying or offensive. This is a great way to actually begin to bond with your new colleagues.

Time Zone and Office Hours

The time zones can matter if you need crossover hours for meetings, pair programming, code reviews etc. Even if you are in Europe, and offshore within Europe then you still need to consider differences in office hours.

For example, the Polish work life-balance is one to be envied. Generally, they drop their kids at school around 7-7:30am, start work by 8am, then pick up their kids at 4pm. It's is a very natural time schedule. Contrast this with UK working hours, and you essentially have Poland starting at 7am GMT , having lunch at 12pm GMT , then leaving the office by 3pm GMT . You realistically only have around 3hrs of crossover time once you factor in lunch. This is with only a 1hr timezone difference!

The issue of crossover office hours obviously becomes more prominent with larger time zone differences. My personal opinion is that it is far easier to work with offshore offices if your timezones give you at least 2hrs of crossover. You cannot realistically expect that someone living in Sydney can be on regular calls to the UK. You really need to consider how you can adjust your processes, and what type of crossover is acceptable (if any).


I have to say that my experience offshoring to Poland has been very positive. Polish developers are very high quality, they have a good work ethic, and give you opinions and feedback. They are highly educated, and can argue with you about architecture and design patterns. I couldn't ask for a better team.

I made a concerted effort to integrate the Polish staff with the rest of the company. This took a lot of work, and I personally flew to Krakow very often to ensure that they felt like we were all one family. I often came with office improvements, gadgets / equipment, and even pay increases. You could probably make the analogy of a father coming home with gifts after a long trip. Part of the integration was also daily video calls so everyone could talk about what they were doing. This also becomes a great perk for your staff. I personally love seeing a new city.

Remember that your offshore office is as an expansion to your current office. Don't call them your "offshore team". They're not another team. They're just working remote all the time. To avoid an organisational silo you need to put in the effort to make them feel that they are part of the family.

Team Building

Video calls are essential for ensuring that people feel connected. It is very easy to just use voice calls, or slack messages, however seeing people is far more powerful when creating human connections. So get your Internet connection fixed! No excuses!

Another important practice is physically sending people between offices. Nothing beats working across the desk from someone, small-talk at the coffee machine, and going for lunch. Do this every month. When a person is booked to come to your office, people will get excited about it, especially if the person has never come to their country before.

An important note about Polish culture... The first time you go out with your colleagues in Poland they will feed you more vodka than you ever thought possible. Team bonding drinks will take a year off your life. It might also costing you an extra cleaning bill at your Hotel/AirBnB *eyes rolling*.

Tips For Offshoring Your Development Team

  1.  Know your workers, and what you're getting
  2. Understand the culture of the people you're hiring
  3. Try to only offshore to a location within a few hours plane trip away
  4. Send staff to and from the offshore offices at every month
  5. Enforce a video policy
  6. Treat your offshore office as 1st class citizens in the company

Final Thoughts

Many companies treat their offshore office as an outsourced office. It takes a lot of effort to ensure this doesn't happen. Treat your offshore workers as 1st class citizens, and try to understand them & their culture. Be diligent and you can build far better relationships between your staff.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Project Managers (coming soon)
  8. Tips When Hiring Remote Developers (coming soon)
  9. Tips To Improve Developer Retention (coming soon)

Friday, 3 May 2019

Good Help Is Hard To Find - Tips When Hiring Junior Developers

This is the fifth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


From a business perspective, hiring Junior developers gives you cheap workers who you can mould into the type of developer you want and need. But what are the pros and cons? Hiring a junior might be compared to adopting a child. It can be very rewarding, but are you really ready? In this article I will outline many of the things you need to expect when hiring a junior. I will suggest some tips on how tackle these issues and hopefully you will become a better teacher.

Why Should You Hire Junior Developers?

From a business perspective, they're cheap and mouldable. They generally have no opinion, and you can teach them the ways of the force. You can give them the trivial work that none of the other devs want to do.

From a non-business perspective it helps everyone grow. For example, having a junior gives your mid-weight developers an opportunity to do some mentoring, and hopefully develop some leadership skills. Also, it should go without saying that teaching is very gratifying.

Will They Slow You Down?

Juniors take time and effort. You need to mentor them, teach them, be their Yoda. All of this is in addition to your daily responsibilities. Be prepared for your other devs to dedicate some time to mentor them. They need to ensure the new dev is meeting coding standards, and actually performing.

If you have never taken on a junior before, then you might notice spending more time with them than anticipated. Keep in mind that they are doing the more trivial work which other devs don't want to do, or don't have time to do. This is the trade-off you need to come to terms with.

They Take Too Long?

Junior developers are not master time keepers (yet). Be aware that will take lot longer than expected. A typical junior is less likely to ask for help, and will sit for hours and days trying to solve a problem. Ideally they should ask for help to solve the problem, then go home and think about why the solution evaded them.

Juniors need to be told explicitly that they should ask for help early. If they can solve a problem in 1hr by asking for help then that is a lot better than trying to solve a problem by themselves in 5hrs. Regularly check in with them to ensure that they are making progress rather than chasing their tail. Reiterate to them to time-box their effort, then ask for help. Set a stopwatch if need-be.

Their Bug Count Is...

Oh boy, juniors have a lot of bugs in their code. They miss a lot of functionality, cause crashes, make your system unstable. Juniors are essentially code gremlins. I should know. I used to be one!

Accept that their output will be pretty bad at first. You need to be supportive. Help them develop habits to double/triple/quadruple check that they have met the acceptance criteria. Get them to sense-check their work with someone to ensure that they have good quality work. It is your job to ensure that they improve. Teach them that it's their responsibility to be better than they were yesterday. Get  them to keep a tally of their bugs each week/fortnight/month.

Their Code Sucks

Let's be honest... We were all juniors in the beginning, and our code was really bad. Code from juniors can have any combination of the following:
  • Excessive verboseness
  • Unreadable
  • Logically flawed
  • Horrible naming
  • Undecipherable dependencies
  • God methods
  • God classes
  • Mega anti-patterns

Be patient with your junior. Obviously if they're doing these things then you need to figure out how to be a good teacher. Give them some reading, send them to a clean code course, get them certified. Show them amazing code. Show them crappy code. Show them YOUR crappy code. Ask them to help you refactor some code you're working on. Ask them to pair program with you. Ask them to summarise a coding article for you. Help them realise that coding is like learning the violin. It takes years of practice, and even when you are good, you still make mistakes. 

They Have No Opinion

This is both pro and con. Juniors generally don't have enough knowledge or experience to have any useful input for some specific problems. On the other had, they don't have years of bias, so they can give you a fresh perspective to a problem.

One thing I find useful is to ask their opinion first. It actually helps me understand my own problem, while also exposing them to real world complex problems. My opinion is that by asking complex problems it will push their thought processes to another level. They will try to solve this complex problem, and be better for it. Remember to thank them for their input. They tried to help, and should be encouraged to keep trying.

Are They A Burden?

By now you have probably realised that you have to explain everything to them. If this is a big problem then perhaps you need to look at your organisation / team and see how it can be more accommodating to mentoring/teaching/coaching etc.

I have been in situations where the development team's reaction was "a junior is too much work, we're too busy to hire a junior". Does this sound familiar? It is a clear signal that people are overworked, and are being pushed to work harder and faster. Too much is being expected, and work is being shoved through your pipeline and pushed onto the dev team. The real burden might actually be up-stream. Fix that problem!

Juniors are not really a burden. You need to figure out how to leverage their current skillset, while also expanding it.

When They Succeed

If you have done your job as a mentor/teacher/coach/leader/Yoda, then your junior will quickly become a mid-weight. They will begin to feel confident, and grow. They will start to shine. One day you will notice a shift in the way they talk an give input. It's like a light-switch suddenly gets flicked.

It's a great feeling when you realise your junior has reached that next level. There are only a few things in the world that can give you this sense of pride. Your entire team will feel this. They all helped!

Tips When Hiring a Junior Developer

  1. Hire people who are hungry to learn
  2. Show them good code, show your own bad code
  3. Remind them that it takes years to learn a profession
  4. Be explicit about the the maximum time you expect them to spend before asking for help
  5. Be explicit about having their code checked before submitting a pull request
  6. Ask them for their help in solving your complex problems
  7. Remember that there are no bad students. Only bad teachers.

Final Thoughts

Juniors are great, and teaching them is extremely gratifying. However, this takes time, effort and patience. When they succeed, you feel like a proud parent. You want them to grow. If you are attentive, you can generally get them productive in a matter of months. If you're really really attentive then you can get them leaping to mid-weight productivity in as little a year or two.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Project Managers (coming soon)
  8. Tips When Hiring Remote Developers (coming soon)
  9. Tips To Improve Developer Retention (coming soon)

Saturday, 27 April 2019

Good Help Is Hard To Find - Tips When Hiring Senior Developers

This is the fourth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


Hiring Senior developers gives you the confidence that things will get done, problems will get solved, and delivery will happen. They're an asset. But seniors can also come with some baggage...

Why Should You Hire Senior Developers?

Senior developers are great for velocity. They know their craft, they are fast, and they can guide junior / mid-wieght developers in projects. They can be the gold standard for processes and best practices in your company.

Can You Teach An Old Dog New Tricks?

Seniors have been doing their craft for years. Like everyone, they have good and bad habits. Expect that some people will have some sub-optimal habits which may be dated or even hacky. They might have done something for years without knowing that it was bad.

Old habits die hard, so you need to be explicit and persistent if you want them to change. Give them an assignment to research modern best practices to present to the team. Get them to own it!

Coding Standards

Seniors come from different environments, and that's great! A  new senior might start doing things that are contrary to your current guidelines/standards, because they think it's better, or they're used to doing things differently. That can be fine, but sometimes can cause confusion to other devs.

Gently remind them of the current coding guidelines and practices in the team. Be explicit that it is expected of the seniors to know these practices and set the example for other staff. If they really want  to change something, then get them to consult the team, and present their proposed changes. 


Seniors have opinions, and that's what you want! However just because they are considered a senior does not mean that they will always have good ideas. Or your team might not be ready or capable such for big changes. Be aware that changes to process may have a good result, or negatively impact your  team / organisation for years. I've seen this happen! 

If your new senior wants to change some processes then get them to present the problem and their solution to the team. Get some consensus and get feedback. This is a great exercise as it gets your team's collaborative juices flowing.

If your team is very small or with little knowledge of proposition you can still take an empirical approach. Try it, inspect the outcome, adapt.

Over Confidence

There are some seniors who forget that the other developers in their team are not necessarily able to learn or perform as fast as them. Many concepts and architectural patterns are hard to learn, let alone implement with any degree of confidence.

Remind your new senior that they need to put themselves in the shoes of the juniors and mid-weight devs in your organisation. Can the juniors learn/do it? If not, then have the new senior outline a plan on how to teach them. This is a great exercise as it helps the new senior to better understand the team capabilities.

Progress Can Be A Battle

A senior might prefer the status quo. I have met a few senior developers in the past who pushed back on any change. They were happy with sub-optimal practices as long as those practices/processes were familiar. Changes in process were treated as battles. 

It's OK to be risk averse. Limiting risk comes with experience. However you also need to continue to evolve. There is a balance every developer and organisation needs to find. Remind your team that without learning we become redundant, without innovation companies fail, and the longer we stand still the faster other people and companies surpass us. Change is inevitable, and we should leverage it to our advantage.

Tips When Hiring a Senior Developer

1. Be explicit about your expectations
2. Be explicit about adhering to the current coding guidelines / practices.
3. Ask them to help implement best practices
4. Take their input about how things can change/improve, and definitely get them to present to the team
5. Be explicit that you expect them to be the gold standard for the more junior developers 
6. Get them to teach concepts to your less experienced developers

Final Thoughts

Hiring a senior has many benefits. They're fast, knowledgeable, and can mentor others.  Leverage their experience and knowledge to help boost your other devs.

They might also come with some baggage, so be pragmatic. Be aware that they might have some coding practices which will need to change. Be explicit with your expectations. Remember, experience does not equate to perfection. No one is perfect. We all have bad habits.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Project Managers (coming soon)
  8. Tips When Hiring Remote Developers (coming soon)
  9. Tips To Improve Developer Retention (coming soon)

Friday, 26 April 2019

Good Help Is Hard To Find - Tips When Hiring Interns

Good help is hard to find.

This is the third in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


I have taken on more than a few interns over the years, and it has generally been a positive experience for them and us. Hiring an intern can be both rewarding and a challenge, and you really need to be prepared, and know what you want an intern for. Typically our interns have been with us for 1-3 months.


I'll be absolutely transparent... Our motives for taking interns was to see if we could groom/screen them for hiring. If the person is really smart, hungry to learn, with a good attitude, then they could be a prime candidate for hiring.

We would give them some trivial tasks, some things to read, interact with them, and see how quickly they pick things up. Very often we would also give the intern a list of tutorials to do, so we can see how motivated they are, and how fast they learn.

A Learning Experience

Having interns is a great learning experience for your junior / mid-weight developers. It is a chance for them to do some mentoring of their own. This is a crucial skill as people progress in their careers. It thrusts your devs into becoming teachers, so they are forced to learn how to communicate better.

The caveat here is that you need to ensure that your staff are told to mentor, not whip-crack. 

Expect Nothing

Generally speaking, an intern has no experience and should not be relied on for any work. They are also not there to make coffee. They are there to learn. So you should be ready to teach.

We always give trivial tasks which are not really time dependent. These may be some updates to our website, or a tweak of a tool. We bring interns into all the daily routines and stand-ups. We even tag them on code reviews.

The key point is to expect zero productivity from them, and for them to probably be a bit of a time drain. If this is a problem then you really need to look at your motivations (see above).

Tips When Taking On Interns

1. Don't expect them to be useful or productive
   - Interns are not meant to be "used".

2. Give them some trivial work that has low time dependency and low risk

3. Give your junior & mid-weight developers the task of mentoring the intern
   - This is an opportunity for your devs to learn some mentoring skills

4. Have people communicate as much as possible with the intern
   - This is a great way to find out if they fit the company

Final Thoughts

Hiring an intern is a great experience for them and you. Your devs will get more experience in mentoring, and hopefully learn some soft skills.  Be prepared to consider interns as a time investment, because they will actually take your time. If you are really lucky, the intern will be super smart, and someone you want to hire as a graduate.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Project Managers (coming soon)
  8. Tips When Hiring Remote Developers (coming soon)
  9. Tips To Improve Developer Retention (coming soon)

Thursday, 25 April 2019

Avengers End Game - Non Spoiler Review

Its freaking good. Go see it!

A little slow paced in the beginning, but totally worth the payoff.

Well done Russos. Well done.

Seriously go see it!

Tuesday, 23 April 2019

Good Help Is Hard To Find - Tips To Ensure Quality Delivery When Outsourcing

Good Help Is Hard To Find.

This is the second in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


Outsourcing is typically a last resort strategy to augment your current capacity. It is costly and can have a lot of drawbacks. In this article I'll give a couple of examples of how we handled outsourcing in the past, followed by some tips help improve the outcome.

Silo'd Outsourcing

It is very temping (and easy) to simply hand an entire project to a freelancer or company. The problem with this silo'd approach is that often the code will come back written / architected in an unexpected way. It could be so obscure that you cannot maintain it, or don't want to maintain it.

Many years ago we outsourced to a company (who will rename nameless) who wanted to use a code-first package. We were sceptical about the approach, but the company told us there would be significant time saving. They assured us that the code-first package could be removed after launch. So we let them do it. 

Fast forward to post-launch... They handed back the project and it was an unmaintainable mess.  Even something as simple as changing the label of a CMS field needed to be "code-first", and hence require a code deploy. Worst of all... the code-first package was mangled so much into the code that it was like trying to separate flour from a cooked donut. 

We learned never to just hand a project to another company again.

Extreme Integration

During the busiest growth phase I experienced, we were outsourcing 13 projects to freelancers and smaller agencies. Internally we only had 4 Umbraco/.net developers and 2 Frontend developers. It was a tripling of our capacity over night.

We had so many projects that we couldn't outsource fast enough. We were so stretched that we literally only had 1 developer per project for the majority of the time, while also needing to field support/emergency requests of sites which we maintained. It was stressful, but we learned from our earlier experiences.

This time, outsourced (remote) developers & companies were integrated into our daily routine, and treated as normal core developers. They were subject to all the stand-ups, code reviews, meetings etc. Our core developers all became gatekeepers, and they were all overseeing quality of up to 3 projects each, including the project which they were already actively developing on. The entire development team was in charge of ALL projects collectively, so all core devs were helping each other get their projects delivered.

This of course resulted in the core devs having significantly reduced capacity for their own projects. However, the benefits were worth it in our case. All the projects were delivered with a consistent quality, the code was maintainable, and everyone had enough knowledge of all projects to jump in to help.

Tips to Ensure Quality Outsourcing

  1. Try to go back to the freelancers / companies you have worked with before, or ones who are recommended to you
  2. Ensure your core developers are the gatekeepers of code quality, overseeing outsourced code quality
    • Don't just hand over a project to be worked on in a silo 
  3. Where possible, integrate the outsourced workers / companies in your daily routine
    • This ensures less friction, and promotes better communication
  4. Ensure the development team (as a whole) is actually responsible for the quality of outsourced work
    • Your development team will need to maintain it in the future

Final Thoughts

In my opinion your development team needs to own the outsourced product. They need to figure out how it can maintain quality control during the development. This does necessitate a time drain from your internal team, however the project will have more predictable outcomes, and will be more maintainable in the future.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Project Managers (coming soon)
  8. Tips When Hiring Remote Developers (coming soon)
  9. Tips To Improve Developer Retention (coming soon)