Month: April 2023

Article originally posted on InfoQ. Visit InfoQ

AWS announced their entry into the generative AI race with the launch of Amazon Bedrock and Titan foundation models. Amazon aims to democratize access to generative AI technology, catering to customers across various industries and use cases. This groundbreaking development positions Amazon as a formidable competitor in the rapidly growing AI market.

Amazon Bedrock is a new service that makes foundation models from AI21 Labs, Anthropic, Stability AI, and Amazon accessible via an API. Bedrock will also offer the ability to access a range of models for text and images including Amazon’s Titan models. Customers can also privately customize models with their own data, and easily integrate and deploy them into their applications using the AWS tools and capabilities.

Amazon Bedrock allows users to identify the most suitable model for their specific needs. Moreover, the serverless nature of Bedrock offers a hassle-free experience, enabling quick and easy customization of FMs using private data. The integration and deployment of these models into applications can be achieved seamlessly using familiar AWS tools and capabilities, including Amazon SageMaker ML features like Experiments for testing different models and Pipelines for efficient management of FMs at scale. Additionally, users do not have to manage any infrastructure.

The Amazon Titan models, which are a component of the Amazon Bedrock offering, will also be made available to external clients, giving them the resources they need to create generative AI solutions and apps, in addition to being used to power Amazon’s internal use cases.

Amazon Titan FMs are pre-trained on vast datasets, making them highly potent and suitable for various purposes. They can be utilized as they are or customized with private data for specific tasks without the need for annotating significant volumes of data.

We think every application out there can be reimagined with generative AI, said Vasi Philomin, VP of generative AI at AWS, to TechCrunch.

The Bedrock initiative was introduced in the wake of OpenAI’s revelation of GPT-4, a robust language model that powers ChatGPT. Microsoft, which has made significant investments in OpenAI and provides the startup with computing power via Azure cloud, is a major player in the field.

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

Database vendor MariaDB has cut a number of jobs and reiterated a “going concern” warning over its medium-term financial viability.

In a statement to the stock market [PDF] late last month, the company, which floated on the New York Stock Exchange at the end of 2022, said it was reducing its headcount by 26 “to achieve cost reduction goals and to focus the Company on key initiatives and priorities.”

In December, CEO Michael Howard told The Register the company was looking to hire more people following $104 million in funding and $18 million through private investment in public equity through the special purpose acquisition company that enabled the flotation.

Although the job losses may be a fraction of the reported 340 people the company employs, other details in the filing may highlight further cause for concern over its financial viability.

It includes a mention of MariaDB’s February 10Q warning that the company’s current cash and cash equivalents “would not be sufficient to fund our operations, including capital expenditure requirements for at least 12 months from… February 13, 2023, raising substantial doubt about our ability to continue as a going concern.”

The March 24 statement said it anticipated that the money raised by database subscriptions and services would not be enough to meet its projected working capital and operating needs. “We are currently seeking additional capital to meet our projected working capital, operating, and debt repayment needs for periods after September 30, 2023 … Going forward, we cannot be certain when or if our operations will generate sufficient cash to fully fund our ongoing operations or the growth of our business,” it says.

The timing of MariaDB’s flotation may have been unfortunate. While it was already in train, the SPAC model was going out of favor. Research from early December 2022 by investment research firm Bedrock AI found 49 per cent of the quarterly financial filings by companies floating via a SPAC since the beginning of the year contained an admission of ineffective internal controls. Earlier this month Europe’s biggest SPAC, Pegasus Europe, announced it would cease operations and return capital to its investors at the beginning of May. In May last year, Goldman Sachs took a break from handling SPAC-based IPOs.

Speaking to The Register, MariaDB CMO Franz Aman said the company was still hiring, but a number of job losses had also been necessary. “It’s absolutely no secret that, like companies in tech, we need to be super prudent, and we need to be fiscal responsive. We also had a look at our headcount plan, and we had to make sure that we were doing the right things. We had a reduction in workforce… so have most other tech companies: everyone’s concerned about profitability, cash position.”

Aman argued that a “going concern” notice in regulatory filings was far from unusual.

For example, research from Audit Analytics [PDF] showed nearly 18 percent of companies received a “going concern” audit opinion in the 2020 financial year.

“The moment auditors think there could even be the shred of opportunity that… there isn’t enough money for operation, you have to add the going concern as a risk factor. It’s a risk factor, like many others, and we’re in pretty good company there. If you look at the history of going concerns, IBM, Apple, Ford, and GM, they’ve all had a ‘going concern’ at some point in time in their company’s evolution,” he said.

The SPAC process also made such a warning more likely, because it allows investors to pull out cash without justification. As economic conditions worsened and the stock market fell last year, that’s what they did, creating a high redemption rate, which affected MariaDB too, Aman said.

Nonetheless, through its D-found funding combined with the SPAC flotation (called a de-SPAC in financial jargon) the company raised $120 million cash: “more than we had in the history of MariaDB,” Aman said.

The company was in the process of raising capital to continue operating beyond September, Aman said, but he was unable to go into detail owing to a regulator “quiet period” prior to its forthcoming quarterly results.

Meanwhile, MariaDB has appointed Conor McCarthy as CFO. “The leadership team and board’s depth of industry expertise combined with the company’s ability to execute, as demonstrated by 90 percent year-over-year growth in cloud-related subscription revenue, makes me excited for what’s possible with MariaDB,” he said in a pre-canned statement.

Only in July last year, Christine Napoli was appointed CFO, but her LinkedIn profile makes no mention of MariaDB. It says she started as CFO of MediaMath, an ad-tech firm, in November.

“Christine was there for a very short time, and she made a choice not to continue. We took our time [to find a replacement because] we wanted to make sure that we had a CFO who has a background in software-as-a-service and had CFO in a public company. With Connor checking all the boxes, he’s got what we were looking for,” Aman said.

Another potential cause for concern is the share price. Although it may not be immediately relevant to tech buyers or users, it can affect the company’s ability to raise cash, given the ability to raise capital against warrants and share options issued around the flotation.

According to its SEC filing from March 24, 2023 [PDF], MariaDB expected to secure $186.3 million cash from the exercise of warrants.

“If the market price for our Ordinary Shares is less than $11.50 per share, we believe the holders of Public Warrants and Private Placement Warrants will be unlikely to exercise such warrants. On March 23, 2023, the closing price of our Ordinary Shares on the New York Stock Exchange was $1.43 per share, as a result of which the Warrants are currently out-of-the-money,” it said at the time.

Aman admitted MariaDB was disappointed with the outcome, but he said that in January and February of 2022, when MariaDB was planning to go de-SPAC, “the world was a different place.”

Cloud growth

The database MariaDB was developed by Michael Widenius, the main author of MySQL. Following the sale of MySQL to Sun Microsystems and then – via Oracle’s Sun acquisition – to Oracle, Widenius created a fork of MySQL which became MariaDB. He no longer sits on the board of MariaDB, the company.

“As companies grow and succeed, this personnel changes. As we went through the SPAC process, we had to design the board for a public company so the entire board got restructured, a lot of the old investors they’re not on the board anymore,” Aman said.

He said Widenius had always worked with MariaDB on a fixed-term contract and that remained the case, although he was no longer CTO. The company currently does not have a CTO but has a “field CTO”, he said.

Aman said MariaDB was making more than $50 million a year in revenue with 20 percent annual growth. Its cloud business, which includes DBaaS SkySQL, was growing at 90 percent year-on-year, he said. “We just released the new SkySQL version with cool features and a lot of savings opportunity for our customers with auto-scale not just up, but down,” he said. ®

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

NoSQL Database

Stay up-to-date with Global NoSQL Database Market research offered by HTF MI. Check how key trends and emerging drivers are shaping this industry growth.

PUNE, MAHARASHTRA, INDIA, April 18, 2023/EINPresswire.com/ — The Latest Released NoSQL Database market study has evaluated the future growth potential of NoSQL Database market and provides information and useful stats on market structure and size. The report is intended to provide market intelligence and strategic insights to help decision-makers take sound investment decisions and identify potential gaps and growth opportunities. Additionally, the report also identifies and analyses changing dynamics, and emerging trends along with essential drivers, challenges, opportunities, and restraints in the NoSQL Database market. The study includes market share analysis and profiles of players such as Couchbase (United States), MongoDB (United States), Redis (United States), IBM Cloudant (United States), Amazon DynamoDB (United States), RavenDB (Isreal), Cassandra (United States), Azure Cosmos (United States), DataStax Enterprise (United States), Riak (United Kingdom)

If you are a NoSQL Database manufacturer and would like to check or understand the policy and regulatory proposals, designing clear explanations of the stakes, potential winners and losers, and options for improvement then this article will help you understand the pattern with Impacting Trends. Click To get SAMPLE PDF (Including Full TOC, Table & Figures) https://www.htfmarketintelligence.com/sample-report/global-nosql-database-market

According to HTF Market Intelligence, the Global NoSQL Database market to witness a CAGR of 30.5% during forecast period of 2023-2029. The market is segmented by Application (Data storage, Metadata Storage, Web application, E-commerce, Data Analytics, Others) by Technology (My SQL, Hadoop, Oracle) by Distribution Channels (BFSI, Healthcare, Telecom, Government, Retail, Others) and by Geography (North America, South America, Europe, Asia Pacific, MEA).

Definition:
NoSQL databases can store data in documents rather than relational tables. However, it classifies not only SQL and subdivides it by a variety of flexible data models. There are various types of NoSQL databases include pure document databases, key-value stores, wide-column database,s and graph databases. NoSQL databases are built for the storage of data and process huge amounts of data at a large scale and support a growing number of modern businesses.

Market Trends:
• The most trending NoSQL Database is PostgreSQL, MongoDB, and MySQL

Market Drivers:
• RDBMS databases installation is expensive and its proprietary servers, while NoSQL databases can be easily installed in cheap
• RDBMSs is not easy to scale-out commodity clusters, but NoSQL databases are made for transparent expansion for a user to interact

Market Opportunities:
• Growing of data in the various ed-tech firms is building opportunities for usage of NoSQL
• As the Presence of large in today world, however, it to create large job opening in the market

Revenue and Sales Estimation — Historical Revenue and sales volume are presented and further data is triangulated with top-down and bottom-up approaches to forecast complete market size and to estimate forecast numbers for key regions covered in the report along with classified and well-recognized Types and end-use industry.

SWOT Analysis on NoSQL Database Players
In addition to Market Share analysis of players, in-depth profiling, product/service, and business overview, the study also concentrates on BCG matrix, heat map analysis, FPNV positioning along with SWOT analysis to better correlate market competitiveness.

Demand from top-notch companies and government agencies is expected to rise as they seek more information on the latest scenario. Check the Demand Determinants section for more information.

Regulation Analysis
• Local System and Other Regulation: Regional variations in Laws for the use of NoSQL Database
• Regulation and its Implications
• Other Compliances

Have Any Query? Ask Our Expert @: https://www.htfmarketintelligence.com/enquiry-before-buy/global-nosql-database-market

FIVE FORCES & PESTLE ANALYSIS:

In order to better understand market conditions five forces analysis is conducted that includes the Bargaining power of buyers, Bargaining power of suppliers, Threat of new entrants, Threat of substitutes, and Threat of rivalry.

• Political (Political policy and stability as well as trade, fiscal, and taxation policies)
• Economical (Interest rates, employment or unemployment rates, raw material costs, and foreign exchange rates)
• Social (Changing family demographics, education levels, cultural trends, attitude changes, and changes in lifestyles)
• Technological (Changes in digital or mobile technology, automation, research, and development)
• Legal (Employment legislation, consumer law, health, and safety, international as well as trade regulation and restrictions)
• Environmental (Climate, recycling procedures, carbon footprint, waste disposal, and sustainability)

Book Latest Edition of NoSQL Database Market Study @ https://www.htfmarketintelligence.com/buy-now?format=3&report=2489

Heat map Analysis, 3-Year Financial and Detailed Company Profiles of Key & Emerging Players: Couchbase (United States), MongoDB (United States), Redis (United States), IBM Cloudant (United States), Amazon DynamoDB (United States), RavenDB (Isreal), Cassandra (United States), Azure Cosmos (United States), DataStax Enterprise (United States), Riak (United Kingdom)

Geographically, the following regions together with the listed national/local markets are fully investigated:
• APAC (Japan, China, South Korea, Australia, India, and the Rest of APAC; the Rest of APAC is further segmented into Malaysia, Singapore, Indonesia, Thailand, New Zealand, Vietnam, and Sri Lanka)
• Europe (Germany, UK, France, Spain, Italy, Russia, Rest of Europe; Rest of Europe is further segmented into Belgium, Denmark, Austria, Norway, Sweden, The Netherlands, Poland, Czech Republic, Slovakia, Hungary, and Romania)
• North America (U.S., Canada, and Mexico)
• South America (Brazil, Chile, Argentina, Rest of South America)
• MEA (Saudi Arabia, UAE, South Africa)

