Jen Leech, Truss Cofounder, Included in List of Accomplished Women Speakers in Tech

It started with a tweet in mid-April, where tech writer Melanie Ehrenkranz asked the wide world of Twitter for recommendations of women who can and do speak at tech conferences. All-male conference slates and panel participants are unfortunately frequent in many industries, but they particularly plague tech events. Ehrenkranz's tweet received more than 1,500 replies, many with dense little lists of awesome women in tech, all of whom are qualified to speak about subjects other than just diversity and inclusion, important though that is. 

Ehrenkranz released her list yesterday, accompanied by stats about speaking time by gender at major conferences and advice about not tokenizing non-male speakers, speakers of color, and other underrepresented groups. It's worth a read as both a call to action and as a state of the union for attempts at gender parity in tech talks (to say nothing of the list of 1,000-plus smart, accomplished women in tech embedded at the end of the article). 

At Truss, we strongly believe that diverse groups are smarter groups (and are far from the only ones to feel that way), but the article had one more bit of delight for us: our own Jen Leech, VP of Engineering and Truss co-founder, was included on the list. Jen is indeed a strong technical speaker and welcomes opportunities to bring her expertise to your panel or conference. Just drop us a line


Slack, Serendipity, and the #rage_cage

Here at Truss, we rely on Slack for internal communications. Like many other companies we prefer chat to email and Slack over Hipchat. We are a distributed consulting company which relies on chat to keep people informed, connected, and engaged.

Over time, our sense of how to best use Slack has evolved. Some of our innovations have proven much less useful than others; some took on a life of their own. This is the story of how we discovered that a default Slack setup should come with one additional channel that proved more vital than we imagined when it was created.

A bright shiny new Slack team setup contains a channel to which everyone is subscribed: #general.

It’s unlike all other Slack channels because no one can leave it — which is what makes it so useful! You don’t need to invite anyone to #general — they’ll be added automatically when they join the team. (Source)

In addition, there’s a second default channel: #random. As its name implies, it’s there for random conversations, things that you want to address to anyone who’s listening, but not for stuff of essential importance. The difference between #general and #random is the difference between “Payroll is running one day early this month, get your expenses in by the 14th” and “OMG check out this Corgi GIF!” Another important difference is that you can leave #random. If you don’t have time for the chatter, you can turn it off.

So far, so very common, and like many other companies I’m sure, our Slack channels grew from the original pair: channels for clients, channels for projects, channels for the office and games and… some thrived and some died. Natural selection at work.


Among the predominant values of the culture at Truss are transparency, reflection, and candor. We try to be as honest, direct, and intentional as we can. To help that goal we hold periodic retrospectives based on the process described in the digital service manual.

When we started out, having the entire company gather, reflect, and write up post-its which reflected their concerns and delights (both critical and petty) was an excellent way to surface issues we were too busy to address in the normal day-to-day work or patterns that only emerged when everyone got together and shared their experiences.

As we grew, however, the time spent gathering ideas and organizing post-its began to eat up the time set aside for the discussion of the issues raised. In addition, a number of people felt a lack of immediacy, having to wait for the next retrospective. This meant they forgot to bring things up when they were no longer proximate to the relevant event.

While discussing these things in one of our retrospectives, a couple of folks suggested that maybe we could use Slack to help. When things came up, people could drop a post in a Slack channel and the post would get added to the whiteboard come the next company retro.

Thus #retro_good and #retro_subpar were born: landing places for achievements we were proud of and pitfalls we would like to avoid.

Unexpected Consequences

Like all new Slack channels, #retro_good and subpar started off relatively slowly but began to pick up steam. There were reflections on our use of Friday time (our day set aside for personal development).

Screen Shot 2016-12-09 at 5.36.55 PM.png

And areas where we weren’t doing so well

Screen Shot 2016-12-09 at 5.40.28 PM.png

Over time, however, something started to happen that we didn’t expect. Truss is a consulting company, and many of us are out with clients for much of the week. As a consequence we have not made spending money on ‘the office’ a high priority; in fact we rent space in a modern warehouse owned by friends of the company. The place has tons of character and tons of bugs (not literal bugs, the roach count is non-existent, but)--little issues like door handles not quite fitting.

What we noticed happening over a couple of months was that #retro_subpar began to be dominated by complaints about the office…

and these complaints seemed to feed off one another…

This all came to a head in a company retro during which Jamie, the Biz Ops Manager, was understandably frustrated that, no matter how hard he worked, he could never seem to make us happy. We were always griping about something in #retro_subpar.

