from Hacker News

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

by fictorial on 7/17/18, 2:45 PM with 14 comments

• by davismwfl on 7/17/18, 4:04 PM

  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.

• by YuriNiyazov on 7/17/18, 2:59 PM

  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.

• by osullivj on 7/17/18, 3:00 PM

  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.

• by yc-kraln on 7/17/18, 2:54 PM

  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.