Some Extracts from NoSQL Database Market Study Table of Content

NoSQL Database Market Size (Sales) Market Share by Type (Product Category) [] in 2023
NoSQL Database Market by Application/End Users [Data storage, Metadata Storage, Web application, E-commerce, Data Analytics, Others]
Global NoSQL Database Sales and Growth Rate (2019-2029)
NoSQL Database Competition by Players/Suppliers, Region, Type, and Application
NoSQL Database (Volume, Value, and Sales Price) table defined for each geographic region defined.
Supply Chain, Sourcing Strategy and Downstream Buyers, Industrial Chain Analysis
……..and view more in complete table of Contents

Check it Out Complete Details os Report @ https://www.htfmarketintelligence.com/report/global-nosql-database-market

Thanks for reading this article; you can also get individual chapter-wise sections or region-wise reports like Balkan, China-based, North America, Europe, or Southeast Asia.

Criag Francis
HTF Market Intelligence Consulting Pvt Ltd
+ 1 434-322-0091
sales@htfmarketintelligence.com
Visit us on social media:
Facebook
Twitter
LinkedIn

Article originally posted on InfoQ. Visit InfoQ

Docker Desktop’s latest 4.18 release, brings a wealth of new features, including vulnerability quickview, recommendations, and image diffing for Docker Scout, stable Container File Explorer, an init command to quickly add Docker to a project, and experimental Compose File Watch to monitor changes inside a project.

Introduced in version 4.17 and currently available only for Docker Pro, Team, or Business subscriptions, Docker Scout aims to provide insights into container image security by analyzing image content and listing all identified CVEs using the docker scout cves command.

Docker Desktop 4.18 is now able to provide suggestions as to how to remediate to any identified CVEs. This is accomplished by running the docker scout recommendations command, which will hint at the availability of a new base image and list the benefits it will bring. Additionally, Scout offers a new docker scout quickview command to list all issues found in an image, including its base image, grouped by severity.

Docker Scout also brings a new experimental feature aimed to make it easier to compare images and retrospectively document which changes were made to an image to address its vulnerabilities. The report, which can be generated using docker scout compare includes a summary of CVEs found in the base images as well as a list of all added, removed, or updated packages.

A new CLI command in Docker Desktop 4.18, still in beta, is docker init, aimed to easily create all required files to add Docker to an existing project, including Dockerfiles, Compose files, and .dockerignore. Currently, docker init support Go projects, but Docker is working to add support for Node.js, Python, Rust, and other languages.

Away from the CLI, Docker Desktop includes a new GUI tool to simplify the task of checking or removing files within a container, the Container File Explorer. It allows developers to check a container file system, drag and drop files and folders, edit, and remove files. The new tool will be particularly useful in those cases where no shell is available within a running container.

As a final note about Docker Desktop 4.18 it is worth mentioning a new Compose configuration option aiming to keep services constantly up-to-date while you modify them. Still experimental, Compose File Watch includes a new watch service, which can be run by docker compose alpha watch. The service behavior can be controlled through a new x-develop section in compose.yaml which specifies a list of actions that should be run for any change to given targets. For example:

 x-develop:
      watch:
        - action: sync
          path: ./web
          target: /app/web
        - action: rebuild
          path: .package.json

The snippet above will in have Compose automatically synchronize to any change under ./web and rebuilding the image for any change to package.json.

Do not miss the official release note for a detailed view of all changes in Docker Desktop 4.18.

Article originally posted on InfoQ. Visit InfoQ

Microsoft has recently released the third preview of the .NET Multi-platform App UI (MAUI) framework in .NET 8 roadmap. This latest release includes a number of quality improvements for UI controls and layouts, with a focus on memory management also. In addition, Preview 3 also brings support for the NuGet package version of the app. This means that developers will now have the ability to preview future builds and lock their applications to a specific version of .NET MAUI.

Based on the releases, the engineering team has been prioritizing the most pressing issues affecting the most commonly used controls. This includes improving layout functionality, addressing concerns with CollectionView, and enhancing the performance of Shell and drawing features such as shapes, shadows, and clipping.

Regarding the .NET 8 development, the project has made significant progress, having already resolved 303 issues and merged 713 pull requests. Some of the most significant improvements in the upcoming release have been identified by the team, including keyboard interactions with Entry and Editor, Grid helper methods, and Shell lifecycle events. These improvements represent just a few highlights of what can be expected in the .NET 8 version. Developers looking for more detailed information on the upcoming release are encouraged to refer to the release notes.

Furthermore, Memory Management is another highlighted improvement that this version brings. One of the key improvements in this area was made by Jonathan Peppers, who discovered a memory leak that occurred when users repeatedly navigated forward and back within an app. Peppers implemented a WeakList to keep track of references, which solved the issue and ensured proper memory release.

In addition to memory management, the team has also made performance improvements in several other areas, including Button, Page and Layout, Window, Shadow, Clip, Background brush, BindableLayout, and more. These updates have been backported to the version of .NET 7, providing immediate benefits to those who are using earlier versions of the platform.

Another highlight of this release is the possibility to use and layer a specific version of .NET MAUI via NuGet packages, providing more flexibility and control over the development process. While .NET MAUI is still used and installed via the workload part of Visual Studio or the dotnet command line, the NuGet packages way of doing this enables the way to review pull requests, preview unreleased or experimental builds, or pin a project to a specific version.

Those who are interested in trying out these features can do so by installing .NET 8 Preview 3 and running the following command for the MAUI workload:

dotnet workload install maui

While full Visual Studio 2022 support for .NET 8 previews is still in the works, this latest release provides a way for developers to preview and experiment with .NET MAUI in a supported environment. For more information on the .NET 8 roadmap and new features coming for .NET MAUI, users can visit themesof.net.

Also, there is an interesting fact regarding the .NET MAUI. According to a tweet written by Shaun Walker, it reports that .NET MAUI is currently one of the most active projects within the .NET Foundation. When Android, iOS, and .NET MAUI are combined, they account for a significant proportion of issues and pull requests. Impressively, the usage of .NET MAUI has grown by a staggering 450% in less than a year.

In the original release post, author David Ortineu, Principal Product Manager, .NET Multi-platform App UI states the following:

Our goal in .NET 8 is to make you even more successful using .NET to build apps for Android, iOS, macOS, and Windows with .NET MAUI.

Lastly, in addition to an original release blog post, and as part of the development process, the development team calls on developers to test the new release and share feedback through the GitHub issue tracker.

The community members are also invited to visit the official GitHub project repository and learn more about this project and its future roadmap.

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for April 10th, 2023 features news from OpenJDK, JDK 21, Spring Framework and Spring Data updates, GraalVM Build Tools 0.9.21, MicroStream becomes an Eclipse Project, Micronaut 3.8.9, Helidon 4.0.0.Alpha6, Hibernate ORM 6.2.1, Micrometer Metrics 1.11.0-RC1, 1.10.6 and 1.9.10, Micrometer Tracing 1.1.0-RC1 and 1.0.4, Piranha 23.4.0, Project Reactor 2022.0.6 and Gradle 8.1.

OpenJDK

After its review had concluded, JEP 444, Virtual Threads, has been promoted from Proposed to Target to Targeted status for JDK 21. This JEP proposes to finalize this feature based on feedback from the previous two rounds of preview: JEP 436, Virtual Threads (Second Preview), delivered in JDK 20; and JEP 425, Virtual Threads (Preview), delivered in JDK 19. This feature provides virtual threads, lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications, to the Java platform. The most significant change from JEP 436 is that virtual threads now fully support thread-local variables by eliminating the option to opt-out of using these variables. More details on JEP 425 may be found in this InfoQ news story and this JEP Café screen cast by José Paumard, Java developer advocate, Java Platform Group at Oracle.

Similarly, JEP 430, String Templates (Preview), has been promoted from Proposed to Target to Targeted status for JDK 21. This preview JEP, under the auspices of Project Amber, proposes to enhance the Java programming language with string templates, string literals containing embedded expressions, that are interpreted at runtime where the embedded expressions are evaluated and verified.

JEP 442, Foreign Function & Memory API (Third Preview), has been promoted from Candidate to Proposed to Target for JDK 21. This JEP incorporate refinements based on feedback and to provide a third preview from: JEP 434, Foreign Function & Memory API (Second Preview), delivered in JDK 20; JEP 424, Foreign Function & Memory API (Preview), delivered in JDK 19, and the related incubating JEP 419, Foreign Function & Memory API (Second Incubator), delivered in JDK 18; and JEP 412, Foreign Function & Memory API (Incubator), delivered in JDK 17. This feature provides an API for Java applications to interoperate with code and data outside of the Java runtime by efficiently invoking foreign functions and by safely accessing foreign memory that is not managed by the JVM. Updates from JEP 434 include: centralizing the management of the lifetimes of native segments in the Arena interface; enhanced layout paths with a new element to dereference address layouts; and removal of the VaList class. The review is expected to conclude on April 21, 2023.

JEP 445, Flexible Main Methods and Anonymous Main Classes (Preview), has been promoted from its JEP Draft 8302326 to Candidate status. This feature JEP, formerly entitled Implicit Classes and Enhanced Main Methods (Preview), proposes to “evolve the Java language so that students can write their first programs without needing to understand language features designed for large programs.” This JEP moves forward the September 2022 blog post, Paving the on-ramp, by Brian Goetz, Java language architect at Oracle.

Paul Sandoz, Java architect at Oracle has submitted JEP Draft 8305868, Vector API (Sixth Incubator). This JEP, under the auspices of Project Panama, incorporates enhancements in response to feedback from the previous five rounds of incubation: JEP 438, Vector API (Fifth Incubator), delivered in JDK 20; JEP 426, Vector API (Fourth Incubator), delivered in JDK 19; JEP 417, Vector API (Third Incubator), delivered in JDK 18; JEP 414, Vector API (Second Incubator), delivered in JDK 17; and JEP 338, Vector API (Incubator), delivered as an incubator module in JDK 16. This feature proposes to enhance the Vector API to load and store vectors to and from a MemorySegment as defined by JEP 424, Foreign Function & Memory API (Preview).

JDK 21

Build 18 of the JDK 21 early-access builds was also made available this past week featuring updates from Build 17 that include fixes to various issues. Further details on this build may be found in the release notes.

For JDK 21, developers are encouraged to report bugs via the Java Bug Database.

Spring Framework

Versions 6.0.8, 5.3.27 and 5.2.24.RELEASE of Spring Framework have been released to primarily address CVE-2023-20863, Spring Expression DoS Vulnerability, a vulnerability in which an attacker to provide a specially crafted Spring Expression Language expression that may cause a denial-of-service (DoS) condition. Other new features include: a new overloaded truncate() method defined in the StringUtils class to serve as centralized, consistent way for truncating strings; a new nullSafeConciseToString() method defined in the ObjectUtils class to generate a more “concise” null-safe toString() representation of various objects that does not include an entire object graph; and replace the use of the unmodifiableList() method defined in the Collections class with the copyOf() method defined in the List interface which results in Spring application code that more readable, prevents unexpected bugs and easier to maintain. More details on these releases may be found in the release notes for version 6.0.8, version 5.3.27 and version 5.2.24.RELEASE.

Spring Data 2023.0-RC1, 2022.0.5 and 2021.2.11 have been released this past week. Version 2023.0-RC1 features: the reinstatement of MariaDB support for Spring Data R2DBC; a new @Hint annotation in Spring Data MongoDB with support for reactive bulk operations; and many enhancements to the Spring Data JPA Hibernate and JPQL parsers to better support aliases and other aspects of query parsing for @Query annotated queries. Versions 2022.0.5 and 2021.2.11 are service releases that ship with improvements and bug fixes for regressions. These versions may be consumed with the upcoming releases of Spring Boot 3.0.6 and 2.7.11, respectively.

GraalVM Native Build Tools

On the road to version 1.0, Oracle Labs has released version 0.9.21 of Native Build Tools, a GraalVM project consisting of plugins for interoperability with GraalVM Native Image. This latest release provides notable changes such as: a fix to ensure compatibility with Gradle’s configuration cache; deprecate the requiredVersion property in favor of using a version string; and a new write-args-file Maven goal that writes an arguments file such that other plugins downstream in the life cycle may use it. More details on this release may be found in the changelog.

