Contractors vs Agencies

It's been almost been a year since I switched jobs, it has been a fun/exciting /frustrating/<placeholder for more emotions> journey, and besides the logical and expected differences between jobs.

There is one thing that has been quietly consuming my idle time: This company loves their agencies!

When there is no budget to hire Full Time Employees or support to do that altogether, the workaround is to hire Contractors, although is easier to get more people from an existing "Partner", however I tend to steer away from that strategy in order to build new practices or even increase velocity;

Besides the elephant in the room

These are my reasons on why I diversify my portfolio of partners and approaches on how to grow teams:

Agencies have an incentive to create hard boundaries and push towards a "feature factory" culture

This way they'll sell more "resources". Making roles more granular helps selling more profiles.

For example: 

• 1 Project Manager
• 2 Backend Developers
• 2 Front End Developers
• 2 QAs

When it could be just 2 or 3 senior engineers!

With such segregation of responsibilities, each team member can also be more junior on average, and the non-senior profiles are the ones where agencies make the highest margins.

This translates into suddenly a team of 10 or 15 people, without actually shipping much value.

Agencies don't have an incentive for increasing code quality standards

Clunky QA and Deployment processes are an opportunity for them to sell the people who operate them. Why should they push for automated CI/CD? They would lose business by doing it!

Issues in Production mean more bug tickets, regression tasks, triage calls, etc. That's an scope increment they'll happily bill for.

Also there's an incentive to accept loosely defined tasks, and not go deep to define all edge cases ahead of development. This will generate more work down the road.

Bottomline, it will hurt the client's pockets!

Agencies create barriers and bureaucracy

This makes super easy to add new people to the team. But not so easy to downscale when needed. Or to fire that person who's not performing. Unless, the person responsible for the relationship decides to go over a lengthy process to discuss why you don't want certain individuals (I did this and it's worth the effort)

Contract clauses like minimum tenures and so on can really hinder nimbleness in a small team (your legal and procurement team will help you here).

Are GitHub Copilot and GPT-4 the cure for all our software engineering bottlenecks?

As a leader I decided to take for a spin such technologies before fully embracing them or even asking my teams to play with them. And the lines below summarize my personal journey and my 2 cents on the matter:

On average, developers produce or change 30 lines of code a day. Most of that time is spent on reading and trying to understand code so they can change it.

It’s almost a 10:1 ratio of reading versus writing code. 

If I knew a DB table was going to be read 10x more often than writing to it, I wouldn’t optimize it for write speed. 

That’s why Kent Beck’s Simple Design prioritizes:

1. Passes the tests
2. Reveals intention (should be easy to understand)
3. No duplication (DRY)
4. Fewest elements (remove anything that doesn’t serve the three previous rules)

There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so passes the tests takes priority over reveals intention”.

Developers who are disciplined will spend at least half their time refactoring the code to satisfy 2–4 as best as they can. We spend a lot of the remaining “coding” time writing tests.

I have experimented doing Test-Driven and Test-After development with GitHub Copilot and GPT-4, and they just got in the way. 

Mentoring developers vs Coding, I realised that it’s better to turn Copilot off. It was just noise!

Can your CTO still code?

Chief technology officers need to keep their sleeves rolled up and maintain their coding skills to better challenge their teams of developers.

Many chief technology officers study technology, consider different architectures and challenge their team to deliver products and services. The problem with this approach is that many CTOs today no longer maintain application development proficiencies.

The CTO is often at the mercy of many differing opinions within their organization without the important understanding, in some level of depth, the challenges, capabilities or even limitations that certain platforms present.

Worse yet, when a CTO completely relies on the advice of his or her engineers, that advice may simply be based on the preexisting comfort levels of the designers, programmers and architects.

When you’re consistently taking the word of others and haven’t maintained enough skill to perform basic discovery for yourself, you, as a CTO, are significantly diluting the power you have in driving true digital transformation for your company.

Continue reading