Debbie Madden, CEO of Stride, interviews Jean Barmash, VP Engineering at Merchantry, Co-organizer of CTO School Meetup
Debbie: How should a CTO decide what percentage of their time they should spend coding?
Jean: It really depends on the size of the team and what other responsibilities you have. For example, if you are in a B2B company, you are probably being pulled in to help with sales. If you are going through a big hiring phase, then you are probably spending a lot of time on that. Your duties as a company executive may override your ability to ship code at that point. You really need to be very careful not to become a blocker. For smaller companies where you play both roles of CTO and VP Engineering, I think it's around 5-7 team members when you should probably start doing very little coding. I know I have in the past become a blocker once you have a few team members and still take on significant work. It's important to plan this transition and make sure you have people who can do the work only you previously were able to do.
Debbie: When not coding, what do you think are the top 3 things a CTO can spend time on to benefit the engineering team?
Jean: Figuring out how to make the team better, whether by hiring new people that level up the team, growing your people. Also thinking about how the team collaborates and making adjustments to meet whatever your current challenges may be.
Thinking about supporting roles and how to have a well-balanced team skill sets is hugely valuable. If you have 10 engineers, but no testers, or no designers, then as a team you are probably not doing your best work. You figure out ways to compensate, but if your engineer is spending half a day per week doing testing (which they will not be as good as somebody who lives and breathes testing), or a backend engineer is trying to figure out CSS positioning, you are losing out.
Another part of your job as a technical leader is to advocate for nonfunctional requirements. They can get easily lost, but they are key to us doing our job well. Business typically doesn't ask you to do more testing, but they do have some level of quality in mind. Business doesn't specifically tell you they want monitoring, but they want to prevent failures and recover quickly when something does fail. Making sure nonfunctional features are being implemented and thinking about infrastructure and tooling to help operate the application. How do you diagnose problems in production quickly?
Debbie: What do you wish you knew 5 years ago about leading tech teams that you know today?
Jean: I think as you grow as a manager you spend more time thinking about how people collaborate with each other, balance of skills on your team and skill gaps, and spend more time thinking about people's motivations. Another thing I noticed as I moved from managing several engineers to managing several teams is about how to coordinate cross-team. You also think a lot about where you team is, where its problems are, and how to mitigate them.
You learn that you can only make so many changes at any one time, and need to focus one one or two areas of improvement. For example, we have rolled out Continuous Deployment this year. It was a 4-month process and involved a lot of coordination between Engineering, DevOps and QA. Then we had some cross-team projects to focus on stabilization of our production environment to prepare for the holiday shopping season (we are in eCommerce).
You also get better communicating with non-technology stakeholders and advocate for the needs of the technical team. And of course you get better at planning, risk management, and many other more managerial type tasks, which as a manager really is a big part of your job.
There is much more of course, but these are some things that came to mind.
Debbie: You spend a lot of time giving back to the NYC tech community through the CTO School Meetup. What are some of the top trends you see coming for NYC tech in 2015?
Jean: I'll slightly hijack the question and talk about the topics topics we are working on at CTO School Meetup. We certainly try to be relevant to what's happening in the world of technology and startups. Our January session will be on advanced process topics, ideas from the book "Principles of Product Development Flow," there is some rigorous academic research around how to run an engineering team. Beyond that we are working on a session on event-driven architectures and CQRS, which I see startups starting to adopt. We are also planning to do a session on Docker and light-weight containerization, which have been seeing huge adoption. Continuous Delivery is still not a default way of doing things, and we haven't done a topic on it. Last, but not least is engineering culture and how to organize work, especially moving to autonomous self-organizing teams.