MicroStream

MicroStream has announced that their Java-native persistence layer will become an Eclipse Project. The MicroStream Serializer product will be renamed to Eclipse Serializer and the MicroStream Persistence product will be renamed to EclipseStore. MicroStream also plans to launch an EclipseStore Working Group as a standard for the Jakarta Persistence specification in which EclipseStore will become a compatible implementation.

Micronaut

The Micronaut Foundation has released Micronaut Framework 3.8.9 featuring bug fixes, support for JDK 20 in annotation processors and updates to modules: Micronaut AWS and Micronaut Kafka. There was also a dependency upgrade to Netty 4.1.91. More details on this release may be found in the release notes.

The fourth milestone release of Micronaut 4.0.0 was also made available this past week featuring support for: annotation-based CORS configuration; compilation time expressions in annotations; the ability to disable streaming HTTP request processing; and conditional routing.

Helidon

The sixth alpha release of Helidon 4.0.0 features notable changes such as: support for JDK 20; completion of the shortcut methods for all HTTP methods in the WebServer and WebClient components; and a rename of the receive() method to onMessage() for consistency with other methods in the WebSocket component. More details on this release may be found in the release notes.

Hibernate

The release of Hibernate ORM 6.2.1.Final ships with notable fixes such as: improved sub-queries using aliases and left joins; generic associations being ignored when dirty checking and bytecode enhancement were enabled; part of a composite @IdClass primary key not being returned when querying; and Internal nullness marking and checking.

Micrometer

Versions 1.11.0-RC1, 1.10.6 and 1.9.10 of Micrometer Metrics have been released. New features in version 1.11.0-RC1 include: a new Supplier variant of the getOrDefault() method defined in the Context inner class of the Observation interface; metrics support for Netty allocators and event executors; and more efficient cumulative count computations in the takeCountSnapshot() method defined in the AbstractTimeWindowHistogram class. Version 1.10.6 and 1.9.10 primarily provide bug fixes and dependency upgrades.

Similarly, versions 1.1.0-RC1 and 1.0.4 of Micrometer Tracing deliver bug fixes, dependency upgrades to Micrometer 1.11.0-RC1 and 1.10.6, respectively, and new features: allow propagation of spans via ThreadLocalAccessor interface; alignment with annotations changes in Micrometer; and support for creating spans with links.

Piranha

Piranha 23.4.0 has been released. Dubbed the “Update Components” edition for April 2023, this new release includes: updates to various compatible implementations of Jakarta EE components to their latest versions; update running automated tests in the release workflow to use JDK 19; and basic code cleanup. More details on this release may be found in their documentation and issue tracker.

Reactor

Project Reactor 2022.0.6, the sixth maintenance release, provides dependency upgrades to reactor-core 3.5.5, reactor-addons 3.5.1, reactor-netty 1.1.6, reactor-kafka 1.3.17 and reactor-kotlin-extensions 1.2.2. More details on this release may be found in the changelog.

Gradle

The release of Gradle 8.1 features: a stable version of the configuration cache; support for dependency verification; improved error reporting for Groovy closures; support for Java lambdas; improved memory management; and support for building projects with JDK 20. More details on this release may be found in the release notes.

Article originally posted on InfoQ. Visit InfoQ

Amazon recently announced that AWS Lambda functions can progressively stream response payloads back to the client. The new feature improves performance for web and mobile applications and is currently available for Node.js 14.x and newer runtimes, as well as custom ones.

Response streaming helps developers stream responses from their functions to their users without necessarily waiting for the entire response to be finished. The long-awaited capability is supported using Lambda function URLs and SDKs but it is currently not possible to use the API Gateway or the Application Load Balancer (ALB) to stream response payloads. Julian Wood, principal developer advocate, explains the advantages:

In traditional request-response models, the response needs to be fully generated and buffered before it is returned to the client. This can delay the time to first byte (TTFB) performance while the client waits for the response to be generated. Web applications are especially sensitive to TTFB and page load performance.

Designed for large payloads like images, videos, large documents, or database results, response streaming requires wrapping the Lambda function handler with the streamifyResponse() decorator, for example:

exports.handler = awslambda.streamifyResponse(
	async (event, responseStream, context) => {
    	responseStream.setContentType("text/plain");
    	responseStream.write("Hello, world!");
    	responseStream.end();
	}
);

where the new responseStream object provides a stream object that the function can write data to and send it immediately to the client. Developers can optionally set the Content-Type header of the response to pass additional information about the stream. AJ Stuyvenberg, engineering team lead at Datadog, tested the new feature and comments:

This launch may seem minor, but it unlocks several key use cases – especially for Next.js and React developers looking to reduce time to first byte while leveraging server-side rendering.

The new feature currently supports a maximum response size of 20 MB (soft limit) and there is a maximum bandwidth throughput limit of 16 Mbps (2 MB/s) for streaming functions. Currently, response streaming is only natively available in the Node.js SDK but it is possible to implement it in a custom Lambda runtime supporting other programming languages. While some developers focus on the limitations, Jeremy Daly, CEO and co-founder at Ampt, writes in his newsletter:

This not only allows Lambda functions to progressively stream responses back to the client to reduce TTFB, but also allows you to exceed the standard 6MB payload limit.

Yan Cui, cloud consultant and AWS Serverless Hero, wrote an article demonstrating how to return large objects with the new streaming response, bypassing the need to store results in S3.

Response streaming in Lambda is not the first option available in the cloud space with Vercel recently offering support for HTTP response streaming in both Node.js (Lambda) and Edge runtimes.

AWS published example Lambda streaming applications in the Serverless Patterns Collection, applications that support AWS SAM to build and deploy the resources. Streaming responses increase the Lambda costs for network transfer but the AWS free tier now includes 100GiB of HTTP response streaming per month, beyond the first 6MB per request.

Article originally posted on InfoQ. Visit InfoQ

The latest stable release of Android Studio, dubbed Flamingo, brings Live Edit for Composable UIs, new app inspection features, updated IntelliJ, and more.

Live Edit is a new experimental feature that enables pushing code changes directly to an attached device or emulator to update an app’s composables in real time. This reduces context switching and optimizes the build-deploy-iterate cycle for UI programming. Live Edit can only apply changes to composable function bodies and does not support method signature updates, adding new methods, or class hierarchy changes.

Live Edit can be applied manually when a file is saved or automatically for each change. Occasionally, Live Edit can make an app crash, in which case a complete app re-deploy is required. Likewise, if you change non-composable functions, the latest code might not be invoked at times. In those cases you will also need to run the app again.

Other new UI-related features included in Android Studio Flamingo are support for previewing themed app icons with different wallpapers, and dynamic color preview.

Android Studio Flamingo also brings a number of new features in the build toolchain. The build analyzer is now able to group tasks by categories, which can be sorted by duration to highlight which categories have a larger impact on build time, for example, Manifest, Android Resources, Kotlin, Dexing, etc.

SDK extensions can be now scanned to detect any issues using to a new linter. SDK extensions are a mechanism enabling system components to be updated with critical bug fixes and other improvements as needed. Additionally, profiling gets one-click automated support for building and running a non-debuggable build, which prevents profiling a debug build unless expressly desired.

As a last note about the build system, Android Studio Flamingo adopts Gradle plugin 8, which brings both improvements and breaking changes, such as the removal of the Transform API. The Transform API was typically used for instrumenting compiled classes to add traces, custom logging, performance analysis and so on. Developers will need to migrate to use replacement APIs, including the Instrumentation API, which can be used for transforming bytecode, and the Artifacts API, which enables adding new classes to an app.

A very useful feature for testing app network behavior is network traffic interception and modification. This will allow you to modify a network response before it reaches your app so you can test how your app behaves when getting distinct status codes, headers, or payloads. Furthermore, Android Studio Flamingo offers an improved integration with Crashlytics so you can more easily discover, investigate, and reproduce issues.

As a final note about the new Android IDE, it is worth mentioning the adoption of IntelliJ 2022.2 , which brings IDE performance improvements, specifically when using Kotlin, enhanced rendering performance on macOS, and more.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Davis: Imagine that you’re the leader responsible for destroying the One Ring of Power. For context, this scenario comes from Tolkien’s fantasy novel, “The Lord of the Rings.” The One Ring was forged by Sauron at Mount Doom in an attempt to rule over all of Middle-earth. Anyone who tries to wear the ring is corrupted by its power, even if they intended to destroy it. In order to eliminate the threat of Sauron, someone has to destroy the ring. You know that you aren’t equipped with the right skills alone. You’re vulnerable to the corruption of the ring. The people available for your team come from different backgrounds, and two of them really don’t get along at all. Everyone has different levels of expertise and experience. One factor in your favor is that one team member is able to hold the ring without immediately being corrupted. You gather up your team, and you try to plan out what you can achieve to get to your goal.

Everyone shares different perspectives, the only place the ring can be destroyed is on Mount Doom. You realize, there are many paths to Mordor, because of the Ring’s inherent properties, you must avoid many of them. You could get a ride from your friends, the giant eagles. The Nazgûl, who are servants to Sauron can also fly, and you would be at greater risk in the air than on the ground. The shortest path leads directly through Isengard, which is tricky, since many people want to possess this ring of power. You decide to take the longer but more sustainable route for all those involved. You have a map that isn’t going to tell you what obstacles and the moment your team are going to face along the way. You need to think about how to help your team navigate the changing landscape and evolving relationships so that they can continually make progress along the way.

Background

I’m Jennifer Davis. My pronouns are she, her. I’m an engineering manager at Google within the DevRel organization, and a published author. My newest book just came out, “Modern System Administration.” My current job, I want to help customers use Google Cloud products in a seamless way. My team works on all things serverless, orchestration, and DevOps. One of the many interesting things about engineering in DevRel is our zeroth customer approach. We want to help people understand how to build, test, deploy, and monitor modern web applications. We explore the concerns that everyday teams will have in building applications on Google Cloud. Then we build those sample applications that help explain the concepts to others, enough so that it’s flexible, that people can adapt to their own organization’s needs. We write code, test it, and manage all the CI/CD infrastructure to support others contributing to the samples as well. Some samples are small snippets of code and some are large conceptual apps.

DORA, DevOps Research and Assessment

For eight years, the DevOps Research and Assessment team have been doing research on development performance. There are four key metrics of software delivery performance: deployment frequency, lead time, change failure rate, and time to restore service. The last couple of years, they’ve also identified a fifth metric, which is the operational performance reliability. These metrics along with associated capabilities are predictive of business success, higher developer satisfaction, and lower burnout. We really don’t want people to burn out. We know if we combine continuous delivery, loosely coupled architecture, version control, and continuous integration, we can foster software delivery performance that is greater than any of those individual activities themselves can contribute. How do we help people embrace these capabilities? My team has to embrace the capabilities as well so that we can support people embracing those capabilities. I need to support an environment that grows the capabilities, especially one that encourages autonomy, trust, sharing your different perspectives, and encourages learning through retrospectives.

Outline

I want to talk about the three areas that are crucial in my approach to support my teams to have high performance: functional leadership, boundary setting, and learning and adaptability. These helps build the crucial capabilities that inform highly performing teams. Again, autonomy, trust, voice, and blameless retrospectives. Those capabilities that we saw earlier that come out of the DORA research, those are the things that we want to focus on.

Functional Leadership

Let’s start off with functional leadership. What is leadership? Often, it’s defined by whether someone is following you. Managers can be leaders, but they’re not always the leader. Sometimes leadership is handed to us, and sometimes we are compelled to lead, because something needs to be fixed. Some lead by example, and some lead by coaching in complex environments. Leadership is getting people together to figure out what the possibilities are, and then following through, fostering the understanding of the specific contexts that we’re faced with to solicit what assumptions and experience people have about the situations that were experienced. We get to a shared context, and we foster collaboration. We also want to hold people accountable to be active in their participation. Mary Follett influenced many modern management practices. She said, leadership is not defined by the exercise of power, but by the capacity to increase the sense of power among those led. When we talk about leadership, we’re talking about, it starts with individuals, and how we approach individuals. When I approach a new team, I respect the roles and responsibilities that each human currently has. I don’t make assumptions about their capabilities or their interests based on that existing hierarchy.

Instead, my first step, whenever I’m approaching a new team, is to get to know the individuals on the team. I need to understand their motivations, their goals, their worries. Why they’re here. What do they want to accomplish? What is on their mind? What’s hindering them to make progress? Once I start building these relationships with the individuals and I see people in action, I can start identifying the different strengths and weaknesses that they have. Their different perspectives, their skills, their experiences, and any interests that support the team’s goals. Next, I have to assess the state of trust of the team and begin to build that trust with each of them individually, one on one, and then together as a team. I start by sharing some of my values, my vulnerabilities, because when you start sharing your vulnerabilities is when you can start building that trust.