As we pulled this apart during the retro, it became clear that people were using #retro_subpar not only to record issues that warranted group recognition and discussion, but also just to air gripes and expel momentary frustrations. A couple of people even suggested we should have a #catharsis channel or better yet #rage_cage. We didn’t think much of this at the time but agreed that we probably wanted to keep #retro_subpar to things worth holding on to and not cluttering it with the ephemeral frustrations of life.

An idea with a life of its own

Despite the fact that no-one had really picked up on it during the retro, I liked the idea of #catharsis and a couple of days later decided to set it up. As I didn’t grow up in the USA, the name #rage_cage hadn’t really resonated with me and, preferring alliteration to rhyme, I created #rage_room.

As happens with a new Slack channel, people wandered in and tried it out. They complained about silly things, they tested the boundaries …

and established social norms…

Screen Shot 2016-12-09 at 6.11.42 PM.png

In particular, there were a couple of things that established the essential character of #rage_room; interestingly, both things had their seeds with a company founder.

First was the name and how it got fixed. I had mistakenly called it #rage_room, and there was some discussion the first day about how frustrating it was that it wasn’t called #rage_cage. Later that evening Jen, one of Truss’ founders, joined the room…

Notice the pause between Jen joining the room, catching up with the day’s posts and then responding. At work, Jen has a very focussed demeanor, not humorless by any means, but not gratuitous or wasteful. That “Done and done motherfuckers” had the air of a Zen Master making a point. If you’re gonna rage, do it properly.

The other essential aspect of #rage cage was a slower burn, but again the tone was set by one of the Truss founders on the first day #rage_cage was around.

A silly, shouty post; a self consciously silly shouty post which turned out to be the first of many, until a week or so later.

And since then the #rage_cage has thrived as a silly, shouty, sweary place for people to vent. Rage is essentially silly in the sense of being pointless, shouty, and often sweary, but it is also essentially part of who we are.

A vital part of #rage_cage is that it is undirected and consensual. We do not moderate the language people use, but we never use #rage_cage as a forum for complaining about one another or the work we do. So far we have managed to give vent to the frustrations we saw in #retro_subpar without anyone feeling picked upon or criticized.

As I mentioned, we are a consulting company. We tend to work with customers who have enough of a problem that they can justify paying a consultancy to help them fix that problem. We are passionate about doing the best we can to make things better, but it can be frustrating, since we are dealing with companies and projects in extremis. Sometimes you just want to put it out there that you’ve had a shitty day; to do otherwise, to hide it or pretend all is good, would go against the transparency we value.

#general, #random, & #rage_cage

#retro_subpar & #retro_good have become much quieter since #rage_cage showed up. We still have issues we need to discuss and things we need to correct as a business, but they are far fewer than we often feel. As often as not we just need to yell a bit.

Where chat or e-mail lists have been adopted as a form of corporate communication, there has always been a space of some kind meant for everyone, the #general channel of Slack.

Very quickly, however, companies noticed that not everyone needs or wants to hear everything. Conversation, corgi gifs, and random chat are an important part of what brings us together as teams and communities of co-workers but are something you should be able to opt out of. Slack recognizes this by including #random in the channels you get by default when you set up a new team.

In #rage_cage, I think we have identified a third important part of this social exchange. Since setting up the #rage_cage, and in talking with others about it, we have discovered we are not alone in having a channel for this. Other channels we have heard about in this vein are #yelling and #scream.

A community really benefits from having space to let off steam, somewhere where you can rail absurdly and not to have to deal with someone else trying to fix or take on your problems. It is still importantly a social activity, a product of the community, but not necessarily one requiring a response. If you’re using Slack in your company, you might want to try adding some some flavor of #rage_cage.

P.S. We have reported an issue to Slack coming out of this. Slack insists that channel names are lowercase, as reflected herein. This is not normally a problem except when your channel really really should be called #RAGE_CAGE.


Truss Awarded GSA IT Schedule 70 Contract to Expand Infrastructure Services to Federal Agencies

We are excited to announce that Truss has been awarded a contract on GSA’s  Federal Supply Schedule 70 for IT goods and services. This award enables Federal agencies to work directly with Truss to modernize infrastructure, reduce demands on internal teams, and deliver better constituent services. Specifically, we expect to deliver cloud services, containerization, security and compliance, as well as Agile and DevOps practices.


Truss completed the IT Schedule 70 application through GSA’s new FASt Lane program. FASt Lane launched in the summer of 2016 to help GSA make award decisions with greater clarity, focus and speed. We are particularly pleased with the support and expedience of the FASt Lane program. As a vendor, we saw significant improvement and Truss advocates its use by other modern engineering companies who want to help strengthen our public institutions.

