Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I wish I knew when I became CTO

medium.com

Post reply on HN
Print view View original

21–30 of 258 posts

Re: What I wish I knew when I became CTO

#21

Post by edmack »

mkarazin wrote: post #13

> I’ve found it a real struggle to get our team to adopt writing tests. I find this hard to believe. Do others CTOs / team leads find this to be the case? I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests a…

I totally agree that requiring PRs to have tests is a good way to solve this - it's what we've adopted after trying a few approaches

Re: What I wish I knew when I became CTO

#22

Post by reilly3000 »

bpicolo wrote: post #16
benhoyt wrote: post #6

Earlier quoted context omitted.

I'm no fan of MySQL either, but probably because they were already using MySQL and they had some Business questions they wanted answered Intelligently without setting up a bunch of new infrastructure. Sometimes at a startup you just need to get things done, and fix it later when (if) it becomes a pain point.

Definitely the kind of thing you use a dedicated replica for

Really not a replica. That is a fine shim for early days but it means you are severely limited to what you can do with reporting based on the data structure prod has. A better pattern is prodDB->Kafka/kinesis streams to a reporting DB like redshift/snowflake/big query. That way you can shape the data however you need, and it lets data teams avoid bogging down engineering.

Re: What I wish I knew when I became CTO

#23

Post by apocalyptic0n3 »

mkarazin wrote: post #13

> I’ve found it a real struggle to get our team to adopt writing tests. I find this hard to believe. Do others CTOs / team leads find this to be the case? I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests a…

I'm not a CTO but I do lead the dev team at our agency (was previously 16 devs, but we've slimmed down to 7 currently). I want to preface this by saying that at an agency, your biggest enemy is always time; sales teams have to sell projects for the absolute minimum in order to get a contract, so you can't waste time on non-essentials for most projects.

That said, the biggest resistance I have found is "this feature is due in three days, I need two and a half to finish, and then we have another half to review and find bugs." In the end, the biggest issue is that we have time to test on the spot or write tests, but not both. You can scrape by with just manual testing, but I don't think anyone would ever rely on automated tests 100%.

Our larger projects are test-backed, and our largest even reaches 90% coverage, but the only reasons we wrote tests for those was because we knew we would be working on them for 2-3 years and it was worth the time in that case. I wish this wasn't the case, but I've found it's always the argument against automated tests in my corner of the market

Re: What I wish I knew when I became CTO

#24

Post by hippich »

hartator wrote: post #8

> Don’t hire someone to do something you’ve not yet figured out Hum. I would say the reverse. Bring people that are smarter and know more than you.

I think by "figure out" OP did not mean "learned it to bits" and more like "learned enough to be able hire for that task"

I was bit before by hiring specialists when I did not know what task at hands was, what metrics I should expect, what kind of timeline is reasonable, what potential gotchas are.

And for person with CTO title, I think it must have.

Re: What I wish I knew when I became CTO

#25

Post by hippich »

eleusive wrote: post #19
Negitivefrags wrote: post #18

Earlier quoted context omitted.

If you don't know how to do something yourself, you wont even be able to identify someone who is better than you in that field. I've seen people who don't know how to market their product go out and try to hire a marketing guy. You might luck out and get someone perfect for you, but I've never seen it. Usually they just end up wasting a lot of money and learning some hard lessons.

So how do you hire effectively as a CEO? There are too many areas for you to be knowledgeable, yet you need to be able to hire top talent across a variety of areas.

You hire CTO and let him do his job. How you hire CTO? You learn intimately how to hire for such positions, what their day to day jobs are, etc. Only then you can evaluate canidate for CTO position.

Re: What I wish I knew when I became CTO

#26

Post by bpicolo »

reilly3000 wrote: post #22
bpicolo wrote: post #16

Earlier quoted context omitted.

Definitely the kind of thing you use a dedicated replica for

Really not a replica. That is a fine shim for early days but it means you are severely limited to what you can do with reporting based on the data structure prod has. A better pattern is prodDB->Kafka/kinesis streams to a reporting DB like redshift/snowflake/big query. That way you can shape the data however you need, and it lets data teams avoid bogging down engineering.

