Blog

forget

Tickets to Never Forget

Our last blog post discussed the “dreaded demo,” (integration, testing, QA, etc) and that its creation should define a sprint’s status as “complete.” 

But this is not the only thing that teams fail to account for when scoping a project or sprint. Those blind spots, the tasks that are not tracked, are the focus of this article. What is the work that must be done but is often either forgotten, not documented or not officially accounted for – thereby leading to sprint overruns or quality issues. Even worse, what are the assumed implicit tasks that end up being overlooked/un-discussed – leading to major visibility issues, ultimately, to incorrect assumptions (to assume makes an ASS out of U and ME) regarding the ultimate goal of your team.

Meetings

There is a movement to eliminate or minimize meetings (and meeting duration) currently ablaze on social media. But independent of this movement, most teams still have scheduled or predictable conversations that are part of most sprints/quarters/cadences. These can be sprint-related (planning, scoping, retrospectives), architectural planning to unify a direction, customer discussions/emails, reviews, company wide meetings etc. These all take time. And often, there is prep-work for each meeting. 

All of these interactions should be documented in tickets (JIRA, Gituhub, etc). If there is an Epic for a new feature, there should be a Story that is a planning meeting. And, there should be  another ticket for any prep work or research in preparation for that meeting; maybe a 3rd ticket to record meeting notes (or maybe one story with 3 tasks – the construct doesn’t matter). Just as the “trendy” fads for meetings (discussion of 30 minute meetings only, or no-slides, or send notes before hand) are capturing aspects OF those meetings, so should any ticket. If the meeting is 30 minutes, make sure the points for the meeting is corresponding. Prep work before hand/after should also have a ticket. And if that ticket wasn’t created at sprint planning, add it after – so that the sprint DOES REFLECT what actually happened  (and maybe why things ran over becomes clear). Consider adding a TAG for tickets made after the sprint started, to capture unexpected additions (not to assign blame but to uncover where work is coming from to make future predictions better).

People often leave these out as they feel secondary to your “real work” or because the point/hour system make them seem unimportant and therefore “invisible” in the broader scale of points.  But don’t let that fool you. These tickets don’t need to be large, or have high hours/points – but pretending they don’t exist is a big problem because that impacts productivity. Even company wide “all-hands” or an “off-site” takes time away. 

We are not advocating for MORE meetings or LESS all-hands…. But if your velocity is 65 points (or whatever your unit of measure happens to be), then if there is an all-day meeting or if monday is your retrospective/planning day, make sure you account for the time spent on those activities and to any foreseeable meetings (e.g. a design review, or architecture designing) that are part of the tasks assigned to a given sprint.

Debt

Deadlines exist and they are an inevitable like death and taxes. While we all would love to design and build n the most robust solution,sometimes we must use metaphorical duct-tape and spit to get out the door. These stop-gap measures lead to accrued technical-debt or design-debt and this is often forgotten once the deadline is met. To prevent the debt from getting out of control,  for every major release (of a product or feature) we create an epic called ABC-Debt. Every story in this epic is created when someone makes a short cut such that we all remember to refactoring and refinement later on. 

Therefore, before that team works on feature 2.0, we make sure to take technical debt off the backlog. If a team-member leaves (because there are other good jobs) a record of each  limitation exists within an annotated ticket and let the team know about blockers This isn’t perfect, and sometimes things are missed – but without recording your debt, you won’t know where there might be a hidden bomb in your product that could easily turn the next great feature from a 4 week project to a 6 month quagmire.

Project Management and Backlog Grooming

Someone always has to clean up the mess around the house. And every sprint the team makes a mess in the backlog. And just like the dishes, if you leave them dirty for too long they develop intelligence, invent fire, and start working against you.  Controlling that chaos is something that must happen every sprint.

 

In theory, every team has a project manager whose sole job is to run sprints, manage the backlog, etc. In theory, that person is using sprints to manage their own time as well. But we have found that most teams lack a project manager, leaving this work for the team leaders, so this tip applies to team leads as well. Set aside time for grooming every week (minor upkeeping) and a larger task every quarter (for a really deep clean). The Project-manager/team-lead will see things that slipped through fingers, find un-finished loose ends, and most importantly, keep abreast of all of the work your team HAS accomplished.

To validate that this clean-up has occurred (and wasn’t just ignored or paid lip service) ensure accountability. Team-leads/Project-Managers should report the current roadmap/schedule/delays to the VP of Product and/or Engineering at the end of every sprint. And at the end of each quarter, this should be reported to the CEO/GM. This hard-accounting is vital visibility that leadership needs to make decisions, and assures that that when the CEO says “hey when is X coming out” that prep work was (at worst) done 7 days ago, and is ready to surface right away (instead of hours of scrambling to answer a seemingly simple question).

Documentation

We were all taught in school to document our code and designs. Use good variable/layer names. Be consistent, and if anything, document first code/design after. Then we got to the real world and getting products done is the primary  task. But 9, 12, 18 months later (or if you are successful 5-10 years later), the team is unlikely to remember how a random function works (or the motivation behind a given design). That documented/written personal and/or group knowledge is invaluable and allows a team  to make changes faster and fix bugs more easily s even if the original author is no longer part of the team .

