Do all software engineers care about customer impact?

I got into a fun chat with my friends about unengaged people at work. Do software engineers care about salary, solving a problem technically (discovery), shipping, or does that work has to have impact in someone else’s life? Of course, different people find joy in many points within this spectrum of outcomes.

Interesting question surfaced: is it that some people don’t find joy in having impact in others or have they just not had the opportunity to make that deep connection to their work? I mean, nothing wrong with just finding joy in solving problems, right?

I referenced 2 stories from my past.

I used to go to church multiple times a week and be involved in many religious activities. I was happy and I never really thought past the bubble I was in. Then my circumstances changed with where I lived, my closest friends’ life circumstances etc. It led to me inspecting the bigger “why’s” of life. As a result, I incrementally focused my energies elsewhere and dropped out of church.

Second story was just me as a software engineer. I loved experimenting with new technologies and making fun little UI apps. As a teenager, I had an obsession with how traffic lights worked. I found it really fun to code road junction in Java Swing UI. It was a fun way to learn Java but also… just liked figuring out how things worked.

Then I made a jump to building some iOS apps with my brother. I’ve written about this before. Watching us have direct impact in someone else’s day was just incredible. I was working for Vigil Systems at the time where we guaranteed 15% reduction in public transport accidents (sketchy memory on this metric). These things mattered to people. The direct interaction and knowing how my work helped people was a wonderful feeling.

After that, I always wanted something more. It wasn’t just enough to write good code or ship things quickly. I wanted to know my code made a difference and it helped people to make time or be better off in some way.

So, is it that some don’t get to experience this moment in time that helps them break out and think beyond their Jira cards? If you are starting off in a big technology company, it is really difficult to have this direct connection to customers to begin with. Most developers I work wth never had to explain to a customer how to find a feature in the interface they coded in. By the way, it is extremely frustrating to see people struggle with what you’ve built.

This image came to mind… this is Maslow’s hierarchy of needs:

Are we just thinking about people in different stages of this pyramid? Does everyone have the opportunity to attain self-actualisation? Does self-actualisation mean having direct impact in others?

I think it is pretty important to generate that connection at some point. But we should remember that sometimes, we find meaning in having impact in others’ lives… and sometimes, discovering is just as important. The very act of making and having fun can lead to things. We don’t have a clear purpose in life. So these competing forces — this chaos — keeps us vibrant and moving forward.

Whatever it is for you, I am hoping you find engagement and joy at work. It helped you stay motivated. If your current work doesn’t give you that, find something that does.

Related article to read: How to burnout a software engineer, in 3 easy steps.

Business outcomes vs customer outcomes

My parents grow a bunch of fruits and vegetables at home. Their little garden produces about 1000 oranges, all at the same time. So my mum calls around to see if any of her family and friends will take some off her hands. My parents would make trips to all their friends' places with boxes of oranges. We can never get through our box. Sometimes, we secretly throw some away. I feel bad about it.

My parents love growing their own produce and cooking with it. Gardening is something they do as a hobby. They like the communal aspect too. There is often produce-exchange happening amongst their friends, all growing different things at home.

Let’s think of my parents' oranges as a business. They are producing something of value that others want. In most cases, people pay them back with their own produce, hospitality or heart-felt thank yous’, instead of money. However, they have an oversupply problem. Their “business outcome” (or goal) has become to distribute as much of their produce as possible before it goes bad. This, however, is not an outcome I am interested in. In fact, being involved in it makes me feel bad.

Most businesses have the same problem. They come up with some goal to hit… “move 1 million units this quarter” or “decrease customer support calls by 5%”. Customers don’t care about these one bit.

I do love oranges from my parents. I want them, just not 100 at the same time. Therefore, the “customer outcome” I have is “to be fed tasty oranges on a hot summer day”.

How do we further business outcomes and customer outcomes together?

This is where we have to do some market analysis. Understand our customers better and solve problems they have. There are many ways to do that. “Jobs to be done” by Clayton Christensen comes to mind (the story about McDonald’s Milkshake sales). Better insights we have of customers, more confident we can be about opportunities we identify. These opportunities should “kill two birds with one stone”. They will solve a problem for a customer, leading to the business outcomes being met.

In my parents' case, the opportunities identified should help them distribute excess produce. They could…

• Sell it at a local market

• Sell it to the local fruit shop