When I started managing my current team, I shared these three values: authenticity, kindness, and trust. What that means is that I will bring my true and genuine self to them, and that I encourage them to be able to do this as well. I’m not assuming that the minute I walk in the door, they’re going to be able to show that true and genuine self. The reason why I encourage this is because I want to build better quality outcomes. When you consider different perspectives and styles, and bring that together, it’s not going to happen unless everyone is being their true and authentic self. That, secondly, I value kindness in all my interactions. This means that I’m going to strive to be friendly, generous, and considerate. I expect others to try to do the same with each other. This includes being kind and telling people the feedback they need to hear when they need to hear it. Then, finally, that I’m going to strive to build relationships with me and with each other, because I don’t take that trust for granted. Trust takes so much time to build and it takes just a moment to break. Trust is absolutely crucial in order to build highly performing teams.

When I think about functional leadership, I recognize that everyone can lead. That doesn’t mean that everyone’s leading all the time. It means fostering the capability of leadership in people. I’m helping the team to scale by helping them adapt to any challenges that come along the way. If we think about the One Ring adventure, if you take a functional leadership role, then your perspective is that any time challenges come, anyone can come up and be the person who leads, because at the core of it, energy is going to ebb and flow. People need to take breaks. I need to be able to take a break. I delegate leadership but I also clearly define roles and responsibilities. As the manager, I am part of the team’s leads team that supports the entire team with escalations, team planning, and prioritization, and holding the line of standards and the expectations we have of the team. This diagram shows you the breakup of how we think about our roles and responsibilities on the team. We also have specific leadership areas around product areas, the product itself, and project leadership. Not everything happens all at once. When that area needs to exist based on the organization’s priorities, then it does and we have people to be able to step into those leadership roles.

Boundary Setting

Let’s talk about setting boundaries to support the individuals and the team. An educational psychologist, Bruce Tuckman, described the five stages of team development: forming, storming, norming, performing, and adjourning. In forming, you support the group of people in finding common ground in their skills, backgrounds, and interests. That’s what I was talking about when I talked about sharing with people and then identifying them. You want to establish the set of goals, the timelines around those goals, and the ground rules of how you interact with each other. In storming, the group is learning how to work together. There may be conflicting personalities and perspectives. There may be different groups forming within the central group, and people having to take on different challenges. Multiple people may have strong opinions. At this point, it’s so crucial not to tone down that conflict. Instead, you want to understand what those different opinions are, and foster an environment where people are supported and enabled to be able to speak up, even if they’re not speaking up in the moment. It’s ok for people to send emails and share their opinions and ideas in different forums. It’s critical to find those different ways to enable everyone to have and share those different ideas and opinions. This may mean sharing documents early to get asynchronous feedback. It’s also important to establish the appropriate boundaries for how the team will work together. Meaning, if there’s particular language that’s used, you want to make sure that the norm is that of like, this is how we talk. For me, I think about it from a kindness perspective. Of course, bring up your concerns, but always come at it from a curiosity rather than saying, no, that’s a stupid idea.

In norming, the team has found that sense of unity. This is where we start seeing a team flow. When we think about flow, it’s that getting into the flow of getting work done and people relying on each other. It’s different from an individual flow, where someone can be in the moment and being able to find that place of working really effectively. Team flow is an even more powerful place. It’s not like you get there and all of a sudden, it just happens automatically. You have to continue to foster the team cohesion, recognizing the value that everyone is bringing, and helping the individuals resolve conflicts, because conflict is going to continue to happen. Performing, the team is really getting to that high flow state. There’s a large amount of safety and trust within the team, and individuals trust each other. You have to continually feed that team cohesion in positive ways. Finally, in the adjourning phase, you’ve met whatever the goal is, and some members may be starting to move on to new projects. This is one area where people sometimes forget to invest that time and effort, where they’re saying goodbye to team members that are moving on, or whatever the case is, because this is where you really establish that and continue to establish that trust that people have.

The interactions between the team is vital for that team cohesion. There has to be room for individuals to have different perspectives, continually, and to share those different perspectives. You want people to be able to be different and not get into a group mind, because then you’re going to be biased against all the other different perspectives, and you may not build as high quality of a solution. You want to preserve those differences, while also building trust and psychological safety for the team. It’s absolutely crucial to identify the set of team boundaries and enforce them. It starts with communicating the boundaries and expectations, and repeat them over. This is an example of one of the ways I repeat and document boundaries. I literally copy and pasted from the agenda for our team meeting where it tells the goals of the team meeting. I set this expectation in the team meeting. We share information. We develop working expertise in a scoped area. We own collectively our team norms. It’s not just Jennifer defining, this is what our team norms are. We talk about them, and we all share and embrace them. They can change over time. We align on our goals and we share feedback on the work people are doing because we want to share and talk about, make that work visible, and so that there’s no single points of knowledge or failure within the organization. Do we accomplish that all the time? No. Of course, there’s going to be single points of knowledge. It’s a continual process to work on it.

We also introduce team rituals. Those are those small regular activities that are ingrained in our team culture, no matter how the team changes over time. Some examples of our current rituals include starting with a shared playlist, we have music that we share. This allows us to talk about different interests and see even different cultures. We also talk about our emotions. I started talking about authenticity, and bringing your real self. It’s not all rainbows and sparkles all the time, even though, sometimes what I’m associated with is the sparkly DevOps. Being able to share when you’re having challenges, and when you need help, is a really crucial part, because then we create a system of mutual support. Sometimes things aren’t going great. By talking about these things, we can encourage and support each other. If someone isn’t feeling great, this is an area where folks offer up support. We celebrate all the little things. We encourage a gratitude culture, because it teaches people how to give and receive feedback. Know that all those little things, even though that’s just my job, people appreciate the effort you’ve made. Research shows that engaged employees are ready to go the extra mile to help other team members. This impacts the overall performance of the team. These proactive and prosocial behaviors spread and are shared within the team encouraging the behaviors with one another. It’s this positivity spiral.

Play. Games, especially role-playing games, or putting Lego together, just talking, help people learn about the boundaries and appropriate ways of working together. Often, our work roles are really tied up in our identities. When we disagree with one another, that can add an emotional weight of any past traumas that individuals may have had about themselves in the workplace. Playing builds up that team connectedness and it gives people the chance to practice how they communicate within the context of the scenario that’s separate from their identity. Some of the boundaries you can set and encourage them by encoding them. We’re constantly evaluating, what things can we do to improve our work and minimize the toil? For example, we can put tools to support the norms. We can leverage GitHub Actions. GitHub Actions, this is a continuous integration and continuous delivery platform available right on GitHub. We create workflows that test and build every pull request to our repository. Then, this workflow is triggered when an event occurs. Events, like a pull request being opened or an issue being created. One of the actions we use is to auto label pull requests so that teams can better understand, when a PR comes in, what is the subject matter expert that should focus on it? We automatically label what the type of API is, and so the right person gets the right pull request. Then, if people want to learn something about something they don’t have any expertise on now, they can go check it out, and learn about those particular areas. We also use GitHub Actions to lint incoming code, we have a style guide and expectations. Having that linting there, we can automatically test what it is the code coming in and whether it actually applies. This is an example of the black Python linter being run against our code. We also use Terraform linters.

When we’re writing code, we’re not just writing code to get something done. We’re also writing code to help people understand what it is the concepts, and so we have to think about all the different concerns, that may not be something that every engineering team has to think about. Working code is not good enough. We need to write code people can understand, read, learn from, and then share with their coworkers or within their organization to help advocate for change. We have a publicly shared sample style guide that informs our values, our principles, and practices, and that informs across the org how we write our code. It’s part of our onboarding process for when people are joining the team so they know how to write code as well.

We also have to think about boundaries across the organization. Interteam conflicts can aid in team cohesion and forming bonds, because you think of, this is us and them. The us and them can create this model within the org that can harm larger initiatives. Because a lot of times within DevRel, we are collaborating across boundaries to build up and develop and improve products. I don’t want to have a lot of us then dynamics, I want to encourage cross team projects. These are larger, more complex projects that span different teams across the organization. With those kinds of initiatives, we can build even more value, but it’s so challenging to get everyone aligned, because everybody reports to different people. Then you have the different feelings because, this is this manager on this other team, and how are they going to impact me as an IC? By embracing functional leadership, you enable individuals with the skills to lead regardless, to build these ad hoc teams, where it doesn’t matter who the manager is, everyone’s coming together to work together to accomplish a particular set of goals.

The problem is that different folks can have different team cultures within their team. It’s not like I can define, this is the perfect team for all teams. The team culture emerges. Be aware when there’s too much friction to overcome between members, especially when it comes to underrepresented folks. If the underrepresented folks in the industry are bearing all the cost to move the project forward, this is especially important as a manager to come in and enforce boundary setting. This may mean saying no in different ways than just saying no. What I mean by this is say, yes, and we’ll do that far off in the future without a specific date. Not saying it exactly that way, to, no, this isn’t possible at this time. Or, no, we’re not going to be able to do this because these sets of experiences that people are having to have because of this particular environment.

Learning and Adaptability

This brings me to my final theme, learning and adaptability. The terrain is always changing, and I need my team to be able to adapt to whatever is happening around them without constantly churning on execution. This starts with setting time aside explicitly for people to learn about emerging technologies, as well as any technical leadership opportunities that they might want to pursue. How much training, really depends on the scope of the team and where people are at currently. I cannot stress how important it is to encourage learning and being aware of what’s happening in the industry. I also encourage collaborative learning through friction logging. Friction logging is something we do at Google, that is exploratory testing. You take on this zeroth customer mantle to explore developing or building applications the way a customer would. We provide the feedback that we get through running through this friction log exercise directly to the product engineers, and then develop samples and use case scenarios to support demos to help people. Aja Hammerly, my peer in advocacy, has written this great blog post on friction logs. You can check that out. Sometimes taking that friction logging up a level not just as an individual, but as a team or a pair. When we do this team friction logging, we take that learning to a new level, because people are working together and then synthesizing what they’ve learned in the process. That really levels up the team learning about whatever this concept is, and also identifying where there may be mixed mental models about particular things.

We also use decision records in our large apps to help us build a coherent, shared understanding. Decision records show the path we took to users, but it also helps us onboard new contributors, and remind us of what we did and why. For example, when we were thinking about managing resources, we prioritize the need for IAM privileges, pull request checks, and nightly builds. We could have used GitHub Actions or other internal Google CI tooling, we decided on Cloud Build because it had the least overhead and security risk and IAM access to Google Cloud resources. We didn’t need to export service account keys, and Cloud Build also had GitHub Integration, PR checks, and the capability to do nightly builds. Finally, it’s just something external contributors can use, and that’s important to us being an open source project. We also decided to use Canary rollouts rather than an all at once, or blue-green deployment. We crafted this pipeline with Cloud Build triggers, Pub/Sub, that use the Cloud Run traffic management feature. Then we auto deploy to staging but required a manual approval to promote to production. We can adjust the traffic in increments to staging and prod in the code. All of those decisions that we made, we documented in our repository, and that informs how we did and why. Then, people coming in to learn from this can see what decisions we made, and then apply that same context to what they’re facing if it applies to them. Sometimes, we see a lot of these, this is the best practice. Why is it the best practice? Is it really the best practice for you in your context. Decision records really helped take things to that next level.

We also created a small show and tell just for the team. We have a larger demo time, and that’s across the larger org. Show and tell, specifically named that way, it sounds more like, here’s your show and tell for elementary school. That’s exactly the feeling I want to get to because the idea is to not set up this large context that people have to get over in order to share, because sometimes it’s hard to share what you’re doing, especially if it’s not finished, or it’s only partially there. You’re trying to figure something out, or you just want to connect with other people. This is a space for people on my team to share anything that they’ve learned or tried out. It’s not some prescribed, here’s exactly what you need to show and you need to show your work every week. Instead, what we get is people sharing, potentially photos from their recent vacation, so it encourages people to take time off. Or people showing some interesting tool that they learned about. This actually has helped develop the sense of sharing and learning across the team.

You also want to inoculate your team from stagnation for themselves and for your team. I encourage people to contribute to open source by getting involved in open source projects and working with other organizations across the industry. This gets your team exposed to other patterns of work, collaboration, and cooperation. It also helps you to experience some of the other learnings that are happening outside of your organization. It is so dangerous to get into this mindset of, it wasn’t built here, so it doesn’t matter. That makes you vulnerable to changes in the industry of patterns, and what are the things that people are caring about right now.

