I need to take the lead in being responsible for the development of WithKittens.com. I not only have to do the work, but also have to keep track of all the variables that can stop the work from happening. I'm a specialist in developing the custom Kittens API, but I also have to understand how the whole stack comes together. Frequently, I'm the first person contacted when a problem comes up, and may be the only one who knows how to solve that problem.

I have the experience to know when the project is moving in the right direction, and what issues we need to watch out for. I want to see the code improve as it develops, while still supporting the requirements of the project. My goal is to make the product adhere to the highest practical technical standards. I got my title because I have years of experience, including work on projects that went far off the rails, and I never want to see that happen again.

The perfect day for me is uninterrupted time to work on my part of the code. I usually know what I need to do next, and I don't want to be interrupted. I don't want surprises. I got to this point in my career because I have the talent and the knowledge to do the work and do it right. I like to work with other people who can bounce ideas around and discuss technical issues at the same level that I can. But, while not wanting to sound like a curmudgeon, I really just want everyone to get out of my way and let me do my job.

Because I'm one of the most experienced members of the team, I'm often the first one asked when problems come up around the Kittens API. My experience with this part of the system means that I'm sometimes the only one who can find answers to these problems. I don't mind showing people how to do something if they're interested, but usually the ones asking the questions don't understand things as well as I do, so I may need to explain the same thing over and over. Being interrupted in the middle of working on something difficult, or being asked to go to a meeting where my expertise isn't actually required, are two of my leading frustrations.

I've been on multiple teams that have claimed to be following scrum. I don't know what they were doing, but I hope real scrum isn't like that. We always seemed to have dozens of meetings that never ended, and requirements that changed all the time. They threw around words like "transparency" when they really meant "micro-management". I never had the opportunity to focus on the long-term objectives of the project before things changed again. Instead, we just got into endless debates about the process that interfered with getting the work done. You could say I'm pretty skeptical about scrum.

I was brought in to do performance optimizations on the front end, but the way it's worked out, I seem to do a lot of styling and layout fixes for WithKittens.com's membership and admin pages. I've kind of become the one they call when there's a bug that needs to be fixed, and nobody else wants to work on it. I can usually figure it out, even if it takes me a little bit longer than it might've taken some of the more seasoned people. I guess that makes sense. This is only my second job, and I've only been here about six months. I'm still learning.

I got into engineering because I love working with computers. I was really excited when they gave me the opportunity to work on WithKittens.com, because it's a very popular site. It's the sort of thing that will look good on my resume. I'd like to do some projects that I can be proud of. And really, I want to learn from the other engineers. Sometimes I'm amazed at how much talent there is around here, and I'm just wondering when I'm going to feel like I have the same skill set as these other people.

Most days start with finishing up the things I was doing the day before. I usually have a pretty long list of tasks that need to get done. They pile a lot onto my plate, and I just go through the list and try to do one at a time until I'm finished. On a good day, I can finish four or five tasks and get them into review before everyone else goes home. On a bad day, I might find myself grinding on the same task for hours into the evening. But even those are good days in a way. Days like that give me an opportunity to learn some more about the code behind WithKittens.com. All in all, I like what I'm doing.

I think my biggest frustration is that I feel like an imposter. Sometimes I can't believe they gave me this job. The people I work with seem so much more experienced, and they have such fast answers to questions that I wouldn't have any idea how to answer. I don't have a lot of experience working at different companies, and as far as I can tell, most of the people who work here are pretty satisfied with the work, so I don't complain about the long hours. I just wish I had an opportunity to do more than the small tasks they assign me. Sometimes it feels as if I'm trapped in a CSS ghetto, when I know I could do more if given the opportunity.

I've read a little bit about scrum, and I'm curious what it's going to feel like when we start doing it. Right now we have a routine that works. I know what I'm expected to do, and as long as I get my work done, everything goes pretty smoothly. I hear that in scrum there's a lot of talking. I'm not a big talker. I tend to like to sit quietly and get my work done, and I don't feel as if I know enough to have a lot of opinions worth sharing. I'm a little bit concerned that scrum is going to put a spotlight on me, and force me out of my shell more than I'm comfortable with.

I started here at WithKittens.com as a senior engineer. I was promoted to manager here after the last manager left. As the manager, I'm responsible for making sure that my team has everything they need, and that everybody is working on what they should be working on. I report up to senior management, and have to justify the budget for the team, and provide reports that demonstrate that we're doing what the company needs us to be doing. Sometimes I have to play referee, and sometimes I have to make some tough decisions. That goes with the job. It's not as much fun as being an engineer, but it seemed like a good opportunity for advancement at the time.

I really like my team. I hired about half of them, and the others were mostly working here when I got here. I like to think that what I do, I do for them. My job is to keep everybody engaged, employed, and content. At the same time, I have some strong opinions about how the code should evolve, and I like to make sure my influence is in there. At heart, I'm an engineer, and I like working with talented engineers.