I know justifying documentation isn’t the point of this article, but seeing documentation fall by the wayside because it “was not a priority,” simply cannot be an excuse. When you are creating your projects, make sure to add some stories for documentation. Explicitly set aside time to annotate and explain what you created. Then when sprint planning occurs, or leadership wants to know how long something will take – you can look at the epic and say “this is a 2 sprint epic” and know that at the end of that sprint, it will be working AND be able to be supported.

In other words, start looking at sprint management as team management. It should capture everything your team must do to build and support your product – now and in the future.

CONCLUSION

So lets summarize some key take aways of things to ALWAYS track to better manage your company, more accurately predict releases, and ensure high-quality product creation:

  • Add sub-tasks to tickets for PRs, testing and integration as part of every ticket to amortize this work [from prior article]
  • Make internal live demos happen at the completion of every sprint [from prior article]
  • Make documentation of code and architecture happen (and track as tickets) as part of every sprint – and a completion criteria to prevent loss of tribal knowledge and allowing better collaboration between team-members
  • Add Sprint/work/ticket related meetings as tasks in your management system to track the full scope of how much time it takes to complete a project
  • Add company-wide meetings as part of your management system to track its impact on available points/time
  • Have a repository epic for technical debt (to be cleaned up) from the current release/feature as a method to track future work, and ensure it is picked up and resolved at the next opportunity
  • Every sprint AND quarter grooming should occur (and be tracked as tickets) to ensure a clean and organized back-log
  • To ensure visibility, better predict release schedules and make sure grooming occurs, present backlog and velocity information to VPs and CEO on a semi-regular basis

Cover Image by Fabrizio Frigeni on Unsplash

new years

Happy 2020 from Kleeen Software

Happy 2020 from Kleeen

From everyone at the Kleeen Software family to yours, we wish you a wonderful and successful 2020. 

Looking back at 2019, KS has had quite a year. Our company secured pre-seed funding, grown to 14 full time team members, 1 part-time, 2 interns, and a distinguished and accomplished board of advisers. We have launched our podcast series Kleeen Talk, and our blog series on how to better create mange and build b2b enterprise products.

Thank you to everyone (especially our friends and families) for making 2019 a year we can be proud of, and we look forward to 2020 bringing new challenges!

Cover Image by Roven Images on Unsplash

dreaddemo

The dreaded demo?

Nothing is more scary than the words “live demo.” As developers, designers and product managers – we all focus on how they fail. But what if –  and hear me out – we thought of demos as the mechanism by which we succeed? Whether you are presenting a new feature or in the development process, demos should be thought of as the forcing function to highlight what your product CAN do, and if done right, can be the way your team is brought together.

Let’s take a step back. What makes the live-demo occur? 

  • A customer wants to see the first iteration of a new feature that just was pushed out.
  • A product manager or upper management asks to review the latest build (which may or may not be stable)
  • An investor wants to know what you are doing with all their money

All of these demos make the assumption of a completed “something.” The demo is thought of as a culmination of some work, effort, and time. And, in many situations, it is the ONLY manifestation of  various components coming together.

During the panini press of a product, the team uncovers challenges with integrations, missing testing, edge-case checking, scripts and use-cases that have not yet been considered. Teams often find out that, yes, the spec could have been better, and yes communication with testing could have been better – but they weren’t and it wasn’t. Inevitably – unfortunately sometimes with some sleepness nights – these issues do get resolved.

Now imagine that instead of the external requirement for “live demos”, these were integral development process steps. What if every sprint’s goal was a fully integrated, front-to-back, live demo? This may mean that at the end of the sprint, your team MUST show a widget, for example, working in a real flow. If you are in middleware, the UI must consume your output, and you must handle real data from the backend. UI components must be able to be handled by someone that is not you. Back-end teams must handle real (not synthetic) data, with real parameters. And this must be done IN PUBLIC. This must be shown-off to both your peers and leadership.

Your testing and integration work has been amortized. People do not have (as many) sleepless nights. And your estimates for completion time now are more realistic as the explicitly factor in integration, testing, etc from the start. 

Jump 6 weeks in the future to the inevitable request to see the latest and greatest. You can dust off the latest build with confidence:you know it is stable, you know it is tested, and you know it will impress.

Cover Image Photo by S O C I A L . C U T on Unsplash

creativeNext

Creative Next Podcast Feature Article

Amy Yoshitsu, our VP of Design, was invited to participate on the Creative Next podcast series. Creative work is being disrupted by a seemingly unlikely force: automation. Each episode introduces you to a compelling innovator who offers a new perspective on critical issues related to our creative futures. 

Amy’s episode (SEASON 03 EPISODE 04) was entitled AI DESIGN FOR THE ENTERPRISE.

Amy Yoshitsu, a Founder and the Head of Design for Kleeen software, joins us to talk about their vision for using machine learning to automate a variety of design and engineering tasks for enterprise software.