That’s putting the cart miles ahead of the horse at small-medium organizations. SQL scales a long way. It’s not a shim - it’s the best way to do business until the technology is a limit for you. Modern RDMS can go a long way.

Scale enough to have people dedicated to building and maintaining data lakes is a late stage problem. Who’s going to go build and maintain that reshaping of data?

Re: What I wish I knew when I became CTO

#27

Post by IronWolve »

mkarazin wrote: post #13

> I’ve found it a real struggle to get our team to adopt writing tests. I find this hard to believe. Do others CTOs / team leads find this to be the case? I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests a…

At my old telecom job, we had weekly MOP (method of procedure) meetings, basically the gate process from lab to production.

One of the MOP checkoff boxes, test results.

So many times you could tank someone by asking "Where are the test results" and they would have to reschedule their maintenance window. If you pissed some ops engineer off, expect the question "Where are the test results" every MOP meeting.

Good times.

Re: What I wish I knew when I became CTO

#28

Post by derefr »

redler wrote: post #9
ripberge wrote: post #2

Enjoyed reading this article, all valid points. However, the one thing that stood out to me in this area was how light I was in effective principles of management and leadership. As a CTO of an organization of more than a handful of people you eventually "get things done" largely via other people rather than being hands on yourself. Had to read a lot of Harvard Business Review to gain the skills and confidence for th…

It’s funny how, as you progress through a career and gain responsibility, those HBR articles go from seeming like a bunch of Markov chain corporate-speak to being on-target for that exact problem you had last month with the leadership team.

Are you sure they really have any more meaning, or are you just ascribing them meaning that exists more in your "evaluation context" than in the text itself?

Compare: the way meditation is usually taught. There is something "there" to communicate, but meditation teachers mostly fail to communicate it. To use an old phrase, they are "pointing at the moon"—but, to stretch the analogy a bit, they're doing this pointing indoors, where the sight-picture you get by following the tangent of their finger does not, in fact, contain a visible moon. You have to imagine taking the thing they're doing (pointing), and reframe it in a context where there is a hypothetical moon to see. Whether that helps you find the moon is more about what you know about the sky and fingers and angles, than it is about how well the meditation teacher can point. And this is why the teachers end up failing to communicate: they did not, themselves, figure out how to "reach enlightenment" by absorbing a verbalized lesson, but rather by pondering a gestalt mess of ideas that have little in the way of words associated—so they can't just turn that gestalt mess back into words.

So: are HBR writers pointing at a visible moon, or are their words Markov-chain-speak because they're trying to backwards-chain the gestalt mess of their own mostly wordless understanding into a verbal lesson?

Re: What I wish I knew when I became CTO

#29

Post by sidlls »

staunch wrote: post #10

> ...it’s a blessing that my predilection for hipster technologies has not caused any serious problems. It's entirely possible that this was the primary source of his problems with hiring, firing, testing, and a lot more. The technology you choose determines which technologists you attract. And it's not a superficial thing, it actually says everything about the CTO's own technical skill, judgement, and experience.

I was thinking that most of the problems he notes are the result of that litany of tech. How much of that was really necessary or appropriate?

Re: What I wish I knew when I became CTO

#30

Post by stephensonsco »

majormajor wrote: post #3

> Don’t hire someone to do something you’ve not yet figured out (some exceptional candidates can bring new capabilities to companies, but often the most reliable route is for some “founder magic” to re-assemble the company until it can perform the new thing) I'm curious what this "founder magic" bit means. Is this advice largely because of the difficulty of trying to find a qualified expert to bring new capabilities…

The problem is that a founder who hasn't already filled that role themselves doesn't know two things: 1) what the key parts of doing the job are and 2) which skills/personality the hire must possess.

There are many many ways to fail in a position and only a few key parts that matter. The "founder magic" is taking your unique perspective as a domain expert in your business and finding out what the role really needs. You do it by executing in that role for real. After you do that for a while (weeks/months) then you know what will make a candidate successful (and now you have a 50/50 chance of hiring the right person rather than a 10/90).

Post reply on HN