• Put it in a box and leave it by the footpath for anyone to take

• Throw excess away

• Make orange juice and distribute that instead

Number of these are good ideas. How do we narrow the field? I’m going to stretch this example further and talk about “product vision”. Usually, there are many entities solving the same problem. Whether it is selling fast food or travel accommodation, many companies are trying to fill the same core need. To carve out a piece of the market, it is important to have a vision that speaks to a company’s identity. Customers can align themselves to this identity a lot better. It will also produce an opinionated product, this is differentiated in the market. As an example, many smartphones… perhaps only one company is thinking privacy first.

View fullsize

For my parents, gardening is a fun activity. They don’t care about making money from it. They do enjoy the communal aspect of it. Given all opportunities, making orange juice fitted them the most. More people like juice; it is convenient, easy to store, transport and drink. They repurposed empty glass bottles to store juice and distribute them around instead. I am a big fan of these compared to cutting up oranges one at a time.

Both business and customer outcomes met.

How much planning is enough?

Few years back, I was sitting in Bunker Coffee with Luke for our 1:1.

Luke tells me, “you know, no matter how hard you plan, the error rate of our decision doesn’t change much. If we take path A today versus next week, after having a whole lot more meetings, we still don’t know what we don’t know. What do you think?” He’s always polite to leave space for me to respond.

We were just coming from a team discussion on how to implement a feature. The team couldn’t arrive at a decision. Our most experienced devs wanted to spend more time thinking and white-boarding a solution.

Luke was right of course. We needed to move forward and discover unknowns. But when do you “just start” versus spend time in the drawing board?

Luke doesn’t just write code. He also builds houses. He’s worked through many building projects to know that there has to be a solid plan. However, software is far more malleable. Most decisions made in code can be changed. What truly matters is understanding dependencies in the work being performed. Dependencies can make altering decisions far more challenging.

Generally speaking, further down the stack you go, more upfront thinking is required. In other words, volatility in code and product increases as systems get closer to customers. Remember images like below that encouraged us to front load all issue tackling to save money? Well, they are wrong. Most solutions can do with making mistakes and validating assumptions sooner than later.

Not everything fits this model

The feature we were debating was for a mobile app that didn’t have a large number of users at this stage. That is the second piece to consider: customer impact. For systems that have broad customer impact, more consideration needs to be taken. If millions of users are going to be affected by a certain identity verification system, perhaps more thought should have been given. This is why as products scale, feature development does take a little longer.

Even when there are changes that are high impacting, there are tricks to go faster. It is even more important to learn about unknowns and arrive at informed decisions in these products. A simple way to get there is to reduce scope of changes. Scope can be reduced by either limiting customer exposure or breaking the change down to small iterations.

If you are running a project, always ask your team how something can be delivered in half the time. You can’t bend time and space; things will take longer than predicted. But you can have achieve outcomes sooner than you think.

Dependencies and customer impact

Many tend to be very risk averse, especially in high revenue environments. Like I talked about in “Companies Grow” post, this can become an attribute of growing companies, even to the point of rejecting innovative ideas altogether. More planning becomes the answer to please this conservativeness.

Moreover, developers are always looking to develop the ideal system; they hate writing throwaway stuff. There is natural inertia towards being careful with every change.

We should always keep in mind that these actions have a price attached to it. Being agile fundamentally requires us to try things, learn from them, and try again. We are always wiser for having reworked our solutions with new insight. Mature teams understand this. They aren’t afraid to test solutions, validate assumptions and go back to the drawing board. They aren’t afraid to fail. Like Luke reminded me, there is just always a chance of failure.

Lastly, remember… (maybe this is a construction industry thing) …as my house builder points out, “a plan is just a starting point.” Actual work lays ahead of you.

Conflict Resolution

Recently, my friend shared this story over dinner. He is an iOS developer.

He had been tasked to create a core component for his company’s design system: a container view that sweeps over other views. But there was an issue with how padding was applied. The designer in charge of the component insisted there should be a fixed padding set for content. Most developers who used the component wanted to define custom padding. He was getting lots of requests by others in the company saying their designs can’t be achieved with the new container’s implementation.

Those who worked with me on frontend projects know, bad margins and padding really drives me crazy. They seem to be the trickiest thing for large companies.