You need to think about all of this for yourself as well. It’s so easy to stagnate and get caught up in the daily grind. Broaden your interactions with others and learn from attending conferences like QCon Plus, like other training. One of the most valuable opportunities that I’ve taken for myself this past year was attending Ruth Malan’s Technical Leadership Masterclass. This opportunity was amazing for me because it gave me the opportunity to connect with other industry leaders, whether it was CTOs, CEOs, VPs, architects, senior developers, all within the context. We approached and talked about all these different problems, and how we were solving them in our particular organizations. This was so insightful because it gives you the broad depth and breadth across different places, and then helps you to see different ways of solving problems. Because a lot of times we’re all solving the same problems, it’s just maybe with a slightly different name. Another great opportunity is Lara Hogan’s Management and Leadership Training with Wherewithal. I’ve also taken that. If you don’t have a lot of time, they also come prerecorded. You don’t get that same opportunity to connect with and talk to others, but it’s still just an amazing resource.

Summary

I’ve shared with you three essential themes for helping your team navigate complex environments, and evolving relationships. Embrace functional leadership. Everyone can be a leader at different times, and may have a different style and different ways of leading. Start by building personal connections and understand where people are at, and what leader they can be. Build trust and delegate the leadership. Powering with your team enables everyone to feel ownership in the process and an autonomy to shape the team in a collaborative manner. It’s not just my team, it’s our team. Set and uphold boundaries. Establish team rituals that embed the boundaries within the organization and team itself. Use tools to support the boundaries that you have. Support cross team collaborative opportunities that can grow and foster relationships. Finally, plan and encourage learning and adaptability. Budget time for learning and support the collaborative learning opportunities possible, internal to the team, as well as externally through open source projects.

Questions and Answers

Reisz: What suggestions do you have to break down those walls, for people that maybe are a little more hesitant to share their authentic self?

Davis: There’s no one prescribed way. First is, understand the context of why the person is feeling less open to different ideas, or willing to compromise. A key thing is about, it’s not so much compromise that you want to get to, you want to get to consensus that everyone agrees. One challenge is making sure the systems in play are not impacting how people are choosing to respond. Because sometimes what is happening is there’s a system, say for example, like incentivization, or how people are rewarded for their contributions. Maybe they think that the most important thing for them to do is execute lots of individual things, rather than coming to the right solution. I think really, there’s a lot of paths to this. It’s about a continuous coaching process. The key thing I start from is there’s probably a system in play that is causing this, because people don’t naturally just want to be close-minded. Especially in engineering, we want to do the right thing, we don’t want to waste our time. I have run into situations where people are like, no, I’m the smartest person in the room and I’m doing the right way. That takes coaching. Sometimes you have to hold people accountable for the ways that you want them to interact. At times, they will decide that you’re not incentivizing them to be the person they want to be. They leave the team because it’s not the team they want to be on.

Reisz: I think when you hit on psychological safety, a lot of times it comes back to psychological safety. Really building that space for you to be authentic and be able to disagree, and it not to be like a poor experience or something that your heart starts pounding. It’s the safety to be yourself and the safety to disagree. Sometimes I’ve found my teams, at least, that that tends to be harder. You found some similar?

Davis: It is. I think it takes a lot, especially in a team that’s been having challenges, because they’re going to have learned patterns. Those are the systems at play that are causing some of the friction. Part of it is just starting out and recognizing and being consistent about what you’re expecting, how you’re expecting it, and encouraging people to collaborate. That’s generally where you run into the friction as well with people being close-minded. Once people start to see the value and they start having those experiences that are positive, it feeds into the positivity spiral, and they want more of that psychological safety within the team.

Reisz: I think you also talked about it’s, modeling the behavior, being open to be vulnerable, making sure you set boundaries.

In the beginning, when you were talking about functional leadership, and you were talking about setting those expectations for teams, understanding who the team members are, how do you go about that? From a team that you don’t know, that you’re going to become involved with, how do you really get involved and get to know people, particularly in this hybrid world that we’re in today? Because we’re in-person and online. What strategies, both in-person and online, just to really get to know those folks?

Davis: The great thing for me is, I feel like I have a little bit of a head start, because I’ve been working in a remote capacity for the teams I’ve been on, for many years now. It’s almost a decade at this point. To me, I feel like we should always have been doing work in a distributed model, especially coming from an Ops background and the challenge of being on-call for services, you can’t expect people to immediately be able to do stuff. Because you have to be able to drive, or go to the restroom. You need to go do family type outings, go get some groceries, get food. You have to have a way to negotiate those microtransactions of mutual support where someone else can take on-call for you for that time where you need to not be available. From a distributed point of view, we need that. A challenge is for people in relationships, it’s harder. There’s something that we just don’t capture when we’re in-person versus here in a video screen. Even as I’m watching my talk in the recording, I’m like, I am so much more vibrant when I have a person. It’s like, don’t forget to have, at least at minimum, somebody to talk to, like I’m talking to you right now.

There are certain things that you can do to facilitate more cohesion for a remote team. I mentioned some of them, but I didn’t put it in this context. We have a shared playlist of music, and sharing different things in chat channels, encouraging people to share, not just like, what is it you’re working on? Like, what are you doing? Are you taking a walk for the day? We did a Walktober, where we didn’t compete against each other, but we share how much we’re walking. I also encourage, when people take time off, I’m like, “Great job taking time off. That’s awesome.” To encourage that pattern of behavior, so it builds more connectedness. People know, it’s ok to say I need help. It’s ok to say I’m having a challenge. It’s ok to share your interest and who you are as a human being, because that’s the missing piece. At the watercooler, in-person, you’re sitting there taking a few minutes of a break and talking.

Reisz: For our program committee, we have six leaders across software, some from Google, that meet every week, to talk about who’s going to be the track host, who are speakers, and recommend all these things that go for QCon. We do exactly that. It starts off with a check-in or work. It’s just about building that connectedness as this virtual team is coming together for that next hour to be able to do some work. Then we end with a checkout. Really, you can feel the difference of that cohesion that you talk about in a team like that, and you don’t do that, you just come in and check in and you go off to your next thing. That’s absolutely a great callout to talk about.

I’m going to fast forward over to Tuckman’s Stages of Group Development, because I’ve referenced that every single week in some aspect of what I do. You made a comment when you were talking about performing. You said, feed that team cohesion. I think you talked a little bit about it here with some of the interconnectedness. What are some ways particularly when you have this high performing team that you can keep it high performing? What are some ways that you do, that Google does to maintain high performing teams?

Davis: I think a crucial part of maintaining a high performing team is making sure people are taking enough time off away from work. You have to think about not working just as much. I’m always checking to make sure like, when is the last time? Burnout isn’t just solved by taking time off. What you want to avoid in a high performing team is people burning out. You want to keep them. It’s like a good motor running. Another part of it is checking in with the quality of the work, not the quality of the outcomes, but the quality that the person is experiencing. Are they still connected to the work? Is the work still important to them? What’s motivating them to do these things? All those initial things of like getting to know people, you continue to get to know them. Because people evolve. It’s not like you’re the static person. I’m not who I was 10 years ago. It’s like, I’m a new person.

Also, reward people. Rewards are very personal. People like different things. Money, of course, is always good, but also acknowledgement. Saying the thing out loud. We have some fantastic training about this at Google about making sure to recognize people, but not just that this was successful, but this was successful because this person, what is the specific thing that they did that was amazing? I also encourage a gratitude culture. When I first introduced this in my team, some people were a little bit like, why are people saying thank you for doing their job? What is the value there? Over time, it’s just a little bit of easement of, it just adds a little bit of that positivity to the positivity spiral that you want for a high performing team. It’s not just, you’re just doing a thing. It was also that subtle, how you did it. How you did it makes a difference.

Reisz: There’s a lot to unpack right there with your response there. Daniel Pink’s autonomy, purpose, and mastery, being able to reiterate, a high performing team, make sure all those things are in play.

Really recognizing people in a way that’s personal to them, is that just getting to know them, and then surfacing those things? Like you said, there’s some great training at Google, what does that look like?

Davis: For me, it’s really clear and specific, and it’s timely. Say, a person accomplished something. One of the people on my team led a cross organizational effort recently. A very large undertaking that was across the org, not just within DevRel, but also within our libraries team. The goal was, bring our samples that were in these other libraries into this sample collection, make sure that they were all within the different languages. It was a big undertaking. It was like 170-plus repositories that touched. Assessing the samples, whether they were needing to be done. Then, coordinating this group of 40 people to execute on this. This is not just my team, but enabling him throughout this time, he is now enabled to do and lead in this way. In recognizing the impact, sending out emails. Making sure all the people know explicitly, because any one person in this effort would have seen one slice of his leadership. One part of it. One of the outcomes. The outcome isn’t just, we moved all these samples over. We actually figured out there was a problem, researched it, identified it, brought it attention. Worked with all these teams to come to a collaborative, cohesive consensus of how we’re going to approach this problem. Then, coordinate and execute on all of this with the various individuals. The recognition piece, crucial to make sure and inform all the people so they can also chime in and say, I really appreciated this as well. It also makes them aware of the larger effort and what the person actually did.

Reisz: Just hearing you talk about it, you can just feel the celebrating the wins in the way you describe it.

You talked about learning adaptability. There’s a lot in there that I thought was great, too, the ADRs or decision records. Those are so important. It’s like one of the first things we always seem to forget. How do you really get everyone to like, seems like we just made a decision that someone else may need to know if they’re coming and looking at the repo. How do you make sure you hold each other accountable to make sure you’re capturing these ADRs or decision records?

Davis: We do it at the start. It’s an evolving practice. It’s hard, because like, how do you know what thing to document. I think there’s a lot of guidance informing. The way we thought about as some of the open source agencies and how they think about and document RFCs. It’s so crucial, for us, at the core of what we are in DevRel, it’s not just like we’re solving a problem. We’re solving a problem, and then showing people the way. We want to help people understand. How do you do that? You have to let go of this idea that every decision you made is the perfect right decision forever. That’s where you start from, like, we know we’re making this decision for now. If we document it, we’ll know why we made this, and then how we can change it in the future, or what might be a trigger. It’s been so helpful for us in just even not backtracking and repeating ourselves, which I’ve seen in so many different projects. Like, we did this thing, and then we did this thing. We came back to that thing but we forgot all this context.

Reisz: Do you keep them in Git as well, or in version control so you have the version that can be, this was the previous decision, you see the new version?

Davis: Yes. You can go check it out. It’s a fantastic way, just a pattern if you want to copy it, of just like, here’s how we decided this. Not all decision records are super wordy. Some are just like, we decided this thing just with the brief context that we had. Sometimes it doesn’t matter. That was enough.

Reisz: Yes, I like it. Because again, you look at a code base. You see the decisions that were made, helps you come up to context. You weren’t there for all those decisions so it helps you gain that context of why things are the way they are.

You talked a little bit about friction logs, could you double click a little bit? What is a friction log, and how did you leverage them?

Davis: Friction logs are amazing. It’s basically exploratory testing, but with an explicit intention in mind, like you know you want to do this thing, but you don’t really know how to do it. You take on this zeroth hat and say, “I’m a customer, I’m trying to do this. What do I do?” Usually, the first thing anybody’s going to do, if they don’t know about something, is Google it. We start out. There are tools that you can just record what your actions are, as well. It’s really helpful to pair on this because writing and doing the thing can sometimes take a little bit of extra cognitive ability. What you’re doing is you’re documenting what you tried, writing it up, and then exploring, like how hard its friction log, because how hard was this thing to do? In your Google search, did you find the right thing that you wanted to do? Was it obvious? One of the ones we did last year was, how do you do a static site on serverless? What are your options? It uncovers a lot of the hidden debt that we don’t think about. If you were planning a particular platform, you’re focused on that platform, you might not be thinking about the broader picture. It helps people learn and explore things, and also uncover improvements that we can make.

Reisz: This goes back to when you were talking about making sure that you address learning and make sure learning’s a part of the culture, and that you reserve time for it. Google’s a big company, you’ve got a lot of resources, particularly in mid-size to smaller companies, how do you think about as a leader, making sure everyone has the space for learning?

Davis: For me, the very first thing is I budget from a team capacity perspective. Individuals, I take away a certain amount of time, and just like that’s learning. I also put it in my OKRs. Those are the key results that we want to see from the team that we’re doing learning, and we’re doing exploring, and we’re doing sharing. Also, part of just being the nature of DevRel, you always have to be learning. There’s the industry trends, what is happening? One of the challenges I find is, how do we understand collectively what the team knows? That’s a really big problem. I’ve been thinking about what tools, shared docs that we can have, because you don’t really, always know what it is that you know as a team. There’s no way to audit.

