My relationship with Workiva (WebFilings, at the time) began in the fall of 2011, when the company sponsored my Senior Design project at Iowa State and my team cost the company thousands of dollars in GAE quota. But we learned an important lesson in how to fan out background processing tasks!

Now, after a happy journey along the engineering career track, I’m getting ready to say goodbye to Workiva and set off on a new adventure in parenthood. It has been hugely rewarding to grow up with this company, as I have had ample opportunities to encounter new ideas and apply them to real-world situations.

And so, without further sentimentality, it is my wish to pass on some of the ideas that I’ve found to be most impactful for me as a technology leader here at Workiva. I may not have always remembered these lessons, but sitting here now, these thoughts stand out as worthwhile to share.

On influence

People are happy to follow

You are likely ready to lead earlier than you think.

Don’t stop yourself from being seen as an expert. Leaders at a healthy organization aren’t territorial or greedy for more responsibility. When somebody steps up and claims authority in an area that motivates them, it’s always welcome.

If you tell yourself to wait for an invitation or leadership assignment, you are holding yourself back.

And when you get an opportunity to make decisions, don’t hedge too much. Try out a MUST where you feel safer with SHOULD.

Include others, always

Avoid wielding influence in private. Prefer open slack channels over direct messages. Raise your hand, wait your turn, let others speak. When you don’t have the answers, facilitate a conversation between the people who do, but don’t make yourself a middleman.

Make sure you’re somebody people like to work with.

Requests for Action vs. Requests for Information

As a technical leader, you’re going to field a lot of requests. If you misinterpret requests for information as requests for you to take action, you’ll end up misallocating a lot of your time. Make sure you know what folks are actually asking of you, and make sure you know what you’re asking of others.

Nemawashi: before the meeting

Nemawashi is a Japanese term that I’ve seen interpreted as “the meeting(s) before the meeting.” In attempting to apply this technique, I’ve shifted my expectations for large review meetings, and I think they’ve become more successful. When you have complex ideas that you want others to learn, embrace, or approve of, you shoudn’t expect a one hour presentation to bring everybody up to speed.

Meet with stakeholders before you commit to a decision, and they become your collaborators.

Avoid surprising your colleagues with difficult ideas during live meetings.

On time management

Urgent vs Important

I would like to immediately recommend that you read other people’s words about the Eisenhower Matrix.

In practice for me, this has meant excusing myself from urgent support issues unless I am uniquely capable of responding to them. If everybody is on the urgent work, there’s a whole quadrant of important work that goes un-addressed.

You are assigning tasks to yourself

If your career takes you away from individual contribution of code, you’ll be spending less of your time on well-defined, prioritized tasks that come out of a backlog you built with your team. But you shouldn’t instead find yourself working on poorly-defined, random shit that happens to catch your eye.

Pay attention to what you’re choosing to work on, and make sure it’s worth your time. I started adding the things that pop up during the day to my to-do list before I let myself jump on them.

If you get good at this, you should have just as tight of a standup update as somebody who spent yesterday working on unit tests and plans to pick up the top of the backlog today.

Thinking takes time

Give yourself time to think. That means both carving out time on your calendar to be free of distractions, but also not being too hard on yourself if it takes a while for things to crystallize.

On architecture

What even is it?

There are plenty of definitions out there. I have gotten the most mileage out of thinking about “Architecture” as the process and practice of making decisions about how we change our system(s). And that’s something every engineer does, with varying levels of intention or rigor. I gravitate towards the comfort of standard procedures, so I’ve latched on to “Conversational Architecture” as my preferred expression of architecture as a process.

ADRs ADRs ADRs ADRs ADRs ADRs ADRs ADRs ADRs

With that definition of architecture, the minimal activity to satisfy “doing architecture” is recording your decisions and making them available to reference. I’m a huge fan of ADRs, especially for how they can flex from lightweight notes of an easy consensus, up to technically-dense discussions on the depth of a complex problem.

“Just In Time” Architecture

Avoid the temptation to lay out big, multi-year efforts that drag your system to a supposed ideal state. You will either watch implementation diverge from your initial designs as the plans encounter reality, or you will get stuck in the design/prototype phase and never ship anything.

On documentation

The Types of Documentation

For this one, I kinda have to just point you at Divio’s Documentation System. The types are:

• Tutorials
• How-to Guides
• Explanation
• Reference

It’s excellent.

Documentation dies fast

“Living documents” wither unless you tend to them. It’s like gardening - you have to regularly spend time amongst your docs if you want them to flourish.

There’s no “100% coverage” for documentation

Early on, I had a tendency to act like the goal of documenting was to record every property and detail of it to some historical record. But we don’t write documentation for posterity, we write it to communicate important, non-obvious information to others (or our future selves). Keep in mind who your audience is, what they care about, and how you can efficiently convey that to them.