Part 1
Fire Your Engineering Team
Or better yet, make them productive instead
Webinar Video at the end of this article!
**Newsflash! Part 2 is out now!**
TLDR;
If you have an engineering team and you think they’re not bringing the value you’re paying for, you may be right… But it’s more likely that there are issues that can be resolved. It comes down to People, Processes, and Infrastructure. Read this article series to find out what to look for and how to start fixing them.
A few years ago, I was considering consulting for a company because I had a friend working there and the company started in Y-Combinator (a prestigious incubator that’s hard to get into). The CEO invited me out for a drink. After making idle chit chat, I asked him what he thought of his Engineering team. He said:
“Nothing happens in Engineering unless I make it happen.”
BOOM! What a loaded pistol. He proceeded to tell me a horrific story of how he would literally stand over someone’s shoulder and ask them if they were done yet. Over. And Over. And Over. He was extremely frustrated with his team. It didn’t help that they were easily the highest paid people in the company and yet, he felt that other groups, far less paid, were hustling twice as hard. His approach was wrong but his feelings weren’t. He paid them handsomely and trust me, had every right to feel he wasn’t getting a worthy return. Later, I found out the team was completing about 20% of their sprints on average.
This is just one of many CEOs and companies I’ve spoken to that share the same feelings. Engineers are paid a lot and there is extra pressure on them to perform miracles.
The interesting thing about miracles though, you don’t know how they work, only that you expect to be greatly entertained.
Back at the bar, the CEO wanted to fire all except 2 of his engineers. And he said they’d be twice as productive. He told me how much he paid them on average and ran other numbers by me like he was reading them. He’s a smart guy and clearly spends a ton of time in his spreadsheet watching the money burn.
So what was going on? I know at this point with the horror stories, I probably should have run. Here’s a really intense CEO with zero trust for a team he’s itching to fire. Could I change this CEO’s mind about his team and essentially, work a miracle?
In almost every software organization, there are issues similar to what I’m describing here. There is a trust bridge between Engineering and Leadership. Without accountability or communication, that path is rocky at best. “It’s been 18 months since they’ve released anything!” “Everything they deploy breaks and we lose customers!” The frustrations are real and so is the money.
There are three main parts to engineering: people, processes, and infrastructure. When you know these parts well, you can take on any team issues.
People, Processes, and Infrastructure
People. Do you have the right people in the right seats? As a CEO, this is always on your mind. Who’s working and who’s not. I know in the back of your mind, you’re always thinking about that core group of people that if you had to make cuts who would you keep. As a manager asked me once, “who’s getting on the bus?” That list in your mind comes from an impression — but as well as your instincts have served you, I’m going to share with you how I go beyond feeling to verify where people should be; this is how I coach other CEOs and CTOs.
I can’t recommend Traction (the Entrepreneurial Operating System) enough. Having discovered it not long ago, I can tell you it is a complete blueprint to many of the practices I’ve been following. If you do one thing to help your company deliver on its goals, it’s reading and committing to Traction. The link above is discounted 40%.
Start with setting your core values… Once you have them, then you have a blueprint for evaluating everything else in your organization. From Traction:
“…whatever your core values are, they don’t make the people who don’t possess them right or wrong, nor do they make them good or bad. They just don’t fit in your company culture. If they go somewhere that has their values, they’ll be fine and they’ll probably thrive.”
Wickman, Gino. Traction (p. 85). BenBella Books, Inc.. Kindle Edition.
Of all your observations, 1–1s are the best indicator of whether an employee is where they should be. It’s my secret weapon for managing the team. Set up bi-weekly 1–1s with everyone. Listen more than talk. Follow up on previous things they mentioned (it shows you’re listening and holding them accountable). Follow this guide for killer 1–1s. Get a 360° view around that engineer.
Processes. Product is what features you should add, and Engineering is making it usable in Production. While I’m not covering the Product part of this process, know that it impacts development like requests going into a factory. You can make sure the product owner is refining good user stories before they go into the sprint.
Fundamentals. In order to reach consistently high performance, we need to have a solid foundation of the fundamentals. If they’re already following Agile Scrum, how well are they following it? Get a scrum master to keep everything on track. If you don’t want to hire one or appoint someone on the team, you can rent one by the week from nearshore places like December Labs or Moove-it. In another article, I’ll go into why I recommend nearshore.
As CEO, you may not want to get into this level of detail, but someone has to to get to the bottom of why your team isn’t productive. Do this yourself. You’ll learn so much about how the sausage is made and your perspective as chief of everything will help propel improvements like no one else’s. Follow the whole process — from idea to development to deployment. Don’t be afraid to ask the question: “Why do we do that?” Only after you understand the flow of work can you truly hold them accountable (article Part 2).
Within the Agile Scrum process there are two things that you will constantly have to measure and improve. These are:
- Estimating work accurately
- Meeting those estimations
Getting these right is an ongoing task. It is always evolving and your Engineering team must evolve with it.
Infrastructure is anything used to support getting your product to your customers. It’s not just the servers and network, it’s also how your code is released to Production. In an article about how to restore trust in your Engineering team, why should you care about this?
Because the money you spend building something isn’t any good unless it’s put in the hands of your customers.
And if you can get your product to your customers before the competition or fixes deployed in a matter of minutes as opposed to days, it will give you an edge. This is infrastructure… the pipeline it takes to get your work in front of customers.
How fast can we get a fix to customers? This is called Lead Time. While the customer sees lead time, focusing on process time helps us improve a fast flow of work and typically, the part before the work is started is a matter of prioritization by Product. Use Jira (or some other issue tracking tool) and have engineers track the time they start work until the fix is in Production. Track at least 5 of these in a week over a month and average their times. This will give you an idea of how efficient your team is at processing issues. This is this a time you will want to improve.
How does Production get updated? Have someone walk you through this. Are files updated to the server manually? Think of Continuous Integration / Continuous Delivery (CI/CD) as the opposite. Rolling out a change can happen almost instantly… and if an issue arises, you can rollback just as quickly. Again, ask a partner / vendor like Onix for help if you don’t have these skills inhouse.
How secure is your data? Security is a whole separate discussion. My advice to you is to talk to a security expert like Onix. They will go at whatever pace you want and will do the job right. The point here is to do something — as a leader in your company, there’s no excuse for not knowing what can bring down your company.
What I’ve outlined above is work, there’s no way around it. But if you think it’s easier to fire your whole team and start again, you’re wrong. Swapping out people in a busted system (or no system) will yield at least the same bad results.
Next
Part 1 of this article is about specific elements of software development that your team is likely missing. I have never met an under-performing team that didn’t have issues with these elements. This list isn’t comprehensive in any way. But it’s a start in finding out why your Engineering team may not be delivering.
