team
-
🧱 The hardest things
The magic of product development appears to live in the complex things: the clever circuit design, the brilliant algorithm, the integration of many technologies. Observation suggests the opposite. Success is grounded in doing the simple thi…
-
🚣 Rowing the race you need at the end
Daniel James Brown’s The Boys in the Boat follows the University of Washington eight-oar crew that won gold in Berlin in 1936. The part that stays with me is how they rowed the middle of a race. Washington was a come-from-behind crew. Othe…
-
🧊 Why small teams have to be good at borrowing
Large and small teams differ in many ways, but one difference stands out: how much of the system gets built versus borrowed. Compared to large teams, small teams must borrow a lot more than they build. If we use the iceberg analogy, a lot m…
-
📥 Email is not a workflow
A recent meeting surfaced a problem: BOM changes in the engineering systems were not reliably reaching the production systems. “I told ’em” is how we had been doing things. We told manufacturing about the changes and handed over links to th…
-
⚡ The essence of shipping faster
In recent conversations about why development schedules slip and what to do about it, several themes continue to come up: Openness - This is key to surfacing issues early. Safety - People must feel safe being transparent and speaking up. C…
-
💡 A Simple Example
The Release First mindset starts with how you handle reasonably complex information (a procedure, technical details, etc). There are two approaches: Email or message the information. Put it in Git and send a link or PR. The first is trans…
-
🚀 Shipping faster - what are the stakes?
What do project delays cost? The obvious thing is the loss of revenue. Time is money. However, there are other less tangible consequences: Customers lose interest. Team loses motivation. Supporting organizations (vendors/communities) may n…
-
🔀 The division between group and personal workflow
When thinking about developer workflows, tools, and resources, dividing them into two categories proves useful: personal and group. A group resource is something that multiple people use (or should use): SDKs, libraries, linters, formatters…
-
📦 CDPD - Container Driven Product Development
When updating the Simple IoT documentation, the question arose - how to install mdbook and a few plugins? Of course pacman has part of what is needed. In the past cargo has been used, but that is slow and not a good fit for shared tools. Th…
-
🔄 Three levels of workflow
There are three levels of workflow: Personal (what you do to get things done) Department/Discipline (How multiple people who do the same thing get things done – Example: PCB design) Cross-functional (How people who do different jobs intera…
-
🎯 A single source of truth
An intense discussion about part/version numbers driving application logic surfaced an idea to create a simplified version of the product metadata that simplified the programming logic. However, this rarely works out long-term, because seve…
-
💬 The importance of effective communication
Recently, effective communication has been discussed. But let’s step back – why is communication so important? As developers, isn’t coding what we do? Think for a minute – how much time gets spent coding/designing vs. everything else? For m…
-
🔓 You should not be needed
An effective process, team, or organization should be able to continue on if any individual steps away for a bit, or forever. But, most people are insecure and like to be needed, so subconsciously structure things to require them to be pres…
-
🎧 Effective communication (Audio)
Effective communication requires that those receiving information from us can easily process it. I’ve been on way too many calls where you can barely hear the speaker due to echo, background noise, or other audio problems. Some things I’ve …
-
🤝 Modern product development is a collaborative endeavor
There is no way around this – even if you are a Company of One. You must collaborate with: ▶ OSS communities who provide the tools and software you use, ▶ Your customers – if you are not learning from them, you probably won’t understand and…
-
👷 Make less work for others, part 2
A few examples of how to make “less work” for others: try not to introduce bugs or break stuff communicate in workflows like Tickets/PRs where there is context and messages can be easily processed document your work – including “why” focus…
-
🛤️ Two paths
There are two paths we can follow as a team or an organization: what we do makes it easier for everyone else to do their job. what we do makes it harder for everyone else to do their job. #1 is the formula for scaling. #2 is the formula f…
-
👥 Your team as the customer
Previously we defined our “customer” as someone who derives value from what we do. While it is useful to think of how the primary business value is flowing, hopefully we are providing value to our team as well as people outside our team. So…
-
📝 Personal vs. collaborative documentation
Yesterday, we discussed the importance of a personal note-taking tool. We can also extend this concept to a team or company using Wikis, Markdown in Git, shared Google Docs, etc. Collaborative documentation is very valuable – IF you can get…
-
🤝 What happens when someone else tries to use your work?
It does not build on machine X … It does not work in scenario Y … It is hard to understand by developer Z … As developers, we naturally avoid the rough edges of whatever we are working on – it hurts. When other developers try to build/run o…