There is stuff in here I definitely agree with (record every meeting!), but there is also tons in here that I personally disagree with (e.g., on performance management[0]). This isn't necessarily a criticism -- different problem domains likely demand different approaches and leadership styles -- just to say that I wouldn't take any of this guide as sacrosanct: if anyone reading something in here that doesn't comport with your personal experience, I would recommend deferring to your own experience.
> For example, an individual contributor software engineer s competency matrix may include a row for coding/feature output velocity. In a Level 1 to Level 5 system, the matrix would specify that for a Level 1 engineer, expectations on code velocity are X pull requests per week
It really is a ridiculous metric. So ridiculous that you'd think it would never be used in reality... and yet, I have in the past actually had the CTO of a large engineering firm insist upon it.
I was just thinking the other day about one of the issues I have working in this industry. You are expected to solve some hard problems, within a couple of days, usually. If you fail to do this satisfactorily, people will wonder what you're doing; if you're smart enough. And if you can't solve those problems fast enough, the "right" way, you are let go for not "performing."
In reality, you don't run into these kinds of problems often. Usually, the problems we're solving are relatively straightforward. However, if you accidentally pick up too many of these problems in a short span of time ... you can be screwed.
The thing is, for a junior engineer, this is not that bad of an idea. I don't think that it should be part of a formal performance process, but if you're green and aren't putting out enough PRs, it suggests you're either struggling to contribute, or putting out PRs that are far too large and need to be broken up to be easier to review & safer to deploy.
Think of it as a threshold. A high number doesn't suggest you're great. But a low number can often be a symptom of a greater problem.
I assume this suggestion only applies to big orgs where juniors can get a steady stream of small, well-scoped items to tackle.
At a lot of smaller orgs I assume it's harder to do this? Where I've worked, juniors often receive exploratory items that are lower-priority, and off the critical path, but they're expected to have reduced output, as well as asking for guidance as needed from more senior members.
Perhaps this is a failure of planning (which would have been my own failing as a lead at times), as well as management
> steady stream of small, well-scoped items to tackle
Yes. The part of the quote parent left out is
> or the ability to close Y story points per sprint
With that in mind, it makes sense and the metric is dependent on the entire org functioning well. So to the extent it does so, this is an objective, very quantifiable, metric that all junior engineers can be compared with.
That said, this is a guide for startups. So I do believe this metric is garbaj. Junior engineers will be unfairly held to task for org dysfunction.
“If you can't measure it, you can't manage it”,do you have better ideas that also work in daily operations and practical? is there a way at all to measure software engineer or no?
"If you can't measure it, you can't manage it" is absolutely terrible leadership advice. Or to phrase it another way, if you could magically transport yourself to work on any team in history, which would be and why? And how did those teams run? How did the leadership function? How did the team think of its own performance? In this regard, I feel history is a much better guide than middle management claptrap admonishing us to all kneel before the false god of Measure Everything.
So, interesting example: how much do you know about surgery? The best surgeons care about things that are not, in fact measured -- things that amount to the quality of the craft that very much correlate to patient outcomes, but are also hard to measure. Indeed, if you really get a surgeon going, they will complain about the things that are measured -- namely, the number of surgeries that they perform. I know of more than one surgeon who has left their craft because this quantification was essentially forcing them to perform unnecessary procedures!
In general, quantification of human endeavor is fraught with peril -- even in those domains where it would seem to be entirely non-controversial like professional athletics.
The alternative to measuring everything seems obvious. Don’t measure everything.
Why not measure everything? Because measurement has a cost. And some things cost more to measure than you gain from the measurement.
I was on a team once with a product owner who insisted on absolutely everything being in jira with story point estimations. Well, that’s fine and good but one day I sat down with the designer and walked through the product. We made a list of about 30 things that needed fixing - almost all of them trivial. “This is the wrong shade of blue”. “There is too much spacing here”, etc. Well, I made a list in notepad and got going but I got in trouble for not putting it in jira. Only, it would have taken longer to write up these issues than it would have taken to fix them. To say nothing of wasting everyone’s time doing story point estimation. In this case, measuring our work would have cost significantly more than doing the work! We argued back and forth and eventually he admitted he wanted things in jira to appease upper management, who I suppose wanted to know how busy we were by looking at a number on a spreadsheet.
(He ended up writing up all my points in jira himself, guessing costs and ticking them all off as “done”. What a waste of time.)
And no, software isn’t special. Teaching isn’t measured (except maybe with a student survey at the end of the year). Science is measured in citations per lifetime, not micropapers/hr. And you don’t quantitatively measure your spouse, your friends or your enjoyment of mum’s cooking.
Measurement is a lovely tool. But don’t make a religion out of it. I heard a story from a leadership summit recently. A young CEO got up and said “But there’s no way I’d make hiring and firing decisions by gut instinct!”. A bunch of the older people there disagreed immediately, and said that’s exactly what you should do. Train your instincts then trust them to do their job.
> But there’s no way I’d make ... firing decisions by gut instinct
Well the reason it's so important to hone your gut instinct for good hiring decisions is that you absolutely should have measurements for firing decisions (at least in the US); that decision needs be defensible with data under the scrutiny of a lawsuit
You don't need a reason to fire someone in the most of the US (AFAIK). You can just say that they walked in with a red shirt and you don't like red shirts. As long as the reasoning isn't because they are in a protected class, you can pick whatever reason you want.
Firing someone "because they walked in with a red shirt" would do damage to your company's reputation, and call into question the competence of your management team.
I mean. You can get sued for wearing a red shirt. It would probably get tossed out in ten seconds (unless the judge just wants some entertainment). But you can sue anyone for anything. You can do tens of millions of dollars to a company, get fired for it, and sue them. Nothing is stopping you.
Secondly, no one is going to give a shit why you fired someone except the person you fired (if you even told them why), and HR. In fact, most companies don’t even give managers firing authority, but if you are the owner/CEO or someone who does have that authority, it’s possible even HR doesn’t know the reason. That person is just fired.
not interested in measuring everything, neither do I believe 'measuring nothing because I'm a software developer'
Agile has its merits, abuse it is obviously wrong.
There got be something that is practical and get the job done and benefit all parties in software project management, I'm searching for answers myself.
Measuring software engineers productivity has been a meme and the butt of jokes for decades.
However, I think there are things worth measuring that do help manage success and are not intrusive.
For example, giant pull requests or pull requests that go into production with no/minimal review are likely to create problems. We use LinearB to point this sort of thing out automatically.
Code with high cognitive complexity is likely to generate bugs (and be hard to maintain). There are many other similar issues that can be automatically detected. We use SonarCloud for this.
Asking an engineer "How do you feel about work overall", "your personal well being", "career growth", "work relationships", and "impact & productivity" on a scale of horrible to outstanding once a week prior to 1:1 meetings allows each engineer to tell you their story in numbers. If you have built a culture where people trust that you care about them, you will get honest answers. This helps discuss and correct things that bother your team members, and in aggregate shows whether you have a problem with leadership and/or culture that needs to be corrected.
Those are the numbers I gather, and it takes a lot of the gut feel and guesswork out of management.
It's incredibly difficult to measure the work of a software engineer with metrics which are useful AND objective. You can have many metrics which are useful, but not objective. And you can have many metrics which are objective, but not useful (and often detrimental, like "number of merge requests" per week).
Personally, I would never consent to be recorded at every meeting. Further, I would be mortified asking others for their consent. And how could I, as CTO, ask without coercion?
Once in a meeting I brought up an idea. A coworker said we could have a different meeting to discuss it but the decision was going to be no. And then I said that we should not have the meeting since the decision was taken.
Said coworker went to the CTO and reported me for refusing to have meetings.
Then I thought I should record the meetings. But I decided that quitting was a much better idea.
I ended up having 2 weeks being paid for not working, so that was a nice extra.
Agreed. I would probably consent now and then but largely I find it a bit inappropriate to be recorded, especially when it's a collaborative and group think meeting.
In order to get a text-only transcription you need to record it somehow. I can't be sure that a backup audio file isn't stored anywhere, so I believe the same applies. It means that in theory, your conversation with someone else may be shared. I don't consent to that, normally. For presentations, talks etc it's a different matter.
If you store captions produced by a party you trust (e.g., Google Meet), it could be accomplished w/o accessing audio at all. If I get it right, your concern is more about what's in the pipeline than what comes out.
It's a policy for us, and therefore an expectation, not a request. We also make sure that this isn't a surprise: everyone comes in knowing that we do this (and indeed, many new additions to the team have taken advantage of this by listening to past meetings to come up to speed).
Know that this policy would be illegal in many jurisdictions, especially in the one I live in. Setting it up disqualifies you from being a global employer - at least in theory -, and it's also really unethical. Also workers have a right to their voice and can't be recorded by default.
Have a written record of the meetings outcomes, that's what is actually useful.
I emphatically disagree about it being "unethical" -- we view being recorded as a part of job function. I am also curious (and, frankly, skeptical) about the supposed illegality in your jurisdiction; where do you live?
Yes! Anything that required recording as part of job function would be illegal, which I highly doubt is the case -- part of why I'm interested to get to specifics here...
Some specifics are in https://www.anwalt.de/rechtstipps/was-muessen-arbeitgeber-be.... This assumes you make video recordings of the meetings, then we are not only talking about the personal rights to the voice, but also to the picture. But similar rules would apply if you only take voice recordings, to my knowledge, it's just less documented.
Of course you can have jobs where the voice recording is absolutely necessary, then it can be allowed by default. Or similarly, of course an actor will be recorded in sound and picture. But that's not the case when doing a regular office job. Specifically your "it's expected from the employers" is what would absolutely make it illegal.
Doing it without consent would probably be the only illegal issue you'd run into in virtually every jurisdiction on earth. Otherwise, how would movies, TV shows, or the news get filmed in your country?
We are obviously not talking about positions where recordings are normal and obviously necessary. And parent also specifically did mention that consent is required, thus not freely given, and thus not legal.
Hey, spare me the bullshit. You know fully well that we are not on the same page. Recording all meetings at work by default for a regular office job is illegal and you have no chance to win the process if any employee sues in Germany. And that would be a costly loss, by the way. You might actually go to jail.
This is video calls. Maybe we are talking about different things? I was thinking an audio recording of a real life meeting in a real life office. In that case, I’d expect it to be clear meetings were being recorded and well known. If you don’t want to be recorded, register issues you want brought up in the meeting with someone else in the meeting and just don’t speak or don’t go.
In your article (English translation):
> Documentation by recording is only permissible without voluntarily declared consent if the interest in the recording outweighs the interest in the data protection of the recorded persons
This is a high bar in Germany, but certainly attainable in some situations. I suspect it is highly contextual.
Fair enough :) My work reality did not factor that possibility in.
I don't think it would change all that much. It might make it easier to justify the measure, but you would still have high bars to claim. In the end it would still be an unusual recording, which might negatively impact employees privacy and in a work context lead to conflict. As it is completely possible and way more common to just have text documentation, logs and meeting outcomes, I really am quite confident that even just a regular voice recording of meetings in a real office would not stand in court.
Also, "it's part of our process and employees have no say in it" as in parent's comment would be without any doubt not legal. Given the requirements you now saw I think we can agree on that now :)
It settles debates about what was discussed, informs people that did not attend, increases discoverability, and promotes transparency. Especially useful in interactions with customers. It's not for your daily stand-up. To quote the inimitable "Yes, Minister" (https://www.youtube.com/watch?v=85fx0LrSMsE):
It is characteristic of all committee discussions and decisions that every member has a vivid recollection of them and that every member's recollection of them differs violently from every other member's recollection. Consequently we accept the convention that the official decisions are those and only those which have officially recorded in the minutes by the officials, from which it emerges with an elegant inevitability that any decision which has been officially reached will have been officially recorded in the minutes by the officials and any decision which is not recorded in the minutes has not been officially reached even if one or more members believe they can recollect it, so in this particular case if the decision had been officially reached it would have been officially recorded in the minutes by the officials. And it isn't so it wasn't.
In my professional ~20 year experience, throwing evidence in higher powers face that they changed their mind.. is not going to score you any points & give you a win.
Well guys you decided this at the meeting 6 months ago, that's why you aren't getting the feature you just imagined in your dream last week. Guess what, it generally doesn't matter. Stakeholders want what they want, business, customers and requirements evolve. Having "receipts" or thinking that throwing them in peoples face is somehow going to win you arguments is naive.
Having receipts is the difference between "oh I guess I didn't request that 6 months ago. but I want it now, so how much will the change order cost?" and "you're lying and trying to rip me off, you'll be hearing from my lawyers next".
> It settles debates about what was discussed, informs people that did not attend, increases discoverability, and promotes transparency. Especially useful in interactions with customers.
Oh, so we're talking about “recording” as in writing down a record? Not “recording” as in “audio recording” of the meeting. Then I agree with that.
Edit: it looks like bcantrill was actually talking about audio recording [1], and then I'm much more skeptical.
This probably merits a long piece at some point, but recording every meeting has been transformative for us: it's zero time and energy (you just need someone to hit the record button!) and it gives engineers the freedom to not be in a meeting for fear of what will be done in their absence (a surprisingly common motive for attending a meeting!). As for going back through meetings: yes, we definitely do (for a variety of reasons), though the distribution is lumpy (and most meetings are likely never listened to again).
> it gives engineers the freedom to not be in a meeting for fear of what will be done in their absence
Recording the meeting won't prevent what will be done in engineers' absence, will it? Do you mean that engineers have peace of mind that they could listen to the recording and learn about everything discussed in the meeting?
Having a record allows all kinds of automated followup, post analysis, etc. This level of business intelligence and actual understanding is helpful in improving organisation function and individual training long term.
Asynchronous is _a_ great next step beyond that:
Moving discussions and decisions async has been a massive improvement in the organisations I have helped. Goes against dogma and habit (with all the huge obstacles that come with it) but pays off quickly.
Discussions are more factual and evidence based.
Decisions are thought through and transparent.
Collective (and individual) memory of what has been discussed, decided, and why is much better.
Training people to be clear, succinct, transparent also help them not get bogged down in gut feeling, habit, dogma, ego, posturing, pestering, politics, etc.
And of course the immediate bonus of individually flexible scheduling and not killing efficiency by slicing everything to administration/manager-mode-time.
Meeting minutes has been my go-to strategy in the past startups I worked at. We share them on notion, participants can edit / add, while it is also visible to other members to view. Just one notion page with subpage for different meetings.
I believe the idea for the meetings are mostly to plan for something or align the team due to changes in requirements or divergence in execution and as such they should rather discuss limited topic(s). That's why I feel meetings minutes are suffice to reach good consensus
I'll take the bait: no, but I think watching a livestream or a video of someone using the tool you need can be better and quicker than a tutorial, text or video.
Documentation is good, but it only gives you what the author wanted to show you. Recordings give you what they cared about, which questions they've considered and which questions they already see as settled, what problems they need help with, etc.
(But the video format isn't ideal. I'm looking into using Whisper on the meeting archive.)
It makes the information discoverable to people who weren't there that day, to people who will be hired in the future, and to LLMs you may want to train to make all relevant information in the company discoverable.
Having said that, some meetings don't meet these criteria. 1:1 meetings don't for sure, nor do calls centered on conflict resolution.
Just read through your twitter thread, I really appreciate this perspective and I completely agree, a manager's job includes ensuring the right circumstances to foster intrinsic motivation. I think where I might quibble is there are often circumstances where there are genuine skill gaps and, a manager acting as coach, can accelerate someones growth and performance.
Sure -- but why drag the entire organization through a perf process to accommodate those folks? Especially when they are tied to comp, performance review processes are (in my experience) about justifying decisions that have already been made rather than actually earnestly trying to improve an employee's growth: decoupling review from comp and then additionally not having a one-size-fits-all review process allows that coaching and mentoring to go where it's most needed -- and it similarly allows for positive feedback to happen much more quickly, broadly, and earnestly.
I don't think you're comparing apple to apple here.
You are talking about _forward looking_ performance. That is, how to improve performance from here.
Performance reviews in most corporations is _backward looking_, it's about ranking your past performance in the process of allocating compensation and promotions.
You propose a wonderful fw looking process, but at the end of the day, you need some bw performance assessment as well.
Would you mind posting your twitter thread here? I believe one needs an account to read any replies to a tweet, and since the tweet is in the format of a multi-post thread, it's unreadable to me. From some of the comments here, it seems like it would be quite interesting.
I had the privilege of working with the author across two companies, and I can’t tell you how big of a difference it makes when everything he’s written about here gets implemented. The impact is felt across the organization - not just within product or engineering. Like with any system or set of recommendations, eventually you’ll need to make them your own in some way, but I’d definitely recommend utilizing what Zach teaches as much as possible.
It might be just me, but I like having meetings recorded, and not for having ammunition in my hands when the team starts the blame game, the he said she said. I joined a team where some meetings are recorded and I really like being able to re-watch meetings and discussions.
Let's assume there is an important discussion, an alignment where I really stretch my capabilities. I can't pay attention to the topic and take notes/memorize everything at the same time. If I know there is a recording, I can fully dedicate the meeting (where other people are present) to paying attention, asking good questions, challenge their assumptions and so on.
Then, the next day, I can listen to the call, pause, increase speed 2x,3x, take notes for myself, write minutes, write summaries for internal use (casual slack message), notice inconsistencies in our thinking, or run an AI note taker all on my own schedule.
And let's not forget when someone is sick, need to pick up a mother in law from the airport, have a parallel meeting, or joined a week after an important alignment.
If the meeting wasn't that important? No problem, just ignore it. Set up a sane auto delete rule, and that's it.
In practice, I don't think people spend time snooping around where they shouldn't, so that isn't really an issue.
> Then, the next day, I can listen to the call, pause, increase speed 2x,3x, take notes for myself, write minutes, write summaries for internal use (casual slack message), notice inconsistencies in our thinking, or run an AI note taker all on my own schedule.
The necessity of re-watching to identify inconsistencies in a meeting is a problem with the medium. An inconsistency in thinking early in a meeting can invalidate the whole meeting but because a meeting has to move at pace it's much more likely for an inconsistency to slip in. Team meetings also bias the conversation towards whoever is most confident in speaking up, this is especially disadvantageous towards people new to a team or those where the dominant language is not their own.
I'm not against meetings outright as some people much prefer communicating using their voice instead of in writing, and a good team is one that is able to accommodate each member's preferred style of working... but if a team meeting is taking place that is both important and also stretches the capabilities of participants, it should not be a meeting. A meeting should only happen when every participant has decided that it's the best medium for that specific conversation.
A meeting is like sitting in front of a hose: details will be missed.
I moved to google workspace precisely because of the ease in which you can record and retrieve recordings of meetings. (IE; it's embedded into the calendar event).
If a meeting is not important enough to be recorded then it probably wasn't a meeting worth having.
My personal position is that I put more hours into the day than other people, but it's not synchronous. I might be in a more important meeting when there's another important meeting happening; a lot of nuance gets taken out if you just read meeting notes (which people seldom do also) - but even there it's so helpful to record a meeting so that you can properly revise meetings notes quickly.
I really push quite hard for having meetings recorded.
We moved away from Google workspace because we were acquired (miss you, Google!), but I'll add for the benefit of those in the MSO ecosystem that Teams can also caption recordings.
The blame game has no place in a successful company. As CTO, I lead by example by taking responsibility for my own failures and failures of my team. The sooner the real causes are understood, the sooner a problem can be fixed. I highly recommend Extreme Ownership by former Navy Seals Jocko Willink and Leif Babin to understand this idea and now to implement it in your company.
Asynchronous meeting participation is fantastic for all the reasons stated above. It makes the information in the meeting discoverable. Meetings can now be captioned by NLP, which makes the content discoverable to LLMs. We currently train an internal chatbot on our Confluence content and are extending that to train it on the content of recorded meetings.
I'm sure there are various tools out there that can help with that, saving time is crucial nowadays.
Shameless plug as excitingly I'm working on a tool https://designpro.ai which converts input from various sources into insights and tasks. I've used it to generate insights from my call transcripts, so I do know that it does work.
I recently became CTO, and one of the biggest struggles I have is communication with the CEO. (Sorry if covered by the book, just read the index)
On 8 months so far, the CEO:
* Don't want to have any alignment meeting.
* Don't want to plan anything.
* Don't want to drive vision.
* Want to focus only in the killer feature.
* Don't want to build mockups or prototypes to test with users.
* If we do, they have to be beautiful.
* Don't want to work on anything that takes more than a week.
* Rejected to have any effective meeting.
</Frustration>
What I want to say in this message is that I miss exactly the things that are not in the book.
I've seen that before. At least in my context, this happened because the CEO did not see the CTO as anywhere near equal at all. Instead, the CTO was the CEO's "tech guy". And because he was considered the best or most important tech guy, the CTO got his title.
Sorry about that, but it sounds like you should consider the possibility that the CEO sees you as just another employee (with a fancy job title). In that mental state, it would mean a waste for the CEO to include you into his decisions.
Here I take the blame. I ask from day one to work on some kind of vision. She said that we can't talk for days, so better do it fast.
I said yes (instead doing what I wanted that was to invest the time needed to agree on a vision).
Then I continued saying yes again and again, until without realizing it, I put my self in an employee mindset. Waiting for her to decide what I work as she blocked everything.
I need to move back to founder mindset and start setting some boundaries.
I've been in this situation. The CEO did not listen to his "tech" people about product, marketing or business issues. The company ultimately collapsed, leaving him with 2 options 1) go out of business, 2) fire sale acquisition. Well, he got "acquired" for pennies on the dollar. None of the original investors, himself included, got anything.
I had a job offer recently and it's very obvious that the CEO does way too much CTO stuff than they should. It was my biggest red flag (against everyone's recommendations, since the job offer came with a very generous package)
Long ago, when I was young(er), I made the trek to YC's Startup School one year. I was sitting in the audience when someone asked Marc Andreessen how they should go about deciding when to break up with their cofounder.
I still remember Marc's answer exactly: "If there's any doubt, then there's no doubt."
I know it's such a huge decision that I, as a random Internet commenter, won't be able to convince you. Let me try anyway: It's been eight months. Presumably, you've tried everything you're going to try to fix this. What else is left that you haven't tried? What are you logically expecting to have happen here?
And how much more of your life are you planning to invest in a situation like this, when you could easily go elsewhere and be working in a productive situation instead?
I'll relay a quote from my mother -- "If you're feeling bad about this. Don't worry. It will only get worse! Hahahaha! (phone click)"
In all seriousness -- what you're running into is exactly what makes the job challenging. Here are a couple places to start, having been both in your shoes, and the shoes of those on the other end:
1. Executive 1:1s -- who are the other executives you work with outside of the CEO if any? Try to get 1:1s scheduled so you can get some more context about what you're walking into. Get a sense of what their needs are, which will give you a sense of what the broader organization's needs are. Remember, you're being hired to make the CEO's problems go away /without/ their asking you. Being able to integrate into their executive team is one of the best ways to prove you know what you're doing, and all it takes is some consistency, diligence, an open mind, and a desire to earnestly ask helpful questions.
2. Executive alignment meetings -- Is your CEO and executive team meeting regularly? If so, ask to join. If not, take the initiative to plan it -- ideally after you've aligned with the other executives beyond the CEO. Even if the CEO cannot make every (or even most) of their meetings, they'll greatly appreciate the initiative and it will build credibility. I know you mentioned they don't want to have these meetings, so it may be required to work indirectly through other executives first, based on who has the CEO's ear.
3. CEO 1:1 -- if you're the CTO, your CEO likely wants to have some degree of a regular 1 on 1 catchup, if at least to make sure you don't leave. You can figure out a cadence to make this work on said CEO's calendar -- whether it's once a week, biweekly, monthly, etc. The purpose of this meeting is to ensure that you are able to align with the CEO and collect feedback from them about what areas you're doing well on and around what areas you can improve. If you can't get this scheduled, I don't think you're in a place where you're set up to succeed and I'd advise you to leave. If it's hard to get this scheduled, try pushing on the first two approaches first to get the rapport to get here.
Most importantly -- if you can't get any of these scheduled, you should really re-evaluate whether this is the right role and whether you shouldn't move. If you are the CTO and you cannot get some kind of regular time, no matter how infrequent, with the CEO and other executives, you are not really the CTO and you should consider leaving. Just my 2c.
That said, I'd worry about the lack of planning or driving vision. Those are two critical parts of any early stage CEO position. Do you know why they are so focused on the near term? Is it because they're trying to drive an MVP so they can fundraise or sell? Because they don't have a vision? I'd probably dig into that and try to understand why. (Or, as others have suggested, leave.)
Are you up to the point where you outline necessary short-term steps that must be taken, and the CEO says "Yeah ok, here's what we're doing <totally unrelated stuff>"?
Or the cool part where you push for SOC2 accreditation, the CEO says "not yet" but still talks about how you're "working towards SOC2 accreditation" in sales pitches?
I have worked with a few CEOs like this; the last was an old company (25 years) in dire need of a digital transformation to survive. The company had more than 300 employees and was still using Excel and Lotus Notes on-prem server room. I started a move to Office365 and Azure Cloud .NET, but the CEO showed no interest in the technology and gave me a few months to complete the transition. He came up with some unrealistic ideas for accomplishing the move when timescales were not met.
After a year, I left the company after delivering a few things. Recently, I visited their website and found only a single home page with several PDF documents embedded within it and no sign of any client-facing solution. Assume they are back in Excel again.
There are plenty of CEOs / Founders out there that would love to find a great CTO / CIO so don't give up looking :)
My advice is to start looking for a new job or go freelance. I started doing fractional CTO work - which is interesting but challenging to find new clients.
I see two possible situations here; but, IMO, both situations imply that you should probably walk away.
In general: Most people can't start a tech business. Starting a tech business is like being a professional athlete: Most people can't be a professional athlete either!
Situation one:
Early stage businesses need to try a lot of different things against potential customers, and see what sticks. (Look up product-market-fit.) If you aren't at the product-market-fit stage, it doesn't make sense to work on anything that takes longer than a week. (Or a month.)
This is because, if you build something that takes longer than a week (or month,) you're probably building the wrong product.
IE, if this is the situation you're in, you might be better suited to working for a company (startup) that generally has product-market-fit, because you like to build a known thing. There is nothing wrong with this, because this describes the vast majority of technical work.
Situation two:
The CEO probably is a lousy CEO. There is nothing wrong with this, because most people can't be a CEO of a successful startup. It's up to you and your other founder (and investors) to recognize this and figure out what to do. (Replace the CEO, walk away...?)
This is also hard to recognize: I spent over a year of my life working unpaid with someone who initially appeared to be a good CEO. At the end, I realized this person was better off building a sales organization instead of being the CEO. (The big issue was the person I was working with would constantly let their imagination run away, which made it very difficult to plan anything.)
I also more recently spent time with two founders investigating if I should be their CTO. Again, great people and appeared very promising; but, in one of our last conversations, one of them made some off-the-cuff remarks that made me realize they didn't know how to start a "tech" business. Although I wish them the best, I don't think they're going to meet their market window because they're just working on the wrong thing for their talents. (IE, they didn't want to invest enough time in me to build appropriate trust among us; and they didn't know how to hire the right people to build the product they needed.)
Founder issues are the #1 reason for companies to fail. And mismatched founders are very common. Especially with inexperienced founders. And with startup accelerators being biased to young and inexperienced founders, you can blindly assume this to be the case for most startups in such programs.
From reading your comment, my conclusion is that you are not a CTO but a lead engineer employed by your two co-founders. This company is probably going to fail and it isn't your fault necessarily. Or very fixable. If your CEO can't delegate things he's not good at that you are supposed to do, that means either you are the wrong person for the job or they are. It's that simple. Figure out which it is. And have that conversation with them ASAP and not in two years. It will save both of you lots of time and money.
I see this a lot in the startup world: non technical founders involving a CTO because they believe they need a tech person to take care of the pesky tech thingies they don't understand. Tragically, a lot of companies end up picking the wrong person for this job because they simply lack the capability/judgment of picking the right person. And a lot of would be CTOs end up wasting a lot of time dealing with a rudderless co-founders and companies that they are not actually empowered to fix.
Such companies founding with a CTO is a ticket for disaster. Either you are a tech startup in which case the CTO should be the main founder of the company and the largest shareholder that has the final say in what the product is and does. The CTO should be seeking out a good CEO/CRO to manage the business side. Not the other way around. Classic example here is Google with effectively two founder CTOs eventually getting Eric Schmidt to lead the business. Worked out great. Mark Zuckerberg maybe should have done the same thing with Facebook.
Alternatively, you are some kind of non technical company where tech just is a means to an end (we need a website, an app, and a thingy and some hand wavy slide compatible aspirational buzzwords). That's completely valid of course. Such companies need technical and operational leadership and managers but these aren't founders necessarily. Amazon is the classic example here. Jeff Bezos was the business guy building a market place. Involved lots of tech of course. But in the end it was a simple (ugly) website and logistics operation. AWS bootstrapped much later out of that. The right person to get would be somebody that can execute and lead. Somebody like Werner Vogels who wasn't a co-founder of Amazon. And the reality is that you end up replacing some of these people over time as well. Early engineering teams with 2 or 3 people are very different from later stage companies.
I actually get the question if I know a decent CTO a lot from would be founders. My standard answer is: you don't need one and you should avoid getting one. I always recommend other founders to look for a good VP of engineering instead but not immmediately and maybe start with just a few good engineers and a project/product manager. Maybe one of the existing people can step up in an interim role. Don't slap the CTO title on anyone unless you really need one. And if you do, make sure the equity is appropriate and plan for that person to leave or disappear at some point. The person that does your app and website initially is unlikely to be your long term dream CTO.
> Wikipedia describes DevOps as a set of practices that combines software development and IT operations…
> I translate that as follows: DevOps is all the work that goes into making sure the business software runs in places other than your developers machines. Unless you've got a DevOps specialist on your team, you're probably deprioritizing DevOps to some degree…
That seems like a weird interpretation of the original definition. Especially the “devops specialist” part.
Good feedback! I was trying to get at the idea that DevOps is broad, its often invisible and its therefore often undervalued/underprioritized. I'll have another go trying to convey that.
Thanks for putting this together! I read the rest of this section and it seems solid, the into however does read like you’re suggesting to compartmentalize “devops tasks” which I think is antithetical to the original idea
the problem with the "original idea" is nobody can decide what it actually means.
The interpretation that I see banded about comes from the 10+ deploys a day talk from flickr, where they said having a team of diverse backgrounds was better than having an individual.
Somehow in that zeitgeist sysadmins got rebranded devops, so in that case it makes sense to have a "devops engineer".
We know for sure it never meant “rebrand your sysadmins as devops/platform team and be done” that’s just how middle management tend to interpret things. They did the same with agile = scrum
It’s the same as agile and communism. They’ll claim till the end of time that no one has implemented the truest version of it which would solve all of everyone’s problems with magic
I don't know any of the companies or people mentioned in this. Does anyone else here? Before I sink any time into reading this: I have an innate suspicion of "chief technology officers" to begin with; is this worth reading?
I don't see anything in it that will be new to anyone with industry experience who has made it to the level of entry level engineering management.
The target audience seems to be "CTO"s who inherit the title by being technical co-founders at startups with little to no professional experience beforehand.
My first reaction was to ask: who is the author?I wish it was someone with good CTO credentials under their, but it doesn't tell me anything.
I've been cto at 3 companies over the last 10 years, and maybe I'm getting old and impatient, but I think as others say, this feels more of a book for the just-graduated CTO that finds himself in the role as a cofounder (I do technical advising to those) . In my experience the more you've been in the role, the more specific info you look for, like the Accelerate book.
Boring technology is so crucial. As a private sector startup company you are already living a fraught existence - why risk it even more with unproven tech?
As an example, mongodb inexplicably became a de facto DB for a bit between 2013 and 2016. It seemed like 1/3 of startup companies switched from MySQL or Postgres to Mongodb. What an absolute unmitigated shitshow clusterfuck moronic disaster
Literally every client I've had in the past months uses MongoDB, even though their data is relational.
I can't imagine why would someone choose mongo in that case except to be slightly faster in the first few days of development, since you don't have to create a schema and update it. The problem is that you pay back that initial advantage with a lot of interests once your data becomes more complex and you need stuff like BI.
Anyway, even if your data isn't relational, JSON in postgres still works better than mongo.
Just want to put it here: relational data is not a matter of someone's view, there's theory and science behind it. In fact, there's more than 40 years of theory:
The problem is that nowadays universities are not teaching relational algebra as part of the software Engineering courses. And thus students dont grasp the reasons why relational databases are how they are.
Exactly and the reason I asked is usually when you hear this perspective it's a misconception of what the relational model is -- eg the link you shared describes an internal relationship within the table that is described first and foremost -- this is distinct from what the poster above and many others believe it is when they talk in terms of jargon of related tables "like users, post, and comments" and assume that's what the relational data model is.
"My data is relational" is generally a misunderstanding of the terms
Data with multiple entities that have a relationship between each other. Take a website that has users, posts and comments, for example. Users have many posts and many comments, posts have many comments and one user.
Got it: I consider different objects or entities stored, indexed, and queried separately but with references to each other in the form of identifiers to really just be sound design. Relational data models typically come with more constraints that inhibit classes or online data mutations and scalability choices. I think it's easy to conflate multiple sets of tradeoffs.
The deepest question is whether it's useful to be able to model the world with first class structure in the form of embedded arrays and embedded sub structures that can be richly indexed. Does this involve certain forms of denormalization? Sure but do tables really represent how you think about the world?
> Sure but do tables really represent how you think about the world?
It's not about "how you think about the world", but how you intend to use this data.
Following my previous example, if you're building a blog you know you'll need to show a post along with its author, or that you'll need to filter posts by author, or maybe show only comments by verified users, etc.
Of course you can also structure your data this way on mongo, since over time they've added tools to support it, but it still feels like a feature tacked onto it rather than something "native" as it is with SQL.
Now, I understand what you're saying about my concept of relational being just a form of design and not inherent to the data itself. That's interesting indeed and I haven't thought about it this way before.
Think about an author for a moment: do you want to model all authors with the same set of columns? Might there be a different set of attributes for a current events journalist and a short story writer? Would you not want to describe certain author attributes in terms of lists of attributes and enable filtering/querying on these easily? This is what a flexible/heterogeneous model with first class support for embedded documents and arrays gives you.
I always struggle to think of you would ever want NoSQL to represent data. The benefit of NoSQL is... lack of schemas? Why would you want this except with unstructured user-generated content (which then will need to be structured later to be useful)?
I think there are may be some misconceptions here. There's always a schema. It's about flexibility and heterogeneity of the schema shape and evolution over time
Yes I can change a RDBMS schema over time quite easily. I'm being honest - why is a NoSQL DB better for general purposes? I am a longtime CTO and I have yet to figure this out.
In an RDBMS a schema change is both an application tier change and database tier data definition change and depending on what you want to optimize for that can be a material difference in terms of agility. Anything can be described as "quite easily" but in a fundamental sense if a change requires you to reason and initiate at two layers and that change often requires downtime, you have a major impediment on your hands. You might also call slowing down a feature. I think it's a bit like fiat vs Crypto, there's a religious ferver aspect that drives some people to declare a position on this and a set of tradeoffs aspect.
Yep. Chasing shiny new tech can cause a company to focus on learning the tech with all its early stage issues rather than focus on solving the problems the business faces.
Some new tech fades away. Some is here to stay.
SQL was the shiny thing near the start of my career. I pushed my company hard to abandon network databases in favor of SQL and that worked out quite well.
Same with object-oriented programming over classic C.
Some tech never lives up to its promise and becomes an albatross for its adopters.
There was a time when it was too early to responsibly incorporate LLM technology. There will soon be a time when the board will ask why you didn't. (Maybe for external use cases, certainly for internal ones).
One challenge for CTOs is making the call on new tech. When is boring tech the best thing for the company, when is it acceptable to introduce early stage tech, and when is new tech such an accelerator that you must adopt it?
NoSQL in general is a niche tech. Data is inherently relational. It is very hard for me to imagine a situation where basing everything on Dynamo or Mongo is the correct move, vs. only using NoSQL in specific problems that make sense. Dynamo and mongo generally smell of developers enamoured with specific tools over solving problems efficiently.
I find the breakdown into 3 types of CTOs (tech, people and external oriented) very interesting. A very early stage startup (no product yet, just some basic demos, doing pre seed funding) is courting me for a CTO role. What should I expect is most needed for this role? A tech CTO? A people CTO? I expect that it should mostly be a tech role for the beginning, because we would have to develop the product. But I wonder how soon would the transition be toward a people CTO? Does anyone have any insight/experience with this?
the question might be the other way around. #1 What You want to be? (now, but do reevaluate later ~1year into it) The tech guy? The people guy? The <other aspect123> guy? Be mostly that one, keep other stuff more-or-less afloat, and when/if that work gets too much/critical, hire other people for other 2++ aspects.
But there is another question which is harder to answer: #2 What do they/others CXO want you to be? Because this can be/become obstacle to #1. And, in some cases, it's CTO without the C. Just some tech guy who is told what needs be done, runs bragging-shows and is never told the "why's" about business.
Here few links i've bookmarked on the topic "WTF is a CTO"..
Agreed. Sometimes the project is small enough and the debt large enough that a rewrite is in order. However, a project of any size and complexity only reaches tech bankruptcy when the advice given in the book isn't followed; when tech debt is ignored for the benefit of shipping features, which become increasinly hard to release and increasingly prone to bugs.
The analogy only goes so far and it's not clear to me what you mean, what do you mean "default on tech debt"? Re-write? Give up and just accept the penalty when changing systems?
I have never, ever in my career ever seen one "thrown away". Unless the project or startup itself dies, of course.
Once something is built, and in production in the hands of end users, it is something that needs to be maintained and built on and fixed over time. It's never thrown away.
Now if you are lucky, it has been well-written and designed so that parts can be refactored over time as new features are needed and old ones deprecated. If it's shoddily built and rushed because you couldn't afford or couldn't be bothered to do it right the first time, then that's going to be tech debt you are going to have to deal with for years to come.
I've only ever been involved in something close to that "tech debt default" in my career. All other cases of throwing something out were either planned to begin with (so intentionally a throwaway prototype, not tech debt), or just giving up on the product (tech debt included, but who cares at that point).
(the case I was in was the game Commandos. We completely threw away all source code for the sequel, which we wrote from scratch with different architecture, tech and even somewhat different coding standards. Getting rid of the tech debt that Commandos accumulated over the yearlong deathmarch was nice, but without the completely different architecture needs I doubt it would have happened)
Yep, this is the majority of my experience, and clawing a way back from that sustainably has been a fairly large part of my consulting/contracting career over the years.
I'm writing Opinionated Launch (https://opinionatedlaunch.com) to share practical ideas based on my experience as CTO for a small startup and VPoE in a publicly listed company. When I started writing, I realized there are two distinct topics: management/team/people side of things, and tech side. I ended up focusing on the tech side since that's what I'm more passionate about. I'm glad someone did the other part!
So little about tech, and what that's there is mostly how to annoy your devs with trivial corp-like control nonsense.
Too many people in startups try to "play house", pretending to be big shot managers/company rather than develop the product and actually moving the needle (i.e hiring an HR manager as employee #3-5).
How about you do the work, keep to a pizza size team in a garage until you actually can't?
My advice: Understand all the tools. Apply the ones called for in any given situation.
I agree that you want to keep your pizza-sized team focused on fast iterations and on shipping ideas to see what works.
There's a huge transition in management skills when that team succeeds. I've seen many companies flounder and fail when they don't recognize how things have changed.
My current startup is larger (a little over 100 people) and almost at break even. We just acquired one of those pizza sized companies. It's been a fun challenge keeping their velocity high and enabling them to focus on shipping stuff while integrating them into our more structured ecosystem.
Use the right tool for the right job at the right time.
Agreed, if the company is small keep the process light and focus on good people and a good product. This includes a good DevOps “product” side of things.
Personally I do like having a documenting culture so things can easily by found.
In the current startup it’s often said: code is the documentation. But to me that’s just lazy. Especially if the code doesn’t have a minimal set of inline docs.
There's a lot of good management advice to be had that applies to tech startups in which software is a very small part of the technical product or infrastructure.
Such a book can't be written by one person alone, but this could be the kernel of such a book. I've worked in the last 30 years exclusively in tech startups (or as they are called these days, "deep tech", bletch) and there are important model commonalities across software, cloud, networking, pharma, mechanical, consumer electronics, and chemistry as much as there are of course significant differences. The key is the word "startup" which implies "fast moving / high growth" compared to "normal" companies in those sectors, even when it takes five years to get to product.
Such a book can't be written by one person alone, but this could be the kernel of such a book
Completely agree, and that's my dream for the book.
Should be named "Software Startup CTO's Handbook"
I struggled a lot with the title -- good point that it lacks the specific software reference, that should be perhaps be incorporated somehow. "Startup" as well as also important to me, as I agree, size matters and changes how you evaluate trade-offs. Implicit in the word "startup" is that time is your most valuable resource, and much of the advice in the book is based on that assumption.
These days the language has become so debased that any new business or small business is called a “startup” (and of course they have to be “tech” startups even if they just sell organic oats online — real example).
I’d set the ground rules up front so people who don’t want a high-growth business (and I see complains about that on this site which is fine) can stop reading. Likewise if your business doesn’t need the CTO function (even if they are still a four-person startup) then you can stop reading.
If your dream for your book is to be about tech startups (in the actual meaning of the two words) I’d partner up with someone else from a different domain relatively soon, then expand the scope again after you’ve got edition 1 done. And call it the “Tech Startup CTO’s Handbook”. What about the folks making semiconductors?
Appreciate the feedback. I think you've nailed something with the phrase "Tech Startup", feels more precise and universally understood/aligned with what the book is about.
"Section 3.4 Testing" is missing an explanation of why testing is necessary. Some startup CTOs make critical errors like un-staffing testing or migrating to Service-Oriented Architecture without integration tests. We need the handbook to instruct such people on why testing is a necessary part of the software process.
[0] https://twitter.com/bcantrill/status/1216491216356823040