Onboard new teammates with a 90-day plan

My new boss had written up a 90-day plan for me the week before I started. This was perfect timing. I was already starting to put a bow on my current work and my focus was wandering. Now my brain could start working on ideas for the next gig. Plus, I had a much better idea of what I’d start working on and how to make an impact than I did coming out of my interviews. It was one of the better emails I’ve ever received.

It seems totally obvious that hiring managers should have a plan for new hires. Yet, in more than a decade of work and several jobs, I’d never had a 90-day plan for a new position. In the parlance of our times, a 90-day plan for new team members is one weird trick that is pretty dang easy to pull off.

For all my hires since then, I’ve written up a 90-day plan. I’m convinced that this is one of the best things a hiring manager can do to bring new people onto their team. And it’s relatively easy!

A 90-day plan for onboarding starts off with very specific tasks for the first day and week. Do the paperwork, meet the people, get your digital and/or physical workspace set up. Learn about the team’s process, the rhythm of building and delivering. Meet with a team buddy who will introduce you to folks on the team and explain all the quirks and features of how the team works.

The first 3-4 weeks of a 90-day plan, for hands-on engineers, is about working with a buddy to spin up the flywheel. The goal is to come up to speed on learning the systems and contributing to them. Get the system running on your laptop or development sandbox so you can make quick iterations and one-off experiments. Land your first code change, your first review, and your first change to production.

(My angle here is for folks building SaaS web applications, but it’s the same for any kind of developer: get a few early wins and build from there.)

The second 30 days are when new team members start to come into their own. This is when I want to help my new teammates plant the seeds to realize the potential I saw when they interviewed. Important projects start spinning up. Strategy comes into play. Now is when I re-emphasize to them the potential I saw and brainstorm how to put that special skill, innate talent, or superpower to work improving our team or outcomes.

The final 30 days should start showing evidence that my new teammate is creating good outcomes. The seed of what makes them special (and what compelled me to hire them) is planted and starting to take root. I should be able to talk to teammates and co-workers and hear about how this new person is making an impact on our work and the company’s trajectory.

After 90 days, my new teammate should feel like a productive part of the team. At every point in those first 90 days, they should see little hints that they belong with this group of individuals making a thing together. After 90 days, they should feel confident that they do in fact belong with these folks and made a great choice when they accepted our offer.

Writing a 90-day plan for new hires forces you to think through how to get them started. You won’t just throw them in the pool and say “good luck!” And, it tells your new hire that you’re a smart person who is invested in their success. Every leader should do this.

Use a tag line that means something

I like that Ember’s tagline is about ambition.

It’s easy to write an empty, temporary tagline. “Simple and good”. “Only 4 kilobytes.” It’s harder to write a tagline that generates principles which stand the test of time. “Simple and fast” are in opposition. “Only 4 kilobytes” is unlikely to last if the software evolves.

Ember logo

“Ambitious” as a tagline speaks to a number of qualities, but none of them are in conflict. An ambitious project could choose the boring tactics in favor of rapid delivery. Another ambitious project could aim for longevity. Yet another ambitious project might aim to have a large impact in the world or aim to do something previously considered implausible.

For a framework the size of Ember, that’s an appropriate diversity of goals. But they’re all covered by ambition. The tagline unifies and clarifies as much as it inspires.

Towards smaller JavaScript

The JavaScript ecosystem’s gone to a strange place where dense frameworks and complex tooling are the status quo. But, there are data-points suggesting the pendulum could swing back sooner than later:

  • Snowpack 2.0 – download all your deps, import them as modules. Snappy development experience ensues.
  • lit-html – generate DOM without going through React/Vue/etc. intricacies
  • Alpine.js – attach dynamic interactions to elements with data elements describing DOM manipulations
  • htmx – attach dynamic networking to elements with data elements describing AJAX/Websocket/SSE events

Caveat: I haven’t tried any of these. But, the trend-line is promising. JavaScript the language, while not perfect, is Pretty Good now. Perhaps the next few years will see the great ideas of the frameworks squeezed into more accessible, less sprawling expressions of those ideas.

The possibility of software through the ages

The gestalt of what’s new in software and how it’s changing our world has evolved over the decades.

In the ‘90s, it was “don’t make me think!”. User interfaces went from text-based systems that required memorization and expertise to graphical systems that afforded more casual use of computers. Unix users and their terminals are a notable holdout to this day.

In the ‘00s, it was “don’t make me remember!”. The internet let us to stop worrying about access to common knowledge. Search engines, news feeds, e-commerce, and listing sites made it pretty easy to answer many questions without a resident expert. Nascent social platforms made it possible for our “friends” to feed this information back to us. Notable holdouts: it was impossible for me to search for punchlines from SNL skits, and largely still is.