Thank you Dirk Knemeyer for an engaging conversation and inviting us onto your program. 

designSystemChaos

Design Language System | Growth without Chaos

The arena of UX Design tools is growing – both in quantity and functionality – to empower designers to more precisely convey their creations to development teams. This expansion is driven by the increasing requirement to design and build visually pleasing products that allow instantaneous understanding of complex functionality. Consistency in component styling, micro-behavior, and page layouts are key to facilitating usability but they can also be challenging to maintain, especially as product requirements grows. To support the necessary clarity and thoughtfulness during the creation phase, more design teams are implementing design language systems. At minimum, these are libraries of components with documentation of the patterns and contexts that leverage the components.

While there are many possible tools for and approaches to building a design language system, this article will focus on tips when building upon an established component library in Sketch. In order to mitigate design language system confusion, of which teams can be at high-risk when rapidly iterating on mock ups and integrating new concepts and components, I have outlined three goals:

  1. Maintain component name consistency in library files so that they adhere to the constantly evolving vocabulary rules
  2. Allow designers to easily identify and customize subcomponents in mock ups (in Sketch, these are known as Overrides)
  3. Ensure designers are able to navigate the library files and have easy access to the most current version of each component 

While Sketch plugins (and products built to integrate with Sketch) will be the methods described below to achieve these goals, there are many other products that could provide the same functionality.

 

Maintaining Component  Names

As library components, known as Symbols in Sketch, increase in quantity and as their compositions change, vocabulary used in the names of both artboards and layers may need to be adjusted to more precisely describe categories and variant. No matter a design team’s naming protocol (clearly described in detail in design documentation, of course), groups of existing Symbols’ names will need to be modified. To do this, I recommend two Sketch plugins:

  1. 🕵🏻‍ Find and Replace Text plugin for Sketch by chriswetterman
  2. Rename it by Rodrigo Soares

Both plugins allow designers to use a Find and Replace functionality to update a string of text immediately for every instance; one-at-a-time per instance; or immediately for one or more selected artboards/layers. 

A few bonus advantages of each:

The Find and Replace Text plugin allows a designer to not only search at the page-, artboard- or layer-level, this functionality also applies to override values. This can be especially useful for updating placeholder text in nested Symbols. 

Find and Replace Text plugin can bulk modify override values.
Find and Replace Text plugin can bulk modify override values.

 

The Rename It plugin allows designers to not only add or modify custom text string prefixes and suffixes, but it also provides the option to integrate useful, dynamic values to artboard or layer names such as a layer’s width, a layer’s parent name or sequential numbering. 

Rename It plugin provides dynamic prefixes and suffixes.
Rename It plugin provides dynamic prefixes and suffixes.

 

Maintaining Easy Use of Overrides

Consistent naming and ordering of nested Symbol layers is vital to making sure that overrides are easy to modify during a designer’s workflow.  Often, it is useful for different Symbols to have the same names when they are nested in and layers of other Symbols, and when they perform the same semantic use in these Symbols. For example, different Symbols may be used for the purpose of ‘title’ within multiple, more complex Symbols, but, as a user of these components, a designer only needs to know in which field to input the ‘title value’ within the Overrides panel. Therefore, all “sub-Symbols” used for title-purposes, may have the layer name “Title”. Eventually, it may be necessary to change all nested Symbols/layer names from “Title” to “Header”. To do this, I recommend the Select Similar Layers plugin, by wonderbit, to instantly select all layers with name “Title”. (Without this plugin, the desired layers would have to be individually selected, which can be a tedious and time-consuming process especially when there are hundreds or more layers.) Then, either of the renaming plugins can do the rest.

Select Similar Layers by Name
Select Similar Layers by Name

 

Additionally, since the order of Symbol layers also facilitates better or worse usability for a  designer working with overrides, the Select Similar Layers plugin can also be useful in bulk reordering layers. For example, for designers immersed in cultures that read left-to-right, the overrides should be listed top-to-bottom based on the sub-Symbols’ layout order from  left-to-right or top-to-bottom. If a change to the library causes layers of the same name or properties to be out of order within multiple Symbols, the Select Similar Layers plugin can batch select to allow for a batch layer reorder. 

 

Ensuring Everyone is Synced 

Once all Symbols have been modified and organized at the artboard level and below, the page may have to be reorganized. The plugin Symbol Organizer, by Jason Burns automates this. It visually orders artboards by group level (identified by the “/” in each artboard name) as specified by the designer. By organizing the Symbol artboards, both in the layer list and visually in the main editing area, other designers should be able to easily navigate the library file.

Symbol Organizer plugin organizing artboards.
Symbol Organizer plugin organizing artboards.

For design teams larger than one, lone multifaceted designer, it is important to ensure that design language changes are accessible (as soon as possible) to all other team members. In order to avoid extra work or confusion that can be caused by using old or the wrong versions of components, there are now a growing number of tools that allow designers to sync, see a history of changes in, revert and see diffs between Sketch files; essentially these are “git for Sketch” tools. While there are multiple options out there, I have used Abstract and Versions by Sympli and they both provide the ability for designers to see all the changes to a file and access the most up-to-date “source of truth”. While version control is is an extremely valuable function to have when collaborating on mock ups, it is vital to the process of transparently and seamlessly scaling a design language.