My friend goes back to the design partner to change the requirements for the padding. “Let’s set it to zero and let people put things inside a layout view”. The designer explains, “design system needs to be opinionated; all views inside the container need to have the same padding set for consistency”. The tennis match was one of stamina. Conveying how practical usage is suffering didn’t really matter. My friend got tired and gave up after running around the court.

Conflicts like this happen all the time. Perhaps, it would help to think through a framework that helps both parties arrive at shared understanding and agreement.

—

Eliyahu Goldratt, in the book It’s Not LUCK, guides conflict resolution towards finding common objective. Each action in conflict is motivated by a requirement, which in turn, is motivated by an objective. If we can work back to find the common objective in a conflict, we have the opportunity to inspect underlaying assumptions and work towards resolving the conflict.

So in our story, we have…

Developer: [A. Leveraging the design system to unlock consistency]← [B. Flexible system that matches feature designs] ← [D. Remove default padding]

Designer: [A. Leveraging the design system to unlock consistency] ← [C. Consistent component behaviour through fixed values] ← [D’. Apply default padding]

My favourite thing about this framework is its invitation to show empathy. It forces us to inspect motivations on both sides. Conflicts are part of working as a diverse group of individuals. Being able to understand differences and learning to view problems from many lenses helps teams do amazing things.

—

Let’s take another piece of wisdom from (the super awesome book) Crucial Conversations by Kerry Patterson to help us.

Often, a conflict exist because each party doesn’t have the full picture. Much like a Venn diagram with two partially overlapping circles, each party has unique knowledge with some shared understanding between the two. We should approach conversations with a level of curiosity to close the gap on shared understanding (bring those circles closer together). What do you know that they don’t? More importantly, what do they know?

Going into a debate thinking you want to “win it” yields no favourable outcomes; only annoyed people having formed a poor opinion of you.

Again, this is sounding a lot like empathy.

—

A. Leveraging the design system to unlock consistency

Going back to our conflict, I played the designer and debated with my friend. We both asked “why” a whole bunch and tried to explain the differences of theoretical and practical issues.

This is where we arrived (if you care for technical details)…

Some containers describe layout patterns while others define interaction patterns. For example, a Card is a way to lay content out. A Dialog or a Split View may be more of an interaction pattern. Perhaps, we need to have an a rule in the design system on how to approach these two types of components. It make sense for layout views to pad content. How about interaction patterns? Perhaps the rule is to pair interaction components with a layout.

This seemed like a path forward to figuring out how to resolve the conflict.

—

Conflict resolution is all about empathy. Empathy builds great teamwork, which builds great products.

Companies Grow

As successful products increase in revenue, companies grow. Growth allows a company to improve their products, support more customers and create additional value-add services.

Growing up isn't easy. As a handful of engineers become hundreds, or even thousands, the added weight introduces many issues. These can often lead to the opposite outcomes of what growth should have brought: products falling short of providing value and unhappy customers.

-

Why is that?

As companies grow in size, chaos takes over. There is a need for structure to allow humans to successfully exist with one another. Typically, employees are grouped into "teams" and each team is assigned ownership over part of the product. This allows teams to work alongside others to achieve a larger outcome. Often, metrics are put around these areas to understand if progress is being made.

For example, an e-commerce product would usually be split up based on customer flow (or funnel). There will be teams tackling home and landing pages, search, product pages, payment, receipts and so on. Landing and homepage teams only work to increase SEO rankings and "click through rate" to product listings. Product page teams care about converting customers by sliding them to payment.

To ensure all these groups work well, we add management. Managers keep track of progress and tackle a constant stream of people problems. Sometimes, they are also to blame for these problems.

That's not enough. There has to be a way groups can communicate effectively and coordinate tasks. This layer of protocols is "process". Process mandates its participants work to a standard. When mistakes happen, process tightens up to prevent future occurrences. When efforts are successful, process digs deeper. In all instances, process wins.

These pieces that form the structure -- team layouts, metrics, management layers, process -- overtime leads to an organisation becoming more rigid. Rigidity, unfortunately, takes the innovative drive away from organisations.

-

Safi Bahcall, author of Loonshots, managed to capture this in an equation.

From "Innovation Equation" (HBR): In organisations, the competing forces can be described as “stake in outcome” versus “perks of rank.” When employees feel they have more to gain from the group’s collective output, that’s where they invest their energy. When they feel their greatest rewards come from moving up the corporate ladder, they stop taking chances on risky new ideas whose failure could harm their careers.

