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.
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.
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.
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.
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?
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 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.
Gruntwork is hiring a senior Golang engineer to focus specifically on Open Source projects, primarily OpenTofu but also Terragrunt and other tools.
Work collaboratively with the open source community to design and implement innovative new features at the frontier of devops tooling.
Help maintain and improve the quality of our codebase, infrastructure, and documentation.
Review and provide feedback on pull requests from the community and team members.
https://jobs.ashbyhq.com/Gruntwork/a6b852e6-2ab6-4eaf-b643-3...