[0] https://twitter.com/bcantrill/status/1216491216356823040

I mean. No.

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.

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.

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

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.

Software projects are notoriously hard to manage indeed, but it has to be managed somehow, Agile approach is a nice try, we had CMMI as well.

Even a neurosurgeon can be measured, why can't software developers, why are software engineers so special? Maybe AI programmer is the way out.

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.

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.

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

And you can still get sued.

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.

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.

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.

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.

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.

Edit: I actually found a source for this specific question, https://www.anwalt.de/rechtstipps/verboten-video-konferenzen....

See https://www.anwalt.de/rechtstipps/verboten-video-konferenzen....

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.

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.

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.

Hmm I’m probably due for a re-read…

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.

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

Having access to past meetings is super useful for onboarding. You can get a picture of what everyone is working on super quickly.

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.)

Recording generally means transcription and the ability to do automatic summarisation and to query action items, which _are_ useful

Also it means folks can be away or if someone didn't quite catch/understand something relevant to them they might want to rewatch some of the meeting.

Having said that, some meetings don't meet these criteria. 1:1 meetings don't for sure, nor do calls centered on conflict resolution.

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.

Every written text is a state of mind of the author in a point of time. Should never been taken as the only to do things.

People learn and grow, so does their advice and context.

Read to learn perspectives and ideas, not to just follow.

EDIT: found it. https://threadreaderapp.com/thread/1216491216356823040.html

> I wouldn't take any of this guide as sacrosanct

That goes without saying, doesn't it? None of this thought leader stuff should be taken literally. The book is literally an advertisement:

>> I'm also happy to discuss advising, coaching, and mentorship opportunities at the same address.

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.

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.

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.

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.

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.

What I want to say in this message is that I miss exactly the things that are not in the book.

Edit: we are just 3 cofounders!

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?

Thanks for your comment.

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.

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.

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.

I wrote about the difference here: https://www.mooreds.com/wordpress/archives/2555

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.)

Which means, you should be informing your boss (CEO) what the product vision is and executing on it. Not seeking their approval to do so.

Unsolicited advice: you probably don’t want to be calling out your CEO when people know who you are (HN profile).

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 "?

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?

Don't worry, its not you that's schizophrenic.

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.

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.)

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.

> 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.

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".

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.

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.

The founder wants me to both build the product and eventually grow the technical team.

Sometimes it’s cheaper overall to default on certain tech debt rather than pay it down. As long as the product managers don’t try to collect.

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.

(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)

Result: you're now stuck with a ton of tech debt and a flimsy product.

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!

Done

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.

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?

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

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?

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.

https://opentextbc.ca/dbdesign01/chapter/chapter-7-the-relat...

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.

"My data is relational" is generally a misunderstanding of the terms

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?

(3 time CTO)

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?

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.

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.