Home » Archive by category "Wrapping Up"

Very fond farewells

Yesterday was my final day at the old company. Wrapping up and taking care of the details, packing up my stuff, a couple battles with Nerf darts, having both HR and Exidor offically remind me of my non-disclosure/non-compete agreements (really? twice?), turning in my access card, and I departed…

…to a nearby bar where New Kid and I were the erstwhile guests of honor at an informal gathering, where many of our now former coworkers came to wish us well at our respective new positions. Old Company alumni Red and Smiley also showed up, to the warm welcome of all in attendance. Phoenix and Kabob from my team were there, as were Sparky and Cupcake, Cupcake’s team, both the QA guys, and lots and lots of people from other teams. It was fantastic.

From a professional perspective (after all, that’s the focus of this blog) one thing for which I’m very grateful is that I’ve developed these great relationships with Red, Sparky, Smiley and Cupcake, each of whom has warmly offered to be a resource for advice, counsel and ideas moving forward. And as Cupcake is a lead whose soft skills I greatly respect, and the other three all serve in the same kind of management/technical direction role I’m about to enter, I know their support will be invaluable in the days to come.

From a personal perspective, I’m very glad to have formed valuable friendships with everyone in the development group. Parting company with great coworkers who are great people is a very difficult thing for me to do.

But this is also an important point for me to remember: The team that I build going forward can be staffed with the most technically talented people in the state, but if they’re not people that I can form strong relationships with, nor people that can form strong relationships with each other, it’s not going to work. At the old company, the hiring process sussed out whether the candidate was a cultural fit as much as a technical fit. We would pass on people who were technically strong but whose personalities weren’t right for the team, and we would be more willing to bring on someone who was technically weaker but a strong cultural fit. In those instances where we hired despite having concerns about cultural fit, we always came to regret it.

So when I start building my team, I need to understand the culture into which I’m bringing them. And though I believe I know intuitively the kind of person I personally get along with, it wouldn’t hurt at all to spend some time thinking about — even writing down — the character and personality traits I want to see in the people with whom I work.


First, a side note: There was massive snowfall yesterday and this morning. The drive to the central office of my new employer is about 40 miles from home. It was orientation, so I felt it important to go anyway. This was a mistake. I came very close to destroying my car and possibly myself via collision with snowplows, and only a well-timed swerve when braking proved impossible kept me from being a snowplow sandwich. It is NOT worth braving dangerous driving weather, even for a very important work meeting.

That said, I did go to the new job, and I did get some orientation. I took notes. Lots of notes.

I got to meet the CEO face to face. He’s a younger guy, five or so years younger than I am, but very ambitious and very likeable. He also doesn’t try to hide it when things aren’t being done as well as they could, and he listens to criticism.

I got to meet a couple other new hires. One’s in IT and seems to be a likely ally, which I will need, as the laptop they assigned me is locked down and I can’t install my own software on it without IT administrator access. This is not an acceptable situation to any self-respecting developer. The new IT person, whom I’ll call 80’s Hair, understood and appreciated this.

The other new hire is the BA-slash-PM-slash-QA expert. She’s going to be wearing three hats, which I suppose is tenable for now, but that role needs to be broken apart. She and I are working on building a good rapport, as we’ll be working closely together in the months to come.

It was also “monthly meeting” day, which meant a group lunch. This was a chili cookoff. And me without my special homemade chili. (I’m quite a foodie, I admit.) But the chili I sampled was plenty tasty and I had time to get to meet more of the people in the main office.

But the big thing today was what we term ‘drinking from the fire hose.’ The concept is being flooded with more information than I can possibly absorb at once, and all I can do is try to take in all I can.

