This is the story and process of an engineering team, left underfunded and underequipped, scaling a platform and having fun doing it.

1. Architecting a Better
Knowledgebase
A Pragmatic Solutions Engineering Story

2. Who am I?
I am:
• Joseph Marhee (@jmarhee on Twitter), part of the ecosystem engineering team at
Packet Labs
• Previously a developer, infrastructure engineer, and solutions engineer @
DigitalOcean, Platform9 Systems, Recurly, and IBM Cloud. (Relevant for reasons I’ll
explain in a moment)
• Many Loves to make technology accessible to end-users.

3. What is a Knowledgebase and Why do you
need a “better” one?
Your team’s collective knowledge It needs to grow, adapt, further
collectivize, index, become accessible

4. Why we needed a better knowledgebase
Constantly putting out fires (reactivity), with
middling user satisfaction despite high resolution
rates. Siloing!
We needed a path to proactive engagement to
solve Problems of Scale, Problems of Perception.
The solution to this sense
among customers that they did
not have technical partners was,
simply, to do better.

5. Are we asking the right questions?
Resource constrained!
Problems of scale!
Problems of Perception!
Existing frameworks, CSE wisdom, and CRM tooling was
not going to help!
How does having 3 people help or hurt?
Can a massive cohort be effectively served?
Why do customers see us positively, but not prod-ready?
How do we amplify our impact?

6. What builds a better knowledgebase?
What does this look
like?
One way is a process for
conceiving, and
delivering solutions to
your users, via…
Framework-centered
use of your team’s
talents and interests
Creating systems
supported by the belief
that trust with
consumers is
sustainability.

7. The Theory
I believed (having taken a cue from—new to me- self-help/sales literature) through:
data, knowledge, and wisdom
we could solve problems, and when we couldn’t, we could “[leave] a trail of trust
behind” with every account touch.

8. Data
Data is the raw information collected from
customers (context from tickets, emails, things
you’ve observed about their account, everything,
possibly actionable or not)
In practice, I call this Discovery– don’t review the
data, just collect and observe it.
Source: #WOCinTechChat

9. Knowledge
Knowledge is the process by which we assess the
data, begin to understand it, contextualize the
input.
In practice, this is Iteration; Assume nothing,
avoid getting defensive, this is where empathy is
important to foster.
Your team, through this process of iteration on
knowledge should cultivate new knowledge for
everyone, but a team SME for the account’s
domain is crucial for use in repeated use.
Source: #WOCinTechChat

10. Wisdom
Wisdom is the state where you understand the
problem and, in a theoretical universe where a
solution exists, you know what it is and how it works,
and are ready to collaborate to implement, re-iterate
(if needed), and are capable of making these
evaluations.
This application is Delivery; You make a proposal to
your customer, for them to accept and implement, or
reject and collaborate on getting closer to the mark.
This is not the end of the job, but the lifecycle of one
component in a pipeline. Source: #WOCinTechChat

11. Stitching it Together
Your team can enable this process, to operate
cooperatively, by developing in these roles, becoming
SMEs, but also operationally for this process, for
example (amongst others):
• An administrator (could be a customer’s TAM, or
just someone leading the charge on an incident) to
tap the appropriate experts, teams, etc. over
• An orchestrator (usually a solutions engineering
tech lead) to oversee the process and peer review
knowledge-backed solutions before delivery!
We documented everything, wrote playbooks, even
built tools atop this framework, and these roles!

12. Keeping it Together
Things you can do to be sure you’re helping:
- Conventional wisdom of tracking touches, and noting
how it went
- Visualization of things like completed enhancements vs.
rate of ticket closure, or if proactive touches out weigh
reactive responses.
- Develop a formula for a Health Score
Pay these learning experiences forward to your dev
community:
- Re-package delivered solutions (i.e. Ansible playbooks,
Terraform plans, etc. you might have scripted; write
blog posts about the utility to platform)

13. Satisfying, not merely correct, solutions
It’s okay to say you don’t
know, and you have to
accept you can’t always
deliver; It’s a process
and relationship.
Tap your team’s
knowledgebase; you
won’t be right 100% of
the time, but the odds of
finding an answer might
be.
Share findings with
customers, find ways to
proactively reach out,
personally (“Hi, you
might be interested
in…”)
Examine biases,
question assumptions,
and collectivize findings
for faster iterations and
maximizing reuse of
solutions delivered

14. Conclusion
Using a framework built on the principles of Data,
Knowledge, and Wisdom, to deliver thoughtful, well-
considered, and most importantly cooperative solutions
to your users, you also:
- Afforded your team the ability to see themselves as
shards in a better, itself cooperative, knowledgebase.
- Allow your customers to view their experience as
more nuanced by offering the ability to partner in the
process.
- Expose the customer perspective to engineering
teams, product teams

15. Questions!
Feel free to address questions to me privately as well after we’re done, or via:
Twitter: @jmarhee
LinkedIn: josephmarhee
Slides can be found here: [slideshare when I finish maybe]

16. Thank you!