Cover Image Photo by Erol Ahmed on Unsplash

valueOfDesign

The $$$ of Design

The battle cry for so many companies has been, “Design is so important—but we don’t have the time/money to do it.” And even for those who do find design resources, in nearly every instance they want a “quick mockup” so engineering can go build it. Validation, customer feedback, testing, and idea iteration are left to fall by the wayside. In this article, I am going to convince you it costs far more to not do design, then to include it.

Now, much can be said as to why software teams decide to omit design and design methodologies from their process (see our blog post on the Egocentric Intuition Fallacy); however, this article is not about the why. It’s about the actual cost. How much could/should it cost to include design—and how much to omit?

TLDR? - Click for the Infographic

valueOfDesignInfoGraphicHero

By the Numbers

Let’s start by looking at direct costs to make one new “feature” for an existing solution, or an MVP to launch a new product/company. Everything presented herein assumes a very “lean,” albeit optimistic, execution.

$4.1k/week

Senior UI Engineer

$4.1k/week

$163k/year + benefits (~30%) = $212/year

$4.3k/week

Product Manager

$4.3k/week

$172k/yr + benefits (~30%) = $224k/year

$1.5k/week

Sales Representative

$1.5k/week

$60/yr + benefits (~30%) = $78k/year

NewCo’s Project

You are building a product, and you are super lean. So let’s look at the cost to build your UI. Since you are so lean, let’s assume you have only one UI engineer building your product. One Senior UI Engineer in S.F. (a very expensive market) costs $4,100/week. Engineers are notoriously expensive. 

As an aside, many companies look to off-shore engineering consulting firms as an alternative to reduce costs. In my own experience — both running my own firm and hiring others — with engineering consulting in US-compatible time-zones, such as Central and South America, you are generally going to pay around $3k/week per engineer. Most firms strongly suggest hiring more than one engineer, usually around three, so let’s say $9k/week. With an engineering firm, your higher costs come at the flexibility to scale up and down your engineering efforts as needed. Often, these firms, like the design firms, can bring on team members with specific skills to augment the skill sets of your current team. So given the increased costs, let’s assume you stick with your one FTE.

Your one engineer hits the ground running Day-0, and you tell them exactly what to build (no design work done). Being super optimistic, they successfully build your entire UI in three months. Wow! That is crazy fast—but good job! Your initial cost is $49.2k. 

You’re excited and you start showing off your product to customers; but, something goes off script. Your customers do not understand what your UI is showing them. They are confused. They misunderstand the data you are showing in your visualizations. They can’t figure out how to navigate your dashboards, let alone your product. You are spending many, many hours of your time, and your sales team’s time coaching your customer on how to use your product. And only then, after a week or two, your customers say, “Yeah, that isn’t what I want.” How much did this mistake just cost you?

Remember that cost is more than just money spent on a developer. It is also your time and your team’s time. So in this situation, your Product Manager has spent 10 hours a week for a month working with your customers at a cost of $4.3k, plus your sales rep adds another $1.5k for sitting in on those calls. You have thus spent $55k to build the wrong thing. But, it is actually worse than that. Your UI engineer has spent a month enhancing the very product that went in entirely the wrong direction. Moreover, it is likely something that you no longer need.  Consequently, you just added an additional $16.4k to your costs. Your running total is now $71.4k over 16 weeks, not including potential backend dev costs. This will be our benchmark cost for engineering without design.

Secondary Costs

If a cost loss isn’t a deterrent in itself, don’t forget to factor in your qualitative costs: lost time and damaged perception. Your company has spent four months going in the wrong direction, and you’ve lost four months to competitors. How much does this cost you? How much does it cost you to misunderstand expectations in front of your customers? You have misused your time, your company’s time, and you have wasted your customer’s time. To add to the hurt, you now appear less knowledgeable. Yes, you may have learned something about what to do, but it also demonstrates that you didn’t know what to build at the onset and you’ve expended your finite resources. This is a hard lesson in business, and especially for startups.

Quantifying these “losses” is not easy. But as a proxy, let’s factor in the added cost to fully rebuild your solution the right way (assuming you now understand both the question and the answer).  For simplification, we’ll put this cost at $49.2k for another three months of UI development. This may be overestimating the raw cost since some of the original work could  be salvable, but is underestimating the cost for lost customers or your competition gaining ground. Running total costs are now $120.6k—which took 7+ months to get the “right” idea out. And of course, if you again want to validate your next idea (and let’s assume you are correct) you adding another $5.8k. Bringing your grand total to $126.4k over 8+ months. You have now slipped your release train. This here is a major reason where and why companies have slippage. 

True Cost (Savings) of Design

Using the same scenario, lets now include design into the process. One User Experience Designer in S.F. averages $2,900/week. 