M = E x S² x F / G

M = certain size at which human groups shift from embracing radical ideas to quashing them

• E = equity fraction — the extent to which incentives reflect the outcome of projects as opposed to rank within the organisation
• F = fitness ratio — relationship between project-skill fit (PSF) and return on politics (ROP): F= PSF/ROP
• S = management span — average number of direct reports that executives of the company have
• G = salary growth — average step-up in base salary

He points out that organisations can alter the point in which they become too rigid by employing certain strategies to move the "freezing point".

-

Rigidity has its purpose.

Rigidity brings order to the chaos of having a huge community of people. Society needs laws, companies need rules too. Drawing lines between disciplines, roles and product teams help keep things under control. But, of course, you won't find innovation in excel spreadsheets.

Rigidity helps an organisation be more disciplined and operationally excellent. It protects revenue. That is a key thing to think about: at some point, the organisation will squash attempts to innovate because it could hurt current revenue. Only proven, incremental changes are allowed. Changes have to be discussed, reviewed, checked, approved by many layers of management (that's why most employees just sit in meetings all day without building stuff). It won't even matter if the products are slowly degrading, as long as revenue stays on green.

If an organisation is full of professionals and makers, can't they override these tendencies? It is not quite that simple. In 1960s, Stanley Milgram ran an experiment to understand authority and obedience. He had an authoritative figure order a teacher (participant) to give increasing amount of electric shocks to a learner as they incorrectly answered questions. Two-thirds delivered fatal shocks to learner and no one checked on the suffering humans in the next room or stopped the experiment. Milgram concluded that people can exist in two states: autonomous, where they direct their own actions and, agentic, where they pass off responsibility of consequences to someone else.

Yep, it is hard to break out of a hierarchy of authority. Autonomy doesn't come for free. We have to create the right environment for it to flourish.

It is tough to steer culture back. It can be done.

-

Some companies try to break out by hiring high profile individuals from already successful companies. In the book Inspired, Marty Cargan talks about how many of these new hires have acclimatised to an organisation that's slowed its growth. So they aren't always best equipped to push the organisation towards innovation.

I've only had the opportunity experience the reversal of rigidity in one team thus far. In my previous team, the leadership team actively worked to bring part of the organisation to a more fluid state. While it will take this entire series of posts to explain pieces of it, there are some basic observations I made.

1. We made a hard turn to focus heavily on outcomes
2. We dropped all notions of what process works. We taught everyone how we worked and told them to change it.
3. We worked extremely hard to take power away from leadership and push it down to the grassroots. In fact, we went as far as to break HR management hierarchy from the project work we did.
4. We came up with a new branding for people who were willing to forego their silo and breakout... we called them Makers.

Hackathons

I don't like Hackathons.

I remember when they went from fun to not-so-fun. I was part of the frontend modernisation project at Expedia. It was a long arduous project, filled with many many technical and people challenges. I loved it. Every day felt like a rush and we were doing something difficult that was going to have major impact. When the next company hackathon came along, I was more interested in carrying on with my regular work. What I was doing was more important and rewarding.

Hmm... does this mean people who love Hackathons just don't like what they are working on? Perhaps, they have a better idea to move the needle for the company? 🤔

From then on, Hackathons felt like a surface fix for a larger problem the organisation didn't know how to address.

Why do people love Hackathons?

Answers I've gotten over the years:

• It's my idea
• No processes or reporting
• Something different
• Low bureaucracy
• Get to the end quickly
• Opportunity to learn something new
• Don't have to have a dozen meetings

In other words,

• mastery
• autonomy
• purpose

People feel more driven.

This is no different when you work on home projects. Or when I write these posts. We have greater motivation.

I say, forego hackathons. Create outlets in every day operations to help people engage at the level of a hackathon.

1. Make sure people understand why and are engaged in the problem being solved. It is more important that makers fall in love with the problem to be solved, more than the solution.
2. Create opportunities to pitch and test new ideas out. According to Marty Sagan in the product management book "Inspired", most good ideas for the product come from the dev and UX teams. Provide a way to let those great ideas bubble up. Work on them.
3. Generate a structure that is high in autonomy. Trust the people you hire. It is difficult to build great products in a top-down tyranny.

Don't encourage doing all-nighters though.

Recently, my good friend Jacquie sent me this YouTube by Corridor Crew. We were saying, they seem to have a lot of fun at work. Can yours been this cool?

Make every day work meaningful; make it fun.

Learnings from "Seeing like a State" by James C Scott

Seeing like a State inspects attempts of states bringing “administrative order of nature and society” that’s led to disastrous outcomes. It is an interesting window into inspecting how large, people based systems work at scale.

High Modernism

The book inspects state's appetite to use “high modernism” to solve issues at scale. "High modernism is a form of modernity, characterised by an unfaltering confidence in science and technology as means to reorder the social and natural world."(1) There is less consideration given to history and practical knowledge held in the grassroots.

States employ these high modernist schemes to simplify, standardise and make things more legible (easier to catalog and understand). Simplification and legibility makes it easy to monitor and control outcomes. For example, cataloging land ownership makes for easier track assets and income, leading to more efficient taxation.

It is incredibly difficult to simplify how a community operates. These societal systems tend to have multiple hidden outcomes; they tend to be complex ecosystems. Forcing change solely around an outcome the state is focused can cause a lot of disruption. They can go against the natural order of things. Often, the result is failure.

Scientific Forestry

In 18th century Prussia, the government tried to determine the revenue potential a plot dedicated for timber yield. This measurement resulted in forests being optimised for lumber, leading them on a path of monoculture (1 type of tree), planted in a strict grid pattern. While it made for maximised yield initially, subsequent generations collapsed. This attempt to simplify nature ignored how complex a forest ecosystem is and its need for that complexity to achieve continued growth.

There are learnings here we can apply to large teams and companies. Teams are complex ecosystems too. They have many hidden outcomes that are not visible to "people at the top". Therefore, we have to be careful when we apply new processes to get specific outcomes or do reorgs to align to new direction. It might look great on a spreadsheet or a diagram (high modernist?) but does it work for the humans who have to adopt it?

Visual Order

One of the key points made in this book is this idea of visual order over system order. States (and its planners) appreciate visual order, which is mistaken for actual order in a system. If something looks visually simpler and easier to understand, it must be better! However, it is often the case that visually appealing macro order leads to micro confusion. Complexity has meaning in a large systems; their order requires more context and knowledge to appreciate. A small example might be how a jet engine works. It may look complex to the untrained eye. However, its complex design has order, which yields the desired outcome.

If you are a leader of a company or someone designing software architecture, it is well worth thinking about this idea of “visual order”. Are teams laid out in a way that is easy to collect reporting reflect how work actually happen? Is the architecture side stepping the complexity of the business, which in turn gives it a competitive advantage? Are we causing confusion on the lower decks?

Le Corbusier’s plan for Paris redesign: grids and perfect right angles. Read more about Le Corbusier and Jane Jacobs here.

Mētis

“Mētis” stands for “practical wisdom” in greek. The author talks through examples of every day innovations that come from having context and experience. Not all problems can be solved at scale because the conditions of these systems are unique.

Excerpt from the book:

While doing fieldwork in a small village in Malaysia, I was constantly struck by the breadth of my neighbours’ skills and their casual knowledge of local ecology. One particular anecdote is representative. Growing in the compound of the house in which I lived was a locally famous mango tree. Relatives and acquaintances would visit when the fruit was ripe in the hope of being given a few fruits and, more important, the chance to save and plant the seeds next to their own house. Shortly before my arrival, however, the tree had become infested with large red ants, which destroyed most of the fruit before it could ripen. It seemed nothing could be done short of bagging each fruit. Several times I noticed the elderly head of household, Mat Isa, bringing dried nipah palm fronds to the base of the mango tree and checking them. When I finally got around to asking what he was up to, he explained it to me, albeit reluctantly, as for him this was pretty humdrum stuff compared to our usual gossip. He knew that small black ants, which had a number of colonies at the rear of the compound, were the enemies of large red ants. He also knew that the thin, lance-like leaves of the nipah palm curled into long, tight tubes when they fell from the tree and died. (In fact, the local people used the tubes to roll their cigarettes.) Such tubes would also, he knew, be ideal places for the queens of the black ant colonies to lay their eggs. Over several weeks he placed dried nipah fronds in strategic places until he had masses of black-ant eggs beginning to hatch. He then placed the egg-infested fronds against the mango tree and observed the ensuing week-long Armageddon. Several neighbors, many of them skeptical, and their children followed the fortunes of the ant war closely. Although smaller by half or more, the black ants finally had the weight of numbers to prevail against the red ants and gain possession of the ground at the base of the mango tree. As the black ants were not interested in the mango leaves or fruits while the fruits were still on the tree, the crop was saved. (2)

Successful workplaces allow employees to innovate and solve problems they observe on the ground. Sounds weird, given that is very much the job of an employee. However, processes and constraints put in place can discourage people from applying ingenuity altogether. Couple of things to do:

1. The culture of your workplace has to embrace individuals using judgement to sidestep guidelines and rules that doesn’t make sense. When people blindly follow processes, leaders must push for using common sense. This is difficult for leaders as they are more concerned with order and ensuring everyone follows the same set of rules. Best to have less rules :).
2. We must fight our impulse to solve every problem for people we manage/mentor/advice. It is a leader’s job to anticipate issues and clear the path ahead for teams. However, fixing every issue is unnecessary. Let the professionals on the ground figure it out by encouraging a bottom-up approach. Make it okay for them to be makers (think → do). Instead, work on issues that are more widespread that attack your value system or product direction.