This particular firehose was learning about business processes, specifically order fulfillment and customer service. The former is the basic result of the e-commerce sites which I’ll be responsible for; the latter is the basic conduit of feedback from the customers. The OF guy spent about 90 minutes illustrating his process to us. He showed us how it began with the output from the existing e-commerce site, printing out packing slips, distributing them into bins, filling the bins from inventory, bringing them to the packing area, and packing the orders in bubble envelopes or boxes, labeling them and marking them in the e-commerce site as shipped. I learned about the basic pain points, the basic points of failure, how those points are caught, and the time invested in the process of catching them.

On the other end, the customer service manager and workers had much input from their customers, and that information doesn’t seem to have a distinct process for getting back to development to be incorporated into future development requirements. Both the new BA and I are keenly interested in remedying that situation.

After that, I was exhausted and packed up my new work-assigned laptop for home on the (now much better plowed) long road. I was requested by the CTO to call him to go over some stuff. So, I did. I was tired, but CTO and I talked and planned out the next couple weeks. I also confirmed with him what earlier conversations with the CEO and document review made me suspect: The nearly-complete current development of the core website was done without a clear requirements document — which made its development go badly up until now. CTO’s high priority for when he is in town the next two weeks, and therefore my high priority for the next two weeks, is to define those requirements tightly. Once that’s done, BA can develop a test plan, and I can evaluate the current state of the project against those requirements, and identify the difference between the two. From there I can plan out development and estimate a time to completion — and then release.

Once that’s done then CTO and I can ensure that all future development will be done against a clear set of requirements, and a business owner of those requirements.

TL’s First Rule Of Development: Without clearly defined and accepted requirements, there is no effective way to know when development is complete, nor even to know what exactly needs to be developed.

Sure with vague requirements like “Make it work like that thing worked” you can get a decent idea of what you’re trying to develop, but it’ll never be clear, and whoever the business owner is will be able to push scope creep into your process with nigh-impunity — other than crashing your sprints and breaking your deadline commitments.

A gathering

My former project manager, Smiley, hosted a gathering of mostly current and former employees of my company. Sparky, Red, Phoenix, Kabob and Harley were there — Sparky, Phoenix and Kabob being current along with myself; Red, Smiley and Harley being the ex-employees.

The conversations that were had are not mine to detail — what happens at Smiley’s stays at Smiley’s. But for me, the content of the conversations, including my personal detailing of some of the reasons for my departure and my very candid advice to my team going forward, was part of my process of letting go.

One thing I do when I find a place I like to work is bond with people. And where I work now is no exception. And it’s hard to let go. But this gathering (which was coincidental to my departure) was a good opportunity for me to take a step down that process.

I wonder what the new company will bring me — if I’ll find the people I can bond with, if I find something there worth bonding to.

T minus eight days until I can start finding out.

Well, not counting Tuesday, when I take the day off from Old Job and head to New Job orientation.

Passing the baton

At the workplace I’m leaving, the development group is split into two teams: Development and Production Support. I’m the Development lead — meaning I head the team that builds product enhancements and new features. Cupcake is the Production Support lead; his team handles the day-to-day technological help the rest of the business needs in using the central products, maintains the existing code base, troubleshoots production bugs, et cetera.

Now, apart from Cupcake, there’s really one other guy in the group who has the skillset to be the lead of the dev team — New Kid (who is actually the guy with the longest tenure; I’m second). But unfortunately, much to my surprise, New Kid turned in his notice the day before I did. This means Cupcake’s really the only one on the team who’s got the skills and experience to be the lead of either team.

So, assuming Cupcake would be running double duty if Sparky didn’t fill my role himself, I took the time to give Cupcake some tips about handling the personalities of my team. My team has three developers: Phoenix, the most skilled developer; Kabob, who’s a fairly green developer; and Hockey, a UI designer and the junior member of the whole group.