My best days are the quietest ones. As the manager, I'm often called on to solve problems to do with organizational, administrative, and even sometimes human resource issues. I enjoy the opportunity to do one-on-one meetings with my team members, and I try to schedule these around the workload. Most days start and end by looking at an overview of what everybody on the team is working on, so I can make sure the work is being distributed evenly. Sometimes that's both an art and a science.

As the manager, I'm responsible for all staffing and budget decisions in the team. I decide how the budget gets spent, and I have to make sure enough budget is provided to keep the team supplied with everything they need to do their jobs. Sometimes it feels as if I spend half my time justifying the budget to senior management, and the other half explaining why we don't have enough budget to do something everybody knows we should be doing. The responsibilities of management also involve dealing with interpersonal issues. Human resources can publish all the memos they like, but there's no manual for figuring out how to get people to work together peacefully.

The way I keep hearing scrum described, they talk about self-managing teams. That concerns me a little bit. After all, my role on the team is managing. I don't like to think of some new process coming in and bypassing my authority. I don't have a clear picture of what a manager does in scrum. A lot of the things I've read talk about scrum Masters, product owners, and team members. They don't talk about how the manager fits in.

There's a lot of technical complexity behind a site like WithKittens.com. As a quality assurance engineer, I need to be aware of all the site's specifications and test every aspect of the site to make sure nothing breaks as the code evolves. That means building a complex and comprehensive suite of tests whenever there's a new feature, and making sure every one of those tests passes every time the code changes. My job is very detail oriented. I rely on some testing tools that nobody else in the department has any idea how to work. But they don't have to, as long as I'm here.

Sometimes I feel as if I'm motivated by little green dots on my screen. When I run my test suite, and I see that every single test is passing, there's a sense of satisfaction. But it's also very satisfying to find those elusive little bugs that nobody else saw. I try to look at every specification for new product feature, and figure out the edge cases that nobody else is going to test. For example, if a user is supposed to enter a number into a field on a form, I find out what happens if they enter a negative number, or a word, or submit the form without any data. If I'm doing my job well, I'm keeping the engineers on their toes, and making sure they write code that's resilient.

I like it best when I have a well-defined project to test, and I'm building up a set of tests that need to be run. I take the code, I run the tests, and if anything fails I write the report and let the engineers know. It's interesting and challenging work, writing tests that address all of the possible concerns when a new feature is being developed. Having the time to break apart a new feature, work out what the edge cases are, and build a test suite that's very robust and comprehensive makes me feel like I'm doing my job.

As the one who reports when there are problems with the code, sometimes I feel as if I'm the bearer of bad news. My work comes at the end of the process, after the engineer has completed everything. Often I need to get answers from the engineers about how they developed the code in order to test it properly. It's frustrating when they've moved on to the next assignment, and they don't have time to get back to me with the information I need. I also get pressured to do my work very quickly when there's a deadline to be met. That means some bugs I might have caught can get through.

I'm not sure if scrum has anything to do with me. Most of what I read about scrum has to do with how the code gets developed, not how it gets tested. I'm open to the idea of working in a scrum environment, but my role as a QA engineer doesn't translate to the kind of work the rest of the engineers are doing on the team. The QA structure here at WithKittens.com involves me reporting to the manager of QA, not the manager of the engineering team. I'm not sure how I'm going to fit in.

As the product manager for the WithKittens.com site, I work for the Product group, which reports up to the CEO. We're responsible for making sure the services we provide to our customers are the best they can possibly be. I have to balance a lot of concerns, including feature requirements from Sales, promises that the executives make to the board of directors and the investors, as well as practical budgeting and engineering requirements. At the same time, I have to be looking at how the product is evolving, and planning for the next release and the next version. Our site needs to continue to support all of our existing users, while growing to reach new users.

What gets me most excited about my work is the opportunity to build a service that exceeds the expectations of our customers. I'm happy when I get an email from a user who's received superior service from us. But email isn't the only way I find out about that. I love to see our numbers improve over time. We've incorporated a lot of different tracking services into our site, so we can measure where people are getting the most use out of what we provide. Beyond that, one of my favorite responsibilities is user testing, where I can sit down with customers and find out what they like about our service, and where they think we need to improve. Ultimately, it's about providing the best service we possibly can, and I enjoy being a part of that.

A typical day for me goes back and forth between work with the designers on new features, work with clients on expectations, work with executives on feature expectations, and work with the engineers on how those features are being developed. I enjoy the opportunity to see a project from so many perspectives simultaneously, but I have to switch gears frequently, sometimes thinking about what's going to come down the road, and sometimes thinking about what's happening right now. I spend a lot of my time in meetings. When I'm not in a meeting, I'm usually writing reports or specifications based on design, testing, and research.

Have you ever heard the old saying, "The plan is worthless, but planning is invaluable"? Sometimes that describes my life. I can spend weeks building up the perfect set of specifications for the next iteration of WithKittens.com, only to have everything pulled apart by one rejection from engineering due to practicality, or one comment from executives about a feature we never imagined before. Sometimes my job feels like building a ship in a bottle. I have to drive forward my vision of where I need the products to go, but I can't actually touch the pieces. I also have to deal with the fact that my schedule isn't as mission-critical as the dedicated time of a designer or an engineer. As a product manager, I need to make myself available when the resources I have to work with are available, not the other way around.