For contrast, the UI/UX/ENG consulting company I co-founded would put together a small/mid-sized engagement (with multiple team members) at around $14k/week. That is clearly more money, but the time/pay commitment is shorter and you get multiple, specialized skill sets. My consulting company is smaller, so larger firms (which I have worked with on the other side of the desk) may charge more than $20k/week. All-in-all, design costs money. In exchange for the higher cost, a design firm with multiple team members ensures more ideas are explored and iterated on, more designs outputted, and you will most likely have the best skills available for each stage of the design process. A design firm can also run user testing for a more objective analysis. 

$2.9k/week

UX Designer

$2.9k/week

$115k/year + benefits (~30%) = $150k/year

- vs -
$14-20k/week

Design Firm

$14-20k/week

small/mid-sized engagement

Let’s assume that it takes your FTE or design consulting firm 6-weeks to apply best-practices and design your solution. Had you hired an FTE designer, you would have spent $17.4k, and if you had hired a design consulting firm you would have spent $84k. Either way, throughout that 6-week window you would generally have a few iterative rounds, hi-fidelity mockups, and the opportunity for your sales team or PM to gather customer feedback before any code was written. 

If you then spend three months building what is designed ($49.2k) your cost would be $66.6k with an FTE or $133.2k with a consulting company.

Let’s put this all together

$66.6k + 18 Weeks [CHEAPEST]
cost for building the right thing once with an FTE

$71.4k + 16 Weeks [WORST OUTCOME]
cost for building (likely) the wrong thing and finding out it is bad

$126.4k + 32 Weeks [LONGEST]
cost for building (likely) the wrong thing and just building the (hopefully) right thing after

$133.2k + 18 Weeks [MOST DESIGN]
cost for building the right thing once with a design firm of multiple skills

Weeks Required

UI Eng only
UI Eng + Design FTE
UI Eng + Design Firm
UI Eng + ReBuild

Cost Required

UI Eng + Design FTE
UI Eng only
UI Eng + ReBuild
UI Eng + Design Firm

Now of course, if everything is perfect and you build the right thing first time out, fantastic. But Silicon Valley is all about “failing fast.” Which is faster? Failing two weeks into a project with mockups and reassessing, or seven months deep into building the wrong thing a singular time?

Additional Real-World Factors

Let’s now explore some additional real-world factors that only make the delta between design and no-design abundantly clear.

Longer Build Time?

Let’s hedge our bets a bit. Multiply this up to a six or nine month development cycle to create one new “feature” for an existing solution, or an MVP to launch a new product or company, and things look start looking even worse. Why? Design length does not map directly onto build length. Design costs are generally fixed. If it takes 6 weeks to design a flow—no matter how long it takes to build—it still only takes 6 weeks to design.  

If we consider it will take 6 months to build the UI, our engineering costs have now doubled to $98.4k, and the percentage that the design costs contribute decreases.

$115.8k + 30 Weeks
cost for building the right thing once with an FTE

$120.6k + 28 Weeks
cost for building (likely) the wrong thing and finding out it is bad

$182.4k + 30 Weeks
cost for building the right thing once with a design firm of multiple skills

$183.8k + 56 Weeks
cost for building (likely) the wrong thing and just building the (hopefully) right thing after

It is exceptionally clear that design adds a minimal cost and may be even cheaper than not doing design at all. And—perhaps surprisingly—is faster.

More Considerations

Now of course we can have UX researchers run user studies employing techniques to mitigate bias as to what customers need—not what they want—and testing ideas early. This has a force-multiplying effect to the above equations, as this type of work flow can happen in parallel, saving even more time for minimal costs.

But there is a whole other side to this equation that most people gloss over: the value of design. All of the above considerations are brutal cost comparisons.. But how do you measure the value-add of design? Luckily, there is a way. The Design Value Index or DVI measures just that.

Design Value Index (DVI), based on a portfolio of 16 publicly traded stocks from companies considered to be “design-centric” contingent on a set of criteria that reflects best practices in design management, shows a 211% return over the S&P 500.

Credit to Design Management Institute
Credit to Design Management Institute

These companies put design at the forefront of what they build. And through a collection of factors (adoption, user preferences, retention, etc.) you see a huge amount of success that can be attributed directly to design.

Conclusion

Pragmatically, early design work can save you money, allow you to fail faster, and over time, pay dividends to your success over your competition. Instead of saying, “Design is so important—but we don’t have the time/money to do it”; maybe say, “Design is so important—we don’t have the time/money to NOT do it.”

This article was written in collaboration with Kleeen Studio.

Cover Image by Alvaro Reyes on Unsplash
Additional Photo by Med Badr Chemmaoui on Unsplash
Additional Photo by Luca Bravo on Unsplash
Additional Photo by Marvin Meyer on Unsplash
Additional Photo by Maarten van den Heuvel on Unsplash
Additional Photo by Artem Beliaikin on Unsplash

remoteTeams

A Kleeen Culture | Building a Connected Team

I was recently talking to another CEO at a VC mixer event, who was lamenting the forthcoming challenges she will be facing with a startup that will soon span multiple countries; in particular, the company culture test. How do you create the feeling of a team, and a shared mission, when you don’t even share the same country let alone the same office? (Our entire team actually work from home, much like InVision, so there is no main office).

