We should build an automatic process, a culture of clear and verbose reporting. So that when guys let us know in advance when they work today, what they’re going to do and when they expect to ship certain things (like “today in the evening” or “tomorrow morning”). Given that many of our features require support from several sides, this reporting becomes necessary to ship everything rapidly.

Some of my friends ask me why we don’t ask our programmers to give estimates for tasks that we put in a weekly plan - and doing the estimates for them on our own. Now it feels hard to plan the next week: you need programmers to be available during the planning phase, you need to explain the feature and carefully think about it. It feels like a waste of an entire day, yet in three-four days everything will change due to new requests and emerging bugs. And our planning day is usually Sunday.

As <> pushes hard, we try to establish a release train on the client app: test the build on Monday, roll out on Tuesday morning. The goal is to demonstrate the certain pace for users and for the team, to show the pulse of an ongoing work.

Today <CTO> came in person to Drinkit after his vacation. We had some discussions on security and premature optimizations, but the most significant was that he talked about his ongoing arguments with <> and <>. Then I’ve overheard bits of their hour-long discussion about possible leave, money/equity and such. It looks like there’s not so much help from <CTO> in the changed setup with many full-stack guys, and it’s hard for him to transformate his workstyle to actually be a CTO of Asap. Anyway, I’ve no idea what’s the outcome of their discussion, we’ll see.

<CTO> told me today that he’s going to continue the support of our project, but he can’t confirm the amount of time and whether he’s gonna develop something new. Well, on the one hand, that’s exactly the goal I wanted to achieve in early July when I just joined - to take the place of the CTO. On the other hand, I don’t feel like I explicitly tried to kick <CTO>.

... since May <CTO> was worked specifically for the equity and not for the salary. ... not sure whether the previous salary was completely paid to <CTO> or still presents a debt. Maybe I’ve overheard yesterday that there’s a debt of 400k in salary that company’s gonna return on the next round of investment.

The main conflict during the last several months was that <CTO> was mainly fixing bugs and not helping much with the team expansion and team leading. So <> and <> wasn’t eager to give him out a lot of equity. And <CTO> didn’t want to work for salary. The problem here is that <> and <> were doing these discussions harshly, pushing <CTO> to stress. That’s an issue that we as four remaining founders should fix, or otherwise it may blow up our team work in the future. Also, we should establish founder communications. Right now it’s a star topology: <>&<> are talking to me, <> and <CTO> separately. We feel like there are two level of founders, which isn’t that great.

I’m not sure what my fair equity portion is gonna be when <CTO> quits. I feel like I committed to 800k shares being a second development guy and not a “single point of failure”. Of course, my team strategy is to share as many processes as I can. But in case of fire - for instance, if we run out of money - that’s gonna be me who remains to support IT processes. Can I do that feeling fair for 10% equity?

The last five days were my first vacations while I’m at Asap. It was perfect timing, because right before I left almost all the development processes became independent of me: weekly planning and QA was done by <> and <>, and developers were able to develop back-end, peer review, merge and deploy. At the same time I was enjoying friends, another city and lowering my fomo-yolo lower again.

Today, as I came back, it felt almost like the first day: I should find where I can plug my time and knowledge to make something meaningful that wouldn’t occur otherwise.

Today I started the onboarding of <> who’s currently seeking for new employment. He already got offers from <> and <> and he said that his baseline cost of living is 100k rubles, which we didn’t sponsor to anyone yet. That again will yield strange negotiations on Friday night when this trial period will end. Today he installed XCode and started getting synchronization bugs - so I’d say we spent the entire day on “front-end devops” - setting up the proper dev environment for mobile development.

Yet I believe our pair programming and real tasks strategy looks very competitive. Yesterday <> and I were making fun of a typical onboarding in a large company like Google where you get your laptop, your task and a codebase. Then, as you barely understand what happens where, you start looking around desperately until you find that the sufficient time passed for you to ask a manager what’s the next step of figuring things out.