Two Trussels, Nic Wissman and Ari Kellogg, led the effort and their diligence and cat-herding abilities were the key to a successful bid. They also learned lessons about the government application process that will prove valuable for future federal and state funding vehicles. We also want to give a big thank you to GSA Proposal Help, consultants that specialize in helping companies navigate proposals to the government. Our contact Tracie Grant provided an instrumental wealth of experience and attention to detail; we highly recommend her.

Man, ‘splained: 40-Plus Years of Man Page History

Man, ‘splained: 40-Plus Years of Man Page History

A man page is the most common form of Unix and Linux documentation. Despite the name, they’re not exactly what modern engineers expect from more typical product documentation - and they’re also definitely not tutorials. However, with their own particular format, they’ve become a vital part of regular learning and work for most developers, perhaps the most common “M” in the admonishment to RTM. With something so omnipresent, it’s easy to take it for granted - there’s a utility, so the utility has a man page. Of course.

But the history of man pages is tied inextricably to the history of Unix (in fact, they share a birthday) and is threaded through a certain formative era of computer science. Man pages go back to Bell Labs, back to Jerry Saltzer’s doctoral thesis proposal in 1964, back to decisions that were made without the intention of determining the way certain areas of programming would work for decades. And maybe that’s the biggest lesson of this whole story: never treat a solution as a stopgap or a prototype (particularly if you’re working in Bell Labs in the late 60s or early 70s). Your “This’ll do for today” could become the standard for the generations to follow.

Read More

Hanselminutes Podcast: Everett Harper on Infrastructuralists with Truss

I was excited to be invited by Scott Hanselman to do a podcast on Hanselminutes. It was my first chance to talk about The Infrastructuralists, and he's such a great interviewer that it brought out new ideas and ways to connect this way of thinking to everyday practice.

For those of you who are coming from the podcast - Welcome! Below is more background on Infrastructuralists, and I hope you're motivated to add comments, perspectives and feedback.

If you're reading our blog, check out the podcast on Hanselminutes (and check out his other guests too, they're terrific)

Infrastructuralism is the theory that applying modern software to solve societal challenges requires understanding that there is a dynamic relationship between the overarching technical architecture and the experience that humans want from that software. At its heart is a belief that customers and infrastructure are complex — not complicated —and the best response is to shift our thinking to prioritize adaptation, specifically learning, communication and collaboration.

But doesn’t everyone believe this? Let’s take a common example: a CTO of a traditional, heterogeneous IT organization faces a challenge to modernize their legacy systems because they’re losing customers to a modern, nimble competitor. Unfortunately, the solution gets reduced to a piece of technology, a process dogma, or hiring a unicorn. “Hiring a Rockstar Agile Ninja to push everything to the cloud” rarely is the solution, despite the litter of marketing copy on many companies’ websites and job postings. More often, organizations experience slowing development velocity, value-destroying integrations, and optimizationing for vendor convenience not customer expectations.  

In contrast, Infrastructuralist leaders are systems thinkers, not reductive thinkers. Infrastructuralists know that successful solutions involve people, process, and technology focused on outcomes. The outcome that pays is a superior customer experience that creates value for both customer and company. Customers are not just external to the company, but they are also internal operators of that service — staff, workers, builders and maintainers. Finally, Infastructuralists know that they can’t predict every scenario, but they can create systems to adapt and respond to those scenarios.

What else do Infrastructuralists do, believe and practice?

    •    Measure: Infrastructuralists measure the impact of their solutions in terms of time and attention. It is the highest level of respect they can give to a customer or operator. They ask: Can we reduce the time to do a job, complete a process, or answer a query? Can we capture and release the customer’s attention so they feel compelled to ask for more?
    •    Context: They believe an ethnographic approach to customer development is required to make these relationships visible. Infrastructuralists favor context over focus groups to expose problems to solve, jobs to do, and feelings to address.
    •    Prioritize: They build problem hierarchies, start with the highest risk problem, and progress to solve higher quality problems every single week. Why? Because as we progress up the problem hierarchy, the infrastructure becomes invisible. Watch Truss co-founder Mark Ferlatte talk about how this worked at
    •    Share: They share data to make progress visible, share process to shift builders and owners toward embracing Infrastructuralism without fear.

