CTOs, how do you engage technical members in your team?

Question

As a CTO, you have to perform both technical tasks and management tasks.

Sometimes the team does not see clear goals of the product, or start to act inactively by only completing tasks and performing only code writing.

How do you motivate them?
How do you engage them into improving the product and suggesting ideas?
How do you track their wellness?
How do you help them grow as specialists?

Aliaksei Saskevich · Accepted Answer

@olga_neudakh yes, I agree. Do you think that team climate influences into team member behavior and vice versa? Nowadays, a lot of people in tech works remotely from home, and it's became a challenge to influence on team climate. How do you think it can be improved?

Matt Harbord · Answer

Right, there’s a lot to unpack here - I’m going to reorder your questions, and try to keep it as succinct as possible. Feel free to ask for more depth on any of the points if you want more info. Q: How do you engage them into improving the product and suggesting ideas? Don’t solution engineer! This is my top tip for CTOs and Product Owners. I know it might feel like it’s your job to tell the team what to do, but for a healthy culture please stop! Don’t present solutions to be implemented, present problems to be solved - instead of “we need to do X” ,it’s “how might we solve problem Y?” - Yes, as the CTO you should have an idea of how you would solve the problem, but let’s call that your “sensible default”. Your job is to get the team / individuals to suggest ideas in an open and friendly discussion. Notes: * There are never “stupid” ideas - it’s not “that won’t work because of X”, it’s “Do you think that could work with X?”- let them discover the problem themselves. * You (as CTO) have already done some thinking on this - so don’t be impatient - let the team catch up. Be aware that you’re at an advantage going into the meeting. * Guided Discovery - your job is to get the team to suggest your “sensible default” - and if they don’t you may ultimately introduce it (but hey, by this point you might not like your way of solving it anymore, and prefer another suggestion) * Be flexible, if another team member suggests a slightly different method then err on the side of going with their solution. Less so if it’s critical, more so if it’s not. * For low risk / cost features, let juniors solve it collectively (i.e. stop the senior devs shouting them down). Cheap mistakes, easily fixed, are an education worth paying for. * Note the introverts in the room - potentially identify problems you think they could solve and ask them to think about the solution before the meeting. Check they’re comfortable talking about their ideas before calling on them, but do try to bring them in. Then chair the damn meeting - don’t let others talk over them. Contrary to what you might think, your main job as CTO is not to be the smartest person in the room. It’s to grow a team of people who you can trust implicitly to get the job done WITH OR WITHOUT you. A note on trust: the CTO should not be required to sign off on a merge request (though more than one dev should!) - you must reach a point where trust means not checking their homework. Leave your ego at the door - an excellent technical manager is more impressive than a 10x dev who nobody gets on with. Sometimes a consensus cannot be reached - and it IS your job to decide on what happens next. Where possible empower the most junior if you can. Q: How do you motivate them? Let’s add a few words to your earlier statement: “Sometimes the team does not see clear goals of the product, AND SO THEY start to act inactively by only completing tasks and performing only code writing.” The first is a direct cause of the other. Now, as CTO you SHOULD have an understanding of the goals of the product, but I’ve worked in plenty of places where this isn’t the case. In my experience products fail more often because the C-suite doesn't know what they want (in actual detail) than the dev team can’t deliver it. Here as CTO you’re going to have to put some pressure on your other leaders to make answering this a priority. Motivation comes intrinsically or extrinsically. CEO’s think “hey, I’m paying this 25 year old $150k - what more does she want” - but that’s an extrinsic motivation, which honestly, she could get in any number of companies. Intrinsic motivation comes from autonomy, mastery and purpose. You provide the autonomy from the section above - i.e. agency over HOW things are done. The purpose must come from the bigger picture of what (and WHY!) the company is trying to achieve. Mastery requires some management on your part. There can be such a thing as too much freedom - and I have seen plenty of times development descend into an intellectual jerk circle [I need a better, less vulgar phrase for this!], so a part of your job is also to set boundaries and reasons on what is / isn’t required to solve a particular problem. It’s not always acceptable to refactor code for the 3rd time just because you’ve thought of a marginally more elegant solution. Sometimes you have to be the bad guy too. So now, instead of representing the dev team to the C-suite, your job is to represent the C-suite to the dev team. Don’t OTHER the c-suite. This isn’t them versus us. These aren’t dictats that you’re sorry for but “it’s just the way it is” - you need to internalise the reasons why we can’t spend all our time refactoring code, and why sometimes 80% test coverage is a risk you’re willing to take. And then you need to explain that to the team, and make them understand that you’ll take the blame if things go wrong. And finally, celebrate the wins. And not just as a team. Occasionally it’s worth sending an email out to the C-suite or company praising individuals for their achievements. You need to dumb it down for the C-suite - and you better have told them in advance that you expect some sort of reply to all expressing their thanks. I don’t care if they’re stressed / annoyed by development speed. When the CTO says “Bob did a great job” the CEOs job is to say “thank you Bob”. Q: How do you help them grow as specialists? Firstly, beware specialists, they lead to a low bus factor. A useful thing to both develop the specialist, and share the knowledge around is a weekly dev talk where someone presents what they’ve been working on and how they solved it. Again, lean on “the best person for the job” where it’s business critical, but try to bring in juniors with no domain knowledge where it isn’t. Pair them with the specialist - which both cements the specialist's knowledge (through teaching) and spreads that knowledge around. Allow people to change tracks - they might lose motivation if they’re always working on the same flavour of problems. Q: How do you track their wellness? Regular 1 to 1s - but it should be obvious from the discussions who’s engaged / who isn’t. I found this book particularly useful: https://www.amazon.co.uk/Peak-Sc...