As I reflected on her pointed question, my thoughts coalesced into three key pillars we have used at Kleeen Software to build a strong and well-connected team: Owning the Outcome, Team Transparency, and Wielding Your Superpower. These are the three facets of a concerted effort by our leadership team, not just myself, which have disseminated to every individual at Kleeen.

Owning the Outcome

Let me begin by addressing the most obvious aspect of this first: equity for everyone. Every FTE at Kleeen Software has equity in the company, with those who joined earlier having a larger equity grant than those who join(ed) later (we are roughly tying equity levels to funding rounds). This both rewards the risk inherent in joining a startup (with more reward for those took the greater risk of joining earlier) and gives everyone in the company the very concrete feeling of it being THEIR company, and therefore their success if we have a great exit.

But the concept of Owning the Outcome goes beyond the explicitness and simplicity of equity. This mantra is inspired by one of my PhD committee members, Dr. Jiawei Han, who always tells his research lab that, “the success of the individual is the success of the team; and the success of the team is the success of the individual.” This is an eminently pragmatic creed that we live every day at Kleeen Software. Mario ( VP of Engineering), Amy (VP of Design) and I all make it very clear for each team member that identifying the problem, stress-testing all foreseeable use cases, and scaling the implementation are all of equal importance to individually implementing a solution. The successful outcome of every particular solution is guaranteed to require the input and effort of others on the team. And every better quality solution improves the quality of the company offering. In a very practical sense, we all own the outcome of this company.

A corollary to this mantra is the rejection of the notion of rewarding “major” contributors over “minor” ones. Who is a minor contributor? Someone whose role is small, or who is not succeeding in their role. Why would you allow there to be any minor contributors on your team? If someone is adding minimal value, taking a long time to accomplish their goals, and requiring extensive management that takes major contributors’ attention away from their own work, they don’t belong at your (startup with limited resources) company. Therefore, we consider that we do not hire, or keep on, “minor” contributors. Documentation, QA, DevOps, Analytics, Design – these roles all provide a major impact to our team, and are treated as such. Currently, as an early startup with a relatively small team, all Kleeen Software team members are creators. We are sure to require more maintenance, communication, and support roles as we grow. But we will not view the people who are maintaining the quality of our product, ensuring the satisfaction of our customers, and facilitating our new exploits as any less valuable.

We all share in the company’s success. Everyone took a pay cut to join early, to work on something big and exciting. Everyone will get a raise at the next company milestone (securing our next funding round). Everyone’s critical value to the company will continue to be explicitly called out. Everyone will have no doubt as to the importance of their role and that the collective effort is what propels the company forward, and in turn, their professional/reputation and financial success.

Team Transparency

We strive for full team transparency at Kleeen Software. What is the company doing? What are we telling our customers and investors? How is pay calculated? What is our funding roadmap? All these topics are discussed openly with the full team. We also try to be clear about why we pay what we pay. As I have told everyone, my goal is to pay you enough that you aren’t going to leave Kleeen Software due to a paycheck – but you will not stay for the money either, at least not in the short term. You will stay because the work is exciting, challenging, and a valuable experience. By explicitly setting role expectations and explaining the company’s value propositions we ensure that you stay at the company with your eyes open, and leave because you have truly found a better opportunity for yourself (which we will all be excited for you to have found, though disappointed to loose a skilled team member).

As a personal point of pride, we are open about promotion. As team members demonstrate their growing knowledge, execution, and ownership of their work, we promote them. We are clear about the largely quantitative requirements, responsibilities, and rewards of promotion, because we want our team members to get better (remember, as individuals get better, the quality of the company goes up.)  

Another aspect of team transparency is the explicit support of anyone asking any question of anyone else. Motivated by my previous time at Google (as an intern) and Niara (as an FTE), we hold all-hands meetings where everyone is invited and encouraged to speak up. I personally work on facilitating conversations, check-ins, and clarifications, especially across teams.

There is once again a pragmatic motivation for myself and the leadership team to actively work on team transparency, and that is to cut down on rumors, worry, and doubt. When team members know where the company is headed, as well as what they can do as individuals to grow their skill sets and careers, they are truly able to focus on their work, and therefore the success of the company. 

It’s true that this approach is completely predicated on trust in your team members, in your leadership team, and in your direct (and indirect) reports. Not everyone thrives, or is even able to work in an environment with this heavy requirement. However, the longer a particular culture (toxic or otherwise) persists, the harder it is to change or upset it. So: start as you mean to go on. Institute the company culture you want through explicit policy and smart early hires, even though it will mean some concrete effort at the outset, and your future team members will find that the path of least resistance is to contribute to, rather than push against the establishment.

Wielding Your Superpower

The result is that the employees of Kleeen Software truly do “own” different elements of the company decision making process. In practice, this means a two-step decision-making process. First is the team perspective: most decisions get reviewed by someone else, anyone can question a decision, and as differing viewpoints develop, a decision can and should get escalated. This seeks to minimize top-down decision making, and reinforce the Own the Outcome aspect of the approach. Team members are responsible for contributing their opinions and speaking up on entire solutions, not just their own “component” of the pipeline. Engineers give feedback on design directions, designers give feedback on engineering choices, and better solutions are discovered along the way

