I walked into the "Design Meeting" feeling woefully... under-titled, if that's a Thing. Around the table sat a Senior Architect, 3 Architects, the Head of Analytics, and two Principal Engineers. The goal: define the new Compliance Tool we were going to build to automate all the paperwork.
Captain, we're experiencing chroniton waves, or temporal flux, or... some other thing
We're going to look at this through a Temporal Fracture (or something like that, the kind of Science-y thing that drives the plot of a Star Trek episode): We're going to see this as a focal point where two timelines emerge, and see what we can learn from the different choices.
Timeline 1: The Way We've Always Done It
Immediately, the conversation took off. With all that architectural knowledge around the table, the design took shape. One of the architects began drawing up the diagram as we talked, and two full hours later, we had built SO. MUCH. STUFF. (Well, at least on paper!). Our platform design had everything in it... even a couple kitchen sinks.
The diagrams flew through the approval process because everyone in the whole organization was champing at the bit to get access to the new platform because one look at the design convinced everyone it was going to save them so much time and effort. We spun up the implementation project, which was estimated to take six months.
EIGHT months later, we implemented... with tons of bells and whistles. We had... no users.
Eight months in technology might as well be eternity. Everyone was so excited for the design... but those six planned implementation months meant that our users... our customers... our colleagues... were all just standing in the queue, suffering. And then, we were late delivering. People just got tired of waiting for the big grandiose vision to come to fruition.
We got the big design approved and built, but we lost all the momentum because no one saw anything until we had everything.
Timeline 2: A Little Bit of Empathy
Immediately, the conversation took off. We started the journey by asking a simple question: what could we deliver immediately to help our teams improve their footing?
Once we knew the first item on the page, we began iterating - evolving our plan, step by step, with the goal of gradually rolling out more features that could be put to immediate use by the dev teams.
The first sprint ended with a rousing success. It was a small feature delivered into production, but it helped one team save a couple hours.
The second and third sprints delivered progressively more features that addressed the needs of several different teams, such that by the end of the first two months, we had a growing user base who was getting real benefit from the tool.
What's more, we had feedback. That user base was grateful for what we delivered, but it spawned more ideas. We had tons of cool feature requests to prioritize and when we got the hang of prioritizing them, we started delivering even MORE value each sprint. We ended up not actually building some of what we had originally roadmapped because we replaced those features with things that our users wanted even more.
Pick your Timeline
You might be tempted to say "well this is a conversation about The Waterfall versus Agile" or "this is about the dangers of over-designing things".
Both of those are valid observations... but they're not what separates the two timelines from each other. Do you see where the divergence started?
Ego versus Empathy.
In the first timeline, "we designed" because "we knew things". We made assumptions, and we built in a vacuum, with no regard for the fact that our tool was supposed to alleviate user pain. "They'll have to wait until we finish".
In the second timeline, "we designed", but then we held those designs loosely. We focused on delivering something useful to someone, who could give us feedback and help us more successfully alleviate their pain. We wrapped every design decision in the perspective of the person who would use the system. We even abandoned our plans in favor of things that they asked us for.
Hang on friends, I'm going somewhere with this
Every kind of design:
- Team/Organizational Structures
- Process Maps
- Tooling Implementation Choices
- Audit Control Interpretations (cough cough, this becomes important later... 😏)
Literally every one of these things can be built with Ego... or Empathy. Your role as a software engineer is to empathize with the people who will use what you build. Thus it follows that you should measure your success in terms of how much friction you remove for others.
That's right, you heard it here first...
Developer Experience is the foundation of successful design.
The next few weeks are going to explore this from a practical perspective. Tune in next week as we talk about something I've observed that needs a dose of Empathy added!
Top comments (0)