I am definitely not going to prescribe testing or checking, do people learn? You have to make space for it. You have to create opportunities. I’ve had some great discussions with John Allspaw, about, you don’t know what anybody’s learned. I created this presentation. I shared it with the world. I don’t know what each and every one of you have learned from it. Different things are going to be takeaways from you. Same thing for my teams. I always need to be checking, rephrasing, and feedback, but also repeating things that I think are important. Checking to make sure what I’ve said is there. In terms of overall learning, I’m not checking for it. I’m making space for it.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Transcript

Sunderland: I’m excited to be giving this talk as a part of the hybrid work track because I’ve been working in a remote and hybrid environment for the last 10 years, so I have many lessons, thoughts, insights, mistakes that I’ve made. My name is Alexandra Sunderland. I’m a senior engineering manager at the meeting management and productivity platform, Fellow.app. I’m also the author of the new book, “Remote Engineering Management,” where I do talk about one-on-ones and a bunch of other things related to remote management as well.

Why I Care About One-On-Ones

I want to start off by talking about why I care about one-on-ones so much, why this is something I decided to give a talk about. Really, what it boils down to is one-on-ones are the most important meeting that you can have with your direct report. At the same time, they’re also the most misunderstood type of meeting. They’re so critical, because they’re the time where you help your direct report grow in their career. You build trust. You build the foundation of a relationship that’s so important for everything else that you do at work, and has a big impact on their happiness. This goes all the way back to when I was an engineer starting out with my first one-on-ones with my manager. I remember I wasn’t told what the purpose of them was. I didn’t understand what sorts of topics we were supposed to be talking about. What ended up happening is that we would spend this time every week talking about what we were up to on the weekend, and what we were going to have for lunch. We weren’t making the best use of the time together. I really want to make sure that everybody fully understands why they’re important and how to make use of them in hybrid workplaces too.

Outline

The things that I want to cover include how to take advantage of that uniqueness of being in a hybrid and remote workspace when it comes to one-on-ones, because it might seem a little trickier to do one-on-ones when you’re not seeing people in person. I actually think that remote one-on-ones are a little bit better than in-person one-on-ones. I want to talk about the purpose of one-on-ones, why we have them. How to have great one-on-ones, which is the most important thing here, just making sure that we’re making the most of the time together in those meetings. Then we’re going to end off with some types of one-on-ones that you might have, because there’s more than just the typical manager, direct report type of one-on-one. Then, also, how to troubleshoot some of the most common issues and points of resistance that you might have when you’re setting these up.

One-On-Ones Are Important in Hybrid Work

I think that one-on-ones are very important no matter where you’re working in, but especially in hybrid work. The reason for that is that if you are doing hybrid, most likely, there are going to be some people on the team who are working in the office, some people who are working remotely. There’s not going to be a very equal balance between how often you see everyone in person versus over a video call. That imbalance can really play out in interesting ways, especially when it comes to giving feedback and career progression and understanding the value that people are bringing to the team. Because people can tend to overvalue the things that they’re seeing in person and the interactions they’re experiencing in real life. I think that one-on-ones and hybrid work are especially important because it levels the playing field a little bit. It gives you a chance to talk with everyone on the team, understand what they’re up to, and get dedicated face time with everyone, no matter whether they’re working remotely and you’re in the office, or whatever the situation is.

Why Remote One-On-Ones Are Great

Whether you’re working remotely from home or working in an office and having one-on-ones over video calls with people who are themselves working remotely, I actually think that remote one-on-ones are the type of one-on-ones that are the best to have. There are a few reasons for that, a little bit controversial. I think that remote one-on-ones bring a lot of value to them. For example, if you’re doing them from home, then you get to be in your own environment. I, for example, love sitting on my chair with my legs crossed, with a blanket and a mug of tea, and I might be fidgeting with whatever is on my desk. It’s not going to look that good if I’m doing that at the office in person, having a one-on-one with someone. I get to do that in the privacy of my own home where they can only see my face and they don’t get to see all of that stuff. Because I feel more comfortable, it’s easier to talk about things going on. It’s easier to give real feedback.

The other issue I’ve noticed now that I’m working a little bit more hybrid in the office is that you have a lot of privacy when you’re in your own home, maybe not with other people who are living in your home, but privacy from your coworkers. One of the difficulties I’ve run into is when I’m having a one-on-one in the office, I find sometimes you don’t know how thin the walls are and you have to start whispering if there’s something really delicate coming up. If you’re in your own house, that doesn’t matter, you can be as loud as you need to be. Another benefit that I feel makes it a lot easier to have difficult conversations is that you don’t feel like you’re forced to maintain any eye contact with someone. When they’re on the screen, you can look at the screen, you can look around the room, and it doesn’t feel very awkward. If you’re in a room with someone, and they’re looking at you in your eyes and you’re glancing around the room, it might feel a little bit stressful. I find that not having to maintain that eye contact makes it much easier to talk about some difficult things.

What Makes for A Great One-On-One?

What makes for a great one-on-one? Before getting to that, we have to understand the purpose of one-on-ones. At its core, the main purpose of one-on-ones is really to build trust between you and your team members. Building trust is so important because it means that it’s easier to give each other feedback and talk about really difficult things when they come up. Building trust and creating this really great relationship as a foundation for everything makes everything about work so much easier. It’s so much easier to collaborate and be honest with each other. One-on-ones are also great spaces to create alignment on things like company or personal goals and vision. Give and receive feedback about anything that is constructive and helps people grow, something you definitely want to do in private and not in public with other team members around. It’s also a really great space to talk about anything that either of you want, so ideas, blockers, questions. The nice thing about it is that if you have one-on-ones that are set up recurring, so you always know when the next one is going to be, you get to put the topics that you want to talk about, any questions or things that come up throughout the week. You get to save those for the one-on-one and have a whole bunch of discussions at once that happen there.

There are a few things that I look out for to know whether my one-on-ones are going well. One of them, the most important one is really that both people are coming to the one-on-ones prepared with things that they want to talk about. Because if you don’t do that, you’re probably going to end up in a situation similar to me when I started out where you talk about your weekend and what you’re going to have for lunch and things like that. That’s not a good use of anyone’s time. Both people knowing what they want to talk about and having specific things is a really good sign that they are taking the one-on-one seriously, and that it is a good use of everyone’s time. Another big thing though, it’s not enough to just bring topics, it’s really important that the things you’re talking about lead to deep, actual conversations. Bringing in questions saying something that just requires a very short answer, that’s not a real topic. You want to do things like make sure that there are actual conversations being had, opinions being shared, discussions going on, and really diving into topics very deeply, because that is a sign of a great one-on-one.

How to Structure Hybrid One-on-Ones

How do you actually structure a hybrid one-on-one? There are three main parts to this: timing, location, and topics. These three things are the things that differ a little bit between remote, hybrid, and in-person one-on-ones. The first thing I want to talk about here is timing. There are two main components to how to structure your one-on-one with timing. That’s both the time of day that it’s been scheduled for and the length and frequency at which it happens. Time of day. I’m sure at this point, we’re all aware of time zones. Another main thing though, is this whole manager versus maker schedule, where throwing a meeting onto a manager’s calendar, no big deal because our time is meant to be interrupted and refined with all those little meetings happening all the time. Makers, though, engineers, need many long blocks of uninterrupted time to get work and deep focused on writing code. Throwing a one-on-one right into the middle of a big block of uninterrupted time that they have is not good, because it’s going to break that flow state, and then they’ll be less productive than they like to be. That’s something to be aware of.

One of my favorite tips, though, is to avoid scheduling one-on-ones on Mondays and Fridays, specifically, because those are usually the days where holidays happen. Those are the days where either meetings will just get canceled or be squished into some point in the rest of the week. One-on-ones are meetings that you don’t want to cancel very often. By avoiding having them on Mondays and Fridays, you’re less likely to have to do that. For the length and frequency, I would suggest no shorter than 30 minutes for a one-on-one. I think that this is really important because 30 minutes is the minimum time required to get into the groove of things, get comfortable, and really get deep into conversation. Then 60 minutes is the upper bound there. There’s a lot of variety in terms of how you can structure this, mixing length and frequency. At the very least, I think that 30 minutes every second week is appropriate for a lot of people. Very much depends on people’s preferences, how often they feel they need to meet, how many topics they have. I have a mix of things going on right now where some people on my team we meet for 45 minutes every second week. Some people on my team we meet for an hour every week. It fully depends, and there’s no one exact right way other than at the very least, 30 minutes biweekly.

Location for hybrid meetings is definitely an interesting one and a little bit more tricky, because for a hybrid one-on-one, does it mean that you are together in person at the office by chance? Are you both remote? Is one of you in the office and the others at home? What does that really mean? For the purposes of this, though, what I’ve found is that having a good mix of both in-person and remote one-on-ones for the same person is really good at getting a variety of topics to come out and a variety of ways of talking. For example, I’m more comfortable talking to people remotely because of not having to make that eye contact, getting to cozy up with my blanket and everything. Some people on my team are more comfortable talking in-person, because that’s where it’s easier to open up, and chat about things. I like catering to both of us so that we’re able to have different types of discussions.

In terms of options, though, I think that there’s so much more than just the default that we’re used to, which are video calls and meeting rooms. For virtual calls, you can do voice only calls and not turn on your video. That sometimes also makes it easier to talk about certain topics when you don’t see the person and you get to really focus on what it is that you’re saying. In-person, meeting rooms are fine. I do find it a little bit awkward standing up from your desks at the same time and walking over and closing the door and sitting down and facing each other to talk. I really enjoy going for a walk outside, which also has a lot of those benefits of voice only calls because you’re not staring at each other. You’re facing forward. You have fresh air, new sounds, new sights. It makes things different. It can make it easier to talk about things. It can bring new ideas as well. In general, in hybrid, though, what I really appreciate about this way of working is being able to mix up all those options. I love doing a meeting room one week, a video call the next week, it just creates so much more balance between how people work.

In terms of topics, we’re going to talk a lot about different things that should be brought up in one-on-one’s, ideas for how to make the most of the time together. There are some topics that I think are very specific to hybrid work that should be brought up at least periodically to make sure that things are going well, because hybrid is very tricky. We want to make sure as much as possible that there isn’t this like us versus them for people who spend most of the time in their office versus people who are remote. Because there’s always going to be a feeling of, people who are working remotely feeling like they’re missing out on conversations happening in the office, even if that’s not actually happening. We want to get ahead of that and make sure that there’s a lot of discussion happening around how people are feeling about that. Things like asking how connected they are with the rest of the team, is really good. Ideas on how to better collaborate between people who are in the office and people who are remote. Also, just giving them the chance to ask, is there something that happened in the office that I missed out on? That kind of thing. Even if the answer is like, no, you didn’t miss it, or we posted the conversation here, or whenever we started talking about this, we invited everyone to join in on a call. Stuff like that is really good to reassure people that they’re not missing out on things that are happening.

Also, very importantly, I’m a big fan of asynchronous communication. Focusing on things like recording videos and sending those back and forth, or writing things down, commenting, sending documents. Anything like that, where you’re not required to be collaborating on something at the same time. Big fan of that. Makes remote and hybrid work so much better. Anytime someone has an idea of how to improve that, or even what processes or meetings could be moved asynchronous, that’s something that’s really important to talk about in one-on-ones as well. Outside of those hybrid specific topics, there are also many things that should be talked about on a regular basis, in one-on-ones too. For example, anything around career progression. How they could grow in their role, feedback about what they’re doing really well but they could be doing better. Coaching them through new areas that they’re learning. I really love to ask people opinions on things like, what could we be doing to improve the team? What do you want to work on next quarter? What ideas do you have for the company? What do you want to work on? Then, also, thoughts on like, what did you think of that recent announcement that happened? Or, how do you feel about this change that we’ve made? Things like that. People aren’t going to bring up their opinions necessarily in team meetings, but if you ask them specifically about it, they probably have something really valuable to say, and that will lead to really big important discussions.

Importance of a Shared Meeting Agenda