Builders, designers, customer insighters, engineers, and system thinkers: We aim to articulate what you’ve whispered in hallways, riffed over post-conference bourbon, and fought over in budget meetings. You’ve had your hands, code, sticky notes and pencils in this problem, but can’t get across the silos. You’ve been “onto something” for a long time, but been marginalized on the altar of “the way we do things around here.” You’re playing a different game, and the good news is you’re not alone.

You are an Infrastructuralist. Plant your flag, bring your insight and talent, and let’s start talking how to build this.

There’s Method to the Mentoring: Advice from a Teacher Turned Developer

Research psychologist Anders Ericsson has spent decades studying the science of expertise, attempting to answer the age-old question of nature versus nurture when it comes to attaining mastery in a field. His findings indicate that it is not only the quantity of practice that is required to become an expert in something (10,000 hours, if you were wondering), but the quality, which he’s termed “deliberate practice." Deliberate practice involves well-defined, specific goals that are targeted to improve some aspect of performance. He shares in a recent Freakonomics podcast:

“Deliberate practice relies on this fact that if you make errors, you’re going to find ways to eliminate those errors. So if you’re not actually stretching yourself outside of what you already can do, you’re probably not engaging in deliberate practice.”

There are a couple of valuable takeaways here. The first is that errors are indispensable to learning, something I can attest to from my years as an English language teacher. This is perhaps just as true in software development, where one of the first things a programmer learns is how to read and interpret the many types of errors that a buggy program will throw. Both mentor and learner are best served by making space for errors, hiccups, and failures in the learning and teaching process, something that will inevitably happen for both parties.

The second takeaway is the importance of being “stretched” outside of the comfort zone of what one already can do. If you aren’t being challenged to try new things, your horizon will stay right where it is. It’s important to note that being stretched too far can be just as pernicious as not being stretched at all - that is to say, it is important for a mentor to develop the ability to assess the level of difficulty of the challenges being proposed to the learner. Being thrown into the deep end before learning how to swim can lead to a strong adversity to water and in some cases, the desire to never code again.  

Whether you’re interested in becoming a mentor, have been mentoring for years, or are curious about teaching practices in the context of software development, the five pieces of advice below should give you a general idea of what to aim for and expect from the mentor-mentee relationship.

1. Admit when you don’t know something.  

The main question that should continue to surface for a mentor is how to provide enough contextual information without solving a problem for their mentee. In other words, what’s the right balance of challenging versus saving? Being explicit about not knowing something is a great way to avoid unnecessary confusion. By concealing what you don’t know, your mentee is left to assume that you do in fact know the answer and in a desire to succeed, is more likely to conceal in turn what they also do not know. Acknowledge when you don’t know something and immediately provide an explanation of how you would go about solving the problem. Apart from highlighting the role of humility in the error-prone learning process, it can be an excellent opportunity to demonstrate your debugging strategies and encourage autonomy. 

2. Ask and expect a lot of questions.

As a mentor, your objective is to understand why your mentee doesn’t understand something. It’s just like debugging: you need to first recreate the error to understand why and how it’s happening, and from there you can act accordingly. In this case, the “bug” is figuring out the gaps in your mentee’s understanding, and to do that, you need to ask questions. The best mentors are the ones that consistently do this, and it makes all the difference in the world.

If you feel like you aren’t getting enough questions from your mentee, ask open-ended follow-up questions (questions that can’t be answered with a simple yes/no). For example, “Can you walk me through the life cycle of this object based on your current understanding?” is a better question than, “This all makes sense, right?” On the other hand, if your mentee is asking questions at inopportune moments - for example, when you’re explaining something - let them know that you want to answer their questions but ask them to hold off until you’re done. For a great primer on ways to think about formulating and asking questions, check out this article by The Teaching Center at Washington University.

3. Give feedback early and often.

Growth depends on a feedback loop, which is necessary for understanding what we should be doing differently to improve. Feedback can come in many forms - positive, constructive, negative, verbal, textual, tacit, etc. It can be given during a weekly chat over coffee, in an email, and/or in the day-to-day learning process. Whatever the form, it must be given regularly. 

For feedback to be useful, it should be specific, reference clear examples, and provide a context for setting expectations. For example, if you think your mentee doesn’t spend enough time researching answers before coming to you, you could say, “Try spending at least 15 minutes looking into a solution the next time you’re stuck.” If your mentee tends to be vague or disorganized with descriptions of their blockers, you could advise them to take a moment to write down their current understanding of the issue, what they expect to be happening, and formulate their questions before coming to you. Check out Halogen Software’s article on giving effective feedback for more pointers, as well as this article on being radically candid, one of Truss’ core team values.