In the ‘10s, it was “don’t make me describe the content I want to see!”. The now-giant tech companies figured out that their products were more “engaging” if they pushed content to people instead of people clicking around and typing queries to describe what they want. Thus was born machine learning, recommendation systems, and infinite/algorithmic feed scrolling. Notable holdout: none, the blast radius of ad-tech is wide and far-reaching.

From this particular moment, it seems like the ‘20s are going to be “don’t make me leave my enclave”. Even if there’s a breakthrough in medicine and this pandemic is a temporary blip, the writing seems like it’s on the wall. Many kinds of service and retail commerce we used to go out into the world to interact with, along with offices, are going to fade away as climate changes and viruses come and go. Notable holdout: the not-so-middle class folks who do the machine’s bidding and keep the wheels of commerce rolling.

Over three decades, things are at once noticeably better and yet there’s vast room for improvement. If you’re wondering where impactful work can be done in technology, it’s in making the benefits of the technology we’re building for the middle/upper classes today available to the less fortunate tomorrow. If we can make fantastic televisions available to everyone, surely we can improve the outcomes that matter most in everyone’s lives.

If we could bend this curve, the ’20s could be the decade of “no pithy quote, just people helping their neighbors.”

The Revenge of the Intuitive and developer tools in 2020

The Revenge of the Intuitive – Brian Eno lamented the downsides of a modern, computer-based recording console. Twenty years ago! The trade-offs for “freedom” at the expense of human affordances were too much for Eno at the time.

Feels like we’re in a similar spot with developer tooling. It works for the most accomplished and persistent of us. For many people who would like to build software, it’s too much. It’s too easy for our castles of complexity to thwart the novices.

The trouble begins with a design philosophy that equates “more options” with “greater freedom.” Designers struggle endlessly with a problem that is almost nonexistent for users: “How do we pack the maximum number of options into the minimum space and price?” In my experience, the instruments and tools that endure (because they are loved by their users) have limited options

You could just as easily write this today about software development libraries and tools. Too many of them discard pretty good ideas about how to build applications. Too much fascination with meta-tooling. Not enough thought put into how to put applications in people’s hands.

With tools, we crave intimacy. This appetite for emotional resonance explains why users – when given a choice – prefer deep rapport over endless options. You can’t have a relationship with a device whose limits are unknown to you, because without limits it keeps becoming something else.

We need standalone tools and libraries to build upon. However, well-curated, opinionated developers tools are where the magic happens. Frameworks like Rails, Tailwind, Next.js are where the leverage is.

A determined expert can build an application from building blocks. Novices can at least get started with a well-crafted framework. A good community and forgiving documentation can get them through the valleys of confusion to the peaks of accomplishment.

Perhaps low/no-code tools will bring the benefit of the “golden, narrow path” to more people. Maybe the trade-winds of developer tooling will blow away from showmanship back to accessibility. Either way, we should tidy up our house and make software development more welcoming to those who aren’t already monks in the monastery.

One strong center and two senses stimulated

I rented a 12-year old Porsche Boxster via Turo this weekend. Good app, great car. I’m shopping older German convertibles for my next car. Paying a little to rent a prospective car for a day is way better than driving one for less than an hour. Plus, no sales tactics!

I swear this isn’t a headshot for a TV show set in an era where masculine pastels are Extremely The Thing.

The center of the Boxster experience, it turns out, is the tachometer and the engine. The tachometer is dead-center, set in distinctly-Porsche numerals with a digital speedometer in the bottom. You don’t want any other gauges. It’s nice to know when you’re about to run out of fuel, I suppose.

2008 Porsche Boxster speedometer and tachometer

The flat-six cylinder engine sits right behind your shoulders. It is, according to my wife, loud. I found it sonorous. I don’t have a picture of it because you literally can’t see it without taking the car apart. And, a picture of a dirty machine with 130,000 miles isn’t right. The engine on a Porsche is meant, and designed, to be heard.

Once I was between that tachometer and engine, I knew I was definitely in a Porsche Bubble. The switches, seats, even entertainment system didn’t matter much. It helped that it was a lovely day and the air conditioner was up to the challenge. But it’s all auxiliary to the sights and sounds.

Turns out, that’s sort of all you need. A strong design center and two senses stimulated can make a product that stands the test of a decade or three.

Manage for time and mental burden

Features in software are answers to questions. How can customers send what they’re looking at to someone else? That’s share via email. How can customers distill all the data about my project’s tasks down to raw data to analyze it? That’s a report, probably with a CSV export.

All of these answers exist on some kind of spectrum. There are simplistic and sophisticated answers. Maybe reporting has no interaction affordances at all; it’s an HTML table and a link to download it as a CSV. Perhaps reporting is full of interactions, using metaphors of spreadsheets like sorting or filtering.

It hurts to waste time and effort. We get attached to the things we work on. But that’s the Sunk Cost Fallacy talking. If you don’t think a feature is worth the time it takes to make it great, then it is not rational to ship a crappier version simply because you have sunk time into it.