Once you have those one-on-ones set up with the timing, the location, and you start to put some thought into the first few topics, the next most important thing to do is have a shared meeting agenda. I know that some people are big fans of having agendas for one-on-ones that are written by hand in notebooks, or stored on their computers, only accessible to them. I don’t think that’s quite good enough. It’s a great start, but I really think that there’s so much value in having the agenda shared with other people, ahead of time, and collaborating on it together. Not just letting them know a few minutes before, what topics you want to talk about. The biggest value that I personally get out of having a shared meeting agenda, where we’re collaborating together, is that it gives the other person or me in particular, more time to think about the topic and how I want to respond. I’m the type of person where if you ask me something, spur of the moment, what my opinion is, I’m not going to have a very good answer. I need at least a few minutes to go and think about what it is that I want to say. In one-on-ones, if somebody has written ahead of time, “I want to talk about how to progress to the next level of my career.” I’m going to have a much more thought-out and useful answer, if I know that ahead of time that you want to talk about that, and get to put some thought into it so that by the time we’re going into that conversation, I know exactly what I want to say and we can talk based on that answer. We get much deeper discussions based on that.

Also, because we have the shared agenda, there’s this historical record that’s shared about the types of things that we talked about. It makes sure that we have alignment on decisions that were made. Because if I type out, maybe you did ask, how to get to the next level in your career, and I write out some answers. You being able to see those answers means that if I wrote something incorrect, you’ll know that there was a misunderstanding, and we’ll be able to correct each other right then and there. Which is always better than finding out later on that you weren’t aligned on what it was that you actually talked about. Shared agendas are also great because it shows the other person that you value their time. It shows that you’re putting effort into the time you’re going to spend together. It also allows for this thing called batch communication. Instead of me bugging my manager 20 times a day with the many things that I want to talk about and creating a lot of distractions for him, I’ll put those 20 things every day into our shared meeting agenda, where we will get to talk about those things all in one batch. I know that he has an hour dedicated, just talking with me about the things I want to chat about. That makes better use of both of our time, so we’re not constantly interrupting each other.

Having a shared meeting agenda is a very good first step, but there are some key things that make it go from good to great. The first one is that it’s actually collaboratively set by both parties, because it’s no fun if only one person is ever contributing topics to the agenda, or if there’s only one person contributing and then the other person doesn’t even read them until the meeting actually starts. That’s just not very collaborative, kind of defeats the purpose of it. Making sure that both people are really on top of adding topics and checking the note throughout the week before the meeting happens is very important, and a sign of a great agenda in a one-on-one setup. I also really like having headings within the note that are recurring, that aren’t super prescriptive about exactly what should be talked about, but still get people thinking. For example, instead of just having a blank note every single time, which is a little bit daunting, it might be nice to have something like a section that’s just called feedback. That gets people thinking throughout the week, what feedback do I have that I could add to that meeting note? It’s a great way of guiding your thinking and creating topics without specifically saying, you have to add feedback to this, or what feedback do you have for me?

I think it’s also very important to order topics by importance in the note, because you want to make sure in the limited time that you have together that you hit the most important things first. If there’s anything smaller that maybe doesn’t even have to be talked about out loud together, it could be done at the very end of the meeting. What I like to do is have a to-do asynchronously section. Topics that go there are ones that are still important to need discussing, or answers to them. They could be resolved by writing in the notes or chatting on Slack, or whatever it is, afterwards, and don’t necessarily need to be talked about during the meeting when there are other things to go over.

On top of having meeting agendas, which is the list of things that you’re going to talk about. There are also meeting notes, which is the historical record of what it is that you did talk about and the decisions that were made. Lots of distinguishing things here about what makes notes really great. The main one here is also same as with the agenda, that they’re written collaboratively, because it’s no fun where it’s always the one person writing all the notes because it’s hard to talk when you’re writing notes for things. That goes for one-on-ones, and any type of meeting really. You want to make sure that people are taking turns writing notes, doing it collaboratively, and not just always pushing it off to the same person to do that. They shouldn’t be writing down absolutely everything that’s being said. The meeting note shouldn’t be a transcript of the call. If you want to do that, then recording calls is much more efficient. They should capture the key points, so decisions made and ideas that people had so that it’s enough information to jog your memory about what the conversation was about and any outcomes from that.

The one exception that I have to writing key points instead of entire conversations when it comes to one-on-ones is when it has to do with feedback that I’m giving. Any time I’m giving either positive or constructive feedback, this is valid for both, I like to deliver that verbally with people on a call and talk about it there. Then I know that I personally, I absorb information much better when I see it in writing. My memory sometimes fails me, so I like having a historical record to go back to, for anything that’s discussed. For feedback, in particular, especially if there’s anything related to outcomes people have decided on, steps that you’re going to take or are expecting for people to get better and level up, it’s really important to have that written down in the notes so that they can absorb it verbally, when they hear it directly from you. Then refer back to it as well, so that you aren’t having any misunderstandings between what people are remembering.

Types of One-on-Ones

Next, I want to talk about some of the types of one-on-ones that you’ll probably have, because not every one-on-one is equal, not every one-on-one has the same structure. There’s some that have a very particular connotation to them, and also require discussing some things. First one that you’re probably going to encounter is the first one-on-one. Whether this is somebody who is new to the company, or just new to your team, the first one-on-one that you have with someone on your team is going to be very special. In that first one-on-one, some of the core things that you’re going to be doing are getting to know each other, both on a personal level, outside of work, learning about hobbies and stuff, but also learning about each other and how you work. There’s a lot of setting expectations on both sides about how you expect them to be working, and what sorts of things they’re expecting from you, as a manager. Lots of context going on here. This is also an important one-on-one because it sets the tone for how the rest of the one-on-ones that you have together are going to be run. If you show up to this first one-on-one, and there’s no agenda, no set of topics, it’s just all up in the air, then that makes it seem like the rest of them are going to be run like that, too. If you come to these one-on-ones prepared with a collaborative agenda, ready to go, take meeting notes during the one-on-one, then that’s setting them up to understand what it’s going to be like to have these one-on-ones and puts them in the right mindset for doing those same things as well.

Specifically, some of the topics that I really like to cover in these first one-on-ones include hobbies and life outside of work, because social things are super important for building trust between people. You spend so much of your time together with people that you work with, so why not get to know them as humans too. Making sure that expectations on both sides match, very important that this is double-sided, and not just setting up your expectations for them. I like to ask some specific things, like how they like to receive feedback or praise. Because, for example, not everybody likes getting public shout-outs where you’re saying, “Great job, this person, for doing this thing,” and they prefer to receive that in private. That’s a really important thing to know, before you start doing it publicly. I also like to ask how they like to communicate, because some people really prefer communicating over Slack, just having quick written back and forth. Then others like having video calls and are better communicators that way. That’s very good to know ahead of time.

Hybrid-specific, understanding their balance of remote versus office work, probably going to be very dependent on the company and the setup that you have. That sounds like something very important to understand as well, and to share how others in the team are doing that as well. Lastly, I really like ending the call, or the in-person meeting, or whatever it is, with understanding how I can be the best manager possible for them, and understanding what value they like to get out of one-on-ones. What specific things I can do to make sure that they’re happy at work going in their career and doing well. There are so many other things that could be asked and I linked inside to a blog post by Lara Hogan, https://larahogan.me/blog/first-one-on-one-questions/, with just a whole bunch of questions for first one-on-ones. It’s a really good resource to check out.

The next type of one-on-one that you’ll probably have is the feedback one-on-one. The feedback one-on-one isn’t necessarily an entire one-on-one dedicated to just feedback. Feedback is obviously something that should be talked about in other one-on-ones as well, just as a regular thing whenever you have feedback, sharing that with people. Once in a while, there are one-on-ones, for example, if you do a quarterly review, end-of-year review, whatever it is, there’s usually some formal review performance process. Those meetings where you talk about that, I think should really happen in one-on-ones. Because one-on-ones hopefully by the time you’re getting to this place are spaces where you build trust with people on your team, and they’re nice, safe spaces to talk about what’s on your mind without fear of repercussion. For feedback one-on-ones, if you schedule an entire separate meeting that’s just called like performance review, or something like that. That makes that meeting scary and it’s not that same regular space at the same date and same time as people are used to for the normal one-on-ones. It gives a bit of a different air to it and might make people feel a little bit more on guard. I really love doing feedback one-on-ones in the normal one-on-one recurring cadence.

Hybrid one-on-ones actually do have a bit of a key twist to them as well. For example, if you’re working mostly in the office with other people, and there are remote people who don’t come into the office, very often, you might see their work and view their contributions differently, because you’ll be physically exposed to the other people and seeing the things that they’re doing. While the work that the remote people are doing might be a little bit more hidden and might be happening in channels that you don’t have access to, or you don’t check very often, and people might be doing things that are very important, but you don’t know. It’s possible that feedback that’s being given, is skewed more favorably towards people that you work in person with. One of the ways around this that I found I really love doing is, in my one-on-ones in every agenda, automatically gets added this one heading that says, “What have you done in the last week that I do not know about, or I probably don’t know about?” This is giving people permission to brag about things that they’ve done that I wasn’t involved in. Because I’ve found when I was even working just fully remotely with everyone on the team, there were things that people were doing that I wouldn’t find out about until the year-end review process when their peers would write, “I admire that this person is doing all of this work.” I would have no idea. It’s not through any fault of my own, it would be happening in channels that I wasn’t a part of.

I found that giving people this explicit expectation for them to brag to me about the things they’re doing, really make sure that that stuff comes to light and isn’t getting hidden. That starts to level the playing field a little bit more when it comes to giving people feedback and understanding what they’re doing, and helping them grow in their careers. Another aspect to this as well is that hybrid one-on-ones are very important to continue doing, because if you have people on the team who are working fully remotely, then you need to make sure you have these one-on-ones so that you’re building up trust with them and getting to know them, and spending that dedicated time alone with them. Because it’s really hard to give people constructive feedback if you don’t have that foundation of trust already. Having that trust is going to make that feedback hit very differently. I really think that having recurring one-on-ones with everybody makes things better.

The next type of one-on-one you might have is a coaching one-on-one. Coaching is a very specific thing, which is when you’re helping someone develop a new skill and maybe showing them the ropes and making sure they understand how to do it, and answering any questions when they run into blockers. It also involves actively checking in with them and making sure that they’re progressing, and seeing if they need help with anything. This is a really good thing to do to help people grow and learn new skills. It’s also something that can be difficult to do unless you have recurring check-ins where you can see how people are doing, because otherwise, both parties have to remember to talk about it with the other person, and it can add yet another meeting to calendar. I love using one-on-ones as this specific time slot, where coaching is one of the topics that comes up and we can talk through whatever it is that people are learning about. It’s a really good way of staying on top of that and not letting it fall through the cracks.

The next type is a social one-on-one. There’s a lot of advice online that says that one-on-ones should always be work related and work topics. I know that, at the start, I was also saying that it’s very important to not just go into meetings and say like, how was your weekend? What are you eating for your lunch? I do agree with that in principle, but I think that there’s a really good balance to be had of having productive one-on-ones where you are talking about very work related topics with the start of social time built into them. It’s perfectly fine to also have entire one-on-ones where you’re just talking about your personal life, your family, your hobbies, and things like that. It’s not for everyone, not everyone likes to talk about their personal lives with people at work and likes to keep a little bit more of that separation. I don’t think it’s something that should be forced if people are uncomfortable with it. All I have to say on this is that I do think that it is ok to have entire one-on-ones where you are just talking about this, as long as it’s not the norm.

After that, peer one-on-ones are also something that are very common for managers to have with each other. As a manager, your team is just the engineers who are on your team and report to you. The people that you work with directly cross-functionally are your immediate teams, so your peers. For example, for me, that would be head of design, head of customer success, head of marketing, and all these people who lead these other functions in the business. They’re the ones that I have to collaborate with so that we can make sure that projects are getting done and that everybody knows what’s going on. It’s very important to have dedicated time with all of those people so that you can talk about things, like what your priorities are. As an engineering manager, it helps me so much to understand what would be helpful for the sales team, or what kinds of issues the customer success teams were running into that the engineers can help solve. Things like current priorities. Things that we could do in the future to collaborate, or projects that are coming up that we might need to focus on and work together on. Also, just how we can work better together. There are so many things there that are important, because the better you collaborate with the cross-functional leaders that you work with directly, the better the members of each of your teams will work together as well.

Troubleshooting Common One-On-One Issues

There are a few common issues that happen to pop up pretty often with one-on-ones. I know, I’ve definitely run into my fair share of issues over the years, and I want to address a few of them, to make sure everyone understands how to avoid them, or how to fix these. The first one, and probably one of the most common ones is that people are a little bit resistant to having one-on-ones in the first place. I’ve definitely run into this where maybe somebody at a previous company didn’t have a very good time with one-on-ones because they weren’t useful, didn’t really get anything out of them. They felt like a waste of time. They think that all one-on-ones are going to be like that. When you try to set them up with them, they are a little hesitant to actually follow through with them. Maybe they’ll say something like, “We don’t have to have one-on-ones. I’ll let you know if there’s anything I want to talk about. We’ll chat then.” Which I don’t think is quite the right way of going about creating that trust and that relationship with them.