Conclusion

We do have to solve issues at scale. This book doesn't discourage that. However, it is well worth understanding the complexity of systems we change and be careful not to oversimplify. It is difficult to have a full picture of how or why an ecosystem works. There are always second and third order effects for all new ideas introduced. We need to evolve systems in a way that can leverage scale to its advantage while not destroying the hidden goodness that drive outcomes forward.

Seeing like a State was well worth the read, despite its, sometimes, tedious academic writing :). I left out a wealth of good ideas presented in the book. Hope this summary helps you carefully inspect complexity that exist in your workplace.

---

---

Notes

Couple of detailed reviews of the book:

• https://slatestarcodex.com/2017/03/16/book-review-seeing-like-a-state/
• https://thechaostician.com/book-review-of-seeing-like-a-state-by-james-c-scott-1998/

Citations

1. James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed (New Haven, CT: Yale University Press, 1999), p. 4.

2. James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed (New Haven, CT: Yale University Press, 1999), p. 333.

Weekly Newsletter

I've been making plans to write about a specific topic on this blog for a while. I'm finally doing it. I'd like to write about my experience on...

..building a team of Makers.

If you'd like to keep up with the journey, hit subscribe on my newsletter. I'll send articles on the topic to your inbox.

Subscribe to Newsletter