Phoenix is a great developer but he knows he’s a great developer. He also isn’t particularly skilled with interpersonal relations, mostly because he doesn’t seem to value the benefits of such things as diplomacy and communication. He regards them, often, as distractions from doing his job, which he sees as writing code. So I told Cupcake that Phoenix needs to be encouraged to understand the necessity of communication and how it benefits the team, and how using a little tact doesn’t mean he can’t be honest, and that it helps to work more closely with QA (and our QA guy has certainly been frustrated with Phoenix’s brusqueness in the past).

Kabob is a more junior developer and needs more direction. He also doesn’t want to need more direction and feels like he needs to pretend he’s better than he is in order to fit in with a group of largely senior developers. But he’s willing to take direction and when he does, he succeeds. He also has a communication style that creates friction against Sparky’s. Sparky hates being interrupted. Kabob is more stream-of-consciousness and wants to interject his thoughts in the middle of someone else’s conversation. He also really wants to be heard, and doesn’t trust that he will be heard if he waits until the other guy’s done talking to speak. So the friction is obvious. I’ve worked on making their communication go more smoothly (mostly by explicitly stating to both of them the things that cause friction, and playing referee when either Sparky or Kabob starts getting agitated), and encouraged Cupcake to continue to do so.

Hockey is actually not someone I’ve had a lot of time to get to know, but from a management standpoint, he’s been easy. He gets his job done fast and well, he’e easygoing, and he’s self-directed, but asks for assistance when he needs it. Basically,  I didn’t have any suggestions for Cupcake because I never felt like Hockey needed any special management.

At first I felt like I was kinda being mean by telling Cupcake the bad points of Phoenix and Kabob. But then I concluded that, well, no, I’m doing both of them a favor. Because Cupcake is a good guy and naturally has all the soft skills required to be an effective lead (many of which I’m still developing). And he will, with the knowledge I’m giving him, be positioned to help my team continue to succeed at their jobs.

And to me, ensuring the success of each member of my team is the first responsibility of being a lead.

Planning Ahead

Today Sparky invited me out of the office to talk.

Sparky told me that my future boss, the CTO of my new company, called and talked to him about me, to gain Sparky’s insights about me and my strengths and where I could use the most help. Sparky spoke very well of me, of course; he’s good that way. But the conversation between him and me branched out to two important topics: The insights Sparky gained from CTO, and his advice to me as I go forth to, essentially, take on Sparky’s role at my new company.

The first part of the conversation was shorter. CTO is principally concerned with my ability to balance keeping on task with accepting new tasks and scope changes (and Sparky thought my abilities to do such were very strong), and also with my ability to accurately estimate tasks (which I never thought I was very good at, but Sparky seemed to think I’m better than I think). So being good at these two tasks will be important to my success.

