Nearly fifteen years ago I created a small start-up. Knowing I could not go at it alone I scoured my network for the skill I needed. As a tech guy I really needed a go-getter that could so some door-to-door sales and build the initial market. Someone that liked to talk to new people, go to bars and parties, and always meet new friends. One of my friends just happened to fit the bill perfectly AND was technical! We had a few tentative meetings and came to an agreement: I would front the cash, I would make the back-end technologies all work, I would design the business systems, I would manage setting up the corporation and all the legal necessities, and he would own marketing and sales with the ability to do anything else he was interested … no silos here.
The first week was great. We lived in Florida so the corporation was set up the first day! It took longer for the IRS to respond with the S-CORP adoption than it took me to dot every I cross every t and pay every fee! The website was up by the second week and the initial budget created for what we needed to buy as well as a rough draft on the process and procedures for the idea to work. By this time, however, I noticed my friend had not done anything. His excuse, busy with work. We were both working, I get it, so no big deal. By the fourth-week I had 100% up and running ready for the first customer and he had still not made a single motion so we had a special working meeting. I lined up the meet and greets and sent him on the way with a “tour” schedule for five offices.
He came back after the first office and told me the tale of the event and then declared: this is too hard. Can we just hire someone? The implication being that I would hire the person. I inquired at this point what his role would be in the venture? If I am paying out of pocket to hire people, and I am doing all of the work at all levels otherwise why did I need a fifty-percent partner?
Fast forward a few start-ups and this has become a common scene. Now, I normally come in with a nice prototype before trying to build a team and yet the conversation is the same no matter what the role I am looking. People love the ideas (of course I target to people that would), have the skill and the time to invest, and they all believe in the concept. And then, towards the end of the conversation, they all have a great idea (or know of a team that can do this) I should hire someone to do the work or pay their friend that owns the team to do the work. They are certainly willing to sign on as fifty-percent or thirty-percent partners (or even less) but the work, I should farm out and pay for. I always inquire what they see their roll in the venture if I am paying others to do the work. None yet has offered a legitimate value add.
This does not just happen for start-ups that I am trying to bootstrap. Back when I was managing technical teams I went into a company and was tasked with managing a large, matrixed team (ten people, ten people is large in Agile) to deliver a technical marvel. The tech was actually fairly simple. The team, a very interesting reminder of David Graeber’s “Bull Shit Jobs”. Each and every person on the team was wonderful, capable, and fun to be around. We had musicians, we had comedians, we had people that spent years volunteering teaching in Russia during the cold war, we had people with decades of domain experience. On the surface a fantastic team to want to have. And then we noticed something happening with deadlines and with work.
The work-plan was very easy to break out. We had, in a few weeks times, come up with a very practical and very reasonable scope of work that spanned about 18 months on the high-side. We would deliver, incrementally in Sprints (another Agile term), and each Sprint would be very relaxing allowing the tea the ability to work on their “other” matrixed assignments. The first Sprint goes by and we all expect a little rough spots but nothing was delivered. I called in our database team and we had a meeting about the work and the challenges they were having. I put on my teaching cap and worked through the background and the knowledge necessary for them to be able to do the tasks on the plate and we had a great meeting, fantastic even. From my perspective the team had been missing a few critical knowledge gaps and needed just a few key pieces to execute. Imagine my surprise when the two team members line manager called a meeting with me and my director. The topic? Clearly I was a subject matter expert. I should be the one to do the database work for the two individuals. They would, of course, remain on the team but I should do the db work in addition to the other management work I already had on my plate. I politely declined. Only to have the identical situation happen again with the UI/UX team and a different manager.
Across the board, every member of the team WANTED to be on the team. The credit for such a prestigious assignment would look great in their careers but no one on the team WANTED to actually contribute anything other than meetings and planning to the project.
Looking back at this decades of experience you may think I am describing every team and every person. And that is the farthest thing from the truth. I have known and worked with so many hard-working people and enjoy every minute of it. And, as such, the Do Paradox may not exist except that in my professional coaching with Directors of Engineering, Managers of Engineering, and yes even the occasional CTO we are seeing this problem time and time again. The leadership is hiring what should be great teams only to end up spending more and more time doing the work for their teams. The teams? They show up, they are happy. They happily contribute project plans, strategies for action, volunteer for centers of excellence, and attend all manner of training. When it comes to the physical work, however, these people are absent or busy. Always polite and always with a really good excuse and leaving my coaching clients with little recourse other than to do the work themselves.
I was coaching a CTO of a small start-up that went public recently. We were talking, on a Saturday morning, because he had no other time. His nights and his weekends were spent coding and his days were spent coding. He loved his 15 person team but they did little if anything to alleviate his work-burden.
As a manager. Your job is to your people and to your company. You need to be actively involved in the hiring and firing of your team AND you need to actively make sure your team is not comprised of people avoiding work. In short, you need to watch out for the Do Paradox. How you do this? There are a lot of ways and rather than tell you the how (which I know you want) I am going to leave with one last story of how a technical lead tried to get me to manage his team so he didn’t have to. (Leaving him with no assignment but plenty of billable hours)
George was a remote technical lead (name changed). He was hired against my wishes for a team that was dispersed across the globe. I didn’t have anything against George but I prefer to hire directly for teams I am managing. It is one thing to inherit a team but when there are a lot of new hires you do not want a green team thrust upon you while you are green. Anyway it was a rocky start. The team was operating in Sprints, Remote, using GITHUB to manage the source-code with a requirement for all good to use a continuous delivery pipeline. At the end of the first Sprint the team showed of an amount of work. Not impressive but not bad by any means for a new team. Wanting to see the work I logged into GITHUB to find no code and no continuous delivery pipeline. Additionally, I logged into our time tracking system and every developer had failed to report their hours. We were strict but we can’t bill a client for work if there are no billable hours to bill.
I call up George and we talk about the code being absent. He comments that he didn’t know it was his job to make sure the team committed their code into GIT. Being in a new position and realizing he was new as well I explained his roles and expectations as a technical lead. In addition I trained him on a daily report I had used in the past that makes it easier for new technical leads to learn to lead their teams.
The next day the daily report is 15 minutes late and completely wrong. So I call George and we go over the report. I re-explain the need of the report and the value each function provides. Of the course of the next few weeks (and I tracked it) each day the daily report was wrong and just a bit later. Because I like graphs I even gave George a graph like the below to demonstrate. Each day he feigned some difficulty or another finally spilling the daily report over into the next day and wrong.
In addition, I spent time checking the code placed in GITHUB. The first commit, a Sprint late, was hardly production worthy. George and I had a scheduled remote meeting where we did a code review of the developers code and I patiently explained the errors in the code and how, as a technical lead, his job was to review the code every day in GITUB to ensure these basics of quality. Of course, with a new technical lead I set the bar as low as reasonable. Methods must have comments, code must be written consistent with a reasonableness towards the language style guide, no mixing casing in formal parameters and local variables, etc. Just the bottom-line of a review that showed a review had been done. Furthermore, I showed George how to configure the continuous deployment tool pipeline using GITHUB and branches.
As a reward for my efforts George called a meeting with my boss and myself and went on a tirade at the stupidity of the daily reports, the unnecessary administrative burden of him verifying the teams time log, and how it was irresponsible of me to be able to expect him to code review every developers code. He was busy and had better things to do. In his passionate speech George explained to my boss how, if they really needed to be done, that I (George’s boss) should be the one to do them so he could be free to work on more important work. We freed George up for more important work the next day and generously left him with a multi-week severance. And I did, indeed, take his advice and do the work for him that I had suggested he was responsible until we could hire a technical lead that was interested in the work.
There are going to be times in your career when you have no choice in your teams and no control over your budget. Even as a Director of Engineering you may be given an entire team of which you have no control that has mastered the art of the Do Paradox. I work through these issues all the time with my coaching clients. There are way too many variables for a simple blog post on the Internet to offer any simple one-sized fits all approach. We can work together to find a solution that is workable for your team and your situation. With that said, I will leave you with the surprisingly advice my mentor gave me the first time I was given a team that would not work.
“Ennis, just do the work. It is your job to get the project out the door.”
I hate that advice. But, and the truth is, there is a lot of truth in that advice. As Senior Leadership you owe it to your company to help them succeed and being right is not necessarily what pays the bills at the end of the day.