Thank you :)

--

I'll keep it similar to sive.rs (thanks Luke for intro) or pragmatic engineer substack (thanks Shila for intro). Sample post here.

Getting a taste for making

Few years back, my brother and I decided to work on an iPhone app together. It was a little note taking app that I dreamt up to help me record lectures while taking notes. We gave it a terrible name… “notes + u”. App didn’t make it. It wasn’t a million dollar idea. We didn’t know much about making something great just yet.

But we had a lot of fun working on this app.

Every day was a new challenge. Everything had to be learned on the “job”. It was like being in The Matrix and learning kung fu. We learned about tooling, programming languages, design, marketing, copywriting… you name it. Everything was new. We read about the things we didn’t understand and tried it out.

I distinctly remember… I would spend hours on making some screen mocks. My brother would say he didn’t like it. I’d be pissed. Then I’ll try again, after maybe spending hours looking for inspiration on Dribble. It always got better with feedback. Likewise, I’d complain about how hard it was to manage CoreData threads… next day, there would be a better solution from him.

There was no mention of agile or process. We had day jobs so we didn’t waste time either. We just kept building something till we got there.

After the flop of the first app. We made many more apps. Each one better than the last. We made a little bit of money, which led to latest gadgets. But that didn’t matter as much as watching a live dashboard of people using our stuff. It was so exciting to see 50-60 people using the app at 8pm PST.

This feeling, it got really addictive. I don’t think it ever left me. To this day, I love making things. And I love to see people use the things I make.

I often wondered, can this not be “work”? Can’t I just make things that are useful to others in my day job and feel great? Work never felt that good though. Something about being in a corporate setting washed away the good vibes. Why was that? Can we not just focus on making?

My journey to this date has been to figure this out. Can I bring back that feeling of making to where I work? I think I can do it.

Our first app, notes + u