The second, much longer part of the conversation was a very welcome discussion of his tips to me for success. And I wish I had taken notes, but I think I remember all the important points. In no particular order, here they are:

  • Never show up at a meeting without a pen and a notebook. Not a notepad; a bound, leather-clad notebook. Take notes about everything, particularly about any commitments I make, or any commitments or assurances made to me. Make it very clear I’m recording everything I can; this helps to create an air of authority and of seriousness, but warns people trying to BS me.
  • Get familiar with the industry. Not just my new company’s business, but in e-commerce and online marketing in general. If the company has a social media presence, get to know about social media, and social media return-on-investment metrics in particular. There are local meetup groups involved in such.
  • Consider a subscription to Safari Books Online — they have lots of reference materials that I’d benefit from reading. It’s 20 bucks a month but can be written off my taxes, and I might be able to convince my new company to expense it.
  • Get familiar with all aspects of the product development life cycle, including things where I’m not the most competent, like project management. Project management may not be what I’m called upon to do, but I should know the details of what a project manager does.
  • Get in sync with CTO. This means, partly, being willing and able to carry his vision to my team and to my peers, but it also means bringing my own ideas to the table that help implement his vision, or even to enhance and improve it.
  • Try to establish a mentoring relationship with CTO. This is a suggestion Sparky gave CTO in their conversation but he impressed it upon me too. CTO has been there and done that, and I will benefit from his experience and expertise.
  • Establish relationships with key people throughout the company. Not necessarily CTO’s peers, but their assistants, the lower level managers, my peers throughout the company. Also establish relationships with my peers. Never eat lunch alone if I can help it. If I’m not eating with the CTO, or peers, I should be eating with my team. Sparky thinks I have a very gregarious personality and this works to my advantage. But, don’t establish these relationships just to gain a career advantage — let it be a happy side effect.
  • Establish a reputation as a serious, knowledgable member of the team who is the go-to guy when it comes to questions about technology. This means my natural tendency to be the company cut-up, cracking jokes and making people laugh, needs to be, well, managed. It’s not that I can’t make jokes any more, but I need to be sure that I’m serious when I need to be serious, when the conversations are important.
  • Learn to manage vendors. Ask them the right questions. Don’t lay all my cards on the table. Give them high level issues and ask them how they can address them. Let them fill in the blanks. Don’t let them craft their responses to promise me pie in the sky to meet all my needs. Ask to see samples. Ask to see documentation. Ask to talk to other customers. Ask for access to their technical people, if applicable. And don’t call them out or create a hostile relationship if it’s not necessary, and ESPECIALLY if I don’t have an alternative to them. If they have a proverbial gun to my head, never let them know it.
  • Learn to manage up. This means establishing a good relationship with CTO, but also to other members of the senior leadership team. It also means setting and managing expectations, and communicating the needs of my team to facilitate meeting the company’s objectives.

Sparky has said I can call on him for advice and counsel in the weeks and months to come. Which is a relief to me. Not only is he the most brilliant developer with whom I’ve ever worked, but he’s a genuinely decent, kind-hearted guy with whom I hope to continue to keep in contact.

I also plan to seek the frequent counsel of Red, who’s about 90 days ahead of me in moving into a similar role. She, too, is a brilliant developer and architect, and I expect her experience growing into her role will give her some important insights that will help me grow into mine. She’s already recommended a book to me — “The First 90 Days” — which I need to find, buy and start reading as soon as I can.

The story so far

Last Friday, I turned in my notice.

I have been given a great new opportunity at a new company. I am being hired on as the team lead.  Only without a team. There’s no team, yet. Among my first tasks will be building the team I’m going to be leading. And then working with the CTO, my new boss, to establish the development environment, methodology, and structure moving forward — both internally and externally.

Needless to say, this is a very exciting opportunity for a guy who’s been a senior developer for years but a lead only for a few months. I’ve been serving since December as the development lead at my current company, since “Red”, the last team lead, departed to a job analogous to the one I’m moving into.

I’ve learned a lot in the last couple months about being a lead; not just the informal mentoring, architecting and collaboration things I’ve been doing for years, but also the formal planning and interaction with the project managers and business leaders, the encouraging my team to look to me for direction and support, and the surprising number of large and small things that come with the job.

Throughout it all, I’ve had the unwavering support of my boss, “Sparky”, the development manager. He’s been fantastic and I’m going to deeply miss working under him. But I’ve seen the frustration he’s been laboring under, the inexplicable, ADD-like business decisions, the rapid increase of bloat in product management, and especially the strongly combative nature of “Exidor”, my company’s CTO, which has pushed so many good people, some of the finest developers with whom I’ve ever worked in my fourteen years in development (including and especially “Red”), out the door in search of greener pastures.

It has been clear for a while that it’s time for me to move on. It’s just serendipity that this opportunity presented itself and that it proved to be so enticing.

So now I begin my journey of wrapping up my current job (and doing right by the people I leave behind) and transitioning to my new one (and doing right by my new company, my future team, and my own career).

I have little doubt I’ll make a lot of mistakes, big and small, along the way. But I’m going to learn from each of them, and also from my successes, to be the best lead I can be.

First comes defining what “the best lead I can be” is. Second comes charting a path to the goal of becoming that lead.