Reflecting on the first year of Craftwork

We've written many chapters of our story in the last year. And I think it's worth taking a moment to reflect on what we've accomplished and what we've learned. You won't know some things until you try. I've spent a good deal of my career. Working in UX. I've gotten to work with some incredibly talented designers and UX researchers. And I do believe that a good design is a competitive advantage.

Even still, when building real features for real people, you can't always predict what will work and what won't designing. Great software needs to be both proactive and reactive. You need to have a vision for what you want to build, but you also need to actively respond to feedback and data. For example, the very first version of Kraftwerk's estimate builder was designed to be extremely self-serve.

We built a tool that would let customers scope out the entire project they had without needing to talk to us. We thought this would be a great way to let people get a feel for what we could do for them, and to be extremely transparent about what their project would cost. In practice, we found that people were often overwhelmed by the number of choices they had to make. Over and over. We saw people on our site getting stuck playing with the estimate builder.

They were weighing the cost of one little change against another. Many people that stuck in this process and many never actually submitted a request for painting. On a hunch. We ran a quick AB test to see if it would be more productive to have a conversation with one of our team members first, and the results were clear. Our customers have lots of interesting questions. Enterprise calculator just wasn't answering all of them.

We've since reworked the estimate process to be more of a guided conversation. And we found that using it to create a human connection with our customers has been a great way to build trust and to get the ball rolling on a project. You can't do it alone. While building my last company, I was convinced that we could do everything with an exceptionally small team. We were just three people from inception to acquisition. I'm proud to say that we did the damn thing, but it was really difficult.

You'll often hear founding employees at startups. Talk about how they're wearing many hats. That's definitely true. And it makes work a lot of fun. It's also true that you can't wear all the hats. It's also also true that there are exciting, beautiful, new hats out there that you didn't even know you need to wear. From my first day as a working professional, I've always wanted to be surrounded by people who are smarter than me. Building craftwork has been no exception.

My co-founders are dedicated, talented and damn good at what they do. We've also hired some truly amazing people to build our team. A few things that I've learned about building the right team. Engineers tend to undervalue the importance of understanding the mechanics of the business. Uh, our growth team at craftwork has been instrumental in helping us understand how to reach new customers and how to build a profitable product that people want. Building a brand is like nurturing a garden.

It takes time patience and a lot of care. has Kraftwerk's brand has really grown into something special and it's been a joy to watch it happen. Give our Instagram a peek. If you want to see what I mean. At this stage in the startup journey, hiring engineers is really challenging. The perfect engineer for a startup is someone who's comfortable with a lot of ambiguity who can work independently and who can communicate well. In addition to being technically competent.

It's a tall order and it can be a challenge to find the right people. When I have roles open on my team hiring is the most important thing I do day to day. It's also a full-time job in itself. It requires a fair deal of patients to assemble the right team, as well as a drive to actively and creatively seek out the right people. Just enough and nothing more. I recently came across the Japanese phrase, hold a Hodo, which means just enough.

I've been trying to use it as a reminder to keep things simple and to overcomplicate things. My team is tasked with building the features that we need most today with eyes on what we'll need in six months and in a year. And that can be pretty overwhelming. It's easy to spiral out of control with feature creep and over-engineering finding ways to help each other do just enough for now is a team remit. In fact, just enough spills over into a few areas. For example, build versus buy.

Almost every feature our team needs can be bought from a SAS vendor or coach built by our product team. Making this decision can be nuanced and difficult and it's something we revisit regularly. Adopting tooling. Engineers love to play with new tools. There's always a new framework, language, database, or library to poke around with. We've been very deliberate about what we adopt and we've been very careful to avoid adopting things just because they're new and shiny.

We have also adopted tools with good intention, but found ourselves at jettisoning them when they don't work out for one reason or another. Shipping new features, adding new functionality for our customers and teammates is always tempting, but it's important to me. But it's important to be mindful of the complexity that comes with each new feature. Our engineering team is small and mighty. And every new feature we build means we have less time to support the features that we've already built.

I used to say just enough and nothing more. And there's a funny irony in that phrase. A year into this thing, it feels a whole lot more accurate just to say. Just enough.