agile

The Perks of a High-Documentation, Low-Meeting Work Culture

The Perks of a High-Documentation, Low-Meeting Work Culture:

This is a culturally influential decision considering that we’re a remote-first company. We don’t see each other in passing in the office, and we don’t have lunch together. 

It may seem counterintuitive to cut down on face time if you rarely see your colleagues as it is. But it’s working for us, and there’s a few reasons why. 

Practicing meeting mindfulness allows us to free up time for other stuff that matters more. This isn’t to say that all meetings are useless — it’s just that the meetings we do have at Tremendous are meetings for a reason.

[ If you’re feeling a theme, I’m getting this right.]

20. Framing

20. Framing:

Which customer segment is affected? How valuable is this segment compared to the others? What other things are going on in the business that need our attention? You’ll sometimes see live SQL queries and people pulling up past customer research data in a framing session to answer a question or narrow down the opportunity.

The output of a framing session is a well-framed problem: something where the business says “if we can shape this into something doable and execute within X weeks, that will be meaningful to us.” There’s a commitment to spend time shaping, but not yet a commitment to go into a build cycle. That final bet still needs to be made based on how the shaping goes.

[A missing link to a great degree for many companies.]

Screen Shot 2022 03 23 at 2 00 31 PM

Iterate. Iterate. Iterate. – by David Hoang

Iterate. Iterate. Iterate. – by David Hoang:

Iteration sparks movement, which builds momentum. It’s like pedaling a bicycle on a lower gear instead of the highest. The lower gear won’t get you as far but it requires less effort to get moving. My co-worker and friend Izzy once said, “The number one way to be productive is to reduce the iteration cycle.” This is true. If you struggle with getting something creative done, reduce the iteration. Write the outline instead of the final draft, and come back to it later. Sketch out scribbles of the app design…

[I agree with the premise. But I would point out that the examples provided (outline vs final draft, scribbles vs high fidelity render) doesn’t reduce the iteration cycle. They reduce the resolution at which you are working. The *outcome* of reducing the resolution is that you can (if it makes sense) reduce the cycle time. But the two are not linked together, and shouldn’t be. There’s a time and place for both. The trick is knowing what resolution the work should be at a given stage of designing or creation. The cycle time will flow from there. ]

Congratulations! You’ve Been Fired

Congratulations! You’ve Been Fired – The New York Times:

Treating workers as if they are widgets to be used up and discarded is a central part of the revised relationship between employers and employees that techies proclaim is an innovation as important as chips and software. The model originated in Silicon Valley, but it’s spreading. Old-guard companies are hiring “growth hackers” and building “incubators,” too. They see Silicon Valley as a model of enlightenment and forward thinking, even though this “new” way of working is actually the oldest game in the world: the exploitation of labor by capital.

HubSpot was founded in 2006 in Cambridge, Mass., and went public in 2014. It’s one of those slick, fast-growing start-ups that are so much in the news these days, with the beanbag chairs and unlimited vacation — a corporate utopia where there is no need for work-life balance because work is life and life is work. Imagine a frat house mixed with a kindergarten mixed with Scientology, and you have an idea of what it’s like.

[One of the differences between sports and almost any other job, is that while you can try and reduce people to numbers, it’s often horribly shaded by the perception of others. I’ve often said that sports that requires “judges” is not a sport. It’s performed by athletes, but a sport can be measured. You hit the ball fairly or not. You ran faster than the next gal or not. And because of that ability to measure, you can apply other arithmetic solutions to the problem of “value”. That simplicity of goal and skill is why sports is so much fun for all of this. Instead of myriad shades of gray and decisions you have the clarity of simple goals and yes or no. Applying that thinking to most workplace jobs simply reduces people to… well read the article. I know folks are replaceable at a skills level, but you’re failing if you miss the human behind those skills and bringing out the best in them.

Here’s my prescription since I’ve been from one end of the US hiring economy and back.

  1. Stay out of or get out of debt
  2. Build, author, design, create things that other people want with quality and integrity.
  3. Enjoy what time you have, none of us know our allotment.

Since so many young people start off with lots of debt relative their income, I say this to the parents now (it applies to them to, but some bandwagons are hard to abandon) don’t saddle your kids with debt by allowing them to run up huge debt to start out. (and try and teach them that it’s not the Way.) Consider eliminating your own. (cars, house, business loans, venture capital, etc. the stuff that really ties you down.)]

Maker’s Schedule, Manager’s Schedule

Maker’s Schedule, Manager’s Schedule:

When you’re operating on the manager’s schedule you can do something you’d never want to do on the maker’s: you can have speculative meetings. You can meet someone just to get to know one another. If you have an empty slot in your schedule, why not? Maybe it will turn out you can help one another in some way.

Business people in Silicon Valley (and the whole world, for that matter) have speculative meetings all the time. They’re effectively free if you’re on the manager’s schedule. They’re so common that there’s distinctive language for proposing them: saying that you want to “grab coffee,” for example.

Speculative meetings are terribly costly if you’re on the maker’s schedule, though. Which puts us in something of a bind. Everyone assumes that, like other investors, we run on the manager’s schedule. So they introduce us to someone they think we ought to meet, or send us an email proposing we grab coffee. At this point we have two options, neither of them good: we can meet with them, and lose half a day’s work; or we can try to avoid meeting them, and probably offend them.

Till recently we weren’t clear in our own minds about the source of the problem. We just took it for granted that we had to either blow our schedules or offend people. But now that I’ve realized what’s going on, perhaps there’s a third option: to write something explaining the two types of schedule. Maybe eventually, if the conflict between the manager’s schedule and the maker’s schedule starts to be more widely understood, it will become less of a problem.

Those of us on the maker’s schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager’s schedule is that they understand the cost.

[Well explained. I try and line up meetings in a given day. When they can’t be aligned that way I use the middle of the day, reserving the morning and end of the day for “maker” time. Allez! ]

Better than an “email vacation”

Better than an “email vacation”:

Much like inbox bankruptcy, simply running away from email overload doesn’t solve the problem. What does work is to engage email as described in Bit Literacy (free Kindle ebook, free iBookstore ebook). To summarize: move your action items to a todo list, and archive or delete everything else. The inbox should be empty at least once a day.

[Mark’s been talking about this for as long as I’ve known him. Just do it already. You can thank me later. BTW, the email client I’ve been using for work has an setting that shows only unread mail. Very useful.]

Source: Creative Good

Rookies in the bike shed

Rookies in the bike shed:

The ability to spot this is one of the most valuable skills a software developer can possess. There are endless features we could build and debates in which we could engage, but only a small subset are worth the effort.

The best developers aren’t the ones who can write the most code in the shortest amount of time or out-reason anyone on the internets. They are the ones that only write the code that’s most valuable to execute and only enter the debates of high substance.

[And that is what makes anyone good at what they do. It is about editing things down to the most important things and concentrating on those.]