There are certain ways that you can try to fix this issue. The most valuable one really to understand is making sure that they understand the purpose of one-on-ones, because that’s often something that just hasn’t been communicated to them. Same as when I started one-on-ones, and I was never told why we were having them. I think that if they understand the value that they could be getting out of them and the types of things that should be discussed, then that will go a long way towards creating the willingness to go through with them. I recommend even just having like a go-to document saying this is why we’re doing it that you can share with anybody new who joins the team. Another thing you can do is if you have weekly one-on-ones with everyone on your team, maybe don’t start with weekly with them and start instead with biweekly. Because when you have a biweekly cadence, because there are two weeks that elapse between every time you have these meetings, there’s just more stuff that accumulates that you could be talking about. The one-on-ones that you do have might be a little bit more dense, and dense with topics. If you’re talking a lot during these, then it will seem more valuable than even if it’s the same number of topics, but spread out across two different meetings.

Also, very important is for the first few agendas, you might have to put a little bit more effort into adding most of the topics to them. Especially if they aren’t really bought into the concept of one-on-ones, you’re going to have to add topics that solicit ideas from them, solicit opinions, and really get the conversation going so that you’re not sitting there awkwardly on the call just waiting for the time to run up. I recommend also asking a lot of questions when you do that. Write a lot of notes to demonstrate to them. It’s a very good visual way of understanding like, we did talk about a lot, and this was a good use of our time. Those notes are things that are very good to refer back to later on. For example, if you ask someone, what do you think about this process, and they tell you what they think and they have an idea for making it better. Then coming back to them at the next one-on-one saying like, “Your idea was great. We went and implemented it. Here you go. This is how things are better now because of that conversation we had,” which might not have happened outside of a one-on-one. That’s going to show immediate actionable value that has happened from this one-on-one, and will increase buy-in.

The next very common one as well. Even if people are bought into the idea of having one-on-ones and agree that they should happen and understand their value, they still might come to them and say, I actually don’t have anything to talk about. On the same page, as with the last issue, a really good way of going about solving this is by asking a lot of open-ended questions that solicit their opinion on things. I really like to have a set of questions every week that I can always fall back to even if there are topics that are added to the agenda, and we happen to run through them really quickly. I really like asking things like, what did you think of the announcement that the company made last week? Or, what do you think that the product and engineering team could be doing better to increase collaboration? Just open-ended questions where many opinions are possible, there’s no wrong or right answer. Those types of things will get people talking, and it will make them feel good that you’re asking them their thoughts as well because everyone likes to feel heard. Earlier, I mentioned how one-on-ones could also be used as a good time for coaching. This is a great use case for it too, where if there’s nothing that people are really talking about, you can come up with a career goal with them, or something they want to learn, some new skill, and use the one-on-one time to work towards that goal. Ask them questions, see how they’re progressing, and see if they need any help with building up that new muscle. This is a really good time to spend doing that.

The next issue, emotional overload. This is actually an issue that I don’t have a terrific solution for. I just wanted to call it out specifically as something that happens, to point out that you’re not alone if this does happen. It is very difficult as a people manager, because people share very awful things that are happening in their lives and very happy things that are happening in their lives, too, which is great. It’s very difficult in one-on-ones to go through this emotional whiplash, where you’re hearing about really awful things that you can’t solve in their personal lives, which is very hard when we’re used to solving things for them at work. It’s hard going from hearing something very sad in one call to maybe going and seeing someone in-person talking about something super happy, and having to react appropriately in both situations while trying to internalize what’s going on. I don’t have any great solutions for that. It is difficult.

Another thing that I hear often is that people in senior positions don’t need one-on-ones. I don’t believe that this is true. I think that it is true that people who are in senior positions won’t necessarily need as much day-to-day support in their jobs. Maybe they don’t need as much face time with their manager for understanding how to deploy code, how to write certain things, how to go about working together. They still do need a lot of support in terms of making sure that their feedback is heard, asking them for their opinions, giving them context. Making sure they’re aligned. Helping them progress in their career. There’s so much about one-on-ones that isn’t related to helping people directly with questions that they have about their job. I don’t think that senior people should be left out of that, because it’s very important to continue spending time in developing the careers of people who are doing really well.

The last issue is something that is a little bit more hidden. It’s something that I started to discover a little bit more recently, but differences in cultural expectations. I read this book a while ago called, “The Culture Map,” by Erin Meyer. It talks about how different cultures have different ingrained views about things like how to communicate. What actually is effective communication? How to go about making decisions. Who should make decisions? What the manager’s role is. Especially, in a hybrid and remote environment, teams are very often made up of people from all around the world. At one point, my team, every single person on the team was from a different country. That means that there are very different opinions on how things should be done. The best way of addressing this and making sure that everyone’s on the same page is to create a common team culture and have that written down for many key aspects so that everyone knows what’s expected of them specifically. I do recommend reading the book to get the full picture, because it’s very interesting, what types of things come into play when you look at culture.

How to Get Started

If you’re brand new to one-on-ones, and you’re starting them out for the first time, or you want a bit of a reset on them and realign expectations with everyone, here’s what you should do to get started. Number one thing is, communicate the purpose of the one-on-ones. Make sure that everyone’s on the same page and understands that. Say it verbally. Write it down. Just make sure that people truly understand why you’re doing these. Also understand for yourself, why you’re doing them, because it’s one thing to have people understand what value they can get out of them. It’s also very important for you to know why you want to do them so that you have your own list of topics and goals in them, and ways that you might want to guide the conversation so that you’re making the most out of them with your team as well. After scheduling them, make sure that you’re also contributing to the agenda collaboratively with them, not just having your direct reports constantly come up with the agenda entirely on their own every single time. Add a few topics so that it kickstarts the conversation. Then, after a period of time, ask for feedback about how they could be more useful. It takes a lot of iterating to get these right. If you ask for feedback about what you could do better, what should be changed, what would make them more useful to them, you’re going to get to the ideal version of one-on-ones much faster.

How to Know if One-on-Ones are Useful

Once you’ve been having these one-on-ones for a while, you’re also going to want to know, are these actually useful? To do that, my biggest tip is just ask them, do you enjoy your one-on-ones, or do you dread the interruption? Because even if you’re not talking about work, even if you’re only having social time, every single one-on-one, if they at least enjoy that time with you, then you’re building trust and building up that relationship, which is what really makes people work better together. That’s at least a core component of the purpose of one-on-ones. If people dread the interruption and would rather focus on whatever it is they’re working on, something key is not working and you need to take a step back and reevaluate how the one-on-ones are going.

Recap

To recap everything, how to have an effective hybrid one-on-one. Number one, most important, understand their purpose and value, and communicate that purpose to your team. Make sure you have them often. Try to cancel them as little as possible. Contribute to the shared agenda, both of you, not just the direct report. Ask a ton of questions, solicit their opinion so that they feel heard. Use one-on-ones as a space for giving them feedback and providing coaching so that they can grow in their career. Most important, though, is iterate on the format. If something’s not working, don’t just stick with it and see if it gets better. Also, don’t be afraid to personalize them to each person. Different people, especially at different levels in their career, are going to require different things from you. It is perfectly ok to run one-on-ones completely differently between different members of the team. It’s nice to start off from one common format, but then don’t be afraid to iterate and personalize them.

Resources

For more information on how to build trust with your team members, have great one-on-ones, and learn more about the stuff in general, I recommend these three books, which are amazing: “The Making of a Manager,” “Resilient Management,” and, “Effective Remote Work.” My book, “Remote Engineering Management,” is also now available wherever you buy books.

Questions and Answers

Stanier: Could you elaborate on how to get better feedback from one-on-ones, when my manager is not involved with the team’s day-to-day activity? It’s a very common thing. What I often hear from a manager is, yes, everything’s fine. It’s all good. When the manager is not involved with the day-to-day team, how do you get that content in?

Sunderland: That can be so frustrating. I find, no matter what, even if your manager is involved, day-to-day with your work, just asking them point blank for feedback isn’t usually going to get very good results. What I do, because my manager also isn’t directly involved with what I do very often, is just saying, what do you think about how I approached this particular situation? Or, here’s what I’m thinking, do you agree with how I’m going to go about this? Do you have any thoughts on what I could do differently? Just being really specific about what I want feedback on, is going to make them think more about examples and be better at giving that direct feedback. Also, just letting them know that that’s something that you want, will put them on guard and make them look out for instances that they can give you feedback. I find that to be really helpful.

Stanier: Have you ever had difficulty with getting your direct reports to share their own topics in one-to-one agendas rather than you coming up with them yourself? If so, what would you do to encourage your reports to be more proactive in sharing their topics to make it less one sided?

Sunderland: Because even once you get to the one-on-one, even if you as the manager are able to come up with discussion topics and get them actually talking, it can be tricky to get them to think of adding their own topics to the agenda in the first place. My suggestion here would just be to be, make it really explicit that that’s an expectation that you have of them. Let them know that you want for them to come to every one-on-one with at least one topic and that you expect to see that written down on the agenda. That way, they’ll think about it more often. They’ll start doing that, because maybe it’s unclear that that’s really why you expected them. That’s how I normally get people to start thinking about it a bit more.

Stanier: Do you also keep private notes, or do you keep all the notes shared?

Sunderland: I keep most of my notes shared. I’m really big on transparency. I want to make sure that if I write down something about someone, they can see it so that in case I misunderstood, they’re able to correct me and make sure that I have the right information about what it is we discussed or decided. I do have some private notes, because I find my memory can be a little bit embarrassing. Sometimes, I know somebody has a dog, I’m not going to remember the dog’s name. I’ll keep a private note just so that I can look at that quickly, and remember those little facts about them, so that at the end we’re able to have more normal conversation. For things like that, private notes are great, but otherwise, I would recommend keeping everything public so that they know exactly what’s going on.

Stanier: Is it ok to ask your manager to cancel a one-on-one, if there really is nothing to talk about?

Sunderland: Yes. A lot of advice often says cancel. Even in my talk, I said cancel them as unfrequently as possible. I think that there’s always nuance in situations, there’s always room for going against the grain. I’ve canceled many one-on-ones with my manager, because sometimes I just really need the deep focus work or I just don’t feel like talking that day. I just need time to like go take a nap instead. It is definitely ok with canceling one-on-ones, no matter who you are.

Stanier: What if your manager is not interested and doesn’t put anything on the agenda?

Sunderland: You can send them my talk, and hopefully there are some ideas there about why one-on-ones are so important and why the manager does have to contribute a lot to them, as well. As a manager, your job is to be there for your team and be asking questions and be giving feedback to people, and doing all this stuff. Yes, I think communicating why it’s really important to you that you do have these conversations and what you’re hoping to get out of them, might make them understand why it’s so important to be doing these.

Stanier: I love the idea of having clear expectations to different types of one-to-ones that you have. What’s your strategy to decide what format you use for your next session? How do you draw the cards?

Sunderland: It’s not so much that I decide on my mind, this one’s going to be about coaching, and this one is going to be about feedback. Feedback may be like right now we’re at the end of the year, and so we are having actual end of year performance conversations. I like to have a cadence of when certain conversations happen. Feedback, for example, like very efficiently happens every six months at Fellow, and things like coaching and career planning, I like to do once every two months or so. Otherwise, whether it’s a social one-on-one, or you’re just asking a lot of questions, and talking about work, really depends on what’s going on in the company and the team at the time, and what kinds of topics people are bringing to agendas. The topics, or the types of one-on-ones I outlined are more so just like, buckets of topics that you can pull from. It could be a one-on-one that is an amalgamation of all of those things at once.

Stanier: You mentioned a lot of collaborative shared notes. What do you recommend for structuring your one-on-one content?

Sunderland: I work for Fellow.app. We’re a meeting management productivity software. Basically, the nice thing about Fellow is that we’re purpose built for meeting notes. We connect directly to your calendar and your meeting notes are associated with that calendar event. If you have a recurring one-on-one, all of your notes are one on top of the other, so it’s really easy to keep a history of those. You can save a template that you like. I like structuring my one-on-ones where it’s pretty much freeform, but I like asking specific questions each time, and those get automatically populated. Using even Google Docs, or Evernote, or whatever note taking tool you use, anything is better than paper and pencil, which was just shared with nobody, and only for your eyes. Anything is great. I definitely think meeting-specific tools like Fellow are really helpful for making sure that topics are remembered, that you’re getting reminders to add topics as well, and it keeps agendas and notes top of mind.

See more presentations with transcripts