Here at Loggly, we know logs are special. Why are they special? Because we know the specifics of the data that makes them special to you.
Logs are different. Logs are personal. Almost all monitoring tools and platforms reach into your systems and pull out impersonal data. Data such as CPU load, free disk space, and transaction times, are often critical but is not yours. But logs allow your system to reach out in a way only your system can.
I know, as a developer, the first time I saw the code I wrote, and the systems I built, send its logs to Loggly, it was like that system had extended its reach and was now a little bit resident on the Loggly platform too.
Many developers, when they first see their logs messages up in Loggly, feel a sense of excitement and pride. After all, they wrote each one of those messages. It's like watching the initial pulse of the system, as it comes to life.
So sign up with Loggly and send your logs to us. Then enjoy seeing your system reach out all the while letting us do all the hard work.
At Loggly we bring life to your system... by bringing your system to life.
| Leave a Comment
A few days ago an editor from CIO.com asked Loggly to provide two tips on hiring/retaining engineering talent for a future article. “Sure -- happy to help”, I replied. I then mentally outlined how we build and keep our highly sought after development team happy (out of
24 employees 25 employees, another just signed, 22 of our hires write code). The standard Silicon Valley startup checklist popped up:
- Competitive salary, equity packages, etc
- Open vacation, flex hours, etc
- Catered lunches, snack bars, and top-shelf beverages
- Latest-greatest technology and development environments
But to really attract, build and keep top talent you need more. You need the ability to:
- Work on a product that thrives on big data for a formidable challenge ($100b market, per IDC)
- Solve a true market created big problem, that matters... and one that people pay for
- Make a difference, and be recognized for it.
The last line was the true angle to build off and two examples quickly came to mind: how we target our hires and welcome them, and how we keep engineers aligned and motivated on the problem their code will solve, essentially the direct connection to our customer's log management challenges.
I’ll skip the tip I sent over on our on-boarding process, maybe I shouldn’t ever share it ;) but the second tip was about sending our developers to work a half-day in at the Loggly booth at a tradeshow. After reviewing our article suggestions, I heard back from the CIO.com editor:
"Thanks for the tips... Unfortunately, they weren't quite right for the article.
(Every IT guy I have ever known has DREADED being asked to man the booth or attend trade shows and conferences)."
I was shocked... and then I wasn’t. It only confirmed what I’ve already known, we are not our father's IT company. We aren’t:
- Building an old-school IT product (legacy deployment cycles aimed at non-cloud savvy companies run by stiff CIOs)
- Selling an old-school IT product (hundreds of end-users who are also our buyers sign up WEEKLY)
- Selling into the CIO and expecting our technology to be forced down (vs adopted, loved and shared)
- Looking, hiring or retaining old school ‘Dilbertized IT guy' engineering talent who hides at the mere thought of customer interaction
So why would I expect CIO.com to immediately see the value of the tips? I shouldn’t. At Loggly, we are different by design. We've developed a 100% cloud-based service loved and used by over 2,500 of the industries leading cloud-centric brands (AirBnb, Adroll, Sony, EA, GrubHub, Heroku) and we have a fun mascot named Hoover people love and want to interact with (here's Loggly's Hoover vs. the @Spotify shark at #Pycon).
This translates directly into my role driving Marketing and Revenue where I look for innovative developers and SysOps people (guys and gals) who are looking to simplify log management (we can help you!! Free 30 day trial of Loggly
), and it flows directly into who we hire, how we retain talent and how we motivate our teams.
Heading into PyCon
, I had the envious Marketing challenge of selecting booth staff after getting numerous emails, Skypes and SMS from engineers asking if they could attend and work the booth
, a great problem to have. As it turned out, our CTO and two lead developers attended for a half-day and it served to energize them about:
- The billion dollar opportunity we are solving in log management (the booth was busy!)
- The ability to hear from customers and prospects exactly what they want in a product and how they are using it (the good and the bad)
- The way they can make a difference with their efforts to improve and continually optimize the product (our customers enjoyed the face-to-face conversations)
Our engineers arrived at back at work on Monday really stoked to share their booth experience, their conversations, and on how they can make the next killer version of cloud-based log management to solve the challenges of our next 2,500+ customers.
So while the tip wasn’t good enough for CIO.com, I’ll take that as badge of honor. We are doing something different, things are going great
and people are excited to play a role.
If you aren't the luddite "IT-guy" and a person looking for a change, let's chat! Or please send a peer our way.
| Leave a Comment
Here at Loggly we make great use of open-source software to avoid remanufacturing wheels. It allows us to employ the latest technologies to build exciting, interesting and large-scale systems quickly -- all without worrying that the building blocks will forever remain a black-box. But working with open-source at such an accelerated pace requires its own set of skills. Here are five key lessons learned from our Engineering team -- that might help you.
1. Assume at your own risk
It's easy to assume that the project developers implemented a certain feature in a certain way, and before you know it that assumption becomes taken for granted. Without realizing it, one is building a system on that assumption. This is insidious and one needs to deliberately check the source and test the system before making any major decisions. Time is short at a small company like ours, but it'll be even shorter if you have to re-implement due to an invalid assumption.
Also, never make customer adoption assumptions in a vacuum, the Steve Jobs effect is awesome but rare. Leverage your customer community for responsive feedback.
2. Community support
Look for tools that can help debug, deploy, and manage the technology. If the tools ecosystem is healthy, then the open-source technology is probably vibrant too. Your sysadmins will thank you too, if they don't have to build everything from scratch. And take the pulse of the community. Join the mailing lists. Do the same questions come up over and over again? And do they get answered?
3. The project's strength of vision
We at Loggly always feel better when the direction of the project aligns closely with the problems we're trying to solve. For example, ZeroMQ is a technology with a clear purpose. Problems arise when this clear direction is missing, because the items high on your list may not be high on the project maintainers' list.
4. Gambling on the "Killer Feature"
Sometimes you just have to take a gamble because of a "killer feature". ZeroMQ is a good example, a technology we chose during its early days. Data-driven experiments showed that it was an order of magnitude faster and less resource intensive than the alternatives, but it was a very young project at the time we chose it. But we chose it because of its performance, even though it it was immature -- but it did have a strong vision.
5. When there are multiple contenders, choose the one that is weak on the things you want to be strong on, and strong on the things you'd rather be weak on.
This is my favorite insight from the Loggly Engineering team -- it's comparitive advantage applied to software design. Engineering is about trade-offs. Imagine you need to choose from 2 competing technologies. One has great algorithm support, but is weaker when it comes to IO. The other technology is not as strong when it comes to algorithms, but has superb IO support. So if you're planning to design and implement novel algorithms, you're going to become strong in algorithms -- in fact you want to be strong in that area. So choose the system with the strong IO support, and focus on the algorithms yourself.
Hopefully these pointers help you when you next come to evaluating an open-source technology. We believe it shows in the adoption of our world's most popular cloud-based log management service.
Even better, why not join us and help choose the technology for Loggly's next generation systems?
| Leave a Comment