My biggest concern about scrum is the way it doesn't seem to address deadlines. I live in the real world, and that means sometimes you have to promise something will be delivered on a certain date. Sometimes you have to be very specific about what that thing is going to be. Scrum seems to take deadlines and product specifications pretty loosely, allowing the agile process to define them instead of the other way around. I like the idea that a team following scrum will get better at estimating their time, so that I can get a sense upfront how long something we need will take. I don't like the idea that we may not know for sure what we're going to deliver at a specific time. I know the people I have to deal with, and getting them used to that kind of uncertainty might be difficult.

Design is a discipline that reaches into the very depths of a product. I try to design the product from the inside out, thinking about what users expect, and how we can meet and exceed those expectations. That means I have to think both visually and experientially at the same time. Of course, I'm responsible for the style guide and maintaining visual consistency. But I'm also responsible for making sure there's functional consistency. When users come to WithKittens.com, it's my responsibility to make sure they know what they're supposed to do next. If I'm doing my job right, the designs I provide to the team explain both how users are going to flow through the site, and what their experience is going to look like along the way.

I know I can be a little bit obsessive sometimes, but it gives me a strong sense of satisfaction to move through a site I've designed and feel that there's a holistic consistency to the visuals as well as the flow. I want the work I produce to give users an experience that makes sense, that's enjoyable, and that fulfills the potential of the product. For a site like WithKittens.com, we have a number of design objectives around keeping the user experience playful, inspiring, and humorous. It's important to me that the work I do stays true to those design objectives. I don't mind fighting for what I believe in, especially when I know how many people are going to see this site. I have a responsibility to those people not to let that experience be negative.

I became a designer because I like to invent, create, and innovate. Design is about looking at real-world challenges and coming up with interesting solutions that make sense, and that will delight users. I think my best days are ones when I have the opportunity to be alone and focus on the challenges I see for the next generation of the product. There are so many things I want to fix about the way we have things now, but at the same time my mind is always thinking about what we can deliver next. I work very closely with the product group, brainstorming ideas and coming up with interesting ways to do user testing. I enjoy that kind of work.

For practical reasons, the team sometimes treats me as a production designer. As someone trained with visual tools, I'm often called upon to generate and update assets, frequently at the last minute. This kind of work can be tedious, but I'm the only person skilled enough to do it properly. I've seen what happens when we leave design tasks to engineers. It usually isn't pretty. The most frustrating part is when a new feature needs to be developed quickly—or may already have been built by the engineers without any design—and I have to drop everything to create layouts and assets that fit conceptually with the rest of the product. As often as not, a last-minute feature doesn't make sense conceptually from a design perspective, so this kind of work can be very draining.

I try to stay on top of development techniques, and I've read some things about scrum. I've been wondering how design is supposed to be part of the scrum process, and it never seems to be very clearly spelled out. Some people say that integrating design into a scrum process is best done by carving out a separate design sprint before each development sprint, making the whole process less agile. Other approaches seem to advocate asking the designer to fit in between the cracks in the scrum process, or to become a pseudo engineering resource on the team. None of that sounds very appealing to me. I already feel as if I'm doing too much of my work at the last minute. I don't like the idea that what I do may either slow down the scrum process, or that I might find myself more time pressured by having to fit in with a scrum team.

I provide leadership for the entire company. That can mean a lot of different things. When it comes to engineering, it means providing direction on how the product needs to evolve based on my understanding of the marketplace. It's up to me to inspire the engineering team to create the products we need in order to stay competitive and grow.

Ultimately, if I don't do my job well, nobody in the company has a job. That's a big responsibility, and I take it seriously. I need to make sure the products we're developing satisfy customers and support the bottom line.

Because of my perspective on the marketplace, I get a bird's-eye view of what's happening around us, and what we need to do next. I can't always tell everybody all the factors that go into the decisions I make, but I need people to trust that I know what I'm talking about when I say something needs to happen now. It's hard to build a team around you that can understand this and communicate your message to the people doing the work. It's kind of like building a ship in a bottle sometimes. I can see what I want done, but I can't just reach in there and do it myself with my own hands.

I have to keep track of a lot of moving parts around here. I don't have time to shepherd everybody through the process. That's why I have managers, and that's why I have to step back and let them do their jobs. As far as engineering is concerned, my perfect day is when they deliver something that I was waiting for, and that I know is going to delight our customers.

I've seen a lot of initiatives come and go over the years. Every few years there's a new flavor of management system, with a new set of buzzwords that everybody's talking about. I've read a little bit about scrum, and it seems as if it might add a bit of overhead to the engineering organization. I want to keep my eye on that. Also, everything I hear seems to talk about extra meetings, and I'm sure the engineers aren't going to like that. Our engineering team is one of our most valuable resources, and I don't want to see us doing anything that might upset them.