The Executive Brief
Today’s topic is about a first class problem - your engineering team is too good. I know what you’re thinking. “That’s a problem I’d love to have!” I get it. Me too.
Here’s the thing, a first class problem is still a problem. That’s what makes this week’s topic so interesting.
Being a CTO is about being prepared. It’s something I’ve talked about before in articles like CTOs Get Paid to Predict the Future. In this case, you bust your hump to build a fantastic team so you must be prepared for when you succeed.
I don’t want to give too much away here (because nobody likes a spoiler) but I would love to hear your thoughts in the comments.
Btw, before you dive into it, here are the most interesting bits in technology from the last week.
A backdoor was found in a widely used Linux utility. The malicious code was designed to compromise sshd, effectively putting a backdoor into the system. Fortunately it was caught before making it into production versions of Linux.
This is a reminder that supply chain attacks are real and can be devastating. This would make an excellent tabletop exercise. Have your teams figure out what the level of exposure would have been and how they would have addressed it had this made it into production.Microsoft released a suite of tools to help build trustworthy generative AI applications. Its features include Prompt Shields to detect and block prompt injection attacks and Risk and safety monitoring.
The safety and security of AI apps is top of mind for many CTOs and CISOs. Unfortunately there is not an abundance of great tools to help with this. Having tools from the companies behind the foundational models will help greatly. If they do nothing else, their tools give us a benchmark to use when looking at offerings from startups.A container ship struck the Francis Scott Key Bridge in Baltimore, destroying the bridge and closing Baltimore’s harbor. The event is expected to disrupt supply chains for months.
There is still not a lot of clarity regarding the extent of the disruptions. Some high volume items like cars and coal will be impacted however secondary impacts such as FedEx and Amazon distribution hubs in the area are still being evaluated. For CTOs it is probably wise to plan extra lead time for any equipment you need over the next few months.
Poll of the Week
Let us know how we are doing! We’re always looking to improve our content, so your voice is important. Take a moment to respond to the poll or leave us a comment.
When Your Engineering Team Is Too Good
It’s rare, but sometimes a CTO can end up with a product & engineering (P&E) team that’s too good.
This “unicorn team” will have great chemistry between each other, the perfect balance of skillsets to build and maintain the product, and even stability in terms of the teams personal lives which allows them to consistently focus and deliver.
This team builds software with confidence, speed and quality. Usually this kind of team isn’t cheap, but they provide more than a just 1-to-1 return of value. We’re talking about a 10x team that’s way beyond the sum of their parts.
So, how could there be anything negative about a team like this? How could a team like this be “too good?”
Well, let’s look at it from the perspective of the rest of the business. Stakeholders outside of P&E may be thinking about the team like this:
“Let’s not grow the team at all since they have already proven that they can pull off anything we need (and then some).”
“Keep the team focused and working because they are so crucial to everything we’re doing on Tech.”
“Don’t encourage team members to move in or out of the team or it will ruin their chemistry.”
“No raises are needed for the team because they are so good that they don’t need to be incentivized.”
“The next 5 years of roadmap is all on this team. Don’t even bother with the other teams. This team is the key to get it all done.”
“Be careful with giving the team too much PTO. It could really slow everything down.”
“Yes, person A in the team is stealing from the company. But, they are a crucial part of the team so go easy on them.”
Unfortunately, in some cases this is how people outside of Product & Engineering look at world-class A-teams.
Some of the above sentiment is just natural human psychology of course but some of it is just really bad thinking.
This kind of bad thinking, if not properly managed, can lead to several fairly negative consequences for the business & team.
Let’s go through these downsides.
Innovation can stagnate because of the assumption the team is already great and doesn’t need more investment in things like training.
The business can resist parallel development and the added velocity that comes with it because they overly rely on just the one “A team.”
The business can burn out the team by not rewarding it or giving it time off and good talent can leave.
The business’ ability to attract new talent could be impacted if word gets out that the A-Team is frozen and not growing.
The A-Team can’t enable the Product to scale because everything is on them and they have no real support engineers to help them test & scale.
So, what should a CTO do to prevent this from happening?
Under-promising and over-delivering applies really well here. Set the expectations of how much work your team can really deliver over a sustained period of time. Factor in aspects like time off, necessary periods of reflection / thinking, training time, team building activities, and so forth.
Don’t forget to communicate the challenges the team is facing. Constantly touting the teams wins and how great they are is not a balanced approach. The problems they face are important to let stakeholders know about.
Show how past investment in the team has positively impacted its performance and business results. Did you add 1 person last quarter? Was that the lynchpin to the team moving to the next level of performance? Highlight this!
Make good predictions about the skillsets you’ll need for future innovation. As CTO or technology leader, if you feel that the team has all the skills for every possible project you might be thinking about things incorrectly.
Always maintain a risk register and keep this front-and-center with key executives and business stakeholders.
Engage stakeholders in your planning and decision-making processes so they can more viscerally understand the hurdles (both technical and non-technical) that you’re facing.
Establish Continuous Improvement as a core philosophy of your team and let outside stakeholders know this.
Advocate for your team including professional development, comp adjustments, better tools and more personnel.
Build a business case if you need to go get additional funding.
Benchmark your team against industry standards. Compare your teams resources and performance against others in the industry to provide a context for your requests.
Hopefully these are helpful strategies for you.
Closing Thoughts
In my view, a CTO that is advocating for their teams is just being a good leader. But counterintuitively, it can be more difficult for a leader to do so for engineering teams filled with high-performers that are already crushing their goals.
Use the above strategies to mitigate that risk as much as possible.