HN Explorer

Ask HN: Senior dev to CTO - tips for context management (devs, coding, etc)

5 points by fictorial ↗ HN
I'm a long-time generalist "full-stack" developer. Past 9 years I've been a freelance iOS developer and I could take on as much work as I wanted, pick how it was done, etc.

Now, I'm the CTO of a small web development shop and manage 4 developers. I'm struggling with being pulled in a million directions and have a hard time focusing enough to get work done. I'm happy setting up technical architecture, mentoring junior developers, etc. But, I'm also seen as the tech guru who can and should do anything needed quickly and I simply cannot because I need to focus to be productive.

I'm either in full on people mode or full on hyper focused tech mode and switching kills me. Do you have any tips/books/videos/anecdotes/advice for a newbie "C level" developer?

Thanks!

14 comments

[ 2.4 ms ] story [ 50.1 ms ] thread
yc-kraln
CTO is a strategic position. It sounds like what you're doing is engineering management + strategy + product development, which is a recipe for burnout and failure. Identify which one of those things you prefer to do, and clarify your responsibilities within that role. Are you more strategic? CTO. Are you more people manager? VP Engineering. Are you more individual contributor? Senior Architect or similar, non-people-responsibility tech role.

If you go the people management route, expect to be constantly supporting others and developing them--contexts will always be changing.

YuriNiyazov
With a team of 4 the CTO and the VPE roles are usually handled by one person.
fictorial
Perhaps we just need more people to which I can delegate work. I love designing big architectures and also mentoring junior developers. But then also doing a lot of the work or jumping between 5 projects to bail a junior out is spreading me thin. So, we'll see. We ARE hiring more people so maybe I just need to be patient.

Our founders do all the client management, we have a product manager who deals with the WHAT, and I deal with the HOW, with 4 developers under me hopefully as means to implementation.

YuriNiyazov
No you don’t need more people. It doesn’t sound like there’s too much work to do, it sounds like you haven’t developed as a manager.
fictorial
Clearly! That’s why I am looking for help in any form in order to improve.
YuriNiyazov
You need to learn to use your calendar. I mean both the concept and the actual app like google calendar.

You need to do you “light management” in prescheduled meetings that are on the calendar, and you need to fill the space around those meetings with tasks, so that other people don’t interrupt you during those times.

Tell everyone that if they want your time, they need to book an available slot on your calendar first.

fictorial
That would be a solution if it were not for the 24/7 reliance on Slack for almost all team communication. I really really hate Slack-like in-your-face-all-day interruptions. It's hell.
YuriNiyazov
Senior leadership of a company is there to be in the service of the individual contributors. One of the prerogatives of the leadership is that leadership gets to define how that service is delivered to the ICs.

As CTO, you get to set the communications culture of your team.

You should announce that you will check your slack notifications once every two hours and no more. Anything more urgent - come to my desk. Anything less urgent - schedule a meeting for tomorrow.

If people start abusing the “come over to my desk” loophole, start explaining to people what urgent means.

osullivj
Your job is now about making the team productive, rather than just yourself. Switching between coding and managing is only possible IMHO if you started out as an individual contributor, became expert in the codebase and environment, and then moved up to lead. If you're producing project plans for business and management stakeholders - and you should be - do not assign coding and troubleshooting tasks to yourself. Regard yourself as contingency resource, and pitch in at crunch time. You can scratch your coding itch in between meetings by working on POCs, futures & prototypes that are not on the critical path for client deliveries. If those POCs etc end up on the critical path hand them off to ICs.
lnkmails
I think this is a sensible advice and the one I personally follow. I manage around 10 people and as much as I love to write code and be involved in everyday engineering, the real success measure for me is to see everyone succeeding in the team. This requires a personal sacrifice and picking left overs which aren't in the critical path. Initially, I tried to over compensate by putting more stricter requirements on writing code equal to doing people management but when I got more people, it just turned out exponentially harder. If you aren't able to make this sacrifice in a few months time, you should reevaluate and maybe take a different role. You'd do yourself and your team injustice if you focused more on yourself than the team.
fictorial
I agree with you and GP in that I'd gladly take on less coding and focus on delegation and mentoring which I'm finding I really like. However, it seems the founders see me sort of as superman of all things tech. This means, that I'm stuck for now in both worlds. It's a bit claustrophobic but I feel that many people must be in this boat with me.
cimmanom
You need to explain this to your founders and get them on board.
davismwfl
To be fair the role is made harder because you are in a small firm. The larger the firm the more specialized the role is so it becomes somewhat easier as task switching at least stays in one domain. Right now you have to switch domains, which is normal given the size but not easy.

There are literally way too many details to try and explain here. But IMO, it boils down to this, given the size of firm and team, your job is just complete and total expectation management. Expectations of the business on engineering, expectations of clients on what is doable within budget and time constraints and expectations between the engineers to keep a healthy team.

You can/should split your day and/or split your week into domains and tasks. e.g. do customer followups every morning, team meetings every Tuesday and Friday at 10am or whatever makes sense. This is just about time management and again, setting expectations. Once it has been in place for awhile it will become routine and people will know what to expect and when.

Lastly, you need to stay out of day to day coding at this point as much as possible. Given the size you are too small a firm for you probably not to have some code interaction, but your real role is not to be in code -- or get out of it as quickly as possible after helping a developer. CTO of a company with less than 10 developers is really just a normal team lead with a few extra tasks and a C level title which helps with external customers. I don't mean that as an insult, it just helps frame it some for people. However, what the title adds is client facing responsibilities and business execution responsibilities that wouldn't normally be on a team lead. My personal advice, stay out of product code/client code, but focus on pre-sales demos and mockups etc which can keep you fluent and let you set the tone and pace for the team. Again, if you split your week you should have at least a couple of days a week where you can focus on these tasks.

fictorial
> My personal advice, stay out of product code/client code ...

Sage advice and I understand and agree with what you wrote about the role. The founders do not see a CTO in this light. They see me as more of a Super Senior Developer, Dev Team Manager, and Lead Architect all in one.

For instance, when the client and the founders have meetings about upcoming feature dev, the tickets are by default assigned to me if they are too complex as the juniors won't be able to handle it.

And I'm only 3 months in so I don't want to push too many buttons and push back because this stuff needs to get done and there's no one who can do it at this time.

Thus, I don't see it changing much as we have 4 junior to mid-level developers and have a ton of big platform style projects...