However, this does not work in practice without the second half: someone must put their foot down in the name of timely progress. This is the superpower perspective: the team member leading each component does get the final call on the decision (e.g., the lead database architect will make the final decision on the data storage stack.) This is necessarily hierarchical, without descending into micromanagement. As CEO, I will not force my engineers to use a particular technology against their better judgment. I am too far removed from using individual technologies to have their superpowers of delving into the intricacies of all the available options. But, as CEO, my own superpowers lie in the direction of determining and defining the problems we are solving. I may place constraints on the viability of technological choices for exogenous reasons. I may say, “we have to ship this feature in 1 week so you must make a decision and move on,” (though I have always promised to revisit when addressing our technical debt backlog). I may even ask if my team has heard of a particular technology- and my engineers should respond by wielding their superpower and educating me on why the suggestion is, or is not, something reasonable for us to consider using (frequently the latter, of course!) 

And all of this process returns to Team Transparency, as we try to make these decision points explicitly clear. And when someone “uses their super power,” we ask them to make that explicit – and justify it. Decision making should be able to be justified; time, money, features, etc. This minimizes perception that decision making is arbitrary, ensures that no one can abdicate their own role in the decision making process, which results in a higher quality of decisions and outcomes.

Final Thoughts

I will not claim with certainty that these approaches can scale to a large company, or be fully achievable at a company spanning multiple countries. Even though Kleeen Software is comprised primarily of remote teams, we are still all within at most a couple time zones of each other. The cultural alignments across these teams have undoubtedly contributed to our success. However, we also took the time at the onset of the company to discuss and develop the three pillars (Owning the Outcome, Team Transparency, Wielding Your Superpower). We stress the “ownership” of the company to each team member because we have seen how it makes them stronger contributors, who work harder to push Kleeen Software to realize its full potential. We put team morale and collaboration on the weekly staff meeting agenda to make sure that we are following these approaches to keep our staff motivated and dedicated to the product roadmap. In short, we, the Kleeen Software leadership team, have made these decisions and put forth this effort to consider and actively pursue every possible angle that will make our company more successful.

Cover Image by KAL VISUALS on Unsplash

email

Details Matter | Email Avatars and Signatures

Everyone knows “details matter,” but time and again product’s design and workflows are steamrolled in the name of deadlines. But not taking the time to workout the details can dramatically shift how a product is used and the data perceived. From choosing the right visualization, to the right font – details matter.

We were recently informed that a paper submitted to ACM Transactions on
Interactive Intelligent Systems (TIIS) was accepted for publication (due out in 2020). Our paper was a study on some of the smallest details in email products: Avatars and Signatures. And what we found, was quite surprising! We have included the introduction from our forthcoming journal paper here.

In many environments, but especially within a work context, employees are expected to use email with a tacitly agreed-upon degree of professionalism and work appropriateness. While the specifics of these requirements have been informally codified as following good grammar, and avoiding inappropriate topics (e.g., politics or sex), aspects of presentation (design decisions) in emails have not been formally addressed or studied.

The primary contribution of this work is a study of how email author controlled presentation choices impact reader perceptions within a professional environment. While there are many dimensions that email authors have at their disposal (e.g. semantic content/grammar [1], typographic changes, etc), this paper focuses on the two unique dimensions that authors can manipulate to present and identify themselves; Signature (the text after the sender signs off), and Profile Avatar (which appears next to the sender’s name in the client). These are initial and lasting impressions by authors – that augment how senders present themselves.

In a non-email context, initial and non-performance impressions have been shown to directly color all subsequent performance behavior in what was termed the Halo Effect [2]. In other words, if Colleague A initially thinks well of Colleague B, then good work B does looks fantastic to A, and bad work is easily overlooked. With the converse being true as well: if Colleague A initially thinks poorly of Colleague B, then bad work B does looks horrible to A, and good work is easily overlooked as pure luck or an anomaly. These impressions can take a long time to overcome, biasing future actions for an extended period of time[3, 4]. Further, in researching the Halo Effect, these biasing impressions are driven by non-performance, non-content features such as physical appearance[5, 6]. This parallels Signature or Profile Avatar, initial non-content features of a sender. In a more theoretical way, this work seeks to determine if there may be a theoretical parallel between the Halo Effect and email presentation choices.

To measure readers’ subconscious reactions to these presentation variations, 900 unique Mechanical Turkers were asked to complete a personality test about the sender of an email (while controlling the emails content). To quantify the recipients’ view of the sender, the Big Five Inventory (BFI) was used, a mainstream conceptualization of personality [7], measuring five personality (or perceived personality[8, 9]) dimensions: Extraversion, Agreeableness, Conscientiousness, Neuroticism and Openness. Four indicator questions were added relating to style to examine how recipients view the quality of the email.