Julie Zhou, How to Make Things High-Quality

Early in the development of a feature is the time to seriously consider whether to ship the simplistic or sophisticated version of the feature. Before Sunk Cost starts to weigh on our souls. The first few days of building the feature are often about figuring out how much sophistication we can afford to build given the amount of time we have to ship the feature.

It is tempting to stop when it works, but it is only the beginning. That’s the shitty first draft you’d never turn in. Now you must go through the process to make it as simple as possible for others to understand.

Simon Hørup Eskildsen, Shitty First Software Drafts

In a sense, we’re matching a time budget to a mental complexity budget. In one week, we could figure out how to do a very simplistic CSV export. We could get it to work, make the implementation clear, test it out, iterate on code review, and have it ready to ship. In four weeks, we could add all the features that make a crisp and clear customer feature: generating it in the background, emailing a link to download the CSV after its generated, showing progress of the export to a user, etc.

With the teams I work with, we operate with the idea of peak complexity: the time at which a project reaches its highest complexity. Peak complexity has proved a useful mental model to us for reasoning about complexity. It helps inform decisions about when to step back and refactor, how many people should be working on the project at a given point in time, and how we should structure the project.

Simon Hørup Eskildsen, Peak Complexity

Somewhere in the middle of the time allotted to the project, a feature might start to feel like its getting out of hand. Inevitably, there’s some surprise complexity or scope that no one anticipated. If the code of the feature were a combustion engine, it is sitting on a stand, partially disassembled, and in need of a rebuilt component.

Maybe we decide that the surprise scope isn’t worth the toil and scrap part of the feature. We might decide it is essential and scrap some other part of the feature so we can finish this while affording the time and complexity budget.

Eventually you reach a point where there aren’t any more unsolved problems. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.

Basecamp Hill Charts

We reach that Peak Complexity, decide how to get through it, and start working downhill. We’re now reaping the benefits of the thought and effort we put into managing the complexity budget of the feature, given the our time budget. We’re crossing t’s and dotting i’s, finishing detail work, and getting the project ready to ship.

I find that managing software projects as time plus complexity works far better than viewing it as tasks for people to work on until it’s “done”.

Graphs are the new hierarchies

In the sense that trees of people (managers and reports, ala Taylorism) are the old guard. Data (folders and files) are old sauce and nodes + edges are new sauce.

In the sense that part of the confusion of our modern world is that e.g. the Koch brothers have considerable influence on how the Republican party organizes itself. Thus, money is the speech that organizes our current regime and acts on policy. But the Koch brothers aren’t on the org chart for the government or the Republican party.

In the sense that hierarchical databases are such old sauce that I’ve never used one. People new to software development don’t even realize they were at one time a thing that competed against the idea of relational databases.

In the sense that writing is linear or organized by chapters in books. But, the web is a wild mess of hyperlinked graphs. Maybe writers want to organize by graphs too!

(Spoiler: you can represent strictly hierarchical data with graphs too!)

Whiteboard, even if you’re a distributed team

A lot of us are out here, amongst all the strangeness of the world, trying to figure out how to help our teams adjust to collaborating remotely. It’s long been my observation that nothing beats people in a room together communicating via ad-hoc scribbles on a whiteboard.

Seems like a good time to survey the landscape and see if the situation has improved!

On one end of the spectrum are Google Draw and Jamboard. The former seems better for attempting to draw technical diagrams. I think it’s actually better for ironically creating WordArt. The latter seems like an honest, lo-fi attempt to re-create whiteboards online and collaboratively. I don’t think these tools cut it. But, they have the advantage of ubiquity: a lot of companies use Google Suite, so these could come in handy, in a pinch.

Another wild card is to use design software your team might have in place. Sketch or Figma are inherently about visual communication. If everyone has a license and some patience, this could work! If anyone can put some boxes, arrows, and text together, you can basically whiteboard.

I’ve used Whimiscal to create non-trivial visual communications. It works great, it’s easy to share with people, there is some multi-person editing. It’s easy to get started in Whimsical and it has some depth, but not so much depth that it’s intimidating or overwhelming. Pricing aside, this is where I’d start with my current team.

I have not kicked the tires on Miro, but the concept is intriguing. Looks like there’s real-time, collaborative visual communication/editing. They also brag a lot about their integrations with adjacent project/collaboration tools such that one can embed JIRA cards, mockups, docs, etc. in a whiteboard. If you’re already using this, I’d love to hear your experience with it!

Finally, you don’t need software to share ad-hoc scribbles. You can draw on paper, capture it with a camera, and share that image almost anywhere. You could use sketching/drawing tools to do a fancier version of that. If you have a whiteboard at home, you can draw on it, take a photo, and share it.

It doesn’t matter if the tools aren’t that great or if your company hasn’t adopted any of them. Taking the initiative to collaborate, or having the insight that communicating with words is not cutting it, is much more important.