<> moved to Moscow today and had his first day at <>. He’s going to work with us for ¾ of full-time - on weekday evenings and weekends. He said that his onboarding at his main employer is worse: in the best case scenario he’ll get the necessary access next week, so he spent the entire 8-hour workday today by browsing Habrahabr.

Yesterday I summed up our expenses from an investment report since we raised a round. Then I divided that by our burn rate and I got a runway of 4 months only. Though <> later explained to me where my calculations are wrong and why we have a runway of 8 months, the very feeling of a short runway is a very important and sober look to what we’re making. What will happen if one day we can’t pay salaries anymore?

I’m trying to summarize and share what I was doing right for the last four months as a team lead. I name the following points:
— Start hiring
— Iterate over google docs, Trello boards and the Excel person/day task grid
— Make everyone record gifs with the new functionality
— Make everyone ship builds
— Make everyone write backend, peer review, merge and deploy
— Make everyone talk directly to product managers, get micromanagement of "what's my next task" from them and have a tight QA feedback loop
— Offload a managing role to a team of product managers while retaining 1:1 calls
— Don’t block architectural and framework decisions if they lead to faster shipping of prototypes

Today <CTO> had another conversation with <> and <> and told me afterwards that he’s going to become an advisor and stop putting any effort into the development. This de facto means that I’m leading a dev team consisting so far of me and six other guys hired within four months.

<CTO> also told me that he’s going to keep silent in order to settle our project for success and make us all rich. I don’t know what that means.

I continue fixing various XCode build errors. I feel like that’s the worst thing to delegate because it requires more skill and effort. I will delegate it as much as possible, but juniors sometimes just give up and don’t know what to do next. In the future, I will sit next to them on such occasions and pair build what doesn’t build. Today I did it on my own for speed, which is not scalable.

I’m trying to understand my role in the team. It feels like I’m a team lead, but I’m still gaining skills in all the technologies that we use. For every situation that devs struggle with I can offer my time to dig into, try various debugging means, google together and play around, but at times I don’t have a certain answer for “what architectural pattern should we use here?”. I think it’s normal.

Secondly, as <> was digging into the current PHP back-end to change the logic of order/create endpoint, he confirmed that the code is completely opaque, repetitive and unmaintainable. I personally feel like the development of PHP and Laravel is 10x slower that it can be for our team given the right stack and code quality. We had a discussion regarding how to rewrite it to speed up the development. Our strategy is as follows:
— We rewrite one endpoint at a time - only those which currently require changes due to a product request.
— We write it in Node.js and deploy it on Firebase. Pros: same coding standards and IDE settings as for React Native front-end, lower barrier for our front-end team, easy start, built-in monitoring and scalability, feeling of a developing industry. Cons: not so mature and structured as Django.
— Firstly we stay on the same MySQL database structure and write back into it, as there’s a lot of source depending on it. Then, as the back-end is rewritten, we may migrate the database by merging tables or transferring some parts to NoSQL Firestore.

Yesterday <> called me and asked how my tasks in Asap are being delegated. She felt like whatever she does in marketing gets a ton of comments, warnings and arguments from <> and <>. She’s mostly fruitful when given KPIs and free choice of methods. Here at Asap she feels like a micromanaged copywriter. Still, she already does a lot of new and fresh stuff in our marketing channels, especially Instagram, that I appreciate a lot.