4. Pair program.

Pair programming is an excellent way to expedite the learning process. It involves externalizing thought processes, modeling workflow practices and debugging strategies, and requires real, live communication about what you think the code is actually doing. On the other hand, it can be slower than working solo, according to this commonly cited study, and feel more unproductive in the short term to some engineers. In spite of its perceived drawbacks, benefits of pairing include improvements in design quality, reduction in bugs, enhanced technical skills, and increased efficacy in team communications.

If, for whatever reason, you don’t find pairing to be particularly useful for the task at hand, avoid taking over your mentee’s computer without asking mid-pairing. In fact, it’s probably a good idea to refrain from commandeering their computer at all. The consistent urge to do so can be seen as a sign that you have the wonderful opportunity to improve your communication skills. I encourage you to take it.

5. Use your words.

When you find yourself explaining something multi-faceted or particularly complex, it can be easy to fall into the anti-pattern of not externalizing your thought processes. From a mentee’s perspective, this can look like you staring at your screen in eery silence. In these situations, it’s a good idea to either take a moment to yourself to collect your thoughts or make a conscious effort to share aloud what you’re doing. The way in which you explain what you’re doing can make a huge difference as well. For example, “I’m extracting lines 79-85 to an external method” is not as informative as, “This code repeats itself in a few places, so I’m going to refactor it to be easier to read."

Additionally, it’s probably a good idea to filter out the following words from your vocabulary when talking with your mentee: obviously, just, easy, and super easy. It will take a little practice, but being conscientious about not using words that inherently impose expectations and pass judgement on someone to whom what you’re talking about seems to be the exact opposite of ‘obvious’ is not a bad idea.


Needless to say, the success of a sustainable mentor-mentee relationship is directly dependent upon trust and confidence: both parties must be able to trust that the other has their best interests at heart and have confidence that the process will yield results in the form of measurable growth. Through admitting your gaps of knowledge, providing regular constructive feedback, pair programming, and being conscientious of the language you use, you will undoubtedly become an invaluable resource for those learning from you as well as those working with you.

Just as your mentee believes in and respects your abilities, you too must respect their ability to grow and believe in the skills that have gotten them to where they are now.

Truss CTO Mark Ferlatte's Talk from the 2016 Percona Data Performance Conference

At this year’s Percona Data Performance Conference, Truss co-founder and CTO Mark Ferlatte took a critical look at the default settings in my.cnf, the MySQL config file. 

In this talk, Mark explains the fears and hopes that go into creating defaults – and some MySQL defaults you can change today to get your own MySQL experience to better work for you and your goals.

Truss Op-Ed on 18F & USDS in GovTech:

Mark and I wrote an op-ed, Attention on 18F: The Bridge to Modern Government is Built from Both Sides for GovTech, with big assists from Trussels Nic Wissman and Breanne Boland.

As some of you know, 18F and USDS are charged with helping transition government from legacy to modernized technology, processes, and systems. It's a big problem: Seventy-one percent of our $51 billion non-defense IT projects in the next 12 months will be spent on maintaining outdated legacy systems. And from our experience with, we know there's tremendous benefit to taxpayers and the agencies themselves.

There's a lot of momentum, which means there's also resistance. There was a congressional hearing about the role of 18F, prompted by organizations representing incumbent vendors who tend to benefit from maintaining those legacy systems, some of which are over 40 years old.

Here's our position: the way forward is to build a bridge from legacy to modern systems. That experience exists in the private sector. However, this transition has to come by working with -- not in spite of -- the mission-driven objectives of the agencies.  We offer training for agile development, write software to automate processes within complex compliance regimes, and work elbow-to-elbow with teams to solve problems.

The urgency to make this transition is clear, and we're excited to be part of the solution, along with 18F, USDS and a growing number of modern companies dedicated to bringing great service to the US taxpayer:

Routinely measuring and examining the impact of government agencies is critical to ensuring taxpayer dollars are used in a way that’s worthy of the people who work every single day to earn them. But what we should also recognize is that we live in a “post-waterfall” era, and working toward a solution requires changing processes and definitions of success to match our current era — not 2006, not 1996 and certainly not 1966.

Talking with Fortune's Ellen McGirt on building diverse companies, weak ties & Slackbots


I talked to Fortune writer Ellen McGirt about diversity and inclusion at Truss, using Weak Ties to find great candidates, and how we used a humorous SlackBot to call out gender bias.


Sign up for Ellen’s ongoing newsletter Race Ahead-- she building a definitive site for thoughtful reporting and conversation.