Results show that these self-presentation design dimensions impact the perception of both the sender’s personality and the mail’s quality. Further, while variations can positively impact the recipient’s view of the sender, these variations often have negative impact. This implies that many of these seemingly innocuous presentation changes should be made that consider the context of the receiver.

To briefly summarize the findings; Signatures should be as simple as possible (if present at all), and including social media contact information can have some positive impact on the recipient’s perception. Profile Avatars allow users to have some flexibility in presenting themselves as being serious, or slightly light-hearted, but having no Profile Avatar is ideal. However, if the absence of a Profile Avatar results in a placeholder image (as in many email clients), this will generally have a negative impact, and therefore users should choose a Profile Avatar over having a default place-holder image. Of particular note are that decisions such as including Signatures about emails being written on a phone, or having Profile Avatars of babies, have a very strong negative impacts.

[1] E. Gilbert, Phrases that signal workplace hierarchy, in: CSCW, ACM Request Permissions, 2012.
[2] E. L. Thorndike, A constant error in psychological ratings, Journal of applied psychology 4 (1) (1920) 25–29.
[3] D. McRaney, You Are Now Less Dumb: How to Conquer Mob Mentality, How to Buy Happiness, and All the OtherWays to Ou tsmart Yourself, Penguin, 2013.
[4] P. Rosenzweig, The halo effect:… and the eight other business delusions that deceive managers, Simon and Schuster, 2014.
[5] T. J. Wade, C. DiMaria, Weight halo effects: Individual differences in perceived life success as a function of women’s race and weight, Sex Roles 48 (9-10) (2003) 461–465.
[6] K. Dion, E. Berscheid, E.Walster, What is beautiful is good., Journal of personality and social psychology 24 (3) (1972) 285.
[7] O. P. John, L. P. Naumann, C. J. Soto, Paradigm shift to the integrative big five trait taxonomy, Handbook of personality: Theory and research 3 (2008) 114–158.
[8] J. J. Connolly, E. J. Kavanagh, C. Viswesvaran, The convergent validity between self and observer ratings of personality: A meta-analytic review, InternationalJournal of Selection and Assessment 15 (1) (2007) 110–117.
[9] K. Fong, R. A. Mar, What does my avatar say about me? inferring personality from avatars, Personality and Social Psychology Bulletin 41 (2) (2015) 237–249.

Cover Image by Davide Baraldi on Unsplash

startingAgile

Starting with Agile on new teams

First of all, let’s face it, your team it’s not ready for Agile. It’s safe to assume that not all team members are: cross-functional, self-organizing, and problem solvers, that can continuously cope with change, and enhance the process, as the project evolves, right? And that Agile it’s’ not some recipe that you can follow and it will lead you to success.

Let’s take this slowly, and let’s review some of the aspects that you’ll need to ponder if you were to embark with your team on an Agile journey.

First, a couple of questions to ask:

What is that Agile is trying to achieve?

And,

What is that I want to achieve by practicing Agile?

While I can help you with the first question, I can only hope that your answer to the other one isn’t — to deliver faster. To do that, you’ll need to go through some organizational changes around management, planning, and strategy, that doesn’t necessarily relate to software development.

From the Agile manifesto, we can read at its start:

We are uncovering better ways of developing
software by doing it and helping others do it.

What I love the most is that they don’t claim to have found, instead, they say that they are -uncovering better ways, which means that Agile needs to be adapted to every team and organization and that it needs to keep evolving, which leads little to no room for religious practices like — that’s not Agile, or that’s not Scrum.

Besides the general ceremonies that the Scrum framework suggest, I would strongly recommend you start with the following:

Story Points

Please make sure that every team member understands how to estimate using points; three factors must be taken into account:

  • complexity
  • effort
  • uncertainty

Also, the story points do not correlate to days in any manner.

Sprint length

From experience, I’ve found that one-week sprints work the best, here are some of the reasons:

– To correlate story points into days comes somewhat natural in a two-week sprint, where the Fibonacci sequence (1,2,3,5,8,13) tends to fall naturally. However, weekly sprints make it harder to do so.

– Pivoting it’s easier, even if the sprint just started you are always allowed to say — we’ll start working on it by next week.

– Smaller sprints will force you to make smaller user stories, which means that stories are more specific, easier to estimate, and clear for everyone.

Sprint Goal (Purpose)

Success on any major scale requires you to accept responsibility… in the final analysis, the one quality that all successful people have… is the ability to take on responsibility. — Michael Korda

Responsibility comes to each member when they commit to deliver at each sprint. The purpose drives us towards the vision; it’s what moves us from the present to the future. Make sure that every sprint has its purpose that is one that everybody understands and agrees.

As a conclusion starting with new Agile teams should be a joyful and transparent process, regardless of the experience of each team member, we are talking about setting up a unique group of people, that will require leadership and guidance to excel at their roles and responsibilities, this by no means, can be seen as a cookie-cutter process or framework, Agile differs from workgroups due to its principles, by being created by common purpose rather than authority, with shared leadership that needs to be grown and developed.

Cover Photo by Sarah Cervantes on Unsplash

Load More