Brian Sierakowski is the CEO of TeamPassword, a password management and sharing platform for businesses. This week, we had the chance to sit down with Brian to talk about roadblocks in a security-based business, the importance of a clear job description, and why you should try to be a CTO first if you want to be a CEO.
An Inside Look with Codeship is a regular series providing an insider’s perspective on the tech industry. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.
You’re CEO of TeamPassword and you run Client Services at SmartLogic as well. Can you tell me a bit about each of those companies?
TeamPassword started at a startup weekend. I felt like at every company that I'd worked at before, the through line was always being locked out of stuff and spending basically a month of the year being locked out of accounts and not able to do my job. Some of my early jobs were more on the IT side, so the challenge was just getting into servers and logging into routers and all these crazy tools that companies are using. Being locked out of stuff was so frustrating for me, so I'm like, "Well, there's got to be a better way."
There are tools out there that will help you manage your passwords, but we wanted to develop something from the ground up based around sharing. We thought: Let's take it to the concept of organizations and build infrastructure that makes it really easy to manage and share accounts. Developers love signing up for products and love SaaS things, and we do, too.
So you can create a group and share everything. Nobody has to ask what the password for this thing is, or even, “Do we have an account for product X?” And you don't end up with a company that has four different accounts for the same product.
We also noticed that the enterprise-level password management tools out there tend to be pretty heavy duty and difficult to use. We wanted to make something that didn’t require any training or mental bandwidth. I think we still have another year or two of work to get it as simple as we want it. Turns out, it’s a lot of work to make things simple.
[caption id="attachment_2811" align="aligncenter" width="1280"]
Brian speaking at a conference in 2013[/caption]
Tell me about your roles in each of those companies. What's taking the majority of your time?
There’s super-duper, heavy overlap in so many ways. At SmartLogic, my responsibilities are to talk to companies and help them solve their problems. We talk about development processes, sales and marketing, and that kind of stuff. So at SmartLogic, we are an ideal customer for TeamPassword, and the people that we're talking to are ideal customers for TeamPassword.
My work at TeamPassword allows me to be a really good consultant to the companies that come to SmartLogic that are asking for tech help.
I feel like, as a CEO, my drive is to be the manager of all aspects of the company; and I'm finding now, as we're starting to grow a bit, that having me involved in everything is not optimal. For example, one of the first jobs I’ll be removing myself from is “Developer.” I still enjoy writing code, a lot, but I can totally make a mess compared to the standard we have set now.
Something I really like doing is running support. It’s good to be on the front line when people are having problems. I think it’s a very healthy activity to do as a CEO, talking to your most frustrated customers.
The other thing that takes up the rest of my time is how to get a hold of our marketing presence. What’s a good customer, what’s not a good customer, and how to get more of the former and less of the latter. It’s about figuring out the strategy and tactics, then trying things and running experiments.
What are the most surprising/unexpected roadblocks you’ve encountered trying to solve these problems?
The solution we compete the most against, still, even today, is the spreadsheet. That one spreadsheet with all your passwords. You know, spreadsheets are a pretty good piece of technology. Spreadsheets are a good product, but they’re not meant for everything. It’s always out of date, and you have to go out of your way to get to it. So we have a browser extension so you can fill stuff in. Then when somebody leaves, they have the spreadsheet. Have they saved it somewhere?
I feel like we’re in a really great place now with our code standards, but initially there was no bar to meet for building elegant code. I think we got away from that pretty early, thank goodness, but there are still some lines of code from, like, 2013, that I’ll just look at and be like, “Man, this works, but that was just the weirdest possible way to go about solving this problem.”
[caption id="attachment_2812" align="aligncenter" width="797"]
Participating in a startup weekend[/caption]
What’s the biggest challenge you’re facing right now, either at TeamPassword or SmartLogic?
The nature of our product is such that we're storing some pretty sensitive stuff: your passwords, you know, like your bank password and your credit card passwords and your code repository passwords. We take that super-duper seriously. No one at TeamPassword can ever see any of your passwords. Everything is done with private key encryption such that it's kept a secret from us.
As a result, there are problems where I can only provide tools to the customer so they can correct issues on their own. I can't just jump in and say, "Let me handle that for you." But that's what I'd prefer: "Let me handle that problem for you."
If we were running anything that didn't have to be host-proof, then it would be so much easier to write server-side tools or even admin-side tools that we could go in and fix stuff for people. I want people to write in with a problem, and when I write back, I say, “Okay, it’s all fixed.”
Three years from now, I’d love to have people on the customer-success side that aren’t even waiting for inbound requests. Just reaching out — "Hey, how are things going?" "Are things working to your expectations?" "Can I give you a demo of this thing?" "I see that you have zero groups created. Could I show you how groups work?" I'd be totally fine with paying people to do that all day long. That is maybe be less scalable than a knowledge base, but I think that it would make our customers a lot more successful and happier.
Is there anything that makes the development environment/team/culture at TeamPassword different from other places you’ve been?
That’s a really good question. I think sometimes the things that your culture is doing really well, you don’t think about, because you’re doing it really well. There’s a lot of transparency, both at TeamPassword and SmartLogic. I feel like everybody’s very clear, and everyone’s very aligned with the goal: “Let’s do as much extra work as we need to make things great for our customers.” Nobody’s going to cut this corner to make an extra forty-five bucks.
Also, nobody exudes the presence that they’re an expert. And I think, as the CEO, that starts with me and my attitude, because what do I know about anything?
Of course, it’s not the case that I never get frustrated. I’ll be really excited about something — “Oh, I just talked to this customer, and they have this problem, and I think we could fix that problem so well, and I think everybody's going to pay an extra $1,000 a month to use this new thing.” It’s helpful to have somebody else be like, "Well, cool. Maybe you should talk to two other customers before we redirect the company. And we have these other things that we've already got validation on that we want to get through, and we've already communicated with people that this stuff is coming up. So, that would be really bad if we missed out on these things.”
But, yeah, I feel like everybody actually actively asks for feedback. And that’s important on the development side as well. I think very few people know how to give an effective peer review. I think the short tip there is just comment on everything, even if it's just like, "Oh, this is a cool approach," or "What does this method do? I've never seen this Ruby method before." Or, "Is this a potential security concern?"
Giving good feedback, well-formatted feedback, is a super skill. And I feel like that is led by example; I feel like the first time that I get some criticism and just fly off the handle, we’re screwed.
How do you handle hiring? What are you looking for in devs for your teams?
Maybe this is basic. But I think a key is to have really well-thought-out job descriptions. What do we expect this person to do, do we expect this person to get critiques, what outcomes are we expecting? We need to figure that out. I want someone to know they’re being measured and what sort of metrics they’re measuring against and making sure that those are within their realm of influence.
I’m a fan of putting the KPIs in the job description. Letting people know exactly how the success of a role is going to be measured. I’ve been told, "Well, that's kind of heavy for a job description. Maybe we should have a conversation about that." But, regardless, you should know that if I'm hiring you for this role, this is how we're going to tell whether or not you're successful.
And if you don't feel comfortable being measured on that, obviously we can talk about that if you still want to apply for the job. But also maybe it's not a good fit.
Remote officing is enjoying a heyday right now, but there are polarizing views on it. Your thoughts?
I'm definitely not anti-remote, but you totally have to set up systems. I think the issues with doing the remote thing is that you can't have an inequality of information. You can't have communications happening IRL, and then somebody remote not getting the same information.
I think there're a lot of really good tools. Slack is obviously a powerhouse in keeping people looped in. And then basically all the tools that we use are web tools, so Pivotal Tracker and Trello for non-development-related stuff and all that stuff. So, yeah, I think it's just important that you have those systems in place to do that. From the beginning, and making sure that everybody’s using them. If three people are joining a call, and two are in one place and the other is remote, all three need to be on Skype. That way everybody’s on the same playing field. Also it cuts out that weird background noise. The differences are subtle and felt very quickly.
One other tool that that’s pretty critical in having a remote management team is ProfitWell. It’s easy not to talk about the specifics of the health of the business in regular meetings, but, if everyone’s looking at things like growth, MRR, churn, cash flow, etc., it’s a tool that makes it really hard to be in the dark, and that’s a good thing.
How are you mentoring and growing your team’s skills?
Pair programming is huge. You have to sort of jump through some extra hoops to make that work remotely, but I think that is pretty important as well. The amount of time that you spend struggling on one thing gets reduced because two people are more knowledgeable than one, you know?
Let’s say you notice a young person is hungry to be a CEO someday. What advice do you have for them?
Oh, man. The answer to this changes probably every two years. And the state I’m in right now… if you want to be a CEO of your own company… let’s say this: Being a CEO of a company sort of doesn’t mean anything.
So I’d ask them, "Well, what are you trying to do? Do you just want to be a decision maker? Or do you want to be popular? Or do you want to put ‘CEO’ in your Twitter profile?”
And if they say, “I want to change the world!” and we say, “Great! Yay!” Then you work within another startup. Get a job at a company that’s in that growth stage, and just watch. Get in at the point where they’ve got some process established around all the key areas, like sales and marketing and product and customer research. See how they’re doing those things -- you’ll learn so much.
If you want to build a product company, learn how to write code and get to the point where you can at least be a senior dev at another company. Best case, get to where you can be a CTO somewhere else. You are going to bang your head into the wall for, like, a year or more. But nobody will be able to mislead you with code you can’t understand. You’ll have an instinctive knowledge for how difficult things should be and how to manage a process and so on.
For example, if a customer asks me a product question, I can say, "Well, here's exactly how it works. How far down do you want to go? This is exactly, line by line, how it works." That builds a great amount of confidence in me. Any extra boost that you can get, I think, is a good thing.
Brian will be at SAASFest on Wednesday, Dec. 9; he's let us know he'd love to meet any readers there!