<> said that he sees no obstacles to set up the bylaws regarding the share distribution. I got a new concern regarding that - subject to googling yet. Suppose he writes it so that we distribute 8’000’000 shares and I get 800’000 - kinda 10% less investors’ shares. Suppose that <> and <> want to dilute my (or <>'s, or <CTO>’s) share five times. Why can’t they emit 40’000’000 more shares and equally redistribute among themselves? As I obviously won’t have any significant voting power at the board, and neither the investor has, I cannot block this move. Maybe the tax consequences are the blocker, as this emission will already be happening with a non-zero FMV - I suspect it will be at least $2M - our May 2017 valuation. So the tax burden for <> and <> will be around $3M.

We’re drinking after work for the second day in a row. On Tuesday we got the next tranche of money - partially in cash rubles, so that we can instantly pay the salaries to our employees. And yesterday <>'s two weeks trip to Moscow came to an end. We were celebrating it at Steak it easy which is launched in a test mode. As I was testing our waiter's app with tables yesterday, it sucked a lot when you type an order for six guys: it took us around 10 minutes to type the entire order on the waiter's side. A lot to be done yet.

Yesterday <A> and I were thinking again what to do with <B>. He has the weakest performance in our team, he requires a lot of micromanagement. Being uncontrolled he avoids solving problems by blaming the infrastructure around, he always doesn’t like the architecture of the solution and spends a lot of effort polishing it without any reasonable progress. The question is, can we as a startup afford having those guys on board? It feels like 3 more months are required to teach him to be productive.

My thoughts were: we can’t fire him right now as it won’t teach us anything. We should try to fix these guys and grow this internal managerial competence. We should learn from this case, or it will repeat in the future. <B> requires a micromanager that will control his technical decisions and how he spends each hour of coding. We decided to give <C> a try on that, and he agreed that he wanted to try.

On Tuesday we told him that we can’t pay ¾ * 70k rubles anymore (30h rate), as we expect a junior to grow past six months. December is gonna be his second test period during which he’ll only have 30k rubles as an Asap balance and no salary. We also accidentally assigned to him a very complex and global task. It requires changing a lot of moving parts, so it’s interesting to see how he’s gonna own it.

привет!

спасибо огромное за фидбек

по сути мои зарплатные запросы сводились к "мне не надо денег, но дайте мне много денег, которые я потрачу на зарплаты разработчикам, которых сейчас найму". тогда сразу управлять командой мне было важнее, чем получать много денег. альтернативу такого вида на рынке я не искал тк на моём CV тогда вообще не было менеджерских позиций, эта была первая, и в этом был смысл

startupneversleeps я тоже исходно задумывал как hiring funnel

есличе, я считаю, что в этом сезоне всё про менеджмент ужасно со всех сторон. в частности, увольнять нужно наоборот: hire slow, fire fast

разработка отстаёт от вижна - это определение понятия "на проекте есть живой продакт-менеджер". другое состояние "разработчики от нечего делать переписывают код" гораздо хуже

в целом там с самого начала была задача "заменить СТО на меня". она мне не нравилась по той причине, что я-то не хотел быть СТО, я хотел быть продакт-менеджером)) это конфликт, который вылезет у меня и в будущем, если я вернусь в айти: мне интересно быть только продактом, но легко наняться я могу только разрабом

конечно, django не должен в современном мире отдавать html сам. надо понимать что этот кусок джанги написан для веба образца 2006 года. django 2022 == ORM + django-rest-framework + django-admin + jupyter models access

подписчики пришли с рекламы в @thingsread. при этом сам сезон никто вообще не читал (там количество репостов на нуле)

по менеджменту я тогда читал интернет, как раз все первые 100 постов в thingsiread это ровно то, что я читал тогда когда писал этот дневничок. также я пытался читать какие-то книги, но мне не запомнилось примерно ничего. были разумные мысли в The Hard Thing About Hard Things

писал на англ тк мы делали US-based стартап и я мечтал что я эмигрирую на нём, построю большую успешную US-историю и потом сделаю блог такой же классный как книги про Basecamp, Zendesk и SalesForce

навигация по каналу

нормальные твиты начинаются с https://news.1rj.ru/str/ursofuckinghot/188

потом нормальные твиты продолжаются с https://news.1rj.ru/str/ursofuckinghot/857

история одного стартапа начинается с https://news.1rj.ru/str/ursofuckinghot/763

война начинается с https://news.1rj.ru/str/ursofuckinghot/890