23 ms·
How my role as CTO has changed as we've grown from 1 to 100 engineers
- edawerd 8y agoHi all! I'm the author of this post. Happy to answer any questions here about how my role as CTO of Gusto has changed over time!
- mallyvai 8y agoReally interesting post, thanks! You mentioned a few recommended readings (High Output Management, The Score Takes Care of Itself), which are all great general management books. Have you noticed much divergence from their advice when specifically applied to engineering management at high-growth startups?
- smt88 8y agoI use Gusto and like it for it's simplicity. It makes a complicated part of running a company much smoother. That said, I'm very curious what exactly all those engineers are doing every day. What's the most meaty part? Payroll? Dealing with govt? Keeping the servers up? I think unexpected scaling pains are one of the most interesting and unsolved issues with being a CTO and would love to hear more about that at Gusto.
- edawerd 8y agoI can certainly share some of the meatier areas that engineers at Gusto work on. - Calculating payroll and filing quarterly and annual forms are very complicated tasks that (a) is different in every state and (b) changes frequently as federal, state, and local tax laws change. Doing payroll in 50 states is similar to doing payroll in 50 different countries - Benefits is similar to Payroll in the sense that it's also very different in each state. The business logic is complex and a significant amount of engineering work goes into simplifying it for us customers - Because we move billions of dollars per month through the banking system, we have a lot of the same technical challenges as a Stripe, Square, Paypal, Venmo, etc. We have a dedicated FinTech, Payments, and Risk teams for this. - Security is super important to us, since we have a lot of PII/PHI and financial informaiton - Gusto is about 600 employees today and we invest in lots of internal tools for non-engineering functions, an enterprise data warehouse, and security. - We are also looking into what the future of payroll looks like. A personal goal of mine is to rid the world of the concept of a "payday". Why shouldn't employees get paid whenever they want for the work that they did? https://techcrunch.com/2018/06/21/gusto-flexible-pay/ https://techcrunch.com/2018/06/21/gusto-flexible-pay/ - Technical debt: When you grow as fast as Gusto does, you inevitably accrue technical debt and it's important that we carve our engineering resources to keep that low. There's a lot more in there, but hopefully it gives you a sense of how 100 engineers can add up pretty quickly!
- itronitron 8y ago>> rid the world of the concept of a "payday" you might face some ingrained cultural barriers with this as the higher-status the job the more infrequent/delayed the payday... day-laborers are paid at the end of the day, many blue-collar jobs are paid weekly or bi-weekly, and white-collar jobs are typically paid monthly
- lmeyerov 8y agoWe use gusto across multiple jurisdictions where tax laws change every year and our bookkeeper our employees put them through funny circumstances. I've been impressed by how many problems they've made invisible (just notify us) or we sent over and they handled. Cannot say the same about other folks we use here (ex: zenefits caused multiple lapses in coverage).
- dpcheng2003 8y agoI used to be a PM at Gusto so I can add to Eddie's answer. As Eddie mentioned, it's non-trivial to keep the existing applications running as well as they do. That being said, a non-trivial amount of time/resources is spent making an already amazing product that much better. For example, my friends just launched a new product that lets you pick your payday (https://techcrunch.com/2018/06/21/gusto-flexible-pay/ https://techcrunch.com/2018/06/21/gusto-flexible-pay/). To get this to work, there's a lot of data science involved to make sure you're not exposing Gusto to financial risk (it's effectively lending money). Since taxes are withheld with every paycheck, the payment flows associated with flexible pay become incredibly challenging. They're an amazing team. Go Eddie!
- bradgessler 8y agoDid you have to get up to speed on al the details of fraud, risk, and FinTech? If so how, what resources did you use to figure it out? If not, did you hire expertise, bring it in-house, and only have to implement bits of it into Gusto? Second question: how did you determine to shift development from SF to Denver? What criteria went into selecting Denver over other areas? How did you figure out what to move their and keep in SF? Third question: how are you doing? I remember in S08 when you were working on PicWing. We’re still working on Poll Ev!
- edawerd 8y agoHey Brad! I'd say it was a combination of hiring in-house experts (we did that to learn about payroll taxes), and lots of reaching out to people and not being afraid to pepper them with questions (for example, in the case of learning about the ACH system: https://engineering.gusto.com/how-ach-works-a-developer-perspective-part-1/ https://engineering.gusto.com/how-ach-works-a-developer-pers...) As for Denver, a ton of factors went into choosing it. Ultimately though, we just loved the people, talent, and culture in Denver so we went with that! I'm doing great! It's so great to hear from you again.
- sarabande 8y agoWhen you were larger, you state: "At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn’t possible to do both." Since you chose the management track, what did you do/who did you hire (in what levels) to take care of engineering at the level you were previously doing? Or were you effectively functioning as a standard IC so any developer could take your role?
- edawerd 8y agoIt was important to us to be deliberate about hiring senior ICs since I was more on the management track. We already had some in the company so that helped as well.
- ngokevin 8y ago- How much do you miss coding? Do you ever do it? - How would you and the company be different if you stayed on the technical track? Was it a legitmate option? - You mentioned you had to give up one or the other, what made you decide go management over technical?
- edawerd 8y agoDefinitely miss coding! I still do a little during our hackathons but otherwise don't have that much time to commit to any projects. I would just slow down the team.
- benaadams 8y agoThought of contributing to open source to keep your hand in; while not creating bottlenecks, dependencies and project stress in your own company?
- eksemplar 8y agoDid you pick up any management education along the way? I spent time getting a masters in public administration and management when I made the move myself, and found it invaluable.
- edawerd 8y agoIt's great to hear that you found the Masters invaluable! I personally didn't do any formal education myself beyond reading, finding mentors, workshops, some coaching, and experience along the way.
- seibelj 8y agoI am a CTO, going from 2 engineers to a total engineering org of approximately 20. Much of my time is non-coding, but I don't believe you have to totally give it up. I try to leave a day per week free of meetings to code / review code. I keep some projects that, while useful for the company, can be worked on irregularly and slowly, and are not super essential to be accomplished quickly (which is why they aren't prioritized for the engineering teams).
- yarper 8y agoGiving up coding is what you do for your team, so they don't have to deal with the half finished B grade work you did inbetween doing the serious shit they can't do
- seibelj 8y agoWow! What an extraordinarily unhelpful and bad attitude you have
- kochthesecond 8y agoWhile crude, I believe he is right. I have seen it too many times with project managers and now my CTO. Trying to still code and fix that terrible bug with already too little time. Ends up slowing down everyone because he never can get anything finished, or breaking things on a Thursday at 6:49pm because of the half baked solution he thought was good enough, but exploded in production, which he then has to spend 1 more hour fixing and 6 more hours cleaning up the aftermath. Spend your time reviewing and mentoring and try replacing yourself with someone who has time. You now have important shit to do.
- seibelj 8y agoI have determined that I can still code sometimes and not ruin engineering. Nothing is black and white
- 8y ago
- cvaidya1986 8y agoVery helpful write up. Do you feel ‘guilt’ for being solely managerial? How do you manage code and design quality? What criteria do you use to hire now vs early days?
- wallflower 8y ago> To accomplish this, I decided to fly to New York to hole up in a hotel room for three days to read a few highly-recommended management books. > I decided to focus on growing Gusto’s engineering team, and not our code. The technical books on my desk starting getting replaced with books like Mindset, High Output Management, and The Score Takes Care of Itself — still three of my favorites today. If the three books listed in the latter excerpt were not those three books you read in the hotel, can you please tell us what books they were?
- johnrob 8y agoGiven that you were essentially learning management while in the role, did you ever end up hiring people with prior management experience to report to you? What was the mentoring like for these folks - were there cases where your reports actually had more experience than you?
- edawerd 8y agoThat certainly did happen. In fact, I would say its quite necessary for growing startups to continually hire people with more management experience than anyone else in the company. There isn't a sense of ego associated with that. Many of them are really just excited to be on this mission together.
- asdsa5325 8y agoYikes, that open office picture looks like my nightmares.
- sli 8y agoTook me a second to realize you didn't mean, well, OpenOffice. I'll have to second your "yikes," that looks like a really distracting and very echoy place to work. I'd never get anything substantial done with any reasonable speed.
- walshemj 8y agoAll those hard surfaces looks like it would be a noisy environment.
- easymovet 8y agoThe justification I hear for ignoring the data against open offices is: "Every other unicorn has an office like this and they get work done so why can't we"?
- mandelbrotwurst 8y agoIn a place like SF where office space is as expensive as it is, I wouldn't be shocked if the savings in rent from this kind of floor plan outweigh any productivity losses and I'd bet that is a primary reason why there are so many open offices. Edit: That said, that one definitely doesn't look like the most efficient use of space.
- mmt 8y agoThat seems unlikely. I think they're in Boston, but, even in New York, which, for office space is even more expensive than SF, the excuse that square footage is too expensive seems shaky, especially since it's been trotted out routinely over the past 3 decades. This blog post shows a credible calculation, even assuming remarkably low salaries (and a fairly credible $5/sqft): https://business.linkedin.com/talent-solutions/blog/hr/2016/open-office-plans-are-a-lot-less-cost-effective-than-you-may-think https://business.linkedin.com/talent-solutions/blog/hr/2016/... The real key, though, is at the end: > the calculation above doesn't count the cost of setting up the offices For an early startup, that cost, both in dollars and, perhaps most importantly time (move-in delay), could easily be prohibitive. Of course, once the company is past the early stage, it may just be habit or cargo cult.
- iamwil 8y agoSup Eddie. Besides books, did you go and ask people about how to be a great CTO? Who did you pick to ask, and how did you find those people?
- edawerd 8y agoHey Wil! Yeah, I found a few mentors who I would feel comfortable asking questions and getting advice. I met some though investor introductions, and others through friends of friends.
- iamwil 8y agoDid you find their advice helpful? Could you tell ahead of time who was going to be more helpful than others?
- saketj 8y agoGreat post! What were some of the toughest decisions that you had to make in your capacity as CTO, as the company became larger?
- jackconnor 8y agogreat article, loved it
- volaski 8y agoit's refreshing to see someone who actually successfully scaled a company write an article about "here's how we did it", instead of bunch of failed entrepreneurs who write medium posts about why they think their startups failed to either feel better about themselves or to capitalize on their failure with the attention they get from the blog post (answer: they don't know why they feailed, and that's why they failed. The only way they know what they think they have learned through failure was actually something meaningful is to apply the "lesson" in their future endeavors and see if it works out. Until then, all your interpretations are nothing more than your opinion) I would love to see more of these posts on Hacker News instead of failed startup post-mortems. Thanks for sharing!
- seanmcdirmid 8y agoThere is a certain amount of luck/risk involved in doing a startup. You can do everything “right” and still fail.
- yarper 8y agoThat is not a weakness, that is life edit: this is a star trek reference
- worldsayshi 8y agoI certainly agree that this is refreshing and a very interesting read. At the same, because of survivorship fallacy, I think the best way to get insight into what makes stuff tick is to get a balanced mix of both success and failure stories.
- Bekwnn 8y agoSurvivorship fallacy is one thing, but I would say overall there is far more value to success stories where a majority of stories are failure ones. Generally speaking it would seem the path to success, varied as it is, is far narrower than the path to failure. From a failure story you can look at what they did, but if they did X that doesn't mean X leads to failure, as others could do X and succeed. It's possible they succeeded in spite of doing X, but it's usually apparent when that's the case. Maybe X only worked because of a perfect storm of conditions/timing. I would also say a vast majority of people who fail go on to fail a second time, making their whole reflections write up from the first failure kind of weakened by the fact the lessons they learned from their previous failure were not enough to avoid it the next time. Paying too much attention to what not to do just leads you down a totally different road to failure. Common pitfalls are worth knowing, but it would seem there are 10 ways to fail for every 1 way to succeed. Often big successes do the exact opposite of all the "don't do this" advice. But that's just my perspective working in games, where creativity and rule breaking is a lot more substantial to the success, I think. However, I feel it all applies to a broader scope of business and software.
- zmitri 8y agoHow did you maintain compliance and security before you could have someone full time on it? How did you deal with audits? Did you hire an engineer full-time dedicated to this, outsource it, or do it yourself? (I ask because I do this now but at 8 people it's starting to take up too much of my time as CTO) How does it work at your size now?
- lylo 8y agoI think either of your options would work. If you have in-house skills (yourself and/or another engineer), exploit them. If you have a trusted third party who can help, spend some time and money on them. If neither of those work and you feel you need to hire someone, do that (although I’d go with the other two options first). Also, as you undertake these audits, keep a solid record of documentation (questions and answers) as most due dil exercises will be made up of many of the same questions. Stock answers go a long way.
- etaty 8y agoThis video is about : "Finance as Strategy: When and How Startups Should Build a Finance Function" - a16z https://www.youtube.com/watch?v=ns9_OGz4SeE https://www.youtube.com/watch?v=ns9_OGz4SeE But this could apply to any Function in the business.
- jiveturkey 8y agoI would argue, you need a security specialist at about the same time as you need a build pipeline specialist.
- yarper 8y agoAt what point do you start calling people direct reports? I find this turn of phrase really jarring
- shawn 8y agoWhy does it feel jarring?
- yarper 8y agoI think it's because it implies that their job is to report to you -like you're really the brains of the operation rather than just in a different role
- stronglikedan 8y agoReporting hierarchy is there for a good reason. If you report to multiple people, you're the one that's going to have a bad time when they're not aligned with each other, each trying to give you a different list of priorities.
- yarper 8y agoWhy don't they know what's important and what's not?
- jcheng 8y agoIn a larger organization, "knowing what's important and what's not" at all times can be practically a full time job in and of itself. A lot of engineering teams like to protect individual developers from meetings and conference calls so they can focus on development, but that necessarily means developers will be missing context.
- jp_sc 8y agoWhen you are managing people that manage other people, so not everyone _direct_ly reports to you.
- 8y ago
- lylo 8y agoIf you’re now focusing on the people and management, whose responsibility is technical strategy and execution?
- spamizbad 8y agoHopefully you've hired solid technical VPs/leads/senior developers who don't need C-level babysitting
- camdenlock 8y agoFantastic article! I’m in a similar position as you, and will have to face the same decision you did, so this was refreshing and edifying to read. Thank you for taking the time to write it. One thing that stuck out to me was your mention of focusing on “diversity and inclusion”. Why did that become a necessary thing for you to focus on? It seems political, and entirely unrelated to the actual work of building a good engineering team. Isn’t it enough to ensure that anyone and everyone has the same opportunity to get hired? At my company, my goal has been to ensure that all candidates get judged without focusing on attributes like gender or ethnicity; to make sure that the doors are open to everyone, no matter who they are. I then try to trust that the people who want to work in this field, and this company, are capable on their own to come to us. Has that been your experience, or has there been good reason to put extra effort into finding/favoring candidates with certain characteristics?
- asafira 8y agoI have a few questions! 1) Did others in the org recognize you couldn't spend as much time on code, and they appreciated your time elsewhere? I can imagine there being some growing pains as you slowly gave your responsibilities to someone else, and in the meantime things not getting finished as quickly/productively. (Not to mention the fact that an average engineer wouldn't like spending 12-14 hours per day coding) 2) What is your favorite advice from the books you've read? What made the biggest impact on your actions?
- cabaalis 8y agoWe went from 1 engineer (me) to 4 last year. So I'm in the 2-10 stage. I coded prototype and first X customers, which has become literally 20X in the past year. I still code most of the time, and the primary problem I am encountering is being willing to transition technically difficult aspects of the product. This has to happen, as I am finding myself becoming a huge bottleneck.
- jgh 8y agoCongrats on the success! Yes definitely replace yourself sooner than later or you will regret it when you're dealing with company stuff and you need to fix a bug at the same time!
- awad 8y agoThe old cliche to work your way out of a job really resonated with me when I made this transition. It is natural to want to take on a task for yourself and to think you're doing your team a favor by shielding them from details you have a mastery on. But, once you get into the mindset of enabling everyone by focusing on training and knowledge sharing, you find that people are far more capable than perhaps you give them credit for and in fact do them a disservice by not giving them more reign. Worst case, you get a bit of sanity back from being less of a bottleneck. It may not seem like it, but most of the time the people applying tight time pressures are ourselves (customers also have more patience than we give them credit for), and it is generally worth it to invest in teaching someone to fish, as it were.
- bla2 8y agoThis surprised me at first: > having difficult conversations with individuals is never fun But apparently "difficult conversations" is a Valley euphemism for "firing people" and doesn't mean "discussing difficult engineering problems".
- dayvough 8y agoHow is this specifically a Valley euphemism?
- itronitron 8y agoI think they are just hoping that it is highly localized.
- sethrin 8y agoFor most working persons globally, getting fired isn't something that involves a "difficult conversation". Working stiffs do not get that degree of attention to their feelings. Suggesting that this phenomenon is common to (or even characteristic of) the high-income and acutely socially-aware circles of Silicon Valley should not be construed to exclude its observation elsewhere, but SV is one of the few places where the behavior is common, and hopefully the only place that feels the need for a polite euphemism.
- alexchamberlain 8y agoNot sure it needs to mean firing people as much as giving any constructive feedback to an experienced engineer can be difficult, even if done perfectly.
- tyteen4a03 8y agoIt might just be my British shining through but I had no problem understanding that bit.
- legohead 8y agoI was an engineer #1 hired by a "CTO" and we grew to 50 engineers. His story/growth didn't really change much, however. He was a coding machine, a true "10x engineer", and programmed day and night. He even started up a second company while working on the first. He built both codebases from scratch, and even re-wrote the first company's core codebase at one point. He did attend exec meetings and make all major technical decisions, but I never really felt he had to grow into anything. When we got big enough to start worrying about compliance, security, and HR tools, we did it together and moved on to the next thing.
- justAnotherNET 8y agoAre you me? We’re at 30 now and I know exactly what you mean.
- nine_k 8y agoPretty sad that it sounds as if security was an afterthought in your design.
- lancefisher 8y agoThere are a whole host of compliance and security issues that you don’t have to (and shouldn’t) worry about when you’re small. Employee background checks, documented disaster recovery plan, 3rd party pen testing, etc. Those are things you worry about once you have built something. It’s different than just application security which itself can always be improved over time even if it wasn’t an afterthought.
- dfsegoat 8y agoSarBox, GAMP, GAAP, cGMP, PCI-DSS... The devil hath many names.
- jiveturkey 8y agoto offer a counterpoint to the lovefest going on here, TFA is almost completely uninteresting. the role changed exactly as one would expect and predict. the only interesting part is reading about the humble beginnings, the dedication and belief. what would actually be useful to read about is failings, where OP failed in transition to manager and how he overcame those failings. I mean there's a paragraph in there but it's so boring -- "I read these 3 books". ok there's a little more meat than that but it's too nonspecific to be interesting. come on people, let's not just throw love out there for no reason. it has to be earned. this article doesn't earn it. OP should read _the hard thing about hard things_. there are many anti-lessons there, don't treat it as gospel. but read it as a guide as how to write something that actually delivers a lesson. i await your downvotes ... :P
- lostctown 8y agoMirrored my thoughts exactly. Maybe some take to the role more naturally but I've found it quite a struggle. These rosy eyed pieces certainly don't help.
- ChuckMcM 8y agoThe common failure point, which the author mentions, is that people management is not like coding. And trying to do both at once is a losing proposition. I always stress to new managers that managing is different than coding in its execution but similar in its perception. What that means is that when you code a system and it works well, it operates smoothly and when things happen (like you lose a disk drive, or a server crashes, etc) it continues to operate and perhaps degrade gracefully. This is also true of well run organizations. Most people recognize when the organization is running smoothly, and appreciate it when the organization responds quickly and without disruption ton changes in the environment. To me, I see that as the essence of good people management. Sometimes when you have a piece of code that in spite of rewriting it a couple of times the system still bottlenecks or whatever, you restructure. Same with groups, except instead of code being moved around you move people around. Being able to see people as a team with unique capabilities and putting them in roles that are successful has been compared to programming. The next step in the growth of a CTO (or perhaps the one after the next step for the author) is when the company gets big enough to start making choices about which problems they are going to focus on. Are they the payroll company that you can run from your phone, or the one that integrates with Salesforce? Or the one that blends remote workers from the largest number of areas into a single payroll. That is when you have to start thinking as both a business person and a technical person so that you can help steer the priorities to solve the customer problem as it arrives and before it is solved in dozens of ways by your other competitors.
- yelloweyes 8y agoThis guy flew from San Francisco to New York to read books in a hotel? Like... what?
- dustedrob 8y agoThis. I never understood why he even included it in the article. Did he get his company to pay for the trip as well?
- jstandard 8y agoI understand where he's coming from. Sometimes to create a big personal change you need to disrupt your routine in a big way. For me, a change in environment really helps me think or focus differently. New York may have been special in some way that could help that change. I think the anecdote underscores how tough it can be to make that shift from doing something you love and are good at into new responsibilities you're not as strong in yet.
- workinfunk 8y agoI almost started writing a sincere answer to this question before I read your post history. Cynics like you would never understand anyway.
- charmides 8y agoWhich mistakes did you make when you were transitioning from an engineer to a manager? Were there any incidents with your employees that you wish now you had handled differently? Thank you for taking questions.
- balls187 8y agoAlt title could be: how I went from CTO/Co-Founder to the CTO and VP of Engineering.
- mattdeboard 8y agoThis comment is hard to word without sounding like I'm grinding an axe with the author or the blog post or something. I'm not. It's a good post. Anyway, I was disappointed but unsurprised to find that Ctrl-F "leadership" yielded 0 results. Anyone can read management books, and I am sure they're super valuable for learning techniques to maximize the value the company gets out of its employees. However based on my experience over the last many years, it's not enough to be a skilled manager. "Necessary but insufficient." Leadership is a different skillset. I am sure Mr. Kim has learned a lot about leadership, he just didn't split out the two in the blog post. Undoing the semantic smushing of management + leadership so they can be focused on independently is important, IMO.
- beager 8y agoThanks for sharing this. I don't have any specific questions but being at the tail end of 2-10 myself, it's good to have reference points for when other people do certain things, like draw down to ~50% code or 0% code, how much time to spend on recruiting, etc. I will say that I've been feeling a different type of code guilt. I feel guilty when I code, because I view supporting, coaching, and mentoring my team to be my 10x activity. If I'm coding, there could be 8 other people getting blocked or needing help, and I'm off trying to build 4 hours of context to solve problems.
- plinkplonk 8y ago"At this point, I believe technical co-founders have a binary choice: Stay on the technical track and hire a professional manager (usually given the VP of Engineering title), or give up coding and focus on the management aspects yourself. It really isn’t possible to do both." For me this is the key quote. I have a friend who went the other way from the author of this article. He started as one of two company founders working out of an apartment doing all the technical work while the other founder focused on business stuff. When the company grew to a point where he had to decide between staying technical and people management, he hired a VP of Engineering, stuck to coding, and still codes 6-8 hours a day. The company is now at about 200 people, is profitable, raised a series A after figuring out the business model, and blowing past the goals set by the investors. His stake in the company is worth many tens of millions today. Just an existence proof that 'sticking to coding', can be a viable strategy, if an unusual one. He is not interested in blogging/social media etc, or else I'd have persuaded him to write up his experience. I have to agree with dang. Most people running successful startups don't have (or take) the time to write about it. Which is too bad (imo). We could use more writeups from the successful subset.
- Fradow 8y agoI'm another of those technical founders who choosed to stick with the code. Even though we are still very small, it has been a subject of conversation since the beginning between my co-founder and me, and after 2 years of trying to convince me to assume managerial tasks, she finally came to term with that idea. It helps that a late-founder joined us and is already assuming the VP of Engineering tasks. This was done even before our seed round, at only 2 developers. The sooner the divide is made, the sooner you can fully concentrate on building the product. I never really liked the "CTO" title, as I don't think of myself as a "Chief" or "Officer. I'd rather be called Lead Developer.
- jSully24 8y agoI think this is a critical point for engineers to see, and it sends a great message for engineers joining a company: "You don't have to go to the mgmt. track to have great career growth." In many organizations I have seen the deep technical skills one gains through their career are not valued in the same way "Mgmt. Skills" are. "Mgmt. skills" are or at least appear to be much easier for an organization to see and reward. This is a great story!
- sinnet11 8y agoDo you ever feel "bad" about cutting corners early on to push a product but now others are working on the the same codebase? I have this feeling constantly.
- vagab0nd 8y agoWhat do people think about the career trajectory as an individual contributor in an early stage startup? I'm the kind of person who not only enjoys coding, but hates dealing with management, hiring, meetings, etc. I always fear that I will be pushed to take on a management role. At the same time though, I really enjoy working with a group to build something from scratch. In your opinion, do you think it's better that I don't join an early stage startup?
- ccmonnett 8y agoNo! I was the only engineer at a startup for 18 months (!) and we're now up to 7. Some of the other 6 will never be expected to take on management roles. One of the great things about being an IC at an early company is there is so much to do. You get to put your fingerprints on a lot of things across the company because there won't be enough people to spread out all those tasks. As the company grows, those foundations become opportunities for you to grow from sole contributor to technical lead on each one; so much so that the hardest part will be choosing what to give up control of, not to what to keep contributing. If you find yourself in this situation, I strongly recommend being involved in the search for your VPE. It could be really frustrating to build the technical foundations for a company only to be so frustrated by a poor manager being hired above you without your input that you might even quit. Wouldn't be good for your equity, either :). PS this implies that if you don't want to grow into mgmt, you'll need to grow into being a good lead developer. Early startups have no room for people unwilling to grow.
- thecupisblue 8y agoInteresting read, thanks for that. Besides human management, how have your tech skills evolved? What directions have you taken/discovered/fell into, what have you learned?