Aliaksei Saskevich · Answer

@matt_harbord mostly it is research of suggestions and advices 😅

I used to be at position as a team lead, and now I'm building a product with my friends at CTO position. At this moment the team is small and behave like a family, and that is very nice.

But the future for any team and product often is unclear, especially when the product is looking for stable growth, and here is:
- the team is burning out
- the team lost motivation to work
- the team has different opinions and devs (especially seniors) often do not want to accept ideas and solutions outside
- members come to team and leave it  in short time

And I found that mostly technical teams (not only the teams I used to work with, but the teams and products were used to work my friends and past colleagues) has such problems I highlighted in my questions above.

So, I interested in opinions and motivations CTOs have and propose 🧐

It's like "postmortem" of failed product but "pre-portem" - to find common scenarios for the team (and CTO especially) to deal with troubles and problems in near-future.

Matt Harbord · Answer

I have A LOT to say on this, but it's Saturday night and I don't have the time right now so commenting here so I can come back to it on Monday.

Are you asking as a CTO with these problems? Or is this product research? (I don't think it will change my answer, but if it's for you personally I might ask more questions for context!)

Aliaksei Saskevich · Answer

@matt_harbord Wow, such a long answer! 💪

> Instead of “we need to do X” , it’s “how might we solve problem Y?”

Yes, I agree that the good idea to keep everything in form of dialog, not the interview. CTOs are also humans, and humans usually can be wrong.

> Note the introverts in the room

How do you work with them in the epoch of WFH? How to identify them when a lot of engineers prefer to work, not to write into chat or speak on meetings?

> A useful thing to both develop the specialist, and share the knowledge around is a weekly dev talk

Do you prefer to perform it by weekly calls or by creating short lectures with the presentation? My previous team (before WHO) used to meet every Friday at the conference room and discuss the presentation someone created this week, but after the pandemic, this process broke.

Thank you for the book suggestion!

Daniel Do · Answer

@asaskevich It depends on how you set your sprint meetings. We're have 2-week sprints and have:
- once per sprint - sprint planning, sprint retro, mid-sprint sync up, design reviews, estimation, sprint demo (for all teams in the company)
- twice per sprint - backlog grooming / team strategy

Engineering team members are part of everything except for backlog grooming. Engineering lead is part of all meetings. The team especially likes design reviews and then they have estimation, which is making it easier because we implement feedback and they know what to estimate.

I'm sharing roadmaps with the whole team on sprint plannings but we're diving deeper into strategy on backlog groomings / team strategy. I always share everything with them in team space and prepared tickets - research, customer insights, data insights, etc.

I never considered these things to be too sensitive to be honest and in my all companies, we share them with them for the context.

Daniel Do · Answer

I'm not a CTO but I have a few points to your second question. I think it always depends on the person - some will be engaged and some of them won't be so you shouldn't require engagement (in meetings, etc.) too much.

We're trying to involve engineers in sprint meetings (sprint planning, design reviews, backlog groomings) and sharing what we're up to and why (sharing roadmaps, plans, research). It helps a lot because some of the engineers are really curious about why we're doing what we do and they love to hear some customer insights and see the data behind our decisions.

Olga Neudakh · Answer

@asaskevich With the transition to remote work, people began to experience difficulty with work-rest balance. The boundaries of this are blurred and the brain does not understand when work ends and personal life begins. After all, the familiar environment already indicates that you are at home, and not at work. This makes it harder to concentrate on the work itself. A person begins to be more often distracted by extraneous matters or events. And at the end of the day can feel more exhausted than at the office. I recommend that managers ask their subordinates about this, how do they feel when they work from home? and some do it in this way: they go to work in a co-working space, where the atmosphere is more conducive to concentration.

Aliaksei Saskevich · Answer

@pm_optimizer I agree that it is a good idea to give everyone in the team a full review of everything happening with the product.

Did you find an optimal amount of meetings for engineers to stay active and involved?

Do you practice to share with them road maps, customer feedbacks by giving them the access to such information on the constant access (by link, e.g.)?

Are you afraid of leaks of such information or not?

CTOs, how do you engage technical members in your team?

Replies