The key to a high output software engineering organization

After working on side projects and spending the summer at a tech company, I realized one of the most undervalued components of building things: flow.

What is flow?

Flow is that moment when you are so deep in whatever you’re working on, the periphery of the outside world blurs together. It’s such a satisfying state that it’s why many makers make things.

How do we hit flow? Many of us hit flow in different ways. Some find it through writing, others through running, and for nearly all engineers, we find it through building things. And when it hits, we are more productive than at any other time.

Flow can be stopped, too. Flow blockers include things like interruptions and mundane work. A flow blocker feels like that one person who walks in front of the screen at the climax of a movie.

What makes flow so important to an engineer is that when it’s hit, engineering turns from job to nirvana. Virtually any engineer can attest to the state of happiness that occurs when flow sets in. It’s like injecting yourself with a really potent drug. And that drug’s effects can be perpetuated by completing more work.

How do you help engineers reach flow, though? In my opinion, flow can be guaranteed for an engineer if three things are present: the ability to execute, the ability to test and see their progress, and the ability to have ownership in what they are working on.

Execution can be divided into two parts: being able to complete the work, and *being able to get the resources* to complete the work. When you are executing, you can complete work, and there’s little interruption or blockage. This lag isn’t to be confused with moments of thinking/difficulty. Rather it’s the unsolvable blocking or meetings that interrupt thought. If you start thinking like you won’t be able to execute or in the case of a meeting, you stop thinking at all, the anxiety will take over and block flow. And then there’s getting the resources to work. This is the ability to get whatever knowledge and resources are necessary to complete the work. Without this, execution can’t happen.

Testing and measuring progress is the second key. Seeing that console.log(“code hit here”); appear in the terminal buffer keeps you going [1]. It’s verification that you are executing correctly. A programmer’s logs are a lot like an airline pilot’s GPS. While in the air, a GPS can’t fly and land the plane for you. But it can tell you if you’re going in the right direction. When you’re coding, logs can’t write the code, but they can tell us if the code that we write is working. Logs give us immediate feedback and remove the uncertainty that can interrupt flow.

Ownership helps flow by giving purpose to tasks. Inherently, having ownership of a project psychologically attaches you to that project. And through that attachment, you feel the need to be an expert on your project. And to be an expert, you have to know what the goals of your project are better than anyone else. Rather than working on individual tasks, you (and your manager), establish the goals for the project. When a project has owners, it sets an agenda from the start, which makes it clear what needs to be executed. This clarity helps achieve the feeling of control over work, thus boosting performance and flow.

How engineering organizations can be conducive to flow

If you are an engineering manager/leader, I believe one of your top priorities is:

1. Helping new members of your team hit flow as soon as they can
2. Helping current members of your staff be in flow as much as possible when they work.

Enabling flow for developers both makes their job very rewarding for them and helps the output of your organization. As an engineering organization, there’s a variety of things you can do to help flow.

Both components of execution can be augmented. In regards to acquiring resources to execute, many organizations already have streamlined IT and plenty of snacks. Some great organizations have developer experience teams that create developer tools to boost productivity. However, any organization can do a better job providing access to information/resources for execution. Things like better wikis and more documentation play crucial roles in an engineer’s ability to execute and reach flow. Many engineering organizations trade off extra lines of code for proper documentation. In my opinion, quality documentation is crucial.

For many organizations, there are a lot of tools built in-house. Whenever an engineer has a question about these tools/code, they can’t google it. Rather, they either have to ask another developer (usually by email/slack) or look in a sometimes sparse, unorganized internal wiki site. And in these wikis, you may come across blank pages or four-year-old scribbles vaguely associated with your query.

In regards to actually doing the work, organizations can reduce the lag time to gain approval to execute on certain items and schedule meetings using maker time.

The ability to continually test the progress of your execution is a huge advantage in a software engineering organization. If you can compile and run your project and have access to a great logging system, the testing component of flow figures itself out. Knowing your code is functioning without having to deploy to production/staging server (depending on how your organization deploys), wait thirty minutes, and then look at the logs on a crummy interface makes the biggest difference. It all comes down to feeling control over the code. If engineering organizations put time into giving engineers significant resources to continually test their progress, engineers will feel more confident about the code they write and will be more likely to enter a state of flow.

Organizations can help give ownership in two ways: quantitatively and qualitatively. Using numbers can help engineers feel ownership. Metrics and percentages of impact can help engineers value their project. More subtly, though, an organization can qualitatively give ownership to engineers.

For example, I believe that a micro-service architecture rather than a big, monolithic codebase encourages ownership. That is, having the ability to have your own mini codebase, package it up into a complete, independent project, and name it to your pleasing provides increased ownership. It’s like the difference between working on a big boat and having your own boat. When you have your own boat, you name it proudly, furnish it using your styles, and protect with your life. And who doesn’t want their own boat?

Thanks to Dan Isaza, Chris Barber, Aneesh Pappu, Tony Bruess, Niko Alino, and Yonatan Oren for reading/listening to drafts of this.

[1] A log is a statement you write in code that gets printed to your screen when the program runs. Logs are used to see what a program is doing and to help see if certain pieces of the code are working.
3 responses
Nice article! I think the question of ownership is really about X percent of Y. Owning 100% of small projects that are buried under the github page might not be that pleasing, while owning even a small percentage of a high-impact monolithic repo is still meaningful. At the end of the day, we are measuring the net impact of the engineer.
You're right, I think that's a better way to put it. New rule should be "you should be able to point directly to your contribution